Open nyh-workshop opened 6 years ago
I was experiencing some similar symptoms with Wire.h last week (working fine with DTWI). I didn't dig into it at the time though, since it was low priority. I may dig again soon.
Thanks Majenko for helping out. Alright to drop a message here once it's done, so that I can update the Chipkit core and use the Wire libraries? Thanks.
Hello Majenko:
Chipkit version: 2.0.3 Board: Custom with PIC32MZ2048EFH064
I have written a small NES mini controller (I2C) driver for the Arduino, and testing it on the same Chipkit-based board. However, the Chipkit one does not respond at all.
So using a logic analyzer and probing the I2C lines on a normal one and the Chipkit's one revealed that there are some irregularities:
1.) Here, the part simply sends the address of the NES controller, and then writing 0xF0 and 0x55. And another one with the address, then writing 0xFB and 0x00. Note that the stop part is different at the Chipkit one: And this is the functioning one:
The code fragment in reference to the I2C waveforms:
I have to use my own I2C library for it to work as usual there.
2.) Same goes to this, after doing (1) the system sends one 0x00 to the controller, and the system reads back the returned value for 8 times. Unfortunately, on the Chipkit, it returns only 0xff: Here is the Chipkit's one, where it pulls the SDA high after the first byte is read for a long period, and rest is 0xFF: And the normal one:
Again, the code for this part is as follows:
I can replicate the normal trace from the plain Arduino with the same Chipkit but without the "Wire" and the "DTWI" libraries - I used a general I2C driver based on this website: https://electrosome.com/i2c-pic-microcontroller-mplab-xc8/ and modified it to suit the PIC32 series.
Is there anything that prevents the stop bit from functioning? It did look like the stop bit didn't get there at each end of the transmission for the Chipkit Wire library one.