Going with the factory default can be fine. But an upgrade could give a performance boost plus added functionality. Many of the NXP i.MX RT evaluation boards have an LPC4322 based debug circuit on it. One example for this is the i.MX RT1010 board.
NXP i.MX RT1010 EVK
On such boards, one of the first steps I do is: upgrading the firmware and change it to a better option: improved speed, SWO support plus avoiding issues with the USB MSD device.
In my previous article I showed how to import, build and debug MCUXpresso SDK projects in VS Code. In my lectures and labs we are using a robot based on the NXP Kinetis K22FX512 ARM Cortex-M4F microcontroller, and there is only the v2.13.0 SDK available.
Sumo Robot with K22FX512
The software on the robot uses the latest NXP MCUXpresso SDK v2.3.1. The he Eclipse based MCUXpresso IDE 11.8.0 works fine with all the 2.x SDKs, up to the latest 2.13.0 one.
Solar panels and electrical vehicles become more and more common in Switzerland. Ten years ago I installed solar panels. To use the available solar energy, the electrical vehicle charging box has been augmented with an open source charge controller. The controller monitors the building energy usage and adjusts the current using the Modbus connection to the charger.
Don’t worry: despite all the things going on with VS Code, Eclipse is here to stay probably for many more years. The Eclipse foundation is pumping out releases, and so does NXP with their latest MCUXpresso IDE 11.8.0. Lets have a look…
I’m using the RS-485 field bus in many of my projects: it is very reliable and robust, and easy to implement. And with ModBus there is standardized protocol used in building automation or industrial control applications. For example I’m using the protocol to communicate between battery systems and an EV Charger.
NXP LPC55S69-EVK with RS-485
In this article I show you with an example, how the NXP LPC55S69 can be used with RS-485.
It is August 1st, and Switzerland is celebrating its National Holiday. Rather cold and rainy, so this gets me some time to catch up on things. The preparation for the coming university semester in September is in full swing, and I have the honor to take over building up a new Master of Science in Engineering education module. In the existing courses I teach on the topic of embedded systems, I do use devices and MCUs from vendors like Broadcom, NXP, STM, Nordic, Raspberry Pi and Espressif. This not only means different SDKs, but different IDEs with different debug probes.
Just a subset of different hardware kits used in different labs
Eclipse has been the common factor in the mix with all these, and with all the pros and cons, it worked very well. With NXP having released support for Visual Studio Code, adding an announcement, and other vendors going into the same direction, I took the decision that I want to migrate my lab and lecture infrastructure to VS Code.
In many of my embedded projects I need persistent data or storage for settings. If using an SD card, then FatFS is usually my choice for the file system. But if using an external FLASH memory device, then my preferred choice is usually LittleFS: it is a little fail-safe filesystem, designed for micro-controllers, which I’m using with external flash memory devices.
In the case where there is enough MCU flash, or if there is no external FLASH device available in a design, it can use the MCU internal FLASH as storage storage too. This is the topic of this article:
Embedded hardware comes with limitations, and one if it is the given number of hardware breakpoints. Depending on your MCU, 4 or only 2 hardware breakpoints are available, making debugging and stepping in read-only memory (FLASH) a challenge.
Debugging NXP LPC845 with unlimited FLASH Breakpoints using MCU-Link
Did you know that one can have ‘unlimited’ number of breakpoints in FLASH, with the help of GDB? This is very useful for extended debugging, or if you want to use breakpoints for testing?
Sometimes it makes sense to write everything in assembly, even these days. For example if using a tiny microcontroller. Or just if one just don’t need all the productivity of the C/C++ tools. And it is a good educational experience: getting hands-on on the lower levels.