 |
 |
| View previous topic :: View next topic |
| Author |
Message |
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
 Posted: Fri Dec 04, 2020 12:04 pm |
 |
|
| Ttelmah wrote: | Er. Level=7, is the highest priority. Not what is wanted.....
Level=1. |
I haven’t even looked at that yet. I just assumed "there must be a reason it says 7" 
We use a ton of timers (most use every timer available) and I2C as the only interrupts.
_________________
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: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Wed Dec 16, 2020 11:16 am |
|
|
Just curious... I based my polled I2C routines on existing examples. As such, after each byte, I poll looking for either a stop bit or the next incoming ISR flag:
| Code: |
// Wait for either a stop bit, or another incoming data byte.
while ((P == 0) && (I2C_SYSTEM_BUS_IRQ_PENDING_BIT == 0));
if (P != 0)
{
//DEBUG_PRINTF ("P");
break;
}
|
I recently saw code that polled the RBF (receive buffer full) status instead of the IRQ pending bit.
Is there an advantage to one method over the other? I just tested the RBF method in my code and it seems to also work fine... Block until there is either another byte to read, or a stop bit has been seen.
_________________
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: 19538
|
|
| Posted: Thu Dec 17, 2020 1:22 am |
|
|
Some chips have errata on one. On these it is recommended to use RBF
rather than the interrupt. Also, though your chip doesn't support interrupt
on start/stop, a lot do. On these if you checked the interrupt, it might be
one of these, not the data.... |
|
|
allenhuffman
Joined: 17 Jun 2019
Posts: 554
Location: Des Moines, Iowa, USA
|
|
| Posted: Mon Nov 11, 2024 8:44 am |
|
|
| allenhuffman wrote: | | I went down the "I2C bus reset" rabbit hole a year ago, seeing it mentioned and documented with ways to un-stick the lines. But, sadly, FTDI provides no way to do this from their Windows driver/API so we could never implement it :( |
I just wanted to add, since this was posted FTDI finally DID add a Bus Reset feature to its Windows driver.
Sadly, nothing we have tried (exhausting all the suggestions from FTDI) works at un-freezing a system when we get the real lockup. The FTDI chip seems unreliable when it gets messed up, and none of their Reset, Cycle Port, re-init routines will un-stick it. We have to power cycle the Windows computer when this happens ;-)
Windows is not an optimal solution for something you want to run reliably for months at a time ;-)
_________________
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
