This post starts a small (or larger?) series of tutorials using the Arduino Motor/Stepper/Servo Shield with the FRDM-KL25Z board. That motor shield is probably one of the most versatile on the market, and features 2 servo and 4 motor connectors for DC or stepper motors. That makes it a great shield for any robotic project :-).
Character LCD’s (like 2 lines with 16 characters each) as in this post are easy to use. Much easier to use compared to full graphical LCDs.
The ones I’m using have either 1 or 2 lines, but I saw that there are 4 line displays too. So far my LCD component only supports one or two lines.
Not everyone is familiar with Git, and not everyone wants to use it. Although I think using Git or SVN is something every software engineer today needs to master 😉 To make it easier for the ‘non-Gitter’ to use the Processor Expert components, they are available now as *.PEupd files as described here. However, the *.PEupd files are just a snapshot, and not the latest and greatest. So how to use the latest component sources and example projects without Git?
Last Thursday the new Formula Student race car named ‘julier’ had its rollout to the public at Sauber Motorsports in Hinwil, Switzerland. Again a fully electrical racing car, but this time with 4-wheel drive, improved aero-pack and electronics, and able to get from 0 to 100 km/h in 2.6 seconds!
CMSIS-DAP stands for ‘Cortex Microcontroller Software Interface Standard – Debug Access Port’) has been published by ARM Inc. With this, there is an open source alternative to proprietary implementation (e.g. P&E OpenSDA or Segger OpenSDA).
Beside of the ARM MDK IDE, CMSIS-DAP is supported by Coocox and IAR. And IAR is what I’m using in this post.
Looks like there is some movement on the ‘OpenSDA Front’: After CodeRed has released their RedProbe OpenSDA firmware, now Segger has released an OpenSDA firmware.
With this, I get a low-cost debugging solution similar to the well-known J-Link run control devices. The OpenSDA Segger Firmware is something like a J-Link-lite.
Yesterday was a great day: The book “Software Engineering for Embedded Systems” finally arrived 🙂 :
Why I’m excited about this? Because I had the honor to contribute a chapter to that book 🙂
With my Pololu line following robot I had strange problems with the sensor array: the sensor values were very unreliable. Until I have found the problem: Instead of the expected 3.3V, my FRDM-KL25Z RevD board provided 2.8V instead 3.3V on the P3V3 Arduino header pin:
And that voltage even was lower the more current I needed :-(. Luckily there is an easy hardware fix for this.
As with any software drivers: they are never perfect. The same applies to the Processor Expert components delivered in CodeWarrior for MCU10 or the DriverSuite too. That’s why I have created many more components which are available on GitHub here. All these components are using other components to reach the hardware. But what if a functionality is not exposed through the low-level component? Or what if I want direct access to the hardware? Up to now I had to choose either the Processor Expert way, or to do it in the ‘traditional’ way using an SDK like CMSIS or vendor supplied header files.
With MCU10.4, I noticed that there is another way: PDD (Physical Device Driver).
The MCUonEclipse GitHub repository is great for everyone which is familiar with Git or GitHub. Prevsiouly I was hosting my Processor Expert components on steinerberg.com. Exporting and maintaining the Processor Expert Update Files (*.PEupd) one by one is a lot of effort. GitHub makes things a lot easier, but again: you need to be familiar with it. And not everyone is ‘gitting’ yet. To help the rest of the world (the non-Gitter), I have now published Processor Expert update files for all the components in the repository, so it is easier to install them.
IMPORTANT NOTE: After October 17th 2014, the releases of the McuOnEclipse Processor Expert has been moved to SourceForge, see McuOnEclipse Releases on SourceForge
Usually I do *not* use floating point numbers in my projects. For this, I select ‘None’ during the project creation in CodeWarrior for MCU:
But what if I need to change my mind later? How to change such a ‘no-floating-point-needed’ project to one with floating point format support?
I continue to uncover new things in CodeWarrior in MCU10.4 :-). Remember my post “Switching Processor Package in Processor Expert” about the steps needed to switch from one microcontroller package to another? Although that’s not something I need to do on a daily base, this process is simplified in the new version 10.4 🙂
What was missing in the FatFsMemSDHC component presented here is support for a ‘write protection’ pin. Well, that write protection is not present on micro-SD cards, and on normal SD cards it is a simple plastic thing with no real hardware meaning: it is all up to the software to respect it. While my other SD card components have support for such a write protection detection, it was lacking for the FatFsMemSDHC (for Kinetis) component. Time to fix this!
Freescale has released this week an updated version of CodeWarrior: version 10.4. I’m usually not switching a tools version in the middle of a university semester. Unless I see a real benefit, and the risk is low. Well, I have used it now for a few days, and I have decided to move my projects from 10.3 to 10.4. Why? Read on…