For many projects, I have one common problem: I run out of I/O pins on my microcontroller . Luckily, I’m not alone, and the industry has created solutions for this kind of problems. One is to use a shift register as the 74HCT595/SN74HC595 which gives me 8 extra output pins. All what I need to spend are are 3 GPIO pins. Not a bad deal: I spend 3 pins and I get 8 (or multiple of it) on return .
So why do I say this for this Arduino Motor/Stepper/Servo Shield tutorial? I have asked in this earlier post with a poll for the next topic (relais, motor or command line interface). Right now votes are mostly for relay. But before I can do relay (or DC motor), I need to first cover the 74HCT559. So here we go to have you ready for the next tutorial
I’m working with a student on building a small autonomous robot platform, based on the FRDM-KL25Z board. We integrated new software modules, compiled and linked, and then downloaded the application to the board. While debugging and stepping through the application startup, I had this:
The Debugger has lost communication on connection
Outsch! That’s not good. Even worse, trying to connect again to the board failed . What happened?
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 .
Arduino Motor Stepper Servo Shield with FRDM-KL25Z
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.
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).