1
\$\begingroup\$

I am trying to develop an UART protocol to allow communication between two boards Master_Board and Slave_Board. Master_Board shall send commands over UART to Slave_Board and the latter shall answer. The thing is commands are with different priorities and some commands need to be executed in time. For example if the Master_board send "GET_VALUE" to Analysis_Board, the latter shall send values to Master_board for 20 seconds. If something bad happens while receiving data, Master_board shall send "ABORT" to Analysis board. The latter shall stop sending values even if the 20 seconds are not reached. I think there are 2 ways to do so. implement the UART protocol to be managed by interrupts or RTOS. Which way is better in my case? Which way is easier to handle and guarantees the best performance?

\$\endgroup\$

closed as too broad by Jeroen3, Arsenal, Finbarr, Voltage Spike, Bence Kaulics Mar 14 '18 at 21:39

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    \$\begingroup\$ You're asking for implementation opinions. Which is very broad. This is better suited for a forum. \$\endgroup\$ – Jeroen3 Mar 14 '18 at 10:28
  • \$\begingroup\$ Depends on the protocol specification really. If the protocol say you have to stop after some bit times after receiving the abort command, I'd rely on interrupts. If it says you have 100 ms to stop sending stuff, a RTOS would handle that fine as well I guess. \$\endgroup\$ – Arsenal Mar 14 '18 at 11:07
1
\$\begingroup\$

You did not specify your timing tolerances (eg. jitter - does it have to be 1s or 1ms). If it is 1s, then it can easily be done "no matter what" (unless something is very badly coded...) both bare-metal and with an RTOS. Is the RTOS really necessary? You don't use RTOS just to make something "faster", but to make management of many parallel and interdependent tasks easier.

Some ideas:

  1. Within RTOS task: load UART data register, poll transmit complete flag, if not done call vTaskDelay (or other delay function in your RTOS). Primitive and does not guarantee timings.

  2. RTOS task loads TX buffer, starts UART TX interrupt, there is an interrupt for every byte, the task waits for a flag or conditional variable that will be set by the last transmit complete interrupt. There is an interrupt for every byte. Interrupts with higher priorities can affect the timings.

  3. RTOS task loads TX buffer, configures DMA to transmit all data, the task waits for a flag or conditional variable that will be set by DMA transfer complete interrupt. There is a single interrupt for the whole transfer. Very little factors can affect the timings (basically only other DMA transfers - this can be dealt with DMA priorities or round-robin DMA scheduling).

  4. Design everything as a time-triggered system. This gives you 100% reliable timings (well... 99.99something%) at the cost of lower peak performance (ie. your fast CPU will do very little most of the time to have reserves for worst-case execution time). There is a great free book Patterns for Time-Triggered Embedded Systems on this topic. This method will give you the lowest jitter possible.

\$\endgroup\$
0
\$\begingroup\$

It depends on the other specifications of your system. You can do what you need using interruptions; the use of an RTOS will add some overhead that i dont think is justified only by the comunication interface of the system.

\$\endgroup\$

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