ChibiOS Free Embedded RTOS

Hello,
In my program I have to send CAN frame from timer interrupt handler. I have read that the function canTransmit() can't be used to do this.
Is there any other possibility?

Best regards,
Franek

Hi,

Currently not, the driver would require a new API function, you may wake up a thread from your ISR and do the transmission from there.

Giovanni

Do you plan to create such new API function?

How much time I need to wake up a thread to do the transmission? I mean time from Interrupt to canTransmit function in new thread.


Franek

Hi,

Waking up a thread from an ISR takes few microseconds (depending from the jitter introduced y=by other ISRs. Sending the frame is almost immediate so the thread would sleep most time and only execute for some uS.

I will look into adding the new API anyway.

Giovanni

Look at it this way. Instead of directly calling the can_transmit function, the ISR does some stack magic and instead of returning to the code it interrupted, it returns to your code calling can_transmit. This is effectively what happens. when you wake up a (high priority) thread that is just waiting for the event to happen, and calls can_transmit immediately afterwards.

I'm not sure how long the context switch takes (i.e. the meddling with the stack). I would have estimated a bit faster than what giovanni estimates, but he wrote the code and he's interested in performance so I know he must have measured it....Unless you have very hard evidence, trust giovanni on that.

Context switch is much faster that what I estimated, however there are other IRQs in the system, the jitter prevails over the pure context switch time. It is not the best case that matters, the relevant figure is the worst case and that one depends on the application and its IRQs.

Giovanni

Hi,

I made an error, the I-class API has already been introduced, try canTryTransmitI() and canTryReceiveI().

Giovanni

Giovanni wrote:Context switch is much faster that what I estimated, however there are other IRQs in the system, the jitter prevails over the pure context switch time. It is not the best case that matters, the relevant figure is the worst case and that one depends on the application and its IRQs.

That depends on what you are optimizing.

I suspect that the threadstarter here wants to optimize brain-time: he simply has an application where an interrupt routine ends up figuring out that a can packet needs transmitting. So the first thing he tried is calling cantransmit from the interrupt routine. Nothing time critical, just the easiest way to program things.

Then there could be the case where processing time is scarce. Maybe an ESC with a canbus with two motors and about 100kHz PWM frequencies. (that would almost saturate an '407). So then too the status updates in the interrupt are not jitter-critical but do need to be optimized for processing time....