neilh20
Well-known member
Hi I'm curious if anybody else is working extending the lower power paradigm with an event driven model.
I've got the Teensy31 and kudos to Paul for putting together a low cost and low power simple board with the powerful Kinetis MK20DX
I've done a product in the past with a custom Mega2560 (not an Arduino Mega) and used the TinyOs.net paradigm of simple cooperative tasks, event timers and low power paradigm - ideal for wireless sensor networks.
TinyOs uses nesC (network embedded systems C), an extension of 'C' but with simple tasking and split-phase event processing that is elegant. However the tools aren't progressing (suck),has an academic focus, and though powerful for small ram ~2-8K systems - thankgoodness for the MK20's 100Kbytes.
The product I designed is a solar powered water depth gauge for streams - ADC12bits or RS485 of water depth readings, and north wards into the internet Digi XBEE or Cellular GSM SOMs.
I'm looking to transfer it over to the Teensy31/MK20DX, and first doing the wireless GSM SOM that has an XBEE footprint - and fits with a Teensy3+XBee board.
There have been some nice Teensy3 posts on low power.
The other part of low power is the software architecture.
It seems to me this needs to be an event driven model with sleep 99.9% of the time in-between "tasks".
Most of the Arduino code - and its fantastic to see the ideas - is evolved to poll for events.
In contrast for low power design the asynchronous event driven model lets the software be stimulated by events.
In the poll model 99.999% of time is spent polling for an event, which uses (wastes) power.
IMHO, for most software architectures, co-operative tasking is quite adequate - providing the tasks are designed to be reasonably short (in the time domain) - and provides clear benefit for simple design and system stability, compared to the potential issues from pre-emptive multi-tasking.
Pre-emptive multitasking is required when "Hard real-time deadlines" are needed - which are specific design cases - and require greater attention to system stability and debugging.
So I'm wondering if anybody has some pointers on using a C++ class with embedded threads and software timers.?
A thread being a procedure that appears to be executed independently - ie invoked from a scheduler on some criteria - post from another procedure or timer, and has low ram/constructor overheads.
What I've done so far:
The teensy3core/IntervalTimer is good start for software timers, and prototyping the concept of input ISR event to post to a thread, with processing on an array of software timers, and then with expired timers posting to other classes threads. I've prototyped it however getting stuck on the posting to other Class threads.
Tasking references so far, mostly are in 'C' and don't translate to a concept of a C++ class with an embedded thread very well
http://www.codeproject.com/Articles/21114/Creating-a-C-Thread-Class - seems like a reasonable starting point
https://github.com/benhoyt/protothreads-cpp - more tools for a simple design
https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/ - possible starting point
- complex, not structured to able to separate the different classes, not event driven, and partly therefore not clear the level of stability
http://corsi.dei.polimi.it/distsys/2012-2013/pub/17-wsn.pdf -Pg78 is an overview of TinyOS simple threads
https://github.com/tinyos/tinyos-main/blob/master/tos/system/SchedulerBasicP.nc - simple robust fast scheduling algorithm in 'nesC'
http://bharr.is/2013/10/11/toolchain-kinetis-KL25/ Comparision Nuttx, mbed and Contiki - all 'C', selects Nuttx for ease
Nuttx/Contiki/RTOS - complex and benefit if required to use always on TCP/IP, but not for low power system
So throwing it out there, and hoping the feedback can be focused on minimal processing power usage and design.
I've got the Teensy31 and kudos to Paul for putting together a low cost and low power simple board with the powerful Kinetis MK20DX
I've done a product in the past with a custom Mega2560 (not an Arduino Mega) and used the TinyOs.net paradigm of simple cooperative tasks, event timers and low power paradigm - ideal for wireless sensor networks.
TinyOs uses nesC (network embedded systems C), an extension of 'C' but with simple tasking and split-phase event processing that is elegant. However the tools aren't progressing (suck),has an academic focus, and though powerful for small ram ~2-8K systems - thankgoodness for the MK20's 100Kbytes.
The product I designed is a solar powered water depth gauge for streams - ADC12bits or RS485 of water depth readings, and north wards into the internet Digi XBEE or Cellular GSM SOMs.
I'm looking to transfer it over to the Teensy31/MK20DX, and first doing the wireless GSM SOM that has an XBEE footprint - and fits with a Teensy3+XBee board.
There have been some nice Teensy3 posts on low power.
The other part of low power is the software architecture.
It seems to me this needs to be an event driven model with sleep 99.9% of the time in-between "tasks".
Most of the Arduino code - and its fantastic to see the ideas - is evolved to poll for events.
In contrast for low power design the asynchronous event driven model lets the software be stimulated by events.
In the poll model 99.999% of time is spent polling for an event, which uses (wastes) power.
IMHO, for most software architectures, co-operative tasking is quite adequate - providing the tasks are designed to be reasonably short (in the time domain) - and provides clear benefit for simple design and system stability, compared to the potential issues from pre-emptive multi-tasking.
Pre-emptive multitasking is required when "Hard real-time deadlines" are needed - which are specific design cases - and require greater attention to system stability and debugging.
So I'm wondering if anybody has some pointers on using a C++ class with embedded threads and software timers.?
A thread being a procedure that appears to be executed independently - ie invoked from a scheduler on some criteria - post from another procedure or timer, and has low ram/constructor overheads.
What I've done so far:
The teensy3core/IntervalTimer is good start for software timers, and prototyping the concept of input ISR event to post to a thread, with processing on an array of software timers, and then with expired timers posting to other classes threads. I've prototyped it however getting stuck on the posting to other Class threads.
Tasking references so far, mostly are in 'C' and don't translate to a concept of a C++ class with an embedded thread very well
http://www.codeproject.com/Articles/21114/Creating-a-C-Thread-Class - seems like a reasonable starting point
https://github.com/benhoyt/protothreads-cpp - more tools for a simple design
https://code.google.com/p/arduino-scoop-cooperative-scheduler-arm-avr/ - possible starting point
- complex, not structured to able to separate the different classes, not event driven, and partly therefore not clear the level of stability
http://corsi.dei.polimi.it/distsys/2012-2013/pub/17-wsn.pdf -Pg78 is an overview of TinyOS simple threads
https://github.com/tinyos/tinyos-main/blob/master/tos/system/SchedulerBasicP.nc - simple robust fast scheduling algorithm in 'nesC'
http://bharr.is/2013/10/11/toolchain-kinetis-KL25/ Comparision Nuttx, mbed and Contiki - all 'C', selects Nuttx for ease
Nuttx/Contiki/RTOS - complex and benefit if required to use always on TCP/IP, but not for low power system
So throwing it out there, and hoping the feedback can be focused on minimal processing power usage and design.