[IMPORTANT] New feature on the master branch: system timer
Locked
|
Hi,
I have implemented (and merged into the master branch) a new eLua feature: the system timer. It attempts to fix one of the biggest flaws in the eLua design: timer management (I take full blame for this BTW). The documentation was updated (so you can read more about this in the official docs), but this is the summary: I was obviously wrong when I assumed that manual timer management can actually work in practice. It can (and most of the time will) become a nightmare for anything but the simplest applications. Having to manually track timers and their base frequencies is prone to failure and endless frustration. The system timer is my attempt to fix this. It is a timer with a fixed, unmodifiable resolution on all platforms (1us) and large counters:
- 52 bits for floating point Lua and 64-bit integer only Lua (lualonglong, a new feature). In this mode the system timer overflows after about 142 years (I know this is hard to believe, so feel free to do the math yourselves :) )
- 32 bits for 32-bit integer only Lua (lualong). In this mode the timer overflows after about 1 hour (yes, huge difference here). The eLua API was subsequently modified to take advantage of this new feature. I'll say this again: part of the eLua API was modified to take advantage of the system timer, so be sure to check the updated docs. You can find a list of the changes below):
- the timeouts are specified in a much more unified manner across different eLua modules. Their general specification is now [timeout], [timer_id] (note that the order of 'timeout' and 'timer_id' was changed in many modules) with the following semantics:
- you don't have to specify the various timer IDs (CON_TIMER_ID, RFS_TIMER_ID, RPC_TIMER_ID) in platform_conf.h now. If you don't specify them, they'll automatically default to the system timer. In fact you shouldn't specify them explicitly unless you have a very good reason to do so.
- note the new PLATFORM_TIMER_INF_TIMEOUT constant used to specify an infinite timeout. This is an "universal constant" across eLua now; this means that different modules don't get to specify their own constants for infinite timeout anymore (as was the case, for example, with UART and its PLATFORM_UART_INFINITE_TIMEOUT constant); they must use PLATFORM_TIMER_INF_TIMEOUT instead.
You can (and are encouraged to) use the system timer from C code too, not only from Lua code. You can reffer to the system timer with the PLATFORM_TIMER_SYS_ID constant. Unlike the Lua API, the C API (the platform interface) was only modified slightly (with the exception of the timers API that was enhanced quite a bit). In particular, the order of timeout and timer_id parameters was not changed in the C API.
One important limitation of the system timer is that it can't generate interrupts. From an implementation standpoint, this is how the system timer is implemented on different platforms, in a nutshell:
You can find a more in-depth overview of the system timer and its implementation in the documentation (arch_platform_timers.html#the_system_timer). I hope I'm not forgetting anything here. Please don't hesitate to contact me if you have questions. Also, I encourage all of you to test this new feature as much as possible, as it is still very much in beta.
Best, Bogdan _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
 
|
Marcelo Politzer |
Re: [IMPORTANT] New feature on the master branch: system timer
|
|
Wow, great job!
It really is quite a nightmare to manage the timers. So to use this new feature in C code I would do something like this? /* void platform_timer_delay( unsigned id, u32 delay_us ); */ platform_timer_delay(PLATFORM_TIMER_SYS_ID, 10); 2011/10/21 Bogdan Marinescu <[hidden email]>: > Hi, > I have implemented (and merged into the master branch) a new eLua feature: > the system timer. It attempts to fix one of the biggest flaws in the eLua > design: timer management (I take full blame for this BTW). The documentation > was updated (so you can read more about this in the official docs), but this > is the summary: I was obviously wrong when I assumed that manual timer > management can actually work in practice. It can (and most of the time will) > become a nightmare for anything but the simplest applications. Having to > manually track timers and their base frequencies is prone to failure and > endless frustration. The system timer is my attempt to fix this. It is a > timer with a fixed, unmodifiable resolution on all platforms (1us) and large > counters: > - 52 bits for floating point Lua and 64-bit integer only Lua (lualonglong, a > new feature). In this mode the system timer overflows after about 142 years > (I know this is hard to believe, so feel free to do the math yourselves :) ) > - 32 bits for 32-bit integer only Lua (lualong). In this mode the timer > overflows after about 1 hour (yes, huge difference here). > The eLua API was subsequently modified to take advantage of this new > feature. I'll say this again: part of the eLua API was modified to take > advantage of the system timer, so be sure to check the updated docs. You can > find a list of the changes below): > - the timeouts are specified in a much more unified manner across different > eLua modules. Their general specification is now [timeout], [timer_id] (note > that the order of 'timeout' and 'timer_id' was changed in many modules) with > the following semantics: > > Timeout | Timer ID | Result > ============================================================================================================= > 0 | not relevant | no timeout > (the function returns immediately). > PLATFORM_TIMER_INF_TIMEOUT | not relevant | the function > returns whenever it's ready, it might block indefinitely > A positive number | not specified | the system > timer is used to measure the specified timeout > A positive number | an actual timer ID | the > specified timer is used to measure the specified timeout > As you can see, the general idea is that you should be able to specify any > timeout without having to worry about a timer ID; if you don't specify a > timer ID it will default to the system timer. > The main modules affected by this change are tmr, uart and net. > > - you don't have to specify the various timer IDs (CON_TIMER_ID, > RFS_TIMER_ID, RPC_TIMER_ID) in platform_conf.h now. If you don't specify > them, they'll automatically default to the system timer. In fact you > shouldn't specify them explicitly unless you have a very good reason to do > so. > - note the new PLATFORM_TIMER_INF_TIMEOUT constant used to specify an > infinite timeout. This is an "universal constant" across eLua now; this > means that different modules don't get to specify their own constants for > infinite timeout anymore (as was the case, for example, with UART and its > PLATFORM_UART_INFINITE_TIMEOUT constant); they must use > PLATFORM_TIMER_INF_TIMEOUT instead. > You can (and are encouraged to) use the system timer from C code too, not > only from Lua code. You can reffer to the system timer with the > PLATFORM_TIMER_SYS_ID constant. Unlike the Lua API, the C API (the platform > interface) was only modified slightly (with the exception of the timers API > that was enhanced quite a bit). In particular, the order of timeout and > timer_id parameters was not changed in the C API. > One important limitation of the system timer is that it can't generate > interrupts. > From an implementation standpoint, this is how the system timer is > implemented on different platforms, in a nutshell: > > - all Cortex-M3 platforms use the SysTick timer for the system timer > implementation. This has a minimum impact on the Lua code since the SysTick > timer was not exported to Lua. This will also be applicable on M4 platforms. > - AVR32 'steals' a PWM channel for the system timer implementation (since > the timer block in AVR32 was simply too weak to implement this feature). > - AT91SAM7X uses the PIT timer (again, minimal impact since this timer was > not exported to Lua). > - LPC24xx 'steals' one of its hardware timer for the system timer > implementation > - STR9 'steals' one of its hardware timers for the system timer > implementation > - i386, str7 and lpc288x do not implement a system timer. Note that since > all timer IDs have a tendency to default to the system timer this might lead > to problems (this was documented explicitly). These platforms are seldom > used and will probably be declared obsolete in the near future, so the > effort for implementing a system timer was not justifiable. If you actually > use one of these platforms please contact me and I'll see what I can do. > > You can find a more in-depth overview of the system timer and its > implementation in the documentation > (arch_platform_timers.html#the_system_timer). > I hope I'm not forgetting anything here. Please don't hesitate to contact me > if you have questions. Also, I encourage all of you to test this new feature > as much as possible, as it is still very much in beta. > Best, > Bogdan > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > -- Best, Marcelo _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
On Fri, Oct 21, 2011 at 10:32 PM, Marcelo Politzer <[hidden email]> wrote: Wow, great job! Exactly. Or you can use the new platform_timer_sys_delay macro and just do this: platform_timer_sys_delay( 10 );
It expands into 'platform_timer_delay( PLATFORM_TIMER_SYS_ID, 10)', just as you wrote. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
|
|
In reply to this post by BogdanM
Excellent! This is something that we've needed for quite some time
(haha) now :-) I'm looking forward to digging in to make use of this and simplify some of the multiple timer implementations I have on some active projects. I've forwarded this along to one of the end users of some control systems in our lab that I set up in eLua since this will make for a nice clean solution to a timing need for his project. -jsnyder On Fri, Oct 21, 2011 at 2:15 PM, Bogdan Marinescu <[hidden email]> wrote: > Hi, > I have implemented (and merged into the master branch) a new eLua feature: > the system timer. It attempts to fix one of the biggest flaws in the eLua > design: timer management (I take full blame for this BTW). The documentation > was updated (so you can read more about this in the official docs), but this > is the summary: I was obviously wrong when I assumed that manual timer > management can actually work in practice. It can (and most of the time will) > become a nightmare for anything but the simplest applications. Having to > manually track timers and their base frequencies is prone to failure and > endless frustration. The system timer is my attempt to fix this. It is a > timer with a fixed, unmodifiable resolution on all platforms (1us) and large > counters: > - 52 bits for floating point Lua and 64-bit integer only Lua (lualonglong, a > new feature). In this mode the system timer overflows after about 142 years > (I know this is hard to believe, so feel free to do the math yourselves :) ) > - 32 bits for 32-bit integer only Lua (lualong). In this mode the timer > overflows after about 1 hour (yes, huge difference here). > The eLua API was subsequently modified to take advantage of this new > feature. I'll say this again: part of the eLua API was modified to take > advantage of the system timer, so be sure to check the updated docs. You can > find a list of the changes below): > - the timeouts are specified in a much more unified manner across different > eLua modules. Their general specification is now [timeout], [timer_id] (note > that the order of 'timeout' and 'timer_id' was changed in many modules) with > the following semantics: > > Timeout | Timer ID | Result > ============================================================================================================= > 0 | not relevant | no timeout > (the function returns immediately). > PLATFORM_TIMER_INF_TIMEOUT | not relevant | the function > returns whenever it's ready, it might block indefinitely > A positive number | not specified | the system > timer is used to measure the specified timeout > A positive number | an actual timer ID | the > specified timer is used to measure the specified timeout > As you can see, the general idea is that you should be able to specify any > timeout without having to worry about a timer ID; if you don't specify a > timer ID it will default to the system timer. > The main modules affected by this change are tmr, uart and net. > > - you don't have to specify the various timer IDs (CON_TIMER_ID, > RFS_TIMER_ID, RPC_TIMER_ID) in platform_conf.h now. If you don't specify > them, they'll automatically default to the system timer. In fact you > shouldn't specify them explicitly unless you have a very good reason to do > so. > - note the new PLATFORM_TIMER_INF_TIMEOUT constant used to specify an > infinite timeout. This is an "universal constant" across eLua now; this > means that different modules don't get to specify their own constants for > infinite timeout anymore (as was the case, for example, with UART and its > PLATFORM_UART_INFINITE_TIMEOUT constant); they must use > PLATFORM_TIMER_INF_TIMEOUT instead. > You can (and are encouraged to) use the system timer from C code too, not > only from Lua code. You can reffer to the system timer with the > PLATFORM_TIMER_SYS_ID constant. Unlike the Lua API, the C API (the platform > interface) was only modified slightly (with the exception of the timers API > that was enhanced quite a bit). In particular, the order of timeout and > timer_id parameters was not changed in the C API. > One important limitation of the system timer is that it can't generate > interrupts. > From an implementation standpoint, this is how the system timer is > implemented on different platforms, in a nutshell: > > - all Cortex-M3 platforms use the SysTick timer for the system timer > implementation. This has a minimum impact on the Lua code since the SysTick > timer was not exported to Lua. This will also be applicable on M4 platforms. > - AVR32 'steals' a PWM channel for the system timer implementation (since > the timer block in AVR32 was simply too weak to implement this feature). > - AT91SAM7X uses the PIT timer (again, minimal impact since this timer was > not exported to Lua). > - LPC24xx 'steals' one of its hardware timer for the system timer > implementation > - STR9 'steals' one of its hardware timers for the system timer > implementation > - i386, str7 and lpc288x do not implement a system timer. Note that since > all timer IDs have a tendency to default to the system timer this might lead > to problems (this was documented explicitly). These platforms are seldom > used and will probably be declared obsolete in the near future, so the > effort for implementing a system timer was not justifiable. If you actually > use one of these platforms please contact me and I'll see what I can do. > > You can find a more in-depth overview of the system timer and its > implementation in the documentation > (arch_platform_timers.html#the_system_timer). > I hope I'm not forgetting anything here. Please don't hesitate to contact me > if you have questions. Also, I encourage all of you to test this new feature > as much as possible, as it is still very much in beta. > Best, > Bogdan > > > _______________________________________________ > eLua-dev mailing list > [hidden email] > https://lists.berlios.de/mailman/listinfo/elua-dev > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
«
Return to eLua Development
|
1 view|%1 views
| Free forum by Nabble | Edit this page |