 |
 |
| View previous topic :: View next topic |
| Author |
Message |
jaka
Joined: 04 May 2014
Posts: 35
Location: Finland
|
|
 Posted: Fri Nov 22, 2019 9:29 am |
 |
|
Nice to hear that FT4222 does support clock stretching. At least you can rule that problem out 
It's also good to me know about this. We have been using CP2112 and it has been working perfectly in our application. But it is a bit slow since it's HID based and needs a lot of polling. The MCP2221 is even slower requiring more polling. But they both support clock stretching.
Sorry for the off-topic and good luck with your non-interrupt I2C library! |
|
 |
jaka
Joined: 04 May 2014
Posts: 35
Location: Finland
|
|
| Posted: Fri Nov 22, 2019 9:40 am |
|
|
One more thing. There is application note AN1302 from Microchip which implements I2C slave (bootloader) without interrupts. The source is in Hi-Tech C but it's quite simple to follow. It uses quite low level operations and as far as I remember, doesn't use any hidden libraries.
I have been using that bootloader for years and it's working OK. A word of caution for other readers: the bootloader leaves some registers in such states that CCS library I2C functions don't work! |
|
|
temtronic
Joined: 01 Jul 2010
Posts: 9100
Location: Greensville,Ontario
|
|
| Posted: Fri Nov 22, 2019 9:49 am |
|
|
I've been following this thread for days and wondered if the 'state machine' for any Philips ( or NXP) I2C devices was published ? My idea is that it'd be a good starting point as I2C slave devices seem to have been reliable for decades. I understand that a PIC slave is really a 'smart slave' but the basic low level 'state machine' should be easy(?) to implement.
I'd hate to see a lot of 'top heavy' code cut if there was a simpler solution.
just tossing out an idea...
Jay |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Nov 25, 2019 8:28 am |
|
|
| jaka wrote: | One more thing. There is application note AN1302 from Microchip which implements I2C slave (bootloader) without interrupts. The source is in Hi-Tech C but it's quite simple to follow. It uses quite low level operations and as far as I remember, doesn't use any hidden libraries.
I have been using that bootloader for years and it's working OK. A word of caution for other readers: the bootloader leaves some registers in such states that CCS library I2C functions don't work! |
Good to know. I looked at the MicroChip EZ Bootloader, but it looked like we'd have to install timers, etc. through it, requiring updates to the existing code. I am trying to do something fully transparent to our existing code so all we have to do is adjust some ORG/BUILD addresses in the CCS compiler for it to run. They also monitored the I2C for bootloading, and we have that bus occupied for our own protocols so I expect it would have required much work to make it share.
I have been implementing some of our protocol to allow firmware updates and hope to be testing things soon. The next major project is going to be replacing all the i2c_xxx() calls with our own code so we can add timeouts and such. The code polls "forever" on certain bits, which should be fine when everything works perfectly. But we've seen many instances of glitchy I2C traffic that have caused things to get out of sync and code to look up in that code.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Nov 25, 2019 8:32 am |
|
|
| temtronic wrote: | I've been following this thread for days and wondered if the 'state machine' for any Philips ( or NXP) I2C devices was published ? My idea is that it'd be a good starting point as I2C slave devices seem to have been reliable for decades. I understand that a PIC slave is really a 'smart slave' but the basic low level 'state machine' should be easy(?) to implement.
I'd hate to see a lot of 'top heavy' code cut if there was a simpler solution.
just tossing out an idea...
Jay |
I'll do some digging.
As to "reliable for decades," do a websearch for "I2C hang" or similar and you will find thousands of hits about common issues where things get out of sync and a Slave hangs the bus. The I2C spec even has a "bus reset" as part of the specification, but it is not implemented by FTDI's drivers nor is there a function do to it with the CCS code.
I2C is fine when things work as expected - start bit seen, stop bit seen, etc. - but it seems to have been designed for very simple things like polling a few bytes from some hardware, rather than using it as a robust communication protocol. I don't think it's the appropriate tool for the job we are using it for.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19217
|
|
| Posted: Mon Nov 25, 2019 9:11 am |
|
|
The reason it is not in the CCS drivers, is that these
support what the hardware peripheral does, and this does not offer a
reset. However the code involved is minor.
| Quote: |
It is the master’s job to recover
the bus and restore control to the main program. When
the master detects the SDA line stuck in the low state, it
merely needs to send some additional clocks and generate
a STOP condition. How many clocks will be needed?
The number will vary with the number of bits that remain
to be sent by the slave. The maximum would be 9. This
number is derived from the worst-case scenario, the case
where the processor was reset just after sending an ACK
to the slave. Now the slave is ready to send 8 data bits and
receive 1 ACK (or NAK in the case of a bus recovery).
The procedure is as follows:
1) Master tries to assert a Logic 1 on the SDA line
2) Master still sees a Logic 0 and then generates a clock
pulse on SCL (1-0-1 transition)
3) Master examines SDA. If SDA = 0, go to Step 2; if
SDA = 1, go to Step 4
4) Generate a STOP condition
|
It really is basic, but is important. I've run I2C for years without
problems, but always implement this in the master. |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 537
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Nov 25, 2019 9:20 am |
|
|
| Ttelmah wrote: | It really is basic, but is important. I've run I2C for years without
problems, but always implement this in the master. |
Once I learned it was in the spec, I was surprised that FTDI did not have a way to do it. Their driver does give GPIO access to the pins, but not once they are initialized for I2C. They have two different Reset functions that are supposed to help, but during my testing last week I created a bus hang twice that I could not reset from the FTDI side (even shutting it down, and reopening the I2C connection fresh).
On the PIC24 side, we do have one board that has both Slave and Master (it multiplexes to a sub-bus). I don't know if we've put in a bus reset there yet, but I don't expect toggling the I/O pins on the PIC side to be a problem.
_________________
Allen C. Huffman, Sub-Etha Software (est. 1990) http://www.subethasoftware.com
Embedded C, Arduino, MSP430, ESP8266/32, BASIC Stamp and PIC24 programmer.
http://www.whywouldyouwanttodothat.com ? |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
