It happens to me many times: I’m stepping with the debugger through my code, and ups! I made one step too far!
What now? Restart the whole debugging session?
Actually, there is a way to go ‘backwards’ 🙂
Continue reading
It happens to me many times: I’m stepping with the debugger through my code, and ups! I made one step too far!
What now? Restart the whole debugging session?
Actually, there is a way to go ‘backwards’ 🙂
Continue reading
“As an engineer, you should ask for the best tools available. Spending money for better tools can make the difference between finding a problem quickly, or wasting days or weeks, and ultimately failing a project.” (unknown)
I had to learn it the hard way: some ‘hard-to-find-problems’ sometimes only can be found with some amount of luck, or with using a good trace solution. CodeWarrior already supports trace, such as using the MTB on the Cortex-M0+. But with this I’m limited to the on-chip trace buffer or on-chip RAM, which is better than nothing. But to solve the real hard problems, a bit of more power and memory is needed. And here where the P&E Tracelink comes into play: with 128 MByte trace buffer it would allow me to record a lot more trace data :-).
I’m recently dealing again with S19 (S-Record) files. I can easily generate S19 files from my ARM .elf files, but what I need is a simple decoder of the file format.
The good thing is: such a decoder is provided with CodeWarrior for MCU10.x 🙂
That capability is built into the Decoder.exe which is delivered with the Freescale S08 (or S12) tool chain, and is located inside the MCU\prog folder:
If you are a frequent reader of this blog, then you know: I’m a big fan of Processor Expert components. While there are many Processor Expert components delivered with CodeWarrior, it lacks many components and device drivers beside of the normal on-chip peripherals. But value gets added to an embedded project with all the external devices, sensors and actuators. That’s why I have created many more components which are available on my GitHub site. Readers of this blog have asked several times to create a tutorial on how to create a Processor Expert component. So why not working on that on a long Easter weekend full of cold rain and snow?
So here we go: a tutorial how to create a Processor Expert component for the MMA8451Q accelerometer found on the FRDM-KL25Z board:
How cool is this: combine ‘Arduino’, ‘Bluetooth’ and ‘Low Power’ with ‘small size’: an ARM Cortex-M0 board with low power Bluetooth 4.0, shrunk to size of a finger tip! 🙂
This Kickstarter project asked for $5k funding, and it has received over $245k! The video shows the prototype interacting with an iPhone:
It combines Arduino compatibility with the power of an ARM Cortex M0. Given the low-cost and versatility of that board, that would make that board an ideal base for many projects.
Adding an internet gateway, and I will have the ‘Internet of Things’ (IoT) 🙂
Happy RFing 🙂
Many times I have Processor Expert components carefully configured in one project, and then I want to have the same thing in another project. There is actually an easy way to carry out this: to copy components from one project to another.
Using a version control system for software development is a standard procedure today. While things are pretty clear for ‘standard’ Eclipse projects, it is not that easy for Processor Expert projects. I’m using Processor Expert projects with Git and SVN (Subversion). I want to share here tips how to use Processor Expert projects with a version control system. Screenshots and vocabulary are for TortoiseGit and Git, but applicable to any other VCS (Version Control System).
The maze solving robot based on the Freedom FRDM-KL25Z and Pololu Zumo shield has new features:
The FRDM-KL25Z Open Source Logic Analyzer based on SUMP presented here was already very useful with the added trigger support. But it was not capable to do a sampling rate above a few hundred kHz. That’s ok for slower probing, but not for anything with a higher speed. Using DMA (Direct Memory Access) instead of timer based sampling can remove that limitation :-).
If I want a C++ project for my KL25Z Freedom board, I select C++ during the project creation:
This creates a gcc C++ project with all the needed settings.
This worked fine until I added a *.c file to my project which had code in it which was not accepted by the C++ compiler. Wait! Should the *.c not be compiled in C mode, as I was used to with other compilers? It turned out that things are different with gcc (or g++) :-(: the *.c files in my project are compiled in C++ mode. So the question is: how to compile in C mode with the ARM g++ compiler?