Some specs and comparisons Dec 2016
To get an idea of the differences between the original JeeNode v6 and the new JeeNode Zero, we can first of all view them side by side:
No more through-hole parts - there are almost no µCs available anymore in the easy-to-socket Dual Inline Plastic (DIP) package. The pins of a TQFP chip are 0.8 mm apart, less than a third of the 0.1” standard breadboard grid. With a little experience it’s still quite doable to solder these by hand, but you’ll need a fine-tipped soldering iron, tweezers, flux, wick, and patience.
No more pre-defined “JeePorts” with their 6-pin headers - all the I/O pins are now laid out in a single row, which is still compact enough to fit even in a mini-breadboard.
As you can see, the location of the FTDI header hasn’t changed, but the pinout has a slight twist: the CTS pin (2nd from the bottom in the above pictures) is used as “BOOT0” on the JeeNode Zero: it’s pulled low by default, allowing normal operation, but it needs to be pulled high during reset to enter the ROM-based serial boot loader built into every STM32 µC. Since it’s in ROM, there is no longer a boot loader in high flash memory, as in the original JeeNode. This also means it can’t be missing or damaged anymore: every STM32 µC can be re-flashed using the pins on the FTDI port - it can’t be “bricked” this way.
Here is a quick side-by-side comparison of some of the main features, but keep in mind that this is all based on a prototype build. Some details are still “subject to change”:
|JN Zero rev3||JeeNode v6|
|Architecture||ARM Cortex M0+||AVR|
|Performance||30 MIPS||16 MIPS|
|Clock speed||32 MHz||16 MHz|
|Hardware debug||SWD (JTAG)||TWI|
|Flash size||64 KB||32 KB|
|RAM size||8 KB||2 KB|
|EEPROM size||2 KB||1 KB|
|ADC||12-bit @ 1.1 Msps||10-bit @ 77 Ksps|
|Timers, 16-bit||7||1 (+2x 8-bit)|
|I2C & SPI||1x each||1x each|
|CRC & RNG||yes||N/A|
|Unique hardware ID||96-bit||N/A|
|Voltage regulator||max 5.5V||max 13V|
|Battery holder||optional coin cell||N/A|
|Sleep current||< 2 µA||< 7 µA|
|Dimensions||41x20 mm||80x21 mm|
Several aspects are not apparent from the above summary and require further explanation:
32-bit - A 32-bit µC is not simply doing arithmetic faster, it also means that where the ATmega needs to perform several steps, this often ends up being a single instruction on the ARM chip - this tends to decrease code size.
MIPS - Similarly, the Million Instructions Per Second figure shown above really doesn’t do justice to the fact that the ARM chip can get considerably more done in each clock cycle.
32 MHz - The ARM µC can easily switch clock speeds and even clock sources on the fly - this can be used to dramatically reduce active power consumption.
RAM - An ARM µC does not have separate address spaces for flash and RAM, as everything easily fits in one 32-bit space - there is no special code to access flash, and more importantly: C/C++ strings and constant data do not need to be copied to RAM on startup, so RAM usage can actually be substantially lower for the same code.
DMA - The Direct Memory Access controller can sample the ADC and feed the DAC at very high rates without CPU intervention, faster in fact than even a tight code loop could probably handle - also for SPI and I2C, but the setup effort for small transfers will often not be worth the trouble.
Sleep current - the values given above include the quiescent current of the voltage regulator and keep the timer or watchdog running to periodically bring the µC back to life - whereby the low-power timer on ARM has a wakeup resolution down to 30 µs, versus 16 ms for the AVR.