My latest little project was to build something out of a handful of old HP 5082-7302 numeric indicators and my home-made breadboarded (almost) Arduino. These displays are very easy to use once you get past the errors in (some versions of) the datasheet. That is fortunate because they stopped making them a long time ago and there isn’t much information or libraries available for controlling them.
The result was a timer that counts up from zero and with a button for resetting it, and a pair of Arduino libraries. The first library, HPNumberDisplay, can control an array of HP5082-7300/7302 (and probably 7340) displays. The second library, TimeCounter, can count (increment/decrement) time by arbitrary amounts. All source code for the libraries are available here.
A timer build from an Atmega328p and five HP5082-7302 displays.
I also recorded a short demo using my old camera. The quality could be better. Some day I will buy a proper camera.
As I mentioned in an earlier post I have been using snapshots to back up my OpenVZ servers. At first I used a slightly modified version of the backup script found on the OpenVZ wiki to create backups, and that worked fine except for one missing feature: logging.
This seemed as good an opportunity as any to start learning some Python (which to my great embarrassment I have not used much before). The result is a small Python script OVZ-Backup that backs up all OpenVZ containers (or a subset of them) using ploop snapshots and rsync. If there are errors it logs them with syslog and (optionally) sends out error messages to a list of email addresses/users.
The script sends out email using the ‘mail’ command and can only send them to local users as is. My last HowTo explains how you can use postfix to forward user email to an external address and relay emails sent from local email clients without SMTP support through your email provider’s SMTP server. This would let you send error messages to any email address you want.
While waiting for the hardware I need to get any further on my little programming project I have been experimenting with sending and receiving data from the FRDM-KL25Z through a serial port. Mostly to prepare the tools I will need to debug the system I’m planning on building, and in particular the code and algorithms I will use for file encryption. Unfortunately, sending and receiving files and binary data over a serial port proved to be a little harder to do than I had anticipated. It was possible to do this to some extent by using simple tools like ‘cat’ to write data to the serial port’s device file, but I could not get it to work reliably for binary data or files over a few kilobytes in size. It would sometimes drop data or stop halfway for no apparent reason.
Because of this I wrote a simple little program ‘writetoserial’ that reads the contents of file and writes it to a serial port as binary data. This works far more reliably and I’m now able to send both large text files and binary files to the FRDM-KL25Z.
In preparation for a larger project I have been planning for some time now (involving my FRDM-KL25Z, an emulated USB keyboard, and a bit of cryptography) I needed a list of all USB key codes for keys in a Swedish keyboard layout that produces printable glyphs, and their Unicode/ASCII values. To both my surprise and irritation I could not find any existing lists of key codes for anything except the US keyboard layout. I’m sure they are out there somewhere, but it was faster to simply write a small program for the FRDM-KL25Z that let my try different key codes to see what comes out. Most keys are the same in an SE and US layout so there were only a handful of keys I had to find.
I have uploaded the resulting list to GitHub. Since I had to do part of the work by hand there could be mistakes. I will be updating the list as soon as the program that will be using it is complete and I can verify that the values are correct.
By Viswesr (Own work) [CC-BY-SA-3.0 (http://creativecommons.org/licenses/by-sa/3.0)%5D, via Wikimedia CommonsI recently bought a Freescale FRDM-KL25Z to experiment with ARM and embedded systems programming, and I thought I should share my experiences with using it in a completely open source Linux environment so that others may learn from my (many) mistakes. The FRDM-KL25Z is an inexpensive development platform built around an ARM Cortex M0+ based microcontroller. It has support from several commercial development environments, but there is a lack of documentation for how to make it work on Linux using nothing but open source software. After some research, trial and error, and almost bricking the thing, I finally got everything to work.
This post will show you how to set up a development environment around the FRDM-KL25Z using the GCC toolchain and mbed library. To make it more general I will not use any IDE. This will all be by hand. Once you have it working it should not be a problem
I had to buy a freedom board for a school class, and I was frustrated at first to find that there was no support for the linux platform. I'm personally a fan of the teensy ARM microprocessors which are supported by GCC or the Arduino IDE, now I can add the new micro to my growing collection. Thanks again for the great article!
to set up an IDE around it as well, but that is left as an exercise to the reader.
Getting everything to work will require a few steps.
Install the mbed firmware
Install the GCC ARM toolchain
Set up debugging tools
Download and build the mbed library
Create a simple program
Installing the mbed firmware
There are several firmware variants you can install on your FRDM-KL25Z. You can use whichever version you like as long as it supports the CMSIS-DAP debugging interface (i.e. any firmware other than what came pre-installed). The one I have chosen to use is the mbed firmware. It is easy to use and performs a sanity check on any binaries you give it to make sure that you don’t accidentally brick your device (which you very well might do if you are not careful).
To install the mbed firmware first download the newest version. At the moment (2014-08-13) that would be this one.
Start the board in bootloader mode by holding down the reset button while plugging in the board using the SDA USB port.https://mbed.org/handbook/CMSIS-DAP
A mass-storage device named BOOTLOADER will appear. If you were using Windows it would be enough to copy the firmware file to this device and restart the board, but since you are using Linux it isn’t quite that simple. You first have to mount it using the ‘msdos’ file system type.
sudo mount -t msdos /dev/sdd /mnt
In my case the board shows up as /dev/sdd. This may, of course, be different in your case. Copy the firmware file to /mnt and restart the board. You should now see a mass-storage device named MBED.
To test that everything is working you can try one of mbed’s example programs. Sign in or create an account and click “Import Program”. This will take you to their online IDE where you can export the program to a ‘.bin’. Copy this file to the MBED device and press the reset button. If everything is working then the led will probably start blinking (depending on the example you chose).
You could stop here and just use mbed’s online IDE. The rest of this guide will show you how to compile your own programs offline with GCC and the mbed library, and how to get the USB debugging interface to work.
Install the GCC ARM toolchain
The next step is to install the tools needed to compile your own programs. For this you want the gcc-arm-none-eabi from launchpad. Download the one ending with linux.tar.bz2, unless you want to compile it from source.
Just extract it somewhere, add the bin directory to you path variable, and you are done.
Set up debugging tools
With any new firmware the FRDM-KL25Z will support USB debugging using the CMSIS-DAP debugging interface. To use it we need to install OpenOCD and hidapi.
Open ‘tcl/target/kl25.cfg’ and add the following text to the end.
adapter_khz 50
$_TARGETNAME configure -event gdb-attach {
halt
}
make
sudo make install
Permissions
By default only the root user has access to the device files used for debugging. If you want to give a normal user permission to use the debugging tools you will have to set up some udev rules.
Create the file ‘/etc/udev/rules.d/45-mbed_debugger.rules’ and add the following to it.
This will give all users in the ‘plugdev’ group read and write access to all relevant device files. You could use any group you want, or just a specific user.
To test that it is working run the following command as a non-privileged user with the FRDM-KL25Z plugged in.
If it complains about not finding the libhidapi-hidraw.so.0 library check that ‘/usr/local/lib’ is in ‘/etc/ld.so.conf’, run ‘ldconfig’, and try again.
If you now open a second terminal you should be able to connect to the device with GDB.
The mbed development platform consists of an online browser based IDE and compiler (as you saw earlier), and an open source library that simplifies the development of embedded systems code by hiding low level details from the programmer. This is part we want. To use the library offline without the IDE you will have to download and compile the source code.
git clone https://github.com/mbedmicro/mbed.git
cd mbed/workspace_tools
In addition to the main mbed library, the repository contains a number of other useful libraries that can be installed.
When it is done you can find the compiled libraries in ‘build’. Move them to where you want the mbed libraries to be located.
Create a simple program
Finally everything that you need to build your own programs is in place, but before you can start programming we will have to pull all of the pieces together and show how to compile a program from source code. For this example we will, of course, create a simple program that turns the three LEDs on and off.
Most of the work needed to build a program for the FRDM-KL35Z has already been taken care of for you by the mbed library. All you must do is link everything together and compile it. You could set this up by hand, but I recommend you start out by using this makefile. It will set up all the paths and include directories for you. What is left is to set the path to the mbed libraries in MBED_PATH, set the program name in TARGET, add any local source and header folders to SRC_DIRS and INC_DIRS, and to tell it which mbed libraries to use.
Next, create the file ‘src/main.cpp’ and add the following to it.
#include <mbed.h>
Ticker tick;
DigitalOut led1(LED_RED);
DigitalOut led2(LED_GREEN);
DigitalOut led3(LED_BLUE);
void flip() {
led3 = !led3;
}
int main()
{
led3 = true;
//Flip the blue LED every 5 seconds
tick.attach(&flip, 5.0);
//Flip the red and green LED once every second
while (true) {
led1 = true;
led2 = false;
wait (1.0);
led1 = false;
led2 = true;
wait (1.0);
}
}
Don’t forget to add the ‘src’ folder to SRC_DIRS in the makefile, then compile with ‘make’.
If everything is working as it should it should now create a ‘build’ directory with the file ‘mbed.bin’ in it (assuming you did not change TARGET). Copy this file to the MBED device, wait for it to load it, and then press the reset button. The LED should now start blinking in different colors.
That’s all. You are now ready to start programming your own programs. Build something interesting.
Some helpful tips on how not to lock your FRDM-KL25Z and save yourself much pain
Unless you are careful you will sooner or later manage to “lock” your FRDM-KL25Z. This happens when you accidentally enable the security bits. If you have not set up the mbed library (in particular the *.ld files) correctly then this could happen very easily. The mbed firmware will protect you from this mistake by refusing to flash binaries with the security bits enabled, but there are ways to bypass it using the debugger and OpenOCD.
To check if you have set the security bits open the binary in a hex editor and look at the contents of address 0x0000040C. The last two bits should be “10”. If it isn’t, something is wrong and you should NOT attempt to flash this binary to the board. Seriously, don’t do it!
If you ignored my advice and flashed the board with a binary that had the security bits enabled then you will have to unsecure it. This can be a little complicated, but if you read these instructions and still didn’t follow my advice then it’s your own fault. Supposedly there are tools you can use to unsecure the device, but I have not found any that are free and works in Linux. Fortunately, some variants of the FRDM-KL25Z firmware will unset the security bits when they are installed. You can then reinstall the firmware you want to use. This can require some trial and error, but I have had success with the MSD-DEBUG-FRDM-KL25Z_Pemicro_v114.SDA firmware.
Save yourself a lot of trouble and make sure that you don’t do this in the first place. Unless you know what you are doing only program the device by copying binaries to the MBED mass-storage device.
The first small step in cleaning up my simulator is complete. The result is the JaspXML parser. A simple XML parser/iterator for Java, designed for reading data from large XML files without the memory cost of a DOM parser, or the complexity of a SAX/StAX parser.
It is based on code I wrote for a project during a university course several years back. I needed a way of reading data from XML files, and since I did not know how large these data files would be I used a StAX parser. But StAX parsers are a pain to work with so I hid it behind a more DOM like interface to make it easier to use. It was ugly, but it worked. I later reused and improved the parser during my master’s thesis, when I once again needed a simple way of parsing very large XML files.
JaspXML is based on that final version. I completely rewrote, reorganized, documented, and tested it. What was left is a small and simple XML iterator that can step through an XML document using three commands; next(), down() and up().
next()
Steps forward one step and returns the next element at the current depth of the XML document.
down()
Steps down to the children of the current element.
up()
Steps back up to the parent of the current element.
An example application is provided that uses JaspXML to parse an XML document and prints out the contents of each element.
Random technicalities 