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:
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)
Flying a quadrocopter without some sensor and microcontroller intelligence will be a challenge. Definitely I will need some intelligent sensor data to help me out :-). Luckily, there is a Freescale ‘Sensor Fusion Toolbox’ and Library which gives me a nice start and visibility into the sensors I plan to use:
To build an application for a modern microcontroller today is not a simple thing. Well, it depends what ‘simple’ means. But compared to the ‘old days of 8bit micro controllers’ (which are still in use!) developing for a complex 32bit device is definitely a different thing. Not only the complexity has changed, but as well the breath of tools and helpers. In my view, the only constant is ‘change’, and I have changed the way how to develop several times in my career. In this post I present several different techniques I’m using in my development.
These days machines do not have physical serial (COM) ports any more. I do not understand why the USB group had missed to define a clean serial communication standard :-(. And the same mistake gets repeated for BLE again 😦 :-(. So every vendor and provider has its own USB CDC driver and interface. And it is really a big pain of the virtual COM/USB CDC ports installed. I have seen countless cases where “the USB UART or CDC port does not work”. So if you have such a problem, I might have a tip for you: Show hidden devices in the Windows Device manager. But in a special way I had not thought about it!
The Freescale FRDM-K64F and FRDM-K22F have a different OpenSDA (v2) firmware on it: unlike the earlier (v1), that firmware is open and not protected which is a great thing. However, it has the disadvantage if you use the wrong SWD/JTAG header on your board, the bootloader on the K20 OpenSDA microcontroller is gone 😦
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 :-).