#avr Logs

Jun 04 2020

02:59 AM _abc_: Hi. This is a linux question really but I have my reasons for asking here and not on ##electronics where other subjects are discussed usually.
03:05 AM _abc_: I am doing something with avr and smbus on PC/laptop, and am using the i2c-tools commands for now. Then I will write my own special commands.
03:05 AM _abc_: Looking at manpage i2cdetect(8) from $< I see a strange reference to "corrupt tha Atmel AT24RF08 ... found on Thinkpads"
03:13 AM polprog: Ive seen a message about disabling cetrain module in the kernel because it was running on an (ancient) thinkpad, also related to some flash memory
03:13 AM _abc_: polprog: interesting. Do you have a reference on that? Perhaps later? I'll wait. Am reading stuff meanwhile. Thanks.
03:14 AM polprog: yeah i just found a thread on the lm-sensors narkive
03:14 AM polprog: https://lm-sensors.lm-sensors.narkive.com/K8v9IvtQ/i2c-address-probing-and-at24rf08-corruption
03:14 AM polprog: i dont recall if the thinkpad i was seeing it on was the same issue but probably yes
03:14 AM polprog: """
03:14 AM polprog: Our README.thinkpad document states:
03:14 AM polprog: "'Write Quick 0' is not an actual write and should never generate a
03:14 AM polprog: write operation to an eeprom location."
03:14 AM polprog: This is not exact. It should not generate a write operation to an eeprom
03:14 AM polprog: location, granted. But this *is* an actual write. Quoting the SMBus
03:15 AM polprog: spec:
03:15 AM polprog: "Here, part of the slave address denotes the command ? the R/W# bit. The
03:15 AM polprog: R/W# bit may be used to simply turn a device function on or off, or
03:15 AM polprog: enable/disable a low-power standby mode."
03:15 AM polprog: So it clearly states that any chip is entitled to change its state or
03:15 AM polprog: whatever it pleases when receiving a "quick command". After reading
03:15 AM polprog: this, I cannot blame Atmel for poor hardware design on the AT24RF08
03:15 AM polprog: anymore. What's really poor is our use of the "quick command" IMHO.
03:15 AM polprog: """
03:17 AM polprog: heh, the thread is from 16 years ago
03:18 AM polprog: https://www.thinkwiki.org/wiki/Problem_with_lm-sensors
03:19 AM twnqx: that is the problem with I2C: there's no risk-free way of scanning it
03:41 AM _abc_: polprog: thanks, reading
03:43 AM _abc_: twnqx: i2c scanning is risk-free, smb scanning is not
03:43 AM _abc_: address 0 is reserved in i2c for "all call"
03:44 AM _abc_: smbus is a can of worms resulting from compromises by people who did not want to pay royalties to nxp for smb chips
03:45 AM _abc_: this is one of those cases of penny wise, ound foolish
03:46 AM _abc_: i2c chips which enter write mode on device select byte and do something on that alone do not really exist.
03:46 AM twnqx: ok, that implies that you should not scan an smbus the same way you do scan an i2c bus
03:47 AM _abc_: the i2c standard specifies the 1st address byte is only to select the target device on the bus. address 00 write is possibly unspecified, 00 read is specified as all call. All devices not inhibited send ACK.
03:47 AM _abc_: twnqx: yes, and that is due to bone headed design of smb slave devices where makers assumed the only thing accessing them will be their own drivers.
03:49 AM _abc_: even so, there are no problems with 99% of devices out there because there are only very few bone headed makers. Usually the "we are too large to care about standards" ones. IBM is surprising like that (Thinkpad) there are others. I assume Dell and Compaq and Packard Bell may be among them (historic).
03:51 AM _abc_: Also, i2cdetect does exactly that, scans the designated bus and dumps active device addresses on it. Default scan range is 0x03-0x77. I don't know why not 0x03, there must be a reason for that too.
03:51 AM _abc_: Also for 0x77... need to read smb/i2c specs for clues.
03:51 AM twnqx: well, i've seen a weird set of chips recently, including another atmel eeprom
03:52 AM _abc_: weird how? Also did they claim i2c compat or straight smb only?
03:52 AM twnqx: e.g. one that will react to a set of 8 address, though it case only 256 bytes and presents the same data on all
03:52 AM twnqx: instead of an index reg in larger devices, they'll just use a bank at each address
03:52 AM _abc_: Oh all / many eeproms do that depending on address select settings
03:52 AM twnqx: there is no address select on this one.
03:53 AM _abc_: Even so it will not do anything with just the address byte sent, other than ACK
03:53 AM twnqx: well, it lists a0 to a2 as "not connected" :P
03:53 AM _abc_: Sure. Is that a China part?
03:53 AM twnqx: nah, that's the official data sheet
03:53 AM _abc_: Incomplete address decoding is a thing. Saves 4 gates from 100,000 :)
03:54 AM _abc_: twnqx: official part from whom?
03:54 AM twnqx: microchip 24lc02b-i/sn
03:54 AM twnqx: (formerly atmel)
03:55 AM twnqx: bought via digikey or mouser
03:55 AM _abc_: That is a special purpose one, right? DDR id and such?
03:56 AM twnqx: DDR ID requires address decoding. the address is given by socket wiring
03:58 AM twnqx: luckily i had an i2c bus switch already in place. i needed two of those in one system...
03:58 AM polprog: i wonder if you can run i2c over cat5 wiring..
03:59 AM polprog: differential I2C lol
03:59 AM _abc_: Looked up your part, 24LC02B is high speed '02, has SOT23-5 variant, so the address bits are not bonded out at all as you said, even on soic/dip.
04:00 AM _abc_: Not enough pins on SOT for address decoding. And yes that is a bone headed thing they did there. Probably grandfathered in from ancient 2402
04:00 AM _abc_: 24C02
04:00 AM _abc_: polprog: you can do that but using some sort of "turn" capable driver on SDA at least will be interesting. RS485 driver ic might do it with some logic around it.
04:00 AM twnqx: polprog: would be a challenge, but generally speaking, you'd need differential transceivers, similar to CAN
04:01 AM _abc_: In reality, nobody wants i2c longer than a meter or so in one device. It becomes a nightmare before that. Connectors, hot plugging, power domains etc
04:01 AM _abc_: twnqx: what bus switch are you using?
04:02 AM polprog: i can imagine that..
04:02 AM twnqx: tca9543a
04:02 AM _abc_: It's bad enough smb is wired to VGA and HDMI ports which are hot plugged all the time, causing bus glitches if the buses are not isolated completely.
04:03 AM _abc_: That's what I am dealing with now, VGA port smb. Not amusing at all.
04:03 AM twnqx: basically cpu -> switch (on-board i2c, external port -> switch (right module with eeprom & temp sensors, left module with eeprom and temp sensors))
04:03 AM _abc_: Super able to destroy someone else's config eprom
04:03 AM _abc_: twnqx: why not 1-wire for temp sensors?
04:04 AM twnqx: i needed i2c for my onboard DAC anyway
04:04 AM twnqx: and i have 0 unused pins my µC
04:04 AM _abc_: ok, that is a valid reason, but with so many things on the bus, maybe a larger mcu would have been better?
04:05 AM twnqx: also, i needed separation as i wanted to make a single PCB for right & left and not having to change addresses (3 temp sensors & eeprom per board)
04:09 AM _abc_: No problems with the TCA, right? All works from the box?
04:15 AM twnqx: yeah
04:15 AM _abc_: https://learn.adafruit.com/i2c-addresses/the-list interesting list
04:15 AM _abc_: What is CBUS? What are i2c bus compatible variants? (0x02)
04:15 AM twnqx: there's tons of chips missing from that list
04:15 AM _abc_: yes of course.
07:45 AM [1]MrMobius is now known as MrMobius
07:51 AM aborazmeh_ is now known as aborazmeh
07:51 AM ThatDamnRanga_ is now known as ThatDamnRanga
09:09 AM Smidge204_ is now known as Smidge204
11:01 AM kl1n3 is now known as kline
11:49 AM Steffann is now known as Steffanx
04:20 PM day_ is now known as day
07:05 PM rue__ is now known as rue_mohr
09:31 PM day_ is now known as day
09:52 PM day_ is now known as day
10:07 PM McDonaldsWiFi is now known as PublicWiFi
11:39 PM day_ is now known as day