Many applications need to store persistent (non-volatile) data at runtime: configuration data, error logs, sensor data, calibration values, etc. The question is: where to store that data? If it is only a few kBytes, an SD card or similar is an overkill. Adding an external EEPROM? Sure, that works, but adds an extra part to the design. Some microcontroller have internal EEPROM. But what if not? Why not using the microprocessor internal flash memory?
Internal FLASH vs. external EEPROM
Many times I start with a project and tutorial, only to get interrupted for emergency tasks and assignments. For a long time I wanted to add GPS (Global Positioning System) functionality to one of my projects. While I started a few months ago on this, it took me until this week-end to finish the at least the first part: a SD card data logger with GPS :-): I calculate global positioning and time information, can use it in Google maps and store it on a SD card:
Adafruit GPS Data Logger Shield on a FRDM-KL25Z Board
The Freescale FRDM-K64F is a great board for data logger applications: it has a powerful ARM Cortex M4F with 120 MHz, 1 MB Flash and 256 KByte RAM. Best of all: it already has a micro SD card socket on the board :-).
Data Logger with FRDM-K64F
With the Joystick shield I have a convenient way to drive and control a Zumo Robot without a wired connection:
Joystick Shield with Robot
While things started promising, there was a power supply problem at the end to be solved…
Segger just has released their OpenSDAv2 firmware. The OpenSDAv2 firmware is different from the OpenSDAv1 as it is using a different memory map and bootloader. The OpenSDAv2 e.g. is present on the new FRDM-K64F board. The availability of the Segger firmware is definitely good news for any owner of the FRDM-K64F board: so far only the CMSIS-DAP firmware was available (on top of the mbed bootloader). With this, it was not possible to use the board with CodeWarrior, except with using an external P&E Multilink or Segger J-Link. With that new Segger J-Link OpenSDAv2 firmware, I can now use the FRDM-K64F with any IDE which supports the Segger J-Link :-).
FRDM-K64F with Segger OpenSDAv2 Firmware
The latest addition to my set of Arduino shields is a true fun thing: The ElecFreaks.com JoyStick Shield 🙂
ElecFreaks.com Joystick Board with FRDM-KL25Z and nRF24L01+
I admit: my Ethernet Shield project got stuck because of too many urgent other priorities. I was not happy with the way the project was using configuration data from FLASH memory: I have now multiple ethernet shields in use, and configuring the IP address for each shield is a pain. I have not got DHCP working (yet), so why not using the SD card on the shield for configuration data? And right on time I received a tip from Marc about MinIni: perfect, exactly what I need!
Ethernet Shield with SD card
The new flagship of FRDM boards is the FRDM-K64F board. After FTF I have explored different ways debugging the board, and received many comments and questions about it (thanks!). Freescale announced the supports with the new Eclipse based Kinetis Design Studio (KDS). But until KDS is out, how can I use the FRDM-K64F board with CodeWarrior?
Debugging FRDM-K64F Board with CodeWarrior for MCU v10.6
The mbed for FRDM-K64F firmware (http://mbed.org/handbook/Firmware-FRDM-K64F) has great potential. Unfortunately it seems that edges are still very rough: It happens very often that my FRDM-K64F board gets locked up :-(. I can see that the target CPU is constantly resetting: the red reset LED is always on:
FRDM-K64F Red Reset LED always on
I should have known it better, and I always teach my students that they should take the environment into account. And you know what? This time it was me who missed following that rule.
But from the beginning: For the Freescale Technology Forum (FTF) I brought 4 different Zumo Robots to show developing with the Freedom board and Processor Expert. Clark (thanks again, Clark!) has built and brought the Sumo Dojo, and I brought the bots:
Four Zumo Bots at FTF
MCU on Eclipse 