Adventures with I2C & Minerva Mk2

[Dave]

EDIT: There is no solution for HTU21D as it will only respond to a specific write at start, so it doesn't respond to a read which is used for detection, and I think it would be foolish to send a write command to every i2c address given the havoc it could cause

If you scan for devices that declare themselves, you can then write and read from the remaining addresses until you find the one with the HTU21D. You can eliminate the addresses that reported devices.

You could use unused PRAM locations to store a list of these addresses, to be checked in your program's init()...

Hope this helps.

[t0nyt]

So for the AT24C256 device :

And the PCF8583 device:

Meaning if A0,A1 and A2 on the NVRAM are all grounded, and A0 on the RTC is grounded - then they are using the same address - which explain the contention you were seeing Tony.

Thanks Pr0f, that’s exactly what I was seeing

[t0nyt]

If you scan for devices that declare themselves, you can then write and read from the remaining addresses until you find the one with the HTU21D. You can eliminate the addresses that reported devices.

That’s a clever idea Dave, will look into implementing it

Many thanks
Tony

[t0nyt]

If you scan for devices that declare themselves, you can then write and read from the remaining addresses until you find the one with the HTU21D. You can eliminate the addresses that reported devices.

That’s a clever idea Dave, will look into implementing it

Many thanks
Tony

Thinking about it the HTU21D has a fixed &40 address so if I just flag whether any other device was detected at &40, and if there was nothing detected I can then safely just send a command to set the address pointer to 0 to see if it’s there

EDIT: I got confused there. I mean send it a write to start a measurement

Many thanks
Tony

[Dave]

If you're writing the code for just yourself, yes. 100% valid.

If you're thinking of sharing the code/info in the future, it's a closing of a door that means rewrites to support other devices that use that address as their default.

You should follow the path that fits with your goals. No pressure. Nobody is going to send their private army of Vengeance Ninjas after you? Isn't that right Susan? ISN'T THAT RIGHT, SUSAN?!

[t0nyt]

If you're writing the code for just yourself, yes. 100% valid.

If you're thinking of sharing the code/info in the future, it's a closing of a door that means rewrites to support other devices that use that address as their default.

You should follow the path that fits with your goals. No pressure. Nobody is going to send their private army of Vengeance Ninjas after you? Isn't that right Susan? ISN'T THAT RIGHT, SUSAN?!

I get what you are saying but as this is the only device known to not respond to a read, and has a single fixed address, and if nothing else is detected at it's address, I can't see why it would be a problem in this case. If turns out there is another device that doesn't respond to a read then writing to it could still cause problems

[XorA]

You don't have to actually read or write anything to detect an i2c device, you just send the address and detect the ACK.

[Pr0f]

So that Humidity and temperature device offers 2 modes - one using clock stretching (the hold commands) and one that doesn't use clock stretching - In the latter - you kick off your command to do the read, but then your program and the I2c bus are free to do other things, you come back at some point and check if your reading is available - if you read and get a NACK on bit 27 rather than an ACK - it's still measuring.

I can't see that the MKII can handle clock stretching - so the no hold commands are the ones to use.

[t0nyt]

You don't have to actually read or write anything to detect an i2c device, you just send the address and detect the ACK.

So, for example, if the device is $50 do you mean send $50 or $A0/$A1 please?

Looking at datasheets they expect to see $A0/$A1 which by definition is a write or read? (except htu21d which completely ignores the read address until its had a write). My head hurts

Thanks
Tony

[NormanDunbar]

You don't have to actually read or write anything to detect an i2c device, you just send the address and detect the ACK.

Exactly. I laid out the pseudo code for a scanner near the start of this thread. There's a scanner "built in" to the Arduino IDE and I've written one in AVR C, plus another in AVR assembly.

All of them send a start, followed by a write address, and wait for an ACK. If they get one, send a stop.

Easy.

Cheers,
Norm.