Dear EE-ers,
I am coming from a system where I used a so-called time-trigger-task, which got fired every 1 ms.
This trigger-task would then send messages to 3 other "regular" threads (having different priorities), when they should execute a series of tasks.
The regular threads were blocking on a receive_msg(), until they got one,
then checked the content of the message, to see which series of functions should be executed. (e.g. 4ms tasks series, a 10ms task series, and so on)
Additionally, we have a lot of interrupts (for timers, dma, PWM, ...). Some of these are _very_ time critical, others are not. Therefor, at least for these time-critical ISRs, I need the least overhead and jitter possible.
I was thinking about following set-up:
- FP kernel
- An ALARM or counter ISR that will send messages to the regular TASKS
- Waiting for these messages in the TASKS threads. => Are there blocking variants of the ReceiveMessage() primitives? (i.e. the TASK should yield)
- Use ISR1 for the time-critical ISRs
- Use ISR2 for the other ISRs
- System timer set to the STM module of my MPC5643L (EE uses this as system tick then, right? needs to be an ISR2 to it re-schedules?)
Thanks for your suggestions!
Recommended kernel / tasks / alarms setup for my system?
Moderator: paolo.gai
Re: Recommended kernel / tasks / alarms setup for my system?
Hi!
A few suggestions:
- to be minimal you can think at a monostack configuration, without blocking primitives, with the synchronization substituted by ActivateTask.
- when you use ISR1 note you cannot call any OS primitive
- ReceiveMessage has not a blocking variant. If you need that one you can use Events on ECC1 / ECC2 or semaphores + multistack configuration
Just curious... Are you working on a Company or University? is it possible to have some reference link of your company/institution?
Ciao,
Paolo
A few suggestions:
- to be minimal you can think at a monostack configuration, without blocking primitives, with the synchronization substituted by ActivateTask.
- when you use ISR1 note you cannot call any OS primitive
- ReceiveMessage has not a blocking variant. If you need that one you can use Events on ECC1 / ECC2 or semaphores + multistack configuration
Just curious... Are you working on a Company or University? is it possible to have some reference link of your company/institution?
Ciao,
Paolo
Re: Recommended kernel / tasks / alarms setup for my system?
The sender just call COM to Send the message and than activate the receiving Task or activate the receiving task with an alarm and if there's no messages the receiver just return.maximevince wrote: - Waiting for these messages in the TASKS threads. => Are there blocking variants of the ReceiveMessage() primitives? (i.e. the TASK should yield)
Thanks for your suggestions!
Re: Recommended kernel / tasks / alarms setup for my system?
Hey all,
I had been thinking of working with the combination of semphores (or activation/alarms) + messaging, indeed.
I'm working for a company in the automotive business.
At this time, I'd doing a study to see if EE could replace our current OS,
and it turns out positively, I'm convincing my managers that EE is a better choice.
To me, it looks that I'm not far from what I want to achieve, and the fact that the full EE source is availabe + the license EE is using are very convenient.
Once the management is convinced of the migration, they'll probably want a support contract, too.
I had been thinking of working with the combination of semphores (or activation/alarms) + messaging, indeed.
I'm working for a company in the automotive business.
At this time, I'd doing a study to see if EE could replace our current OS,
and it turns out positively, I'm convincing my managers that EE is a better choice.
To me, it looks that I'm not far from what I want to achieve, and the fact that the full EE source is availabe + the license EE is using are very convenient.
Once the management is convinced of the migration, they'll probably want a support contract, too.