Best practice for application architecture (user input, screen updating, file writing)

Can via interrupts, use circular buffer for the messages so you don't need to worry about losing data(process in main loop)

​

If usart is going to receive data, do that with interrupts and circular buffer aswell, then again you don't need to worry about missing something.

​

Transmitting could be done normally within main loop, depending on how much data needs to be sent at once.(calculate of the chunk of data you need to transmit at once takes too much time so that something might look like it's not responding).

​

Update the screen when you can.

​

Like you could use some kind of state machine.

Ie.

1. Process can
2. Process usart
3. Write to sd
4. Update screen

​

And then hop between those like, 1 - 4 - 2 - 4 - 3 - 4 etc. to give most time for the screen updates if that is your biggest consern.

​

E​: and if it's still unresponsive for user actions, you could create state machines inside state machines for the code paths that take too long to finish if everyone is being done at one run.

​

​

​

i would use CMSIS RTOS v2 with FreeRTOS, This way you can add:

• CAN receive from IT which fills your CAN receive queue
• CAN Process thread which processes your can message (with an OS you can wait for a message in the Queue, without polling)
• thread for updating the LCD every like 100ms
• low priority thread which writes your log buffer to the SD card ever 1 second.

Very nice controlable with delays and priorities.

Cheers

>>But I don't think that updating screen with UART in interrupt is good idea as its heavy operation?

Buffer UART output so it is independent of the timer/interrupt.

If the operation is still too heavy, break it into bite size pieces, use a state machine/sequencer and spread it over multiple interrupts.