TivaWare simple task scheduler for TM4C1294

Hello Alexander,

Thanks for bringing up this issue. You are correct, the "schedule.c" utility needs to be updated for TM4C129 device. I will file a bug so that we can update this in the future.

I the mean time, a quick work around, if using only TM4C129, could be to replace "SysCtlClockGet()" with a global variable that stores the System Clock (in the application by calling the TivaWare API SysCtlClockFreqSet()).

Thanks,

Sai

Good morning fellows,

I was just about to post a question to verify if there was such a thing as a scheduler available in Tivaware, and "trained enough" decided to search first.

Using 2.1.4.178. It appears the fix has not yet been implemented - not a major deal, for we do use a global variable witch holds the system clock for any platform.

It appears that this scheduler is really focused on periodic calls. Is it also convenient for managing something like a "one-time call in 670ms from now"? Any suggested strategies for that?

Cheers

Bruno

Bruno Saraiva said:

Is it also convenient for managing something like a "one-time call in 670ms from now"? Any suggested strategies for that?

Anyone inspired to share TivaWare / TM4C scheduler experiences and strategies?

Bruno

The father of such "inspiration" is (usually) "reward."

cb1_mobile said:

The father of such "inspiration" is (usually) "reward."

For the time being, I'd probably be able to hit "like" and a bunch of thank yous... 

Whenever possible, I don't refrain from sharing experiences, and the same would probably be the case with other posters.

Depending on the answer, maybe "big boss" can say: "Why don't you hire this folk to develop that part of the solution for us?"

Cheers

Further comments into this subject:
- I further looked into the simple task scheduler available in the utils package - and it is in fact quite simple. It seemed more adequate to me to port the code into my own set of task controlling library.
- It does not handle the concept of one-time call scheduling or other more elaborate task controls without significant changes - but it is a nice foundation.
Bruno

Look at the Timer examples. There is code to set up one of the many timer peripherals in one-shot mode for just what you need. It's not the same thing as an OS task scheduler, but it will call your timer interrupt at the desired time. So long as you know how to properly implement and handle interrupts, this should be sufficient.

