[Tinyos-devel] TinyOS on Cortex M3?

[Paul Kimelman]

...
> The last time I checked (which was, admittedly, a year ago), there were 
> no sleep current numbers for M3 chips. The brochure claims pretty low 
> numbers. It would be good to see if those hold up in practice; they've 
> always been the issue with ARM chips.

I think you will find that a part designed to run at 50MHz and above with 64K of 
SRAM will always draw more power in sleep modes (hibernate/standby is a 
different matter and they should all be a few uA at most). The problem is that 
SRAM tends to draw a lot of power (a few mA) regardless, especially when 
designed for speed (senseAmps draw more, precharge circuits are bigger, word 
decoders have to be faster nets, etc) as does eFlash (especially when able to 
run at speeds). That is, there is a baseline power number for sleep which is the 
result of the SRAM and eFlash (both of which dominate the chip's die area after 
all) and this is a function of size and max speed.

No, the current crop of ARM parts are not designed to run for years on a single 
battery. That said, three things can be considered if looking at CM3 parts for 
other than gateways/bridges and powered nodes: hibernate, process geometry 
changes, and data models.
Since most WSN nodes/motes are off the vast majority of time, the truth is that 
the hibernate mode is quite viable; this allows a part to be depowered (other 
than some retention memory and an RTC) and then to wake on event or time. The 
choice of how fast to run them once woken can be considered in terms of work to 
be done vs. power at different speeds. But, it is not a linearity. That baseline 
number for things like eFlash and SRAM suggests that getting in and out faster 
may be preferable for many apps in this space. That said, you can get a lot done 
with a more powerful processor, including a lot more pre-processing of the data.
Process geometries are shrinking as you no doubt know. But, the problem is one 
of tradeoffs. Newest/smallest geometries are not only very expensive (multi 
million dollars for a new mask), but tend to be very leaky at 1st (sleep numbers 
are worse than larger geometries, even if run power numbers are better) due to 
difficulties in controlling gate thicknesses and overcoming migration and other 
issues. But, 90nm is now stabilizing as a reasonable geometry in terms of power 
- it is only waiting on eFlash (the key to MCUs). With 90nm, it looks good for 
CM3 based chips to have very good power numbers across the board, using a 
combination of techniques: for devices not pushing the speed barriers, 
slow/normal transistors are very good in both off and on power numbers; SRAMs 
are starting to add more controls for idle use where they depower the current 
hungry components (senseAmps, pre-charge circuits, word decoders, etc) and lower 
the voltage for the rest (so less leakage current); power clamps are easier to 
use more broadly for things not being used (one of the real issues with sleep 
numbers, especially IO rings which run at higher voltage than the logic; eFlash 
will be an ongoing issue (migration, barrier breakdown, etc), but will improve 
in power due to the density allowing for more logic level controls to mitigate 
other issues; with lower overall current needed for run, LDOs and charge-pumps 
are smaller and lose less power in sleep modes.
In spite of all that, the "dumb" mote will still belong to the cheapest, ugliest 
8 and 16 bit parts (I am showing my bias ;-) But, the CM3 based node/mote will 
likely change the notion of what a mote should do. By having far more processing 
power, better code density, more advanced peripherals (including higher end ADCs 
and PWMs and the like), and far more speed range, these motes will do more 
processing of the data locally and within the mesh (sharing data and comparing 
to look for patterns and trends) rather than sending raw data somewhere else to 
be crunched. This will include much finer granularity of data and add things 
like vision (motion detection, compression, etc) and more sensor options. All of 
this allows use of far less bandwidth (especially when having to hop through a 
mesh) and more intelligence in the network itself (only send the results and not 
all the raw data behind it). Since radios use a lot of power (and even with 
improved efficiency, most of that power translates to reach of the signal, 
ability to deal with interference and obstacles, etc) and MCUs driving radios 
use a lot of power (driving pins), more upfront processing means less of that 
power.
With increased energy efficiency of Solar cells (and fast dropping prices) and 
better battery charge/discharge cycling (get to more of that energy, again for 
less money and size), I suspect that soon the focus will change. Maybe that 
leaves TinyOS behind, I do not know. But, I think there are a lot of good 
concepts in TinyOS and the building block approach can work very well for more 
flexible devices (less purpose built, more generalized) as has been seen in 
IEC61131 and the like. Cortex-M3 was designed for just this kind of use. So, the 
future is so bright (in my view) that I am already wearing the shades!

Regards, Paul