The Vent project was based on the Arduino Nano [...]

That's an ATmega328, 5 V, 16 MHz, 32 KByte Flash ROM, 2 KByte RAM, 8 bit AVR core. It's a nice microcontroller, and it once was impressive.

Compare to the Arduino Zero:

ATSAMD21G18, 3.3 V, up to 48 MHz, 256 KByte Flash ROM, 32 KByte RAM, 32 bit ARM Cortex M0+.

It easily runs circles around the AVR at less power, and you really don't have to worry about memory or CPU speed as much as you have to do with AVR processors.

Note: This microcontroller was not designed to be fast. It was designed to be cheap and low-power, for battery-powered gadgets, probably running directly from a lithium primary cell (CR2032 or similar). And still, it runs circles around the AVRs. Of course, if you let it run at 48 MHz with no strict power management, it will drain a CR2032 quite fast. But as long as you have a battery pack or mains power, you don't have to worry about power management. It won't get warm or even hot. Your peripherals will most likely need much more power than the SAMD21.

One obvious problem when migrating projects are the voltage levels: AVRs on Arduino usually run at 5 V. They could run on 3.3 V and even lower, but the AVR core can't run at full speed with lower supply voltages. Or at least, that's what the datasheet said. Maybe it will run at full speed at 3.3 V, but that is out of spec. The SAM needs 3.3 V I/O voltage, the core runs on a much lower voltage (using an integrated LDO regulator). Interfacing CMOS components (any of the 4000 and 4500 series) is usually a no-brainer, they just work as well on 3.3V. The same is true for many I²C and SPI components (EEPROMs, ADCs, DACs, port multiplier). When driving bipolar transistors, you may need to reduce the base resistor a little bit. Driving MOSFETS is again often a no-brainer, they are voltage-driven, not current-driven. But you may have to check if the MOSFET actually switches with a gate voltage of only 3.3 V. Some don't.

Another, closely related problem is the current sink and source capability of the microcontroller. The AVRs can sink or source 40 mA, depending on the Model. The SAMD21 can sink or source only 2 mA, switchable to 7 mA. So if you drive "high" current components directly from AVR pins, you will need some kind of amplification - a transistor, a logic buffer, or (for analog pins) a voltage follower. If you drive an LED directly from a pin, you need to change the series resistor and perhaps have to change the LED for a low-current, high efficency one.

The SAMD21 does not have an integrated EEPROM. There are some few models that can transparently emulate an EEPROM using a part of the internal flash, but none of them can be found on an Arduino board. But it should be possible to use the self-programming capability of the SAMD21 to manually emulate an EEPROM in the internal flash.

Comparing the prices:

• https://store.arduino.cc/arduino-nano demands €20.00 plus taxes for an Arduino Nano
• https://store.arduino.cc/arduino-zero demands €40.00 plus taxes for an Arduino Zero
• https://www.sparkfun.com/products/13672 demands US$25.95 for a really nice Zero-clone, adding a LiPo charger, but omitted the EDBG embedded debugger, and no pin headers supplied.
• https://www.sparkfun.com/products/13664 demands US$20.95 for a stripped-down board, more in the Nano range than in the Zero range. Same controller, but no LoPo charger, no EDBG, no pin headers supplied.

At work, we really like the SAMD21, it has retired the ATmega series within weeks. No new project uses ATmegas any more. The SAMD21 needs less power, is faster, has more resources, more peripherals build-in, more I/Os, has up to six highly flexible SERCOMs offering I²C, SPI, and USART in a single peripheral, and is cheap. Less than €3.00 for the top-model SAMD21J18A, less than €1.50 for smaller ones.

Plus, the big Sparkfun breakout board linked above is a really cheap way to prototype a new device, as almost all controller pins are available on pin headers. At less than €30.00 delivered, we even don't care if we kill one of those boards during development. (So far, we have not managed to kill one.) Yes, it lacks the EDBG. But we have plenty of ICE programmers available, so not having an EDBG blocking pins is actually an advantage for us. The smaller Sparkfun board does not bring out all processor pins. Not a big deal for most projects, but sometimes you really want all pins. So we prefer the larger board.

See also:

• Re^3: 6502 Perl
• Re^5: Using a controllerless servo on the Raspberry Pi with Perl
• Re^18: CPAN failed install (start at Re^14: CPAN failed install for some context)

Alexander