Brian,
When you have a project with 23 recurring functions, all at different periods, and another 40 possible functions that are conditionally executed, some of them with callbacks and other possible triggers, simply properly implementing and handling interrupts is not really enough.
I am talking about a reasonable task scheduler, which allows not only for recurring functions (as the TI's Util simple scheduler does well), but also for schedule one-shot calls and other tricks.
Still, I'm getting too close to a RTOS description here, and we have not yet decided whether to really migrate the projects to RTOS, or to spend the effort into improving our scheduling control and remain with our non-OS codes.
Regards
Bruno

Yes, at that level you might want to consider TI-RTOS just so you don't have to work so hard on a scheduler.

When the many recurring functions are tightly coupled with hardware, as is the case for most of my designs, I find it reasonable to segregate each function group and coordinate them at a higher level. Of course, I'm usually dealing with interrupts for various specific hardware peripherals, so the coupling is logical.

In your case, it sounds like you might just need a generic scheduler. I have found that some RTOS designs are not very different from bare-metal code, so migration may not be as difficult as you think. Usually, a good RTOS is very, very unobtrusive.

Bruno Saraiva said:

When you have a project with 23 recurring functions, all at different periods, and another 40 possible functions that are conditionally executed

Those numbers seem high - might it hold true that "certain of those functions execute in a regular sequence" - thus may be treated as a "group or block?"     Your space here does not allow for your full/proper listing of the execution time - nor the (normal/expected) frequency - of such function calls.     This suggestion is based upon the theory that, "Smaller often proves easier to understand, adapt & manage."

Might you be "bumping against" the limitations of a 120MHz MCU - you are aware that (other) Cortex M4s exceed 200MHz - are you not?      

And - when - or is it (ever) "time" to employ two (identical) MCUs - and "split your function load?"     (ideally under some organized strategy)

It is supposed that, "Every application is unique - most start "small" and expand - and that (sometimes) "early choices" may no longer register as "best choices."

If it is true that your current method, "Meets Program Performance, Robustness and (future) Upgrade Requirements" - while providing (some) "comfort/safety" margin - and has been adequately "test/verified" - your "search for alternative methods" may be delayed.  

You should be applauded for "thinking ahead" - the issues you've raised may arise w/many here (in time) - and you've provided a nice basis for ongoing dialog...

A couple of thoughts,

First, this is possible with interrupts and timers. A single timer and interrupt should be sufficient although you can be more creative with several interrupts.

Second, If you really have this level of activity there would appear to be considerable benefit from introducing some abstraction to help manage it. An RTOS may be of benefit, even without an RTOS other abstractions may be quite useful in simplifying things.

Third consider that one shot and periodic events can be considered a continuum rather than distinct. Periodic events are just rescheduled one shot events and one shot events are periodic events with an infinite repeat schedule. Thinking in that fashion may lead to an appropriate abstraction.

Robert

cb1,

These numbers are not necessarily the true figures, but yes, there are lots of different things happening in some of the projects here. Most of them are VERY SIMPLE things, such as controlling led blinking, scanning or registering callback functions for push buttons, or buzzing a sound - other examples are recurring system verifications, power saving control, smart backlight... For all these together, even something at 1MHz would probably do. But the challenge is to make them all live in harmony AND ELEGANCE in one same project.

It is awesome and my intention to hear echoes like yours: ONGOING DIALOG for everyone's knowledge evolution - thank you.

Within the current products we manage, there are only two which could already benefit from something more powerful. And to remain in these realms, we'll probably start playing with the C2000 line soon - in which case, most likely we will keep a "simpler" MCU for the household tasks, and let the real-time piece dedicated for the calculations (we deal a lot with inertial measurement, accelerations, and similar dynamics measurements - while trying to keep the power requirements low).

Regards

Bruno

Robert,

Thanks for the input. I agree! I feel like there is no escape from RTOS. My sincere mental/psycho blockage so far? Those graphics IDE depicted in most of the "official" training videos.

I am aware that what I'm discussing here is the task management / scheduler which has been evolving for years in RTOS's - and I am certainly not more creative or efficient than all these years put into TIRTOS, for example.

But I'd love to see a simpler training: something that says "you don't need to add any of these EASY TO USE graphic IDE aids, just schedule a function using such and such API within your existing project..."

Not saying, by any means, that TIRTOS is difficult or improperly documented - I just did not have the time to get into it so far, and probably my first choice for learning was not my best - more dedicated to someone who has NOT been using non-RTOS systems for a while. As I might have mentioned, in the end my systems did grow to have some sort of scheduler - but they are sincerely confusing and certainly not as efficient as they could be - let alone a nightmare for any attempt of resources measurement...

Regards

Bruno

Bruno, you might also check out Free-RTOS. It does have a larger community and there is documentation on-line.

It's also not stuck to a single vendor and so not to an IDE.

Not sure how good the introductory tutorials are. I've looked up specific functions but not the overviews.

Robert

Your problem as described appears to call for a delta queue and a timer rather than a full RTOS/RTK but you likely have more going on.

"Delta Queue" sounds like a neat name for a Rock Band... (or Delta Crue ... especially if from the US south...)

Bruno - months back we "started" w/Free-RTOS - especially as it is (as Robert noted) Vendor Agnostic!    SO Good, that!

It may be possible that you & my group "team" - goal is to help each other "over/around the rough spots" - helped (especially) thru "strength in numbers."  

cb1_mobile said:

"Delta Queue" sounds like a neat name for a Rock Band...

Count me in as the drummer - as long as it becomes a Progressive Rock band.

cb1_mobile said:

goal is to help each other

Deal. Will get into it as soon as my team delivers this current #^%&$&^&!* 2-months late project.

Good that - reminds me of Engineering School - five of us teamed (30 man class) - each guy assigned to be "expert" in a clearly defined, limited area.     (it was "rare" that we (all) stunk in the same area - and the "push" from the group proved a great motivator.)      

Different perspectives, varied explanations - often enabled the best & most efficient learning.

Sometimes - for "sport" - we'd force each guy to "attack the problem from a unique direction" (which would NEVER be attempted by one of us, alone) and our joint (post solution review) of "what worked, what failed - and why" proved of substantial (and ongoing) value.     Learning how to "accurately/properly categorize or classify a problem" - and only then "selecting the most appropriate/targeting solution method" paid (then & now) huge dividends...

Bruno Saraiva said:

there are lots of different things happening in some of the projects here. Most of them are VERY SIMPLE things, such as controlling led blinking, scanning or registering callback functions for push buttons, or buzzing a sound - other examples are recurring system verifications, power saving control, smart backlight... For all these together, even something at 1MHz would probably do. But the challenge is to make them all live in harmony AND ELEGANCE in one same project.

There are Eight general purpose timer peripherals in the TM4C1294, each with a Timer A and Timer B part. Your firmware handling of LED blinking, LED scanning, push button polling, and other utilities can easily be handled by timer interrupts. There is a separate interrupt vector for each timer. If you have an LED matrix that needs to be scanned, that interrupt probably needs to be higher priority than others to avoid variations in brightness due to PWM changes. You merely need to carefully sequence your interrupt operations so that the critically-timed code is at the beginning of the interrupt handler, with other bookkeeping following that. Other functions like polling push button states can easily be the lowest priority.

Other functions like power saving probably also have a dedicated interrupt. Altogether, I see little need to rewrite your firmware on top of an RTOS. Everything you've listed is standard fare for embedded firmware interrupt handlers.