Electronics > Beginners
I2C on PIC
Maxlor:
--- Quote from: FrankBuss on November 26, 2015, 11:38:55 pm ---
--- Quote from: Maxlor on November 26, 2015, 09:11:20 pm ---clock stretching can happen here, pretty common actually
--- End quote ---
Do you have an example which devices use clock stretching? I've used a number of different I2C chips, like clock expanders, accelerometers, and temperature sensors, and never saw it on the scope.
--- End quote ---
Yup. The pics below show the communication with an NXP PCF8566 LCD controller, you can see that it needs to slow down after a couple of bytes. Then there's the HTU21D temperature sensor which has a blocking mode, i.e. it stretches the clock while taking the measurement (which takes up to 16ms). You can turn it off there though. I encountered another device this year where the ACK took slightly longer than a regular clock cycle, like 12us vs the normal 10us, but can't remember which one it was anymore. I tested a couple of different environment sensors this year, it'll have been one of them.
Edit: Btw, the one place on this damn scope where a tiny font would acutally come in handy (decoder display), they don't use it. Rigol really needs to study usability.
Vodonik:
--- Quote from: FrankBuss on November 26, 2015, 11:38:55 pm ---BTW: in normal mode for your bitbanging code, you shouldn't drive SCL or SDA to 1. Instead set the pin direction to input, if you want 1 and to output (with 0 for the output value), if you want 0.
--- End quote ---
Why is this? I see that can work, but what is wrong with driving SCL and SDA to 1? :-//
Btw. It is currently 22.0 degrees Celsius in my room. :D Managed to get the temperature reading out of the sensor. :)
FrankBuss:
It is just safe programming, because this is how the bus is designed. For example looks like in your initial code you didn't check for the acknowledge bit, where the I2C slave pulls down the SDA line. If you drive it high at the same time, it could damage your chips (not likely, but unecessary high current). Or there might be a glitch in the slave and it pulls down one or both lines low sometimes (as I wrote, this happens in a project where I wrote the firmware for, would be best in this case to reset or power-cycle the slave). And might reduce EMI a bit and needs a little bit less power.
void_error:
--- Quote from: MarkF on November 26, 2015, 01:12:29 am ---May I ask why you want to do this is software? The PIC has hardware I2C and it would perform faster and better.
--- End quote ---
The 16F628A doesn't have a MSSP module so no SPI/I2C.
Anyway, why use a 16F628A for I2C in the first place? It's an obsolete piece of junk :palm:. I suggest using a 16F886 or similar or one of the newer 16F1xxx chips if you have the patience to go through the datasheet although most basic functions are similar to the '628A.
Seriously, bit-banging the I2C bus with a PIC's general purpose I/O's is completely pointless when the are are PICs which have hardware I2C.
As an alternative to going through several pages of datasheet you could just use Microchip's Code Configurator plugin if you're using Mplab X.
Vodonik:
Im using 16F628A because thats the only one I have. :) And Im not able to get another one for a week or so, and I didnt want to sit araound waiting doing nothing, plus this way I get to really get into how I2C really works. :-+
I looked at 16F886, and that one will probably be my next one, and I will use hardware I2C (on my current pic, I dont even have enough program memory to get all the data from the sensor).
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version