I added a section to the Cerberus page for possible future features. Here’s what I added so far:
On the STM32, the ADC is able to read the voltage on the VBAT pin. This allows the processor to monitor the charge of the battery connected to that pin, even if it is a bit higher than 3.3V. It would be nice to have this feature exposed to managed code.
The STM32 includes an internal temperature monitoring peripheral. It would be nice to have this feature exposed to managed code.
Microsoft.SPOT.Hardware.Utility.Backlight()
is connected to one of the LEDs we have in our system, so setting Backlight on/off for sure controls one visible LED, hence there is no need to lookup for the LED pin values anywhere… 
Battery voltage - read back the voltage on VBAT pin
Battery temp - read back the temp sensor…
Antti
Some form of in field update would be really handy… not sure if this is the right place though…
The Whitepaper which is available for the STM32F4 discovery board would be a good starting point… http://www.st.com/internet/com/TECHNICAL_RESOURCES/TECHNICAL_LITERATURE/APPLICATION_NOTE/DM00039672.pdf
double post
The NETMF includes IFU functionality, but it’s not clear to me whether this functionality depends on TinyBooter or not. Someone with more knowledge of the NETMF workings would need to chime in.
IFU ?
STM32F4 has DFU in BOOTROM
tinyclr that is what is currently loaded to cerberus includes well “tinyclr”
this allows MFdeploy to OVERWRITE complete runtime, so if you want to update
you just use MFdeploy… no need for other tools
well… JUST 2 minutes ago, we had flash corruption… MFdeploy did no longer ping
and we had to use DFU recover 
Antti
Can MFDeploy use TCP/IP then?
If you have a big number of devices in the field, you don’t want to connect them all using USB… you want some form of update using the network.
MFDeploy can use
UART or
USB or
TCPIP
IFU = In Field Update
This allows you to update over, for example, a network connection, without using the built-in DFU software in system RAM. You don’t need MFDeploy, USB flash drive, serial/USB connection, or any hardware modifications (BOOT0/BOOT1 pins).
The current GHI products, e.g. USBizi, do this. In that case, I believe it is a GHI-exclusive feature. In NETMF 4.2, however, the framework got built-in support for this kind of operation, which it calls “Remote Firmware Update”.
That’s looking really good!
[quote]Remote firmware update middleware
This would include a PAL level API and a way to leverage it from the native application. The PAL level API will allow to Open/Close a firmware update transaction, save the data to flash, verify for integrity against and origin with a PK verification scheme (similar to what TinyBooter does today today), and eventually commit the change. We will address devices with enough FLASH/RAM resources to make the change transactional first and save the complete set of update binaries to a location in memory. Most likely an HTTP-based implementation will be provided as well as a sample for one or two ports in the PK.
From http://netmf.codeplex.com/wikipage?title=.NET%20MF%204.2%20Roadmap [/quote]
And USBizi does support it, but it leaves very little room for the remainder of the application…
Edit: after reading some threads it seems after enabling the SystemUpdate on the USBizi there is some 100KB left… I was expecting 50KB…