The concept of Linux (Open Source, broad developer base and broad usage) is a success story. While there is a lot of diversity (and freedom) in the Linux world, Linux is Linux and again Linux :-). And the world has (mostly) standardized on Linux and its variants on the high embedded system side.
“The Linux Foundation Announces Project to Build Real-Time Operating System for Internet of Things Devices. Open source Zephyr™ Project aims to deliver an RTOS; opens call for developers to help advance project for the smallest footprint IoT devices.“
Ζεφυρος (Zephyros) is the Greek good of spring and the west wind. Obviously this inspired the logo for the Zephyr project:
One of the biggest road blocks (beside of closed source) using the BLE (Bluetooth Low Energy) stack from NXP is that it requires expensive tools to compile and build the stack. The good news is that I have now the NXP BLE stack for the Mikroelektronika Hexiwear ported to Eclipse and GNU gcc build tools for ARM 🙂
But one issue I have faced several times is that the board works fine while debugging and connected and powered by a host machine, but does not startup sometimes if powered by a battery or started without a debugger attached. I have found that the EzPort on the microcontroller is causing startup issues.
As a standard procedure, I add some console functionality to my embedded applications. That way I have a command line interface and can inspect and influence the target system. One interesting hardware feature of ARM Cortex-M is Single Wire Output (SWO): it allows to send out data (e.g. strings) over up to 32 different stimulus ports, over a single wire.
Playing with RFID and NFC is definitely fun :-), and they are everywhere! For a research project I’m exploring different RFID tags and solutions. I several types around for a long time, but never found the time to actually work on it, so last nightI thought I give it a try, and I have it working with GNU ARM and Eclipse, powered by the NXP FRDM-K64F board 🙂
I kind of hoped that after “Why I don’t like printf()” and all my other articles about printf and semihosting, that topic would be 200% handled and I won’t have to deal with any more. Well, I was wrong and underestimated how the Kinetis SDK is interfering with semihosting. And I underestimated how many of my readers are still using semihosting (even as there are other and better alternatives), so I keep getting questions and requests for help. That’s ok, and I hope I can help :-).
So here is yet again another post about how to turn on semihosting with Eclipse, GNU ARM Embedded and the Kinetis SDK v2.0. This time with the FRDM-K64F board:
Getting a board from a distributor like Farnell/Element14/Mouser (add your own distributor) means that chances are high that the default firmware on it is written years from now because the inventory has not been updated, or because boards are still produced with that original firmware (because of testing?). So what happens if I use board with a firmware developed pre-Windows 8/10 area?
Freshly Unboxed NXP FRDM-KL25Z Board
It might work, but chances are high that the bootloader and firmware is not ready for the ‘modern age’, and as a result the board might be bricked. If you still have a Windows 7 machine around (I do!), you are lucky. If not, then you need to read this article….
More and more of my students are using Microsoft Windows 10 machines, and my computer has been upgraded to Windows 10 a couple of week ago too. From my work and experience, a new operating system causes always some challenges, and Windows 10 is no difference. And no, this is not about Microsoft vs. Apple vs. Linux, this post is about addressing a potential and painful problem which I have observed with Windows 10 machines, and to my understanding it could happen with any other operating system too. The problem is that somehow on several student machines the bootloader and OpenSDA application on their FRDM boards did not work any more.
FRDM-K64F (top) programming the OpenSDA Bootloader (bottom)
A bootloader shall be small and concise. I very much like bootloaders which do not need a ‘special’ program on the host, so I prefer a simple terminal for this. While porting my serial bootloader to the NXP FRDM-K64F board, I have found RealTerm which offers a lot of cool features:
Sometimes it is very convenient to load a new firmware to a board without the need for a hardware debugger. This is usually done with a bootloader. The NXP Freedom and Tower evaluation boards have on-board debug device/microcontroller (OpenSDA) which can load different firmware implementations like CMSIS-DAP/mbed, P&E Multilink or a Segger J-Link OpenSDA applications. Both mbed and P&E implemenations support to program the board with drag&drop: simply send a file to a virtual MSD (Mass Storage Device) to get it programmed. The latest Segger OpenSDA firmware has this ability added now too: Programming the board with a virtual MSD device:
3.5″ Diskette Drives are not widely used any more: CDs, DVDs, memory/thumb drives and downloads from the web are the usual distribution method these days for software. Back a few years ago, software was distributed on one or many 3.5″ diskettes, and even before that time on 5 1/4″ floppy disk drives. So what to do with all these not-used-anymore hardware? Play music with it 🙂
The challenge with the selection of a microcontroller for a project is: which one has the required number of UART, I2C, SPI? Combine this with the desired package (48pins, 64pins? LQFN?), the needed FLASH and RAM size and then even the hundreds of available microcontroller shrink to a handful only. And many times I need to make compromises: such as I need two hardware I2C, but the microcontroller matching all my other needs has only one I2C hardware. So I might end up with bit-banging the slower I2C bus. Doable, but not ideal.
What is cool that some of the newer NXP Kinetis microcontroller come with an interesting hardware: FlexIO. A peripheral hardware which allows me to implement a custom protocol, including driving WS2812B (Adafruit NeoPixel) LEDs with a FRDM-KL43Z board:
NXP FTF Tech Forum in Austin has been a blast! I’m running another FreeRTOS hands-on session (FTF-DES-N2048) this afternoon which yet again is fully booked. But we will squeeze in as many as possible from the waiting list.
One very exciting thing we are going to use is FreeRTOS thread awareness in Eclipse/Kinetis Design Studio: to see and debug the FreeRTOS threads in Eclipse using the Segger GDB and it will show the list of threads in the Debug view:
Time is passing fast, and many components have been updated to make the compatible with the NXP Kinetis SDK V2.0. As a highlight, besides of FreeRTOS the following components are now usable with the NXP Kinetis SDK: