The Arduino Nano is one of the most popular versions of the Arduino. The low cost of Arduino Nano work-alike clones is one attribute that drives the popularity of the nano design. The use of an ATmega328P makes it compatible with a substantial collection of libraries that go back to the first Arduino that used the ATmega8 - a direct predecessor of the ‘328. Four ‘nano’ designs will be referred to in this document. Arduino Nano refers to a genuine Arduino Nano, Arduino Every refers to the new Arduino Every, nano clone refers to a functional equivalent of a genuine Arduino Nano, and new nano refers to the new design that is the subject of this document. The design of these variants will be analyzed with the goal of creating a new design that has a lower manufacturing cost and remains highly compatible with the legacy nano designs (preceding the new Arduino Every). There is a summary of changes made to create the new nano at the end of this document. PgDn for TL;DR;
The MCU (MicroController Unit) used on the Arduino Nano is the ATmega328P. This is the same MCU used on several other Arduino models and numerous clones. The peripherals are mostly unchanged from the ATmega168 and ATmega8 used on older Arduino models. The most notable change is the increase in flash memory from 8 KiB to 16 KiB and finally 32 KiB. The libraries that are part of Arduino configure the peripherals of the MCU in a way that is suitable for many common uses of a MCU. For example the timer/counter units are configured to generate PWM and also provide a periodic interrupt for timing. In some cases it is necessary to change the configuration of a peripheral to use it for some other purpose. For example the timer/counter peripheral(s) can be used to generate PWM that is suitable for control of small ‘RC’ servo motors. This use requires at a minimum changing the PWM period. The Arduino API does not have a function to do this, so directly accessing the SFRs (special function registers) is required. Doing so makes the application code non-portable to MCU that do not feature the same peripheral and their corresponding SFRs. The new Arduino Every uses a ATmega4809 that features new peripherals. There are certainly advantages to using the latest technology available in the 8 bit AVR family, but SFR and binary compatibility with older MCUs is broken. Existing libraries that access the SFRs will typically be incompatible with this new MCU. It takes courage to
remove the headphone jack break backwards compatibility. A few years ago the venerable ‘328 was revised to become the ATmega328PB. This revised MCU features an additional UART, four more GPIO, two more counter/times, and more. It is not pin compatible due to having more GPIO, so it is not a drop-in replacement for the older ‘328s. This new ‘328 not only has new features, it also has a lower price! Microchip, the manufacturer of the ‘328 often introduces new MCUs at a lower price than their direct predecessor. This creates a financial incentive for users to switch to newer parts and provides Microchip with more demand for these newer parts thus improving the economy of scale. The ‘4809 chosen for the Arduino Every is also less expensive than the ‘328 and contributes to the lower price of the Nano Every versus the legacy Arduino Nano. The new nano uses the ‘328PB to achieve the goal of lower cost while not breaking backwards compatibility.
Most Ardunio and compatible boards feature a voltage regulator so the board can be powered from some voltage above the nominal 5 volts that the ‘328 and predecessors allow. This is typically a LM340, LM7805, LM1117 or similar. A common use of this capability is to use a 9 volt alkaline battery to power the board and circuitry attached to it. Unfortunately this wastes approximately half of the power in the battery. It is mostly lost as heat in the linear regulator and a little by internal losses in the battery itself. An improvement would be to use a switching regulator. The losses would typically be lower, but the component cost is higher. The Nano Every uses a MPM3610 switching regulator. Since the voltage regulator is rarely used and a low cost linear regulator is inefficient in typical applications, the new nano does not have a voltage regulator. If battery operation is needed the ubiquitous mobile phone charger is a great portable source of 5 volts. Over its lifetime it will provide battery power for a much lower cost than disposable alkaline batteries. Another possible battery power source would be 4 AA or 4 AAA NiMh cells. They have a nominal voltage of 1.25 volts, so a battery of 4 cells provides the needed 5 volts. The voltage is quite steady over the discharge cycle of the battery. It is also possible to run the new nano directly from a Li-Ion cell. This requires lowering the clock frequency of the ‘328 to stay within specifications. For stationary power when not connected to a computer the ubiquitous “wall wart” mobile phone charger can be used. Many have a micro USB B connector that will plug in to the new nano.
Most Arduino and clones using 8 bit AVR MCUs have an ICSP (In Circuit Serial Programming) connector. This can be used for programming and debugging the MCU. The signals on the ICSP connector are also on the two 15 pin headers. Since this connector is rarely used and the signals are available elsewhere if needed the new nano does not have this connector.
USB to UART bridge
The first Arduino featured a serial port with a DE-9 connector. This was used to program the ATmega8 via bootloader firmware. The next generation switched to using an FTDI FT232RL USB to serial bridge to allow connection to a USB port. Since serial (COM) ports have mostly disappeared from computers, this was a change that made connecting it to the computer easier in most cases. The Arduino Nano still uses the FT232RL. The Arduino Uno uses an ATmega8U2 or ATmega16U2 MCU as a USB to serial bridge. The Nano Every uses an ATSAMD11 MCU as a USB to serial bridge. Switching to a MCU with USB can potentially lower costs. The FT232RL currently is approximately 2.50 USD in quantities of 10,000. The ATmega16U2 is approximately 2.00 USD and the ATSAMD11 is approximately 1.00 USD. The FT232RL is previous generation chip and probably the most expensive on the market right now. FTDI has the new X series chips that are about half the price of their predecessors but aren’t always a suitable replacement. They are 5 volt tolerant on inputs, but are limited to 3.3 volt output. The nano clones have been available with a variety of low cost USB to serial chips. The CH340G is by far the most popular right now. It is approximately 0.25 USD in quantities of 1,000. That price seems unbeatable by a MCU, but surprisingly it isn’t. The manufacturer of the CH340G also makes the CH551G MCU that currently sells for only 0.18 USD in quantities of 1000. This is what the new nano uses.
USB to serial bridge chips are widely used because the provide a magical solution to connect the UART of a MCU to the “COM port” API of a computer. Everything in between is taken care of by the bridge chip and the manufacturer supplied device driver. Using a MCU for the same purpose requires at a minimum writing firmware for the MCU. In many cases the manufacturer of the MCU will have some sample code to do this. It may appear to just be a matter of using that code, but that is usually not the case. It is often just enough the show the minimum required to make something work. The quality of the code is often lacking to say the least. Some sort of device driver will also be needed if the CDC ACM driver is inadequate. The amount of work required to make everything work as well a USB to serial bridge chip is enough to dissuade someone from choosing a MCU with USB despite the cost savings.
The Arduino can be reset by a high to low transition of the DTR line. This capability is most often used to start the bootloader and program the MCU. To trigger reset only on a transition of DTR and not hold the MCU in reset while DTR is low a 100 nF capacitor is connected between the DTR line of the USB to serial bridge and the reset line of the ‘328. This circuit has proven to work well, but is of poor design. It causes current flow through ESD protection diodes and prevents the use of DebugWire. This circuit could have been eliminated with the transition to a MCU for the USB to serial bridge. The USB MCU could be programmed to briefly pull reset of the ‘328 low whenever DTR is set low. The new nano does this as does the Arduino Every.
The Arduino uses a bootloader to facilitate programming the MCU. This requires that the USB to serial bridge be disconnected from anything that could interfere with programming while programming is in progress. Any application using the COM port on the computer must release the port. This includes the Arduino serial monitor that will automatically close during programming. It may also include disconnecting circuitry connected to the D0 (UART receive) and D1 (UART transmit) pins. Alternatives to using the bootloader are using ICSP or DebugWire. The new nano design connects the ICSP pins of the ‘328 to the CH551. This allows using ICSP instead of the bootloader. This capability can also be used to program the MCU with a bootloader. Circuitry connected to the ICSP signals could interfere with programming just as when using a bootloader. It is possible to program the MCU via the reset pin using Debug Wire, but the protocol is not documented by the manufacturer. There is some documentation created by others so it may be possible to do this with a future update to the CH551 firmware.
Some changes in pin assignments where required due to the elimination of the voltage regulator and the additional two GPIO. The VIN pin that usually goes to the input of the voltage regulator is now connected to the 5 volt line of the USB micro B connector. A zero ohm resistor connects VIN to Vcc (+5V) so that the board in its default configuration will run off power supplied by USB. This resistor can be removed to allow powering the nano separately from USB. One of the reset pins is now D14 - one of the two additional GPIO. The other reset pin is reset by default but can be reconfigured to D15 by moving a zero ohm resistor.
A hardware prototype has been constructed using breakout boards (BoBs) for the ‘328PB and the CH551. The ‘328PB is fitted to a generic TQFP-32 BoB with provision for power distribution and bypass caps on the bottom. A custom BoB was designed for the CH551. It features a USB connector, reset switch, and bootloader switch. The two BoBs are installed in a small solderless breadboard and interconnected with jumper wires. This prototype has been used for all the CH551 firmware development.
Writing the firmware for the CH551 was the most time consuming part of this project. The manufacturer supplied documentation is in Chinese that I can not read, and the example code is for the Keil C compiler that I do not have. Fortunately many others from around the world have taken interest in the CH550 series of MCUs and shared their work. There is an english translation of the documentation and header files for SDCC (Small Device C Compiler). The documentation is terse, but not necessarily incomplete. Some “reading between the lines” and experimentation is sometimes required. For example the header files showed support for USB ping-pong buffers but there was nothing about that in the documentation and none of the sample USB code used that feature. With a bit of experimentation I was able to learn enough to make it work.
After successfully compiling and programming the obligatory LED blinky code, I started working on CDC ACM (Communication Device Class Abstract Communication Model). That is a standard USB device class that was created for use with modems and other telephony devices. The ACM part of the class can be used to create a USB to serial bridge. Current versions of MacOS, Linux and Windows have drivers for CDC ACM as part of a typical installation. The sample code for CDC ACM was run through Google translate to convert the chinese comments to english. The code was written for use with the Keil compiler so some changes where necessary to get it to compile with SDCC. After getting it to compile without errors, I was surprised that it actually worked! I studied the code to better understand how the USB peripheral of the CH551 works. The documentation briefly explains what the SFRs do, but says little about how a USB stack would use them. Most of the code was contained in one giant function with many nested switch/case and if/else blocks. There were some things that just didn’t seem right despite the code appearing to be functional. I spent quite a bit of time refactoring and commenting the code to make it more understandable and make it possible to reuse code with other USB device classes. This was done iteratively with regression testing (does it still work?) after each iteration. Eventually there was very little of the original code remaining and the one large function was replaced by several smaller functions with a very clear specific purpose.
The next step was to implement ICSP programming. The popular AVRDUDE programming software supports numerous programmers with parallel port, serial (COM) port, and USB interfaces. I chose to use the protocol of the Adafruit USBtinyISP because it has a simple minimalist protocol and open source firmware. The protocol uses only endpoint zero and setup transactions. Implementation of the protocol was mostly just a switch/case to handle the various commands. Most of the commands do a little setup work and then call a SPI read/write function. The first step was to handle all the usual descriptors request. When you connect a USB device to a computer, the computer will query the device for several standard descriptors the tell the computer what the USB device is, what standard device class(es) it supports, how the endpoints are configured and more. The computer will use this information to identify the USB device and setup the necessary device driver(s). Part of the CDC ACM code refactoring created some support functions to make handling descriptor requests easy and efficient. Writing the code to handle the USBtinyISP descriptors was trivial and I soon had a CH551 that identified as a USBtinyISP. Another part of the refactoring was adding “printf debugging” to show important USB activity. This initially used the second UART port available on a CH552 and was later revised to use “bit-bang” firmware driven async serial output. The bit-bang code was written in assembly to ensure correct timing and is capable of using any GPIO pin for output. With the CH551 running at its maximum clock of 24 MHz the bit-bang output runs at 3 Mbps. That is the upper limit of many USB to serial bridge chips. The printf debugging is enabled with a preprocessor #define and has minimal impact of USB performance. I told AVRDUDE to query the chip ID and used the USB debugging output to see what USBtinyISP commands where used. I implemented support for these commands and was able to get a valid chip ID and fuse settings. The commands required for reading flash memory where implemented next followed by the commands for writing flash, and then everything else. Now that all the commands where implemented it was time to
break tweak it. I pushed the SPI clock to the breaking point, and then backed off a bit. The USB device descriptor was modified to use full speed USB (12 Mbps) instead of low speed (1.5 Mbps) and maximum packet size of 64 instead of 8. The USBtinyISP hardware is limited to using low speed USB because it uses a ATtiny2313 that does not have a USB peripheral. It uses firmware driven bit-bang USB and isn’t fast enough to do full speed USB. The descriptor changes should “just work” and they did. There wasn’t much of a performance increase because the bottleneck is with ICSP (SPI) not USB and SPI was already running as fast as possible.
USB supports composite devices that allow several USB device classes to be used simultaneously by a single USB device. Creating the descriptors to make this work can be difficult and something that works on one version of one operating system may not work on others. To avoid the possibly painful process of combining CDC ACM with a vendor defined class I chose to implement the STK500 protocol for ISCP programming. This allows the device to present two CDC ACM instances in a composite device. That is something that others have already done and it is proven to work quite reliably. Implementing the STK500 protocol was very similar to the USBtinyISP protocol. A monster switch/case handles the commands and calls the various helper functions written for the USBtinyISP protocol as needed. After a bit of debugging everything was working well. With UART and ICSP support now working simultaneously is was possible to program the ‘328 with the popular Optiboot bootloader using ISCP, and then use it via UART. Some performance testing with a 30 KiB firmware file showed that using ICSP is almost 4 times faster than UART. The CH551 USB to UART also performed a bit better than the CH340. I suspect this is due to differences in USB endpoint buffer flush timeouts.
The CH551 firmware at this point had all the desired features except for one. A very important one. Blinkenlights The CH340 lacks the Tx/Rx LED outputs that similar chips from FTDI and Silicon Labs have so the nano clones drive those LEDs directly from the Txd and Rxd lines. That works when there is somewhat steady data flow, but misses short bursts of data. The Nano Every also does this instead of using additional available GPIO on the SAMD11. The solution is to drive these LEDs from dedicated pins on the CH551 and to [re]start a timer for every character so the LED will always be on long enough to be seen. The firmware is now feature complete!
A 2 layer PCB has been designed using 8 mil minimum trace width, 8 mil minimum spacing and 0.4 mm minimum drill. These design rules were chosen to allow the PCB to be manufactured at low cost. Using more demanding design rules can significantly increase the PCB cost. The Arduino Nano and nano clones place components on both sides of the PCB. This requires a second solder paste, pick-and-place, and reflow operation. Production time and cost is higher. The new nano has components only on the top to reduce manufacturing cost.
Steal This Design
The low cost nano clones are typically manufactured in China and shipped from China. This is the only way to be able to sell them for approximately 2.50 USD including shipping. To take advantage of the cost reduction of the new nano it also will have to be manufactured in China. All the design files with be made available as open hardware and firmware as open software so anyone or any company anywhere in the world will be able to make the new nano.
Summary of changes made to lower component cost
ATmega328P replaced with ATmega328PB
CH340G/FT232R replaced with CH551
Resonator for CH340G eliminated
Voltage regulator and supporting components eliminated
Summary of changes made to lower manufacturing cost
All components are on the top of the PCB
ATmega328 does not have to be programmed with a bootloader
Summary of new features
One more UART
Two more counter/timers
Four more GPIO
ICSP programming (no bootloader required)
No drivers required (uses CDC ACM)