Freemaster + FreeRtos

[sugab]

Hi, 

is there any sample for Freemaster implementation on top of Freertos

I am trying to build this one and found some problem

on freemaster sample, the pool function always called on the main loop and there is no delay in here, 

but if I use freertos and put the pool function on 1ms periodic task, the freemaster will be not responsive, 

it only happened on pool_driven mode

the other solution is remove the delay on the task, but i am not sure is this the solusion, 

thanks

bagus

[MichalH · Accepted solution]

Hello,

the best way to use FreeMASTER in a multi-tasking environment is to use one of the interrupt-driven modes:

• In LONG_INTR mode, everything related to FreeMASTER is processed in the ISR, including the protocol decode.
  • Pros: you do not need to call Poll and take care about FreeMASTER task at all.
  • Cons: the ISR may take long time when it processes the message, preventing other ISRs and high-priority tasks to execute unless proper interrupt priorities are set. 
• In SHORT_INTR mode, the physical character transmission and reception is processed in the ISR which is quite fast and deterministic. Then you need to call FMSTR_Poll in some task to handle the messages after they arrive. You have these options:
  • Run some low-priority task in which will only run when all your other application tasks sleep or wait for some event. In this task you call the FMSTR_Poll and it will not affect anything else.  
  • If you already have a low-priority task which is always running, put the FMSTR_Poll call into its loop.
  • Make the task which does FMSTR_Poll at a normal priority, but let it go to wait-for-event mode after each execution of this polling. Then set this event from the communication ISR after calling the FMSTR_SerialIsr(). This will make the task to sleep most of the time, but it will wake up after each character received to see if there is anything new to process.

If you still want to keep the POLL_DRIVEN mode, you need to run the task which calls FMSTR_Poll without any waits or delays. It would be basically your lowest-priority background task. Beware: in this mode, the FMSTR_Poll also handles physical communication, so it must not be preempted by other tasks for too long time (approx the time of transmission of one UART character or one CAN frame).

Regards,
Michal

[sugab]

Hi Michail

Thank you for the solution, I use the 2nd option (SHORT_INTR, and assign poll to 10ms task), and it works

br,

bagus