When I showed my 60 NeoPixel LED clock prototype to my daughter and her girlfriend, and they both wanted to have one right away :-). Well, that clock was just a proof of concept, with lots of temporary wiring. So I decided this week-end to beautify it and to make it look nice and clean(er). There is nothing like a week-end project with adding a few more LEDs and features :-).
Adafruit Neopixel Clock with 60+24+12 LEDs
It always takes longer than expected: actually 4 weeks from the first board out of the reflow oven (“First New Zumo Board out of the Reflow Oven“), until I have it working on the Pololu chassis. But now I have a mobile Robot with WiFi, GPS, Bluetooth, nRF24L01+ and all the stuff I have dreamed off 🙂
New Zumo Robot
The wired Ethernet connectivity works out of the box with the Freescale RIoT board :-). But to make it more ‘IoT’ capable, a WiFi connection would be a big plus. The element14 site did not tell which WiFi dongles are supported, and a thread in the element14 forum on that topic has not really provided much information. With some risks I decided to order the Wi-Pi WiFi dongle which seems to be popular in the Raspberry Pi community (thus that Wi-Pi name?). And as I anyway have a Raspy, my thinking was that if it does not work with the RIoT board, I still can use it with the Raspy 🙂
Wi-Pi WiFi with the RIoT Board
I understand the challenges of board vendors: they produce many boards, and typically they have an early/first firmware version on it. And when that board gets shipped to customers, that firmware typically is old and outdated :-(. Same for the RIoT board I have received: I was desperately trying some advanced features, only to realize that the firmware on the board is an older one from this year. So time to update the Android on that board.
Freescale RIoT Board
I admit: I love command line interfaces. Because that gives me usually much more control than any GUI (Graphical User Interface). I like the fact that they have put a UART interface on the RIoT board:
J18 UART on the RIoT Board
After the problems with level shifters (see “First Adafruit NeoPixel Blinks with the FRDM Board“) I received the ordered 74HCT245N. Put it on a bread board, wired it up, … only to find out that the device gets very hot… turned off power, and realized that had the device put in with a wrong orientation 😦 oh darn! That’s why I always order things like that in quantities of 3 or more :-). Corrected the mistake, and things are running (or blinking) again 🙂
74HCT245 Wiring for WS2812
I had great plans for this Saturday: to work on really cool project. But as so many times, things turned out to be different. Maybe you have read my recent posts about printf()? A colleague wanted to use that article to the same thing with the Kinetis Design Studio on the FRDM-K64F board. I used the FRDM-KL25Z board, so I expected this to work out of the box for him too. Well, turned out that I was wrong about this, and my Saturday was used for debugging and googling about a printf() problem 😦
While things work as expected for the FRDM-KL25Z (ARM Cortex-M0+) and using the standard GNU GCC ARM Embedded from the launchpad, the application traps on the K64F (ARM Cortex-M4F) in initialise_monitor_handles() with KDS:
Trap in initialize_monitor_handles()
The Freescale Kinetis Design Studio (KDS) V1.0.1 beta is using a different GNU ARM toolchain than the ARM Inc. supported one on launchpad (GCC ARM Embedded). Additionally, KDS is using newlib 1.19 and newlib-nano 1.0, while there just has been a new release of the GCC ARM Embedded a month ago with the 4.8.4 update 2 release in June this year. So how to upgrade KDS to the latest and greatest GCC ARM Embedded?
In “Semihosting with Kinetis Design Studio” I’m using the debugger with semihosting to output text with printf(). But how to use a physical serial connection instead?
printf() and scanf() in action
This post is about how to enable and use printf() and scanf() with GNU ARM libraries. I show it both for the Freescale Kinetis Design Studio (KDS) and for stock Eclipse Kepler with the GNU GCC ARM Embedded (launchpad) toolchain and libraries. The principles are the same, just the details are different ;-).
While new Freescale boards come with the OpenSDA debug firmware, I still students using boards with the OSBDM/OSJTAG. And with new CodeWarrior tools, it might be that there is a new OSBDM/OSJTAG firmware, and when I download to a board with an older firmware, the tool will prompt me to update the firmware. To me, after doing this several times, not a big deal. But for someone who sees this the first time, it might not be that easy. So to avoid any further questions, here we go with a step-by-step tutorial how to update the OSBDM/OSJTAG firmware.
MCF52259 Tower Board with OSBDM Firmware
