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 | |
|---|---|---|
| Microcontroller | STM32L052 | ATmega328 |
| Architecture | ARM Cortex M0+ | AVR |
| ALU width | 32-bit | 8-bit |
| 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) |
| USART | 2x | 1x |
| I2C & SPI | 1x each | 1x each |
| DAC | 12-bit | N/A |
| USB | device | N/A |
| DMA | 7-channel | N/A |
| CRC & RNG | yes | N/A |
| Unique hardware ID | 96-bit | N/A |
| Wireless module | RFM69CW | RFM12B |
| Voltage regulator | max 5.5V | max 13V |
| Battery holder | optional coin cell | N/A |
| On-board LED | red | none |
| 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.