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

[JBond.1]

Hi, my application needs to handle CAN message input, Updating the screen through UART, constant buffered LOG file writing to MicroSD card. I was wondering what kind of flow I could use?

• For CAN messages I could use interrupts and update variables (though if user input is too fast I could loose some of the input and treat only the last one... which isn't ideal)
• Writing LOG in main loop
• Updating screen also in main loop? but that would create LAG depending on if LOG file is ready to be written?

Any ideas and advises? Should I user TIMER interupt for updating screen? But I dont think that updating screen with UART in interupt is good idea as its heavy operation?

[JoniS]

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.

[nico]

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

[Tesla DeLorean]

>>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.