Ambiq Micro’s Apollo is an ultra-low-power Cortex-M4F microcontroller that can utilize less power than the typical Cortex-M3 for many low power applications. I took a look at the Apollo evaluation board (Fig. 1) that can be used to check out how little power an application might use.
Ambiq Micro’s 24-MHz, 32-bit Apollo is designed using subthreshold power-optimized technology (SPOT). While subthreshold transistors use less power, designing a system to use them is more difficult. A significant part of the chip is done using SPOT, but the technique was targeted at energy-consuming areas, resulting in an active mode requirement of only 30 µA/MHz in active mode. The chip only uses 100 nA in standby mode. This results in considerable power savings (Fig. 2). SPOT has been used in their real-time clock (RTC), but that is a considerably simpler device compared to a Cortex-M4F.
The evaluation board is compact with headers on the back that expose all the I/O pins allowing it to be plugged into a suitable carrier board although it can be run without one. I tested it by simply providing power to it via the USB connection.
The Apollo family supports up to 512 Kbytes of flash storage and 64 Kbytes of low-leakage RAM. It includes the floating point unit and has a wake up interrupt controller with a dozen interrupt inputs. The family has an on-chip temperature sensor with ±2°C accuracy and a 10-bit, 13-channel, 1 Msample/s ADC. It has a wide range of timers and serial peripherals including support for I2C, SPI and UARTs. It requires 1.8 to 3.8 VDC and comes in a 64-pin BGA package with 50 GPIO pins or a 42-pin CSP package with 28 GPIO pins. The evaluation board uses the former.
The platform is ideal of wearable and IoT devices and can support wireless operation using external radios. I downloaded the Software Development Kit (SDK) that includes an Eclipse-based IDE and a version of FreeRTOS. This included hardware drivers plus sample applications. The IDE works with the Open On-chip (OpenOCD) debugger command-line terminal interfaces. I did not try out the 10-pin ARM debug port that works with third-party tools such as those from Keil, IAR, Segger, or Lauterbach. The AM-Link mode also the board to operate as a stand-alone debugger for an external target/prototype system for in-circuit debugging. The system also supports the serial wire output (SWO) channel for access to ARM’s Instruction Trace Macrocell (ITM) debug system.
I did not get my hands on the BLE card, based on Dialog Semiconductor’s low power DA14581 that includes an on-board 2.4GHz antenna, or the Sensor Expansion Card that comes with a three-axis accelerometer, gyroscope, and magnetometer, plus an extra 128 Mbits of serial flash memory for storage of sensor data.
I downloaded the Ambiq Control Center and debug tools to start. There are versions for Windows, plus 32- and 64-bit Linux. I choose the latter, but had to fire up a virtual machine to run Ubuntu 14.04 (one of the two supported instances). It is possible to use other Linux versions, or incarnations such as Fedora, but it is a more manual process. The script to install everything is very nice if you happen to target one of the supported configurations. It would also be nice if the script indicated what they were, as I had to look at the script itself to figure it out.
The install script is rather sophisticated, so it will handle conditions where tools like Eclipse may already be installed. Otherwise, it downloads and installs them using the latest supported versions. This includes the other SDK components. It also made things more interesting, since I have a version of Adacore’s Ada running under Eclipse supporting a Cortex-M4F platform. I plan on trying it with this platform sometime in the future. For now, I concentrated on the sample applications provided by Ambiq Micro.
Compiling, downloading, and debugging the samples were no different than using any other Cortex-M4 platform. That turns out to be the case even when trying to optimize power utilization. The chip already does a great job of reducing the amount of power needed because of its design. There really is no special programming approach required other than the usual convention of putting the system to sleep when it is not in use. Of course, there is fine grain power control over peripherals, so only those needed have to be active, but that is the case with most low power solutions these days.
