Which one is the best approach for callback handling?

Question

I need to verify myself about what I am doing.

In my app., there is data stream between my device and vehicle CAN bus which contains like speed, gearbox etc. My device gets these data and by interpreting them, it gives an output to the vehicle. Now. I am handling all these receive transactions in RxCallback and in order to not cause circular dependency, I create a User_RxIndication function.

In this function, I am checking id, dlc, frame, format etc. If all validation passed, then data is passing from specific parser and it is saved. All these transactions are handling in User_RxInditication and this fuction is passed from application layer to the lower layers.

Here is the code sample.

static CanMsg_t RxMsg;
static vehicle_t MyBus;
void VDCU_CanReceiveIndication(CanHandle_t Dummy)
{
    if(ComM_CanRead(&RxMsg)== E_OK)
    {
        switch(RxMsg.id)
        {
        case SPEED_CAN_ID:
            if(     VALIDATE_DATA_FORMAT(RxMsg.id, SPEED_ID_FORMAT) &&
                    VALIDATE_DATA_FRAME(RxMsg.frame, SPEED_FRAME)   &&
                    VALIDATE_DATA_LENGTH(RxMsg.len, SPEED_LENGTH ))
            {
                /*TODO: Apply Parser, if required ?*/
                VehicleIf_SetVehicleSpeed(MyBus, RxMsg.data[0]);
                
            }
            else
                 /*TODO: Send Dia*/
            break;
        case STEERINGWHEEL_CAN_ID:
            if(     VALIDATE_DATA_FORMAT(RxMsg.id, STEERINGWHEEL_ID_FORMAT) &&
                    VALIDATE_DATA_FRAME(RxMsg.frame, STEERINGWHEEL_FRAME)   &&
                    VALIDATE_DATA_LENGTH(RxMsg.len, STEERINGWHEEL_LENGTH ))
            {
                /*TODO: Apply Parser, if required ?*/
                VehicleIf_SetVehicleWheelAngle(MyBus, RxMsg.data[1]);
            }
            else
                /*TODO: Send Dia*/
            break;
        default:
            break;
        }
     }
 }

These cases may extend up to 9-10 btw. I did not design parser but, I will do.

Now, This approach is valid ? Whenever read something about Interrupt mechanism. It is said "keep interrupts as short as possible. Set a flag and do whatever you want in main."

Should I apply this switch case and guard conditions in main or here is okey ?

In case of handling in main , do I miss data while interpreting them in main depending on other task time allocation in app ?

What is the right approach. Thanks.

Answer 1

No, all of that is not sensible to do from inside an ISR, unless your real-time requirements are very tough. In the rare case where you are counting microseconds and you must deal with a package immediately upon arrival, then you can deal with the data directly from the ISR - as long as you are aware that this stalls everything else in the MCU.

(Or in case the data doesn't affect other interrupts, you could use the dirty old school trick of dropping the global interrupt mask first thing you do in the ISR, but keep the CAN rx flag set until the end of the ISR... But these are rather desperate tricks for extreme real-time requirements.)

In normal programs, you would rather just copy data out of the CAN controller hardware buffers and into RAM asap, then worry about decoding it later. Depending on hardware, you basically have to use one of these options:

• Use a modern CAN controller with a 'mailbox' feature (> year 2010 technology). In that case, data arrives in its mailbox and you can grab the latest one whenever you want. In many CAN systems you can even allow overruns of the mailbox in case you are only interested in the latest data. At any rate you don't need to worry about emptying a rx FIFO before it overflows, so timing becomes less critical.

• Use DMA or similar to have incoming data copied from the CAN buffers to RAM, then decode it from the regular background program. Modern MCUs like Microchip SAMC have support for this.

• In case you are using old, outdated technology like ST bxCAN, then if you are using interrupts you might be forced to hard copy the buffers into RAM from the ISR, then deal with them later. Or indeed set a flag, but in that case you might probably just as well use use polling.

  Because for these older controllers, you must service the CAN controller rx FIFO fast enough so that you never risk a FIFO overrun. How easy it is to achieve that depends on the higher layer CAN protocol. On such older controllers we often had to fiddle around with acceptance filters and masking, to reduce the amount of data. Always messy.

  And interrupts stink in general because the majority of all embedded systems programmers out there are sadly too incompetent to be aware of race conditions. Or the old "missing volatile" bug, for that matter. Avoid interrupts when you can.

Overall, if you have a fairly complex higher layer protocol and your MCU needs to listen to a lot of different messages (CANopen, J1939 or similar) then I would strongly recommend to pick a modern CAN controller with mailboxes, since these make real-time design so much easier. This is something to consider when picking MCU.

Since most STM32 can't even be purchased because ST can't manage to manufacture their own products, you might want to seriously consider porting to another MCU family for that reason alone.