I have been wrestling with understanding 7 bit I2C addresses but I think I get it - and wanted someone much more knowledgeable to double check my understanding.
So let’s say your I2C slave device has an address of 0x21 (8-bit Binary 00100001).
In order to make this 7 bits, the leftmost bit (MSB) is taken off. You now have 0100001
Now 0100001 is “shifted” (I don’t know if that’s the right word?) LEFT, leaving a space which I’ll call “X”: 0100001X
Now the read/write bit is appended to the 7-bit number where the X is, making a full byte:
If you WRITE (0) it becomes: 01000010
If you READ (1) it becomes: 01000011
Thank you very much for this much needed help!
-XJ
You have it correct. The Wire library takes care of this bit shifting for you so you just have to specify the slave address (0x21) and when you do a read or write, it does what you describe.
Thank you very much for the quick reply and for letting me know I’m on the right track. I’ll do some learning on “bit shifting” and read up more on the wire library
Thanks I have my project working (just a simple I2C LCD and CO2 sensor) but was bothered I didn’t understand how the address worked….and how you could change the last 3 bits (A0,A1,A2) with jumpers yet the last bit was the R/W bit. That’s what led me to this question and answer.
Just as important is a Logic Analyzer with USB interface. They are available very cheaply on Amazon and there's free software available. The software includes decoders for many different protocols ... I2C, SPI, UART, WS2812, OneWire, etc. With one of these, you can actually see what the signals on the bus are doing.
Or you can pay more for the same thing at Sparkfun.
I got one just to see. I have a "real" logic analyser available to me. Now that is much less important.
I bought another in a different package and installed it permanently on my big bread board prototyping station.
The open source software PulseView out of sigrok works well. I have also been able to use the Saleae software.
It's not quite as convenient as an oscilloscope and there's a bit of a learning curve. But you can spend just ~10 USD and for many purposes have an entirely adequate tool.
I applaud your curiosity, but it is quite true that many ppl live happily having almost no idea of how I2C actually functions beyond the basic concept of handling multiple devices on the bus by their addresses.
I went deeper once and have managed to forget most of what I obvsly can't claim to have learned.
Thank you very much for the info I might pick one of those up from Amazon on my next order. I got a RS485 to USB converter on my last Amazon order to enable me to turn off the automated baseline calibration algorithm on my CO2 sensor, hopefully I’ll get that working this week!
You mentioned these little adapters were not as convenient as a oscilloscope - I have an older 40 MHz analog scope, which works great for some stuff - but it has no storage capability so I doubt that would work for seeing anything other than quick blips of i2C right? Like I wouldn't be able to “freeze” a sequence and see the start, data, acknowledge, stop, and clock pulses right?
And yeah I’ll probably forget all of this, but the nice thing is its usually easier to remember something than start from zero!
When you use an oscilloscope with microprocessors you can do some tricks like arranging for a digital output to be the trigger.
So make a pulse on the trigger and also initiate something you'd like to observe. Make that loop to happen dozens of times a seconds and you'll get the same thing as freezing would show.
And like that.
An oscilloscope with a dual time base is even better. I forget what it's called exactly, but you can trigger a longish set of events, then with the delayed trigger scroll through the data which due to the higher sweep frequency will be enlarged or amplified.
"A intensify by B" shows on the A trace that portion that is being enlarged so to speak on the B trace.
I got my better oscilloscope out of the trash (!) and hunted down a dual time base moduke for it, one of the first things I ever bought online. $40 bucks, told the guy I wouldn't need to return it if it didn't work (he didn't know), a gamble that paid off.
It depends on the problem you're trying to solve. If you're hunting glitches, fighting signal integrity problems (reflections, pulse shape, etc), or similar "analog" debugging, then the scope will work best. But, if you have that stuff under control and are debugging software and trying to communicate with devices, then a logic analyzer with its sophisticated triggering modes and protocol decoders is the way to go ... especially when you need to monitor more than one or two channels.
Gotcha. That’s a good way to break down the uses for the oscilloscope vs logic analyzer… I will definitely pick one of those up. They 100% will be worth it I’m sure. I’m also going to attempt to use the oscilloscope as alto777 suggested.
I do have one issue with a related project that this discussion may already be able to shed light on.
For that project, instead of using an LCD, I chose to do it the hard way and use 5 individual 7 segment LED displays for the 0-10k ppm CO2 sensor using five 74HC595 SRs and used Modulo to break out the individual digits from the sensor. Works great 99% of the time and looks pretty awesome. But occasionally the display goes to the “default” case I coded in….which indicates either a loss of signal from the I2C CO2 sensor, or perhaps a loose breadboard connection (I have plans to move this to perfboard eventually and add in O2 values as well). Learning how to “see” my communications with both the scope and logic analyzer will be invaluable.
If I have issues with the oscilloscope triggering method @alto777 you mind if I comment back here? Or would it be preferable to start an entirely new thread somewhere else?
