1
\$\begingroup\$

I am implementing a protocol decoder which receives bytes through UART of a microcontroller. The ISR takes bytes from the UART peripheral and puts it in a ring buffer. The main loop reads from the ring buffer and runs a state machine to decode it.

The UART internally has a 32-byte receive FIFO, and provides interrupts when this FIFO is quarter-full, half-full, three-quarter full and completely full.

  • How should I determine which of these interrupts should trigger my ISR?
  • What is the trade-off involved?

Note - The protocol involves packets of 32-byte (fixed length), send every 10ms.

\$\endgroup\$

1 Answer 1

Reset to default
1
\$\begingroup\$

If you know the exact length of the received message, then you should use an interrupt on received characters number.

The FIFO half-full, quarter,..-full interrupts are used whenever you recive a streaming data. Example: when it is half-full you process the received data (half) in the meantime the buffer shouldn't overrun. When you leave the ISR and do some other things the buffer is still filling, again you wait for interrupt when it is half full.

With bidirectional communication like master-slave, this kind of interrupts are useless.

\$\endgroup\$
5
  • \$\begingroup\$ Can you give a few use cases from real life where such interrupts actually make sense? (Not Master-Slave cases) \$\endgroup\$
    – SRK
    Commented Feb 11, 2019 at 13:10
  • \$\begingroup\$ @SreekeshSreelal Streaming like audio, video, etc \$\endgroup\$
    – Marko Buršič
    Commented Feb 11, 2019 at 13:31
  • \$\begingroup\$ Bursic . What is the preferred way if we are using a Master-Slave protocol? Send the request and poll for the response? \$\endgroup\$
    – SRK
    Commented Feb 12, 2019 at 5:37
  • \$\begingroup\$ @SreekeshSreelal Yes. Many different ways, the simplest and most used is to set a timeout interrupt. The UART enters in receive mode, when last char is received then it still waits for a certain time - TOUT, after this time elapses then it triggers the ISR. Also fixed number of recv. chars is possible, but it may happpen that you get an inconsistent packet if one character missses just once. \$\endgroup\$
    – Marko Buršič
    Commented Feb 12, 2019 at 13:49
  • \$\begingroup\$ I completely disagree with the “solution” to set your RX buffer size to the size of a fixed-length packet. Serial comms is unreliable; nearly perfect, but one dropped character will completely disrupt that kind of “cleverness”. For example: what if the cable is plugged in mid-packet? You need to treat the data stream as independent chars, and parse for the start (or more tricky) end of packet. \$\endgroup\$
    – John Burger
    Commented Feb 13, 2019 at 2:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.