Hello, I've been using and developing some custom parts of eLua for a while:
I did a ks0108b driver and a custom WDT driver, in C. Anyhow, I'm here to discuss 2 things, firstly is any thought about lowpower inclusion in the near future? I'm going to work on it for str9, with a GPIO wakeup. Any comments about that are welcome. I did a simple WDT module also for str9 and was wondering about its inclusion on elua API as a generic module. The API I've used is the following: For Lua: wdt.init(ms) wdt.clear() wdt.stop() For C: void platform_wdt_start(unsigned int ms); void platform_wdt_clear(void); void platform_wdt_stop(void); There would be also necessary an extra cpu function that would give the reboot reason: cpu.REBOOT_NORMAL cpu.REBOOT_WDT = cpu.why_rebooted() int platform_cpu_why_rebooted(void); -- Best, Marcelo _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On Fri, Oct 21, 2011 at 22:00, Marcelo Politzer <[hidden email]> wrote: Hello, I've been using and developing some custom parts of eLua for a while: Maybe a WDT restart could automatically queue an eLua (new) INT ? Tks for the work !
Best Dado _______________________________________________ _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
2011/10/21 Dado Sutter <[hidden email]>:
> > > On Fri, Oct 21, 2011 at 22:00, Marcelo Politzer <[hidden email]> > wrote: >> >> Hello, I've been using and developing some custom parts of eLua for a >> while: >> I did a ks0108b driver and a custom WDT driver, in C. >> >> Anyhow, I'm here to discuss 2 things, firstly is any thought about >> lowpower inclusion in the near future? >> I'm going to work on it for str9, with a GPIO wakeup. Any comments >> about that are welcome. >> >> I did a simple WDT module also for str9 and was wondering about its >> inclusion on elua API as a generic >> module. >> >> The API I've used is the following: >> For Lua: >> >> wdt.init(ms) >> wdt.clear() >> wdt.stop() >> >> For C: >> >> void platform_wdt_start(unsigned int ms); >> void platform_wdt_clear(void); >> void platform_wdt_stop(void); >> >> There would be also necessary an extra cpu function that would give >> the reboot reason: >> >> cpu.REBOOT_NORMAL >> cpu.REBOOT_WDT >> = cpu.why_rebooted() >> >> int platform_cpu_why_rebooted(void); > > Maybe a WDT restart could automatically queue an eLua (new) INT ? True, but I just can't see how this would be configured, because the wdt event would reset the handler to nil (along with all eLua env). Also try to explain a user why the hell this INT keeps crapping his variables :) > > > Tks for the work ! > >> >> -- >> Best, >> Marcelo > > Best > Dado > > > > > >> >> _______________________________________________ >> 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 > > -- []s, Marcelo _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On Fri, Oct 21, 2011 at 23:04, Marcelo Politzer <[hidden email]> wrote: 2011/10/21 Dado Sutter <[hidden email]>: The WDT event would not persist during the reboot. But during the initializations, eLua can check the CPU status to see if it is ressurecting from a normal Restet, a WDT (maybe a Brownout in the future ....) and then queue an eLua INT. Also try to explain a user why the hell this INT keeps crapping his variables :) This wouldn't be too hard, as the default would still be to have WDT disabled. Thus, if a user gets an WDT INT, it would be because he's enabled it. Or maybe we should mimic the low level behavior and expect users to know a minimum about WDT, even if it is only to disable it at the start of his program (unfortunately a very common practise nowadays :). Pls note that on most MCUs (if not all), the WDT is active after a reset and the user has to handle it (or disable). It might be easier to stay with the first option above though. Best Dado
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
2011/10/21 Dado Sutter <[hidden email]>:
> > > On Fri, Oct 21, 2011 at 23:04, Marcelo Politzer <[hidden email]> > wrote: >> >> 2011/10/21 Dado Sutter <[hidden email]>: >> > >> > >> > On Fri, Oct 21, 2011 at 22:00, Marcelo Politzer <[hidden email]> >> > wrote: >> >> >> >> Hello, I've been using and developing some custom parts of eLua for a >> >> while: >> >> I did a ks0108b driver and a custom WDT driver, in C. >> >> >> >> Anyhow, I'm here to discuss 2 things, firstly is any thought about >> >> lowpower inclusion in the near future? >> >> I'm going to work on it for str9, with a GPIO wakeup. Any comments >> >> about that are welcome. >> >> >> >> I did a simple WDT module also for str9 and was wondering about its >> >> inclusion on elua API as a generic >> >> module. >> >> >> >> The API I've used is the following: >> >> For Lua: >> >> >> >> wdt.init(ms) >> >> wdt.clear() >> >> wdt.stop() >> >> >> >> For C: >> >> >> >> void platform_wdt_start(unsigned int ms); >> >> void platform_wdt_clear(void); >> >> void platform_wdt_stop(void); >> >> >> >> There would be also necessary an extra cpu function that would give >> >> the reboot reason: >> >> >> >> cpu.REBOOT_NORMAL >> >> cpu.REBOOT_WDT >> >> = cpu.why_rebooted() >> >> >> >> int platform_cpu_why_rebooted(void); >> > >> > Maybe a WDT restart could automatically queue an eLua (new) INT ? >> >> True, but I just can't see how this would be configured, because the >> wdt event would reset the handler to nil (along with all eLua env). > > The WDT event would not persist during the reboot. But during the > initializations, eLua can check the CPU status to see if it is ressurecting > from a normal Restet, a WDT (maybe a Brownout in the future ....) and then > queue an eLua INT. That still leave the question, which function will handle the INT? > >> Also try to explain a user why the hell this INT keeps crapping his >> variables :) > > This wouldn't be too hard, as the default would still be to have WDT > disabled. Thus, if a user gets an WDT INT, it would be because he's enabled > it. > > Or maybe we should mimic the low level behavior and expect users to know a > minimum about WDT, even if it is only to disable it at the start of his > program (unfortunately a very common practise nowadays :). Pls note that on > most MCUs (if not all), the WDT is active after a reset and the user has to > handle it (or disable). (god Dam MSP430.... :^) ) eLua would have to turn it off during its startup or it would blowup the eLua shell. > > It might be easier to stay with the first option above though. which one? > > Best > Dado > > > > > >> >> > >> > >> > Tks for the work ! >> > >> >> >> >> -- >> >> Best, >> >> Marcelo >> > >> > Best >> > Dado >> > >> > >> > >> > >> > >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> >> >> >> -- >> []s, >> Marcelo >> _______________________________________________ >> 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 > > -- Best, Marcelo _______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
In reply to this post by Marcelo Politzer
Hi,
On Sat, Oct 22, 2011 at 3:00 AM, Marcelo Politzer <[hidden email]> wrote: Hello, I've been using and developing some custom parts of eLua for a while: Note on my side. Also I don't know about any effort focusing on low power eLua. I'm going to work on it for str9, with a GPIO wakeup. Any comments That sounds reasonable I think. With a few additions it can be made into a fairly generic interface. Best, Bogdan
_______________________________________________ eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
On Sat, Oct 22, 2011 at 6:24 AM, Bogdan Marinescu
<[hidden email]> wrote: > Hi, > > On Sat, Oct 22, 2011 at 3:00 AM, Marcelo Politzer <[hidden email]> > wrote: >> >> Hello, I've been using and developing some custom parts of eLua for a >> while: >> I did a ks0108b driver and a custom WDT driver, in C. >> >> Anyhow, I'm here to discuss 2 things, firstly is any thought about >> lowpower inclusion in the near future? > > Note on my side. Also I don't know about any effort focusing on low power > eLua. Indeed, eLua pretty much lights up targets' peripherals like a Christmas tree, which presumably leads to a higher current draw than if they were brought up as needed. There's nothing precluding adjustment to be more conservative about this, particularly since many modules related to peripheral function have "setup" functions which could be used to limit this area of power consumption without any API change, just a change in intent/stages of initialization. There are certainly other considerations such as sleep functionality and varying triggers which can trigger wakeup events or processing, but I'm not terribly familiar with the details of the interfaces and implementations across the platforms that we work with. Power consumption is something that certainly has been on the very periphery of my mental radar, but I've not had any projects that required highly efficient power use (read: they're usually tethered to an AC adapter or a USB port :-) >> >> I'm going to work on it for str9, with a GPIO wakeup. Any comments >> about that are welcome. >> >> I did a simple WDT module also for str9 and was wondering about its >> inclusion on elua API as a generic >> module. >> >> The API I've used is the following: >> For Lua: >> >> wdt.init(ms) >> wdt.clear() >> wdt.stop() >> >> For C: >> >> void platform_wdt_start(unsigned int ms); >> void platform_wdt_clear(void); >> void platform_wdt_stop(void); >> >> There would be also necessary an extra cpu function that would give >> the reboot reason: >> >> cpu.REBOOT_NORMAL >> cpu.REBOOT_WDT >> = cpu.why_rebooted() >> >> int platform_cpu_why_rebooted(void); > > That sounds reasonable I think. With a few additions it can be made into a > fairly generic interface. Ditto. As with the power situation (which is a whole lot more complicated), it might be prudent to take a look at our platforms before committing to the API, but that seems basic enough that I suspect it should be supported fairly well. One minor thought: should the above millisecond unit maybe be microseconds since we use that commonly in the timer module? I realize that's likely beyond overkill for the frequency of a WDT :-) Best. -jsnyder > Best, > Bogdan >> >> -- >> Best, >> Marcelo >> _______________________________________________ >> 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 > > eLua-dev mailing list [hidden email] https://lists.berlios.de/mailman/listinfo/elua-dev |
Free forum by Nabble | Edit this page |