Dear all,
I am trying to use CAN_MessageRead from CAN driver (CMSIS Driver 2.3) but as I have to introduce that to students, I would like to make it as easy as possible. Thus, I don't want to use the Callback function first, but instead I place the CAN receive function directly in the infinite loop of the main (another CAN node send the data each 100ms). The problem is that the CAN_MessageRead function is non-blockling, and always returns me 4 (the max number of data I have asked for), even if no new CAN message has arrived. My question is: is there a way to "wait" for new received message with this function before going on to work with the nex data arrived ? Thank you. Best regards, Xavier
That mostly depends on hardware and driver implementation, if you require that functionality then you can edit driver to work in the way you want it to. Basically, in real system that way of catching CAN messages would be CPU consuming, and also power consuming and all other, which does not make sense. How much more complexity does it take to explain callback function and implementation of it.
Thank you for your answer. I agree that it will be power consuming, but when you have to introduce something to students, it's better to start with easy things. Last year, the code to receive a CAN message with the Keil driver on my MCB1768 was something like:
can_Init (); /* initialize CAN interface */ ... // in the main loop: if (CAN_RxRdy[0]) { /* rx msg on CAN Ctrl #1 */ CAN_RxRdy[0] = 0; val_Rx = CAN_RxMsg[0].data[0]; }
Pretty easy to present that to students, isn't it?
With the new CAN driver, it is changed to what you can find with the example given in: www.keil.com/.../group__can__interface__gr.html
(BTW I am not sure that this example with extended ID should be the first when you want to explain how the driver works)
You see that even without the callback, it is slightly harder to use the new driver (object notion with corresponding capabilities...). That's why I try first to explain with easier approach :) Best regards,
It seems that, CMSIS-Driver Version 2.04 Driver API for CAN Bus Peripheral (Driver_CAN.h) wants to use one driver for all the various CAN Bus Peripheral, so it has to create a lot of abstraction layers.
And it seems that the users of CMSIS-Driver don't know or don't need to know what kind of CAN Bus Peripheral they are using, so they just ask the CAN Bus Peripheral "What are your capabilities?"
Based on the answers, the software goes different routes.
If my understanding is correct, then it is really something magical.
Magic and High-tech are the same thing to me, if needed, I would be glad to use them, but would not try to understand them.