I have one rule I try to follow every day: my code shall be warning free. Writing software for multiple compilers gets challenging with this rule, but it avoids the ‘not seeing the forest because of the trees’ problem. This rule extends to writing Processor Expert components with CDE (Component Development Environment). What I have missed (and not used) is a useful option to enable debug output:
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?
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.
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…
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?
When I have asked by a student last year if I’m uing Git, I said “Git what?”. Yep, a shame I did not know what Git was a this time. But it is never to late to learn new things.
I was coming from CVS, moved to the successor of it (SVN) and was happy with it. Especially with having a local SVN server and repository, that was (and still is) a great thing. But to truely collaborate with a worldwide community, it is time to use something different: Git.
The Kinetis ARM Cortex-M4(F) is a wonderful machine: a 32bit architecture, plenty of FLASH and RAM, an ideal play field. I love the Kinetis Tower boards, and even more the Freedom board which has an ARM Cortex-M0+ on it. I have a lot of projects on S08, S12 and ColdFire at the university, and they are all using a lot of Processor Expert components. Processor Expert is such a great productivity tool: having software in components allows easy software re-use. With Processor Expert abstracting from the hardware, I can easily port my applications to new boards and processors. Well, until Processor Expert changed for Kinetis :-(.
Typically a Processor Expert component creates two files: a header file and a source file. That’s fine for normal drivers. But this does not work well for more complicated things like an RTOS or communication stacks: these are built from a whole set of source files. So how can I generate multiple files with a Processor Expert Component?
Writing Processor Expert components is not always completely independent of the compiler and underlying microcontroller. In many cases I need to know the compiler for which the source code is generated. Or I need to know on which CPU architecture the code shall run. For this I need to know the compiler and the CPU family.
In my class at the university I’m using a microcontroller attached to a DC motor from Maxon. The job of the microcontroller is to implement (among other things) a PID controller for the motor speed (or position). In the lab we implement the PID and all the related parts of the control loop without Processor Expert. But it easily can be done as well with Processor Expert components, as described here.
Ah, a lot of work went into a new Processor Expert component, and finally it shows up in the component library:
Oh, wait: *that* icon does not look nice enough for that amount of work behind the component?
In my previous post I mentioned the Drivers\Common folder which has ‘include’ files. These files are maintained automatically by the Component Wizard. But what is the purpose of these files?
The Common Folder has *.inc files which are included in the driver as ‘function’ header. The .inc file contains documentation about the function and parameters for that function.
What I describe here is an overview about the different locations, folder and files you will see if you are importing or developing a Processor Expert User component. I’m showing below example screenshot for the FreeRTOS component, as this is probably the most complex one I ever have created.