ChibiOS Free Embedded RTOS

Hi Giovanni,

As far as the code style goes, do you have an eclipse plug-in or an uncrustify config which will format the code to your preferred style automatically?

For adding a separate lld for the hrtimer, that sounds reasonable. In fact, my original implementation used a separate lld with inline function for maximum speed (to reduce jitter). I'll work on reviving that version over the next few days.

Look for "chibios.xml" in the SF download area, it is the Eclipse style description. The other difference is in names, camel names are only used for APIs or important structures, never for scalar types or variables.

There is also an, admittedly incomplete, style guide here: http://www.chibios.org/dokuwiki/doku.ph ... tyle_guide

Sorry for stressing about this, there is nothing wrong in any style, I am just striving to keep consistency across the code base.

Giovanni

Any news on this? I very much like to have such a feature included

Hi guys,

I really need a high-res timer too. I would be quite happy if it mapped directly to a hardware timer with a minimum of overhead. I really wouldn't want more than 1us overhead calling a single timer callback. It would be ok (probably better) if it was kept separate to GPT. I have found from experience it is really a lot better to keep slow rate and fast rate timers separated, it seems like they are logically related and can use similar functions, but they have very different demands. 50us overhead on a 10ms timer is no problem, 50us overhead on a 100us timer is disaster!

If I need more high-res timers than the hardware supports, then I can daisy chain them at an application level. Unfortunately if there is an overhead in the HAL implementation is is impossible to get that back.

However, I will try this code on an STM32 target.

Greetings,

I will work on updating the software to use inline functions for accessing the hardware timer registers/functions. However, I haven't had a lot of free time to work on it, and likely won't for another few weeks.

I agree that it is generally better to keep low-rate and high-rate timers separate. However, the GPT is an abstraction which allows you to create either a low-rate or a high-rate timer in ChibiOS. Therefore, the GPT was used for convenience, and it doesn't add much overhead to an already configured/running timer. For example, after processing the timers, gptStartOneShotI() is called with simply sets a state variable then calls into the hardware via gpt_lld_start_timer. Even with inline funcitons, this isn't going to get much faster. Therefore, the overhead for a small number of timers is pretty low (depending on what you are doing in your callback of course). You introduce the most amount of jitter if you are constantly starting/stopping timers while other timers are running.

As always, the code is yours to modify as you see fit and I welcome improvements. Perhaps we can add a platform specific way of accounting for the overhead of processing the timers based on the number of timers configured. For stm32 the low-level timer driver could take a hardware timestamp when the timer interrupt fired and again when the next timer was started to determine how many microseconds it took to process the timers.

Anyway, those are some thoughts on how to improve the code. But first, I'm not sure anyone has even tried the code (other than myself); maybe it doesn't even work!

I've unfortunately not yet had time to try out the code. But are we really sure that it is the right way to not use GPT functions? I cannot imagine that it adds much overhead - if any. What I find most important, is that GPT driver is not modified and the just interfaces to it.

From a quick look at the code, what I do not like is the isInISR_I function and its use. Probably the source code could be restructured to separate the two code path, couldn't it?

Question, can be it restructured to *use* the GPT and be a high level driver only? if not, what feature we should add to the GPT to enable this?

Giovanni

mabl wrote:I've unfortunately not yet had time to try out the code. But are we really sure that it is the right way to not use GPT functions? I cannot imagine that it adds much overhead - if any. What I find most important, is that GPT driver is not modified and the just interfaces to it.

From a quick look at the code, what I do not like is the isInISR_I function and its use. Probably the source code could be restructured to separate the two code path, couldn't it?

The inISR_I is very ugly. To remove it we would have to split the API to provide functions that must only be called from a thread context and functions that must only be called from an timer callback context.

Giovanni wrote:Question, can be it restructured to *use* the GPT and be a high level driver only? if not, what feature we should add to the GPT to enable this?

Giovanni

The main change to the GPT was to add a pause/resume functions for a timer. To protect against race conditions, the timer is paused during certain api calls and then resumed or re-started. The pause will simply stop the timer from counting, but not disable it in hardware. There also needs to be a way to read the tick count of the hardware timer.

Also, the pausing should (the code currently doesn't take advantage of this) be used to limit the amount of time spent in the chSysLock() state. Once the timer is paused, there is no need to be in a locked state; a mutex could then be used to provide the protection required.

Wouldn't pausing decrease the precision in time of events?

Giovanni