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:
To me, one of the most frustrating things working with ARM Cortex-M cores are the hard fault exceptions. I have lost several hours this week debugging and tracking an instance of a hard fault on an ARM Cortex-M0+ device.
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 🙂
I’m using the NXP FRDM-K64F board in several projects: it is reasonably prices, has USB, Ethernet, micro SD card socket and connectors for Bluetooth classic and Nordic Semiconductor nRF24L01+ 2.4 GHz transceiver:
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.
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.
For many of my applications I need to measure a distance. I have used ultrasonic sensors, but there view angle (beam) is not able to detect smaller objects, it very much depends on the object surface and angle, it is slow and not very precise. I have used infrared sensors, but here again it depends on the infrared reflection of the object in range, it depends the amount of reflected light is not really telling much about the distance, and yet IR reflection is subject of material and object targeted.
But there is yet another sensor type to consider: ToF! ToF (or Time-of-Flight) sensors have a built-in LIDAR: The sensor is sending out light pulses and measures how much time it takes for the light to come back. Similar to ultrasonic sensors (see “Tutorial: Ultrasonic Ranging with the Freedom Board“), but instead of ultrasonic it uses an infrared laser light. Or think about a radar system using an infrared laser light.
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…
It seems to me that not many developers use hardware trace? ARM indicates that maybe only <5% of developers are using trace. Too bad! Why are all the ARM Cortex microcontroller vendors putting a powerful hardware (and complicated!) trace engine into their devices, if only few developers are using it? Seems like a waste of silicon and an unnecessary price adder? Well, hardware trace can be a life saver: Because only with hardware trace the most complicated bugs and problems can be solved. And maybe because only the best are using it ;-).
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 🙂 :
Recently I have been running into the following error message in Eclipse when I started the GDB debugger:
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 :-).