The Hexiwear docking station would have a nice feature: it has embedded a debug circuit (OpenSDA). That way I would not need an external debug probe to debug the Hexiwear. However, a debug probe is required to reprogram the docking station itself:
In “Low Power LCD: Adafruit Breakout Board with Sharp Memory Display” I used a 96×96 Sharp Display (LS013B4DN04) with the Adafruit breakout board, but because that one seems to be EOL (End Of Life), I searched for a replacement. I have found the 128×128 pixel version (Sharp LS013B7DH03), and best of all, it is pin compatible :-). With a small tweak of the driver, it works :-):
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 🙂
The Achilles Heel of the Mikroelektronika Hexiwear is its charging: the charging and USB connector are only designed for a limited number of plug-unplug cycles, and it does not have a wireless charging capability like the Apple iWatch. Until now! I have built a DIY wireless charging system for the Hexiwear 🙂 :
For a university reasearch project I try to pair the Raspberry Pi 3 with a Mikroelektronika Hexiwear using BLE (Bluetooth Low Energy). Most of things worked after a lot of trial and error, but at a certain point I was stuck trying to write to send data from the Raspy to the BLE device.The Hexiwear BLE protocol description is very thin, so I ended up using a BLE sniffer to reverse engineer the protocol with Wireshark.
The Hexiwear (see “Hexiwear: Teardown of the Hackable ‘Do-Anything’ Device“) is a small and portable sensor node with built-in BLE (Bluetooth Low Energy) transceiver. In a research project we try to use multiple Hexiwear in a classroom environment and to collect sensor data on a Raspberry Pi. The Raspberry Pi 3 Model B running Linux has an on-board BLE transceiver too, so why not binding them (wirelessly) together?
Well, things seemed easy at the beginning, and as always, there are many things to learn on a journey like this…
Time is passing by so fast, and the year end is approache fast! I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge:
- Percepio Trace V3.1 for FreeRTOS which includes both Segger RTT continuous streaming and snapshot tracing in a single API
- Generation of sources and drivers so they can be used without Processor Expert using McuLibConfig, removal of dependency to NXP Kinetis SDK: components use a generic API approach to have them working with other SDKs.
- New contributed ExceptionsHandler component
- Callback Setter and Getter in USB CDC stack for simpler option handling
- GenericTimeDate with flexible RTC support and added Unix Timestamp functions
- LongKey events in Key component
- FreeRTOS with optimized task selection on Cortex-M4/M7
- Many smaller bug fixes and enhancements
The Hexiwear device is a great and versatile device with two microcontrollers on it. Developing firmware on a Hexiwear means changing what was originally on it. And sometimes it happens that I’m not sure if the changes are for good. Or that I accidentally destroyed the firmware on the NXP Kinetis KW40 BLE microcontroller :-(. So I had to find a way to restore the original firmware, and this is what this post is about.
About a year ago, on December 7th 2015, Freescale and NXP have announced the completion of their merger. Now it is Qualcomm which wants to acquire NXP? It looks like these mergers are happening faster and faster. The reality is that merging products take more time than anticipated, and nearly one year later I can see the outcome of what comes out of the marriage between Freescale and NXP or between Kinetis and LPC: NXP has announced the MCUXpresso software and tools for Kinetis and LPC microcontroller:
The year is coming to an end, the Holiday season is approaching. In case you are looking for a nice present: I have completed my version of a sand clock: a clock writing the time into sand:
If you are interested to build your own version, I have documented the different steps with tips and tricks…
How to fascinate kids for technology? Show them that engineering is fun :-). At the Lucerne University of Applied Sciences and Arts we have created the ‘MINTomat’: a robotics system for STEM activities rewarding interaction with bubble gums:
Yes, pretty over engineered compared to a normal bubble gum automata, but that’s part of the fun :-).
A new McuOnEclipse components release was long overdue, so I’m pleased to announce that a new drop is available with the following major changes:
- Segger SystemView library with kernel time reporting
- GenericTimeDate supports different hardware RTC devices
- Utility with little endian packet handling functions
- Shell Standard I/O handlers for USB CDC, Segger RTT and Bluetooth
- FreeRTOS and stack size reporting
- printf() support in Shell component
- Various small bug fixes and improvements
Command line tools to build applications are great. But productivity goes up if I can use the standard Eclipse environment with GNU tools. This tutorial is about how to use standard and free GNU and Eclipse tools to build my FreeRTOS application for the ARM Cortex-M4 on i.MX7 🙂 :
My Toradex i.MX7Dual module comes with a preflashed Linux distribution (see “Tutorial: First Steps with NXP i.MX7 and Toradex Colibri Board“). As with any other things, Linux gets updated from time to time, and Toradex publishes new firmware. In this article I’m documenting how I can update Linux in the external FLASH on that module.
In my previous article (see “Tutorial: First Steps with NXP i.MX7 and Toradex Colibri Board“) I have booted the i.MX7 on a Toradex CPU module. In this post I’m showing how to run a FreeRTOS application on that board.
I’m using in several projects different variants of Raspberry Pi boards: they are great and providing a lot of processing power. However, they are not suitable for any hard realtime systems. For a different class of projects I’m currently evaluating the NXP i.MX7 processors: the cool thing with these is that they have up to two ARM Cortex-A7 running at 1 GHz, plus a Cortex-M4 running at 200 MHz. And here things get really interesting: I can run a realtime application and FreeRTOS on that M4, while running Linux on the A7 :-).
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.
In my first post about Segger Ozone (see “First Steps with Ozone and the Segger J-Link Trace Pro“) I missed the fact that it includes support for kernels like FreeRTOS. So here is how to show the FreeRTOS (or any other RTOS) threads with Ozone:
From time to time I face some problems which are really hard to find. Mostly these kind of bugs are very timing sensitive and depend on interrupt execution order. Maybe a dangling pointer is overwriting memory, code is running wild, or some functions are not reentrant as they should be. For these kind of bugs, good tools are worth their weight in gold. The Percepio FreeRTOS+Trace and the Segger SystemView have helped me many times to narrow down such kind problems in my applications. Another ultimate tools is hardware trace: Now I have a Segger J-Trace Pro for ARM Cortex-M in my arsenal of bug extinguishing weapons on my desk:
Dear bugs, look what I have on my desk. Your hiding time is over! 🙂