FreeMaster Over CAN on interrupt fail to compile in polling mode

[millerhughes]

I try to change those 3 mico for enabling polling mode from code generated from  "FreeMaster over CAN" and "s32k3xx_fm_over_can_s32ct" 

FMSTR_SHORT_INTR, FMSTR_POLL_DRIVEN, and FMSTR_DEBUG_TX

but end with compiling failed, reason is that transfer feature freemaster over can from "s32k3xx_fm_over_can_s32ct"  reply on interrupt, but if motor control case using many irq like least 10khz fast task and bctu and hall , wagtch dog, freemaster received no response from controllewr k312, polling mode is necessary.

how to enable those 3 micros and open polling mode for "s32k3xx_fm_over_can_s32ct" 

[iulian_stan]

Hi @millerhughes,

To enable Polling mode you need to update the following macros:

#define FMSTR_LONG_INTR    0
#define FMSTR_SHORT_INTR   0
#define FMSTR_POLL_DRIVEN  1

only one out of those 3 should be set to 1, overwise the code won't compile.

Regarding FMSTR_DEBUG_TX - this is a debug macro that is meant to verify the TX line. Combined with previous definitions this one:

#define FMSTR_DEBUG_TX  1

will instruct FreeMASTER Driver to continuously send a debug frame (note: this helps you inspecting the TX line and you won't be able to connect to the board using FreeMASTER tool while this functionality is enabled).

Could you share your compilation error logs ?

As far as I know, s32k3xx_fm_over_can_s32ct example is implemented by Model-Based Design Toolbox (MBDT) team. If you develop your application using Simulink, it may require updating block configuration instead of manual code changes. In this case, MBDT developers can provide better assistance for your use case through the dedicated MBDT community.

[millerhughes]

I did try before using same setting as you:

for example,  I changed FMSTR_POLL_DRIVEN as 1 (was 0.as interrupt mode)

// Select interrupt or poll-driven serial communication

#define FMSTR_LONG_INTR 1 // Complete message processing in interrupt

#define FMSTR_SHORT_INTR 0 // Queuing done in interrupt

#define FMSTR_POLL_DRIVEN 1/*0 */

7 error: mainly because of

#if (FMSTR_LONG_INTR && (FMSTR_SHORT_INTR || FMSTR_POLL_DRIVEN)) || \

(FMSTR_SHORT_INTR && (FMSTR_LONG_INTR || FMSTR_POLL_DRIVEN)) || \

(FMSTR_POLL_DRIVEN && (FMSTR_LONG_INTR || FMSTR_SHORT_INTR)) || \

!(FMSTR_POLL_DRIVEN || FMSTR_LONG_INTR || FMSTR_SHORT_INTR)

/* mismatch in interrupt modes, only one can be selected */

#error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN

#endif

 3 error happen above for compile

../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN

326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN

| ^~~~~

../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN

326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN

| ^~~~~

../FMsrc/freemaster_private.h:326:2: error: #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN

326 | #error You have to enable exctly one of FMSTR_LONG_INTR or FMSTR_SHORT_INTR or FMSTR_POLL_DRIVEN

| ^~~~~

one is not enough, but two even all also failed.

[iulian_stan]

Communication modes are mutually exclusive options. That's exactly what the error message means.
FreeMASTER Driver routine may require a significative processing time and those 3 settings try to help developers to balance the execution depending on use case as follows:

• FMSTR_POLL_DRIVEN - FreeMASTER routine is executed entirely in the FMSTR_Poll function - developers decides when it is called but has to make sure that it is invoked at such frequency that allows FreeMASTER to keep up with the communication speed
• FMSTR_LONG_INTR - FreeMASTER routine is executed entirely in the FMSTR_CanIIsr function - deveopers forces the system to executed it by assigning a higher priority (I assume this one was used as it fits best in case of big number of interrupts)
  
• FMSTR_SHORT_INTR - is a mix of the previous two: the communication is happening in the interrupt handler (FMSTR_CanIsr), but the processing - in (FMSTR_Poll)

I think what you want to try is the last one (combination of polling + interrupt). Still, while the interrupt may guarantee that the CAN frames will be read, the board may not reply on time if FMSTR_Poll is not invoked frequently enough (due to interrupts with higher priority). As a result - FreeMASTER desktop tool will show timeout errors.

The developer has to make sure that the system can allocate sufficient time for FreeMASTER Driver routines in compute intensive applications.

Hope it clarifies FreeMASTER's communication modes.