I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge., which is supposed to be the last release for 2017 :-). This release features several smaller bug fixes, the new FreeRTOS V10.0.0 and extended device support.
“Amazon FreeRTOS – IoT operating system for microcontrollers”: The announcement of FreeRTOS V10.0.0 was one of the biggest news last week for me. Not only is there now a Version 10, the bigger news is that FreeRTOS is now part of Amazon. Wow! Now this explains why Richard Barry (the founder behind FreeRTOS) was kind of hiding away for about a year: he joined Amazon as a principal engineer about a year ago. I think we all have to wait and see what it means for FreeRTOS.
The NXP Freedom boards are very popular. Many of them are inexpensive (less than $20), include a debug interface and can be easily extended with extra shields or boards. Especially the FRDM-KL25Z is very popular: I’m getting told because of Processor Expert and tutorials available on web sites like this one ;-).
Unfortunately there are no small or breadboard friendly Kinetis boards available. There is the NXP LPC800-DIP but with no onboard debugger and without Processor Expert support. We have the tinyK20, but projects tend to use more CPU power, FLASH and RAM space than what the tinyK20 board (50 MHz, 128 KByte FLASH, 16 KByte RAM) can provide. So we ended up designing the big brother of the first tinyK20: the tinyK22 with 120 MHz, 512 KByte of FLASH and 128 KByte of RAM.
ARM Cortex-M microcontrollers can have multiple memory controllers. This is a good thing as it allows the hardware to do multiple parallel memory read/writes. However this makes the memory map more complicated for the software: it divides the memory into different regions and memory segments. This article is about how to enable FreeRTOS to use multiple memory blocks for a virtual combined memory heap:
Many of the NXP OpenSDA boot loaders are vulnerable to Windows 8.x or Windows 10: write accesses of Windows can confuse the factory bootloader and make the debug firmware and bootloader useless. In this post I show how to recover the bootloader using MCUXpresso IDE and the P&E Universal Multilink.
FreeRTOS seems to get more and more popular, and I think as well because more and more debugger and Eclipse IDE vendors add dedicated debugging support for it.
A bootloader on a microcontroller is a very useful thing. It allows me to update the firmware in the field if necessary. There are many ways to use and make a bootloader (see “Serial Bootloader for the Freedom Board with Processor Expert“). But such a bootloader needs some space in FLASH, plus it needs to be programmed first on a blank device, so a JTAG programmer is needed. That’s why vendors have started including a ROM bootloader into their devices: the microcontroller comes out of the factory with a bootloader in FLASH. So instead writing my bootloader, I can use the one in the ROM.
And as with everything, there are pros and cons of that approach.
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following major changes and updates:
- Complete refactoring for 1-Wire stack and DS18B20 temperature sensor components
- Added HID Joystick device class to the FSL_USB_Stack
- New SDK_Timer component to work with Kinetis SDK
- New ST756P LCD driver component
- New TSL2561 digitial temperature sensor driver
- Added ReadByte() and WriteByte() GenericI2C functions
- Added 64bit mapping functions to Utility
- added configUSE_NEWLIB_REENTRANT and newlib reentrancy support to FreeRTOS
- Pull resistor support for SDK_BitIO
- Many smaller bug fixes and enhancements
For reliable applications, I avoid using functions of the standard libraries. They are banned for most safety related applications anyway. I do not use or avoid
printf() and all the other variants, for many reasons including the ones listed in “Why I don’t like printf()“. Instead, I’m using smaller variants (see “XFormat“). Or I’m using only the thread-safe FreeRTOS heap memory allocation which exist for many good reasons.
Things get problematic if
malloc() still is pulled in, either because it is used by a middleware (e.g. TCP/IP stack) or if using C++. Dave Nadler posted a detailed article (http://www.nadler.com/embedded/newlibAndFreeRTOS.html) about how to use newlib and newlib-nano with FreeRTOS.
For many projects it would be cool to build a custom USB Joystick device, either as custom game controller for Windows or any USB host which can be used with a USB Joystick. Instead buying one, why not build my version? All what I need is a USB capable board, some kind of input (potentiometer, push buttons) and some software, and I have my USB Joystick:
Eclipse for C/C++ (CDT) offers two different ways to get out of a debug session: Terminate and Disconnect:
The terminate and disconnect behaviour is not standardized, and varies between Eclipse distributions and debug connection. This article is about how things are handled in MCUXpresso IDE, and how I can influence the behaviour.
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following changes and updates:
- SEGGER SystemView updated to V2.42
- More components to work with MCUXpresso SDK: GenericSWSPI, FXO8500 and SimpleEvents
- SSD1351 display driver supports 128×128 pixel resolution and Adafruit 1.5″ breakout module
- Extended FreeRTOS debug helper settings
- GenericI2C: added ReadWordAddress8() and ReadWordAddress8() functions
- RingBuffer with new Getn() and Update() functions
- Utility with map(), constrain(), random() and randomSetSeed()
- XFormat: new xsnprintf(), contributed by Engin Lee
- OneWire protocol component with Maxim DS18B20 temperature sensor
- Many smaller bug fixes and enhancements
I’m using Eclipse based IDE’s to develop and debug my embedded applications. This works great, as Eclipse has all the necessary tools to edit, build and debug it. But when it comes just to download/flash a binary to the board, then things are pretty much specific to the tools used. With the advent of the new MCUXpresso IDE, here is how that Eclipse IDE can be used for this.
Many of my currently active projects are using Kinetis Design Studio (KDS) V3.2.0 from NXP (I have published many of my projects on GitHub). Now with the advent of the MCUXpresso IDE (see “MCUXpresso IDE: Unified Eclipse IDE for NXPs ARM Cortex-M Microcontrollers“), I have migrated several projects from KDS to MCUXpresso. This post is about how to easily get KDS projects ported and running in MCUXpresso IDE.
To me, software and tools are by far more important than the microcontroller. Because the silicon is a ‘one time kind of thing’, where the software has to be maintained and working over a longer time. And at least my software usually needs to be ported to a new device, so portability and available software and tools are critical to me.
The combination of MCUXpresso SDK (formerly Kinetis SDK) and Processor Expert is unfortunately not supported by NXP. But I have found a way to get them work together in a nice way, and this article is about making that combination possible :-).
With debugging FreeRTOS applications in Eclipse, it is a big to have views available showing all the threads, queues, timers and heap memory allocation. One of the best Eclipse plugins are the one NXP provides for FreeRTOS: they are free of charge and give me pretty much everything I need. However, if you are not that familiar with FreeRTOS itself, here are a few tips to get more out of the plugins.
I’m pleased to announce that a new release of the McuOnEclipse components is available in SourceForge, with the following main features and changes:
- Wait: Busy-Waiting using ARM DWT cycle counter
- Percepio FreeRTOS+Trace: Updated to version 3.1.1, simplified usage of streaming and snapshot mode
- GenericSWI2C: MCUXpresso SDK can be used with the bit-banging I2C driver support
- FreeRTOS: includes updates of the 9.0.1 release, ‘optimized task selection, enabled MPU support (experimental)
- Graphical GUI drivers for screens, windows, icons, headers, text widgets and more
- SSD1351: display driver for Solomon Systech SSD1351 display
- More components are now supported by the McuLibConfig settings
- Many other smaller bug fixes and enhancements