Category Archives: Microcontrollers

Freedom Board Resources

Introducing The Freedom Board

This article lists some resources useful for experimenting/working/having fun with the Freescale Semiconductor / Element14 Freedom Board KL25z.

The Freedom Board KL25z is an inexpensive (about 12 AUD) Arduino form-factor compatible platform which sports a microcontroller with a 32-bit ARM Cortex M0+ core, rather than the humble 8-bit AVR CPU of the Arduino itself. The board includes an OpenSDA debugger/programmer so no other hardware is required, other than a USB cable.

Official Documentation

Other Resources

At the time of writing, it appears that the Codewarrior for MCU 10.3 beta is no longer available. This is a shame as, using gcc for ARM, this beta (Windows only) gave unlimited code size. The regular Special Edition (free) only allows up to 64kb code size. This isn’t to say that other development environments can’t be used, as an ARM Cortex M0+ is an ARM Cortex M0+, whatever the manufacturer. However, I like to use this Eclipse-based IDE as it features the excellent Processor Expert, which allows rapid configuration and code generation for on-board peripherals and common tasks.

Another reason I like to use Codewarrior is that Erich Styger’s blog is an absolutely first class learning resource for both Codewarrior/Processor Expert and the Freedom Board itself. Combine this with the Freescale Community site, and you will be well-supported in your efforts to make your Freedom Board do Cool Stuff.


I – and others – have been through some very frustrating times with the Freedom Board due, in my mind, to poor documentation. It will not debug from Codewarrior out of the box. The supplied firmware allows for drag-and-drop programming. To go to more conventional debug/programme with Codewarrior, it is necessary to change the firmware to get the full benefit of the OpenSDA goodness. Erich Styger describes the necessary process here.


All in all, the Freedom Board KL25z is an excellent tool at an exceptional price – made all the more valuable when combined with Erich Styger’s learning resources.

For those interested, an alternative product from Texas Instruments exists in the Stellaris Lauchpad. This ARM Cortex M4F-based tool comes in at a similar price point. Rather than following Arduino form-factor, the Stellaris Launchpad follows on from TI’s previous MSP430 Launchpad, and is compatible with some of the Booster Packs (equivalent concept to the Arduino shield.)

Whether experimenter, student, or embedded professional wanting to do rapid prototyping, the Freedom Board and the Stellaris Launchpad have made working with ARM Cortex microcontrollers very simple and affordable.

Microcontrollers – Moving Forward

More Than Just A Hobby

Whilst I have been playing (and I can’t think of a better word) with microcontrollers on and off for a few years, as I am beginning to incorporate
custom embedded hardware design into my business, I have had to start
re-evaluating both the parts I use and the tools with which I develop
the necessary firmware.

Nearly seven years ago – when this was very much a hobby – I
wrote in this journal of my plans to evaluate different families and manufacturers of 8-bit microcontrollers. The first part of my evaluation was
to look at the sampling performance of the shortlisted manufacturers.
My report on this attracted a response from Freescale Semiconductor
and it is that response, the ongoing correspondence and support that
came from it, that has made me comfortable with my decision that
Freescale parts will be specified first in the designs for my major projects.

The Other Contenders

It’s not going to be Freescale all the way. For one, I don’t think that
vendor lock-in is wise in any business, but the main reason is that I just
want to have experience with other families of devices.


Up to this point, just about all the work I have done has been with
Atmel AVR parts. AVR has an excellent Open Source toolchain
but, otherwise, I don’t really seen any particular advantages. I think
that I have only persisted with them to date is because any other family
presents a learning curve, and I have a few parts to hand looking for
gainful employment.

From a commercial perspective, the fact that the
ATMega128 costs twice as much from my distributor (Element 14) as
does the very similarly specified Freescale MC90S08AC128 makes me wonder
whether I have been working with AVR only on the strength of said
toolchain. (Although the AVR community, particularly
AVR Freaks, is pretty good.)
I have a design which I have built (but not programmed) with AVR parts –
but this will be my last, other than quick “junk box” projects.


The Texas Instruments MSP430 range of 16-bit devices has much to recommend it,
and I will be using it in my Solstice Clock project, when I finally have the time to get back to it. I am drawn
to this line partly by the excellent low-power performance of these devices – and thus suitability for running for long periods of battery – the excellent
and inexpensive, nay, dirt-cheap, LaunchPad development board, which can also serve as a
JTAG programmer for other devices and other low-cost and interesting
development products, such as the very hackable
EZ430 Chronos sports watch.

Last, but not least, it was the book MSP430 Microcontroller Basics by John H. Davies that sold me on the line. It’s possibly the best-written
microcontroller book I have ever read, and gave me more than a few
‘Eureka’ moments on concepts with which I had formerly struggled.

The let-down of MSP430 is that the development tools provided by TI are Windows-only. To run anything on Linux, I need to use GCC for MSP430 – not an issue. However, the mspdebug tool,
which is required to – via the LaunchPad – programme devices, does not
keep pace well with new parts, making development on Linux a tricky affair.


I still have Dallas samples of 8052-based devices. I will be using these
more for my own education than anything, because not having worked with
anything from the 8051 family is a bit like studying English literature
without including Shakespeare.

And The Winner Is Freescale Semiconductor

Why Freescale? If I consider the entire product range, rather than
just microcontrollers, my reason for going the Freescale route may be
summarised thus:

  • A very broad range of microcontrollers.
  • CodeWarrior – an IDE which actually runs natively on Linux which
    covers everything from simple 8-bit HCS08 up to the 32-bit
    Kinetis (ARM Cortex M4) parts.
  • A very interesting range of digitally-interfaced sensors.
  • Very important: the exceptional level of
    support that I have received from Freescale, despite my being a
    one-man operation, and even when I was really just in hobby-mode.
    The Kinetis samples I was given recently only being the latest part
    of this – and I can’t wait to get board designed for them.

For the time being, I will be working with HCS08 devices for my main projects,
with some stuff brewing in the background based on the Kinetis ARM parts –
the mixed-signal capabilities of which I am planning to incorporate into
synthesizer modules.

Whilst in hobby-mode, I have always tried to use only Open Source tools,
for reasons of cost as much as anything. When I first started looking at
Freescale devices, all those years ago, my only feasible tool option was
SDCC – and whatever programming
tool was available then. CodeWarrior was a Windows-only affair, and thus
out of the question.

Re-visiting now, I am delighted to find that CodeWarrior is now Eclipse-based, and will run under Linux natively. Whilst there was a time when
I was all about idealism (using Open Source,) I have become somewhat more
pragmatic with age, and now focus on task completion rather than noble
causes. CodeWarrior looks like it will do the job for me, both with
HCS08 and Kinetis parts. The free version is code-size restricted – if that
becomes an issue, I will buy an appropriate license – if I am ever able
to figure out all the licensing options and what exactly they entail. (Black
mark there, guys.) I have already been down this route with the Cadsoft
Eagle PCB design software, and feel quite comfortable with paying for
these things, albeit somewhat lighter in the wallet regions. This is,
after all, business – and I am sure that the time that I save using
a development environment tailored for the parts I am using should more
than recompense me for the financial outlay.


It is the merits of a broad choice of products, a single development
environment that takes care of all those in which I am interested and – above
all – the peace of mind that there is a Big Company that gives a damn
about the small operator that has created my brand loyalty for Freescale
Semiconductor. 2012 will see the development of systems for one project,
already underway, using HCS08 parts and some interesting designs I have in
mind for my precious Kinetis parts – finally I can get my hands dirty
with some ARM!

The Solstice Clock – Part 3

schematic of solstice clock prototype
Solstice Clock Schematic

Solstice Clock Circuit Design

In part 1 and part 2 of this series, I started to describe my concept of a Solstice Clock and some of the design parameters. This post is just a brief note to present the circuit schematic for the clock motor driver and the corresponding circuit board layout.

Minor Changes

I have made a minor change to the circuit as described in the previous article. The circuit now includes an 8-way DIP switch rather than a 4-way one. The reason for this is to provide a means by which the length of the pulses driving the clock motor may be controlled. Too short a pulse and the clock may not tick or – even worse – tick intermittently. Too long a pulse and excessive power is consumed. Whilst I do not see the solenoid or microcontroller getting burned out, a reduction in battery life would occur.

In a production environment where only one type of clock mechanism is being used, it is possible to find a pulse length that works with all members of a batch of mechanisms and set the pulse length in the firmware. For prototypes however, especially when different mechanisms may be used, the ability to change the pulse length without re-programming would appear to be most appropriate.

Board Layout

Solstice Clock Board Layout

The image of the board layout presented here is – theoretically – 1:1 scale. It is on my computer but I have no idea how other web browsers may mangle it. For those in doubt, it has about the same footprint as a box of regular safety matches. Before you say "whoopee, isn't it small?" I would advise that this is just the controller board. Somewhere in the back of the clock we need to fit in a pair of AA cells to power the thing. These may be either in two single holders (might make it easier to fit in) or together in a side-by-side holder.

The Solstice Clock – Part 2


In Part 1 of this series, I outlined my concept of a Solstice Clock. Since writing the original article, I have modified a regular quartz clock and have estimated the requirements to drive it.


My original drive circuit was rather complex – excessively so. Having now reconsidered the requirements (for instance, removing the facility to set the time via a serial data connection) and calculated the drive requirements of the clock solenoid, I have found that a minimal implementation of a Solstice Clock could consist of no more than a microcontroller, timing components a couple of BAT54S dual diodes (protection for the 2 port pins connected to the solenoid) and that's about it.

This more minimal system would use less power (runs on a pair of AA cells – the original would have required 4 or 5) and also fit into far less space than the original. The latter consideration could be important if there is little space in the back of the clock for modifications.

Choosing a Chip

Whilst the very minimal version could be implemented with an Atmel ATTiny45 – making for a very small circuit board – I have decided to make my prototype with a little more flexibility which requires more than the 8 pins of the ATTiny45 and have thus selected the ATTiny2313V. The 'V' is significant – this lower-powered version of the device can operate right down to 1.8V with a clock frequency of less than 4MHz or 2.7V with clock frequencies all the way up to 10MHz.

After playing around with a spreadsheet, I checked some crystal values to see what gives the most accurate results. Actually, it wasn't quite that way – I first looked on eBay for cheap job-lots of crystals in the 3Mhz to <5Mhz range and then ran those through the spreadsheet to find the ones most suitable. I now have batches of 4.9152MHz and 3.579545MHz crystals to play with. There is a trade-off between the time resolution that I can obtain and power consumption; the higher the clock frequency, the better the resolution, but the higher the power drain.

More than just the Tropical Year

My original plan, when I was thinking of controlling the clock through a serial interface, was to be able to vary the 'tick' rate to allow for differing year lengths. Whilst I am now using a mean Tropical Year (so a fixed length), I realised that it would take little effort to provide other mean periods that the clock could operate on. The final list is this:

  • 1 Tropical Year
  • 1 Synodic (Lunar) Month
  • 12 Synodic Months
  • 13 Synodic Months

These 4 periods would be selectable by two positions of a 4-bit DIP switch. This leaves me with 1 switch to control stop/run and another switch reserved for future use.

Setting Up

I have discovered – somewhat to my annoyance – that most quartz clocks provide a means of setting the hour and minute hands, but not one for setting the position of the second hand. As this hand is representing far more substantial periods of time in my slowed-down clock, I have decided to provide the means of setting this hand through the electronics. The stop/run switch will be set to stop, then a push-button held down until the second hand is at the appropriate position. The hour and minute hands would then be adjusted by the regular twiddler on the back and the stop/run switch set to run when ready.

Moving On

In the next article of this series are presented the circuit schematic and board layout of the Solstice Clock prototype.

Open Source MIDI Control Surface

I am in the process of designing a MIDI control surface so that I can control knob-less synthesisers and also control virtual sliders in Digital Audio Workstation applications like Qtractor, Rosegarden, Ardour, etcetera.

The design is made around an 8-bit Atmel AVR microcontroller, a Texas Instruments ADS7961 16-channel, 8-bit ADC, an array of 16 potentiometers, a cheap 2-line character LCD, some buttons and possibly a numeric keypad, although my current thought on that is ‘bloat’.

Firmware will be written in C, compiled with avr-gcc with the avr-libc C library.

I’m currently struggling over how to avoid sending MIDI ‘noise’ from the pots. I can foresee that the ADC will be picking up changing values without the pots being touched. How to determine whether a change is ‘real’ and needs to be transmitted as a value and what to ignore is the issue. Average a number of samples and then send only if the value has changed from the last average, ignoring any changes smaller than the two LSBs? I don’t know and am open to suggestions.

Software will allow each pot to be assigned a MIDI channel and controller. I’ll probably set it up so that assignments can be saved as programmes which can be recalled depending on what one is controlling.

Once I get to that stage, links to schematics and source code will be posted on this page. This will all be released under a Creative Commons Attribution-Share Alike license. (So yes, you could build this and sell if if you wanted to.)

Anyone interested in this project, please get in touch. There is an e-mail address at the bottom of the page, if you don’t already have one for me.

What About Midibox?

A couple of people have asked me if this is like or had I seen Midibox. To this I would answer not really. This project:

  • Is aimed at producing a very basic/simple/cheap device. Midibox is modular and far more sophisticated.
  • Will be using a different family of Microcontrollers (I’m an AVR man, not a PIC man) although the level of simplicity that I’m looking at should make it fairly easy to adapt to other families such as HC08, 8052 – or PIC.
  • Won’t have an operating system.

So it’s about minimalism, whereas Midibox is about modularity and flexibility (as far as I can see). And the reason that I’m doing this as opposed to re-creating an existing design (like Midibox) is because I want to. I like doing things from scratch.


I have decided to use an AT90S8515 for development purposes since:

  1. I have worked with these before.
  2. I have an STK500 development board/programmer.
  3. I have a couple of devices kicking around in my office in PDIP packages, which are easy to get probes on when doing diagnostics.

Whilst this device is technically obsolete its replacement, the ATMEGA8515, is compatible and very cheap at approximately $4 AUD from my regular suppliers, Soanar Plus. (This supplier may not have a huge range, but prices of single/low volume items are often considerably cheaper than the likes of RS, Farnell, etcetera.)


The Solstice Clock – Part 1


My daily routines tend to be vague, imprecise and are subject to the fragilities of my heath, I am no slave to the clock. (The notable exception to this is when it is time to make the dinner; you can set your watch by it.) Over the last year, however, my fascination with the measurement of time, and the history of the same, has been on the increase.

For several years, I have been disenchanted by some of the artificial, arbitrary and often (to me) pointless aspects of modern, 'Western' timekeeping. Take daylight saving, for instance; I have read the various arguments for it, but have yet to see one which does not have a pertinent counter-argument or that justifies upsetting timekeeping around the globe. The changes in various countries and states are not even synchronous. (The USA and Europe are a couple of weeks apart in their change-over dates. In Australia, the state of Queensland does not even have daylight saving – and good for them, I say.)

A more recent annoyance that has come with my entering the age-group that might be termed 'grumpy old man' is the Gregorian calendar. Follow the link if you want to know more about this – I am not going to repeat at length what is recorded in innumerable places. I concede that the Julian calendar had a year that was a little too long and was getting further and further out of whack with the Tropical year. However, what really makes me grit my teeth is the totally arbitrary (in terms of the Tropical year) start point. The Vernal Equinox (Autumnal Equinox for those of us living in the Southern Hemisphere) tends to be the reference point for the Tropical year, but I can see that this would not fit in with the whole 'Rebirth of the Sun' thing, which would make the Winter (or Summer in the Southern Hemisphere) Solstice the reference point. But no, a point some 10 to 11 days after the Winter Solstice is what we've got to put up with.


Let's turn our attention now to calendars in the physical sense. Without any further ranting about the artificial and arbitrary length of the weeks and months of the Gregorian calendar, what does this calendar mean to most of us? Generally, a set of 12 printed pages, broken down into grids so that we can see a correspondence between days of the week and days of the month. This grid may have pre-printed information telling us useful-to-know things like "Moon waxing gibbous" or "Sow mangold-wurzels now!". There may even be space to write our own information like "Wedding anniversary next week", "Wedding anniversary tomorrow", "Wedding anniversary", "Doh, missed it again! In dog house."

If we look at a clock, it tells us what time it is. If we look at the calendar described above, does it tell us what date it is? The answer is no. Despite the fact that calendars that tell you what the date is have been around for quite some time (e.g.: Stonehenge), the ubiquitous paper (or other medium) calendar gives us absolutely no idea of what date it is.

The Importance of Calendars: Food

What events of real importance are indicated by calendars? Irrespective of the calendar system used, the most important thing that I can think of that might be indicated by a calendar is the timings involved in agriculture – the sowing and harvesting of crops, the gestation of livestock, etc. Without these, we have no food. (I suspect that the world population is a little too large for a total reversion to a hunter-gatherer system.)

So, calendars can be of importance, in more widespread terms than the occasional murder due to forgetting one anniversary too many. Our graphic calendars, diaries and almanacs still do not help us know where we are in annual cycle. There are many seasonal indicators that can tell the farmer that it is time to start ploughing (like the snow may have melted so that there is actually ground visible to plough) and – of course – there are always the stars for those who know how to read them, and don't live somewhere that has a permanent overcast. The moon is always a good time-reckoner and many calendars are based on it – you still need a clear sky to watch it though and some way of keeping track of how many moons have passed since event X.

A Clock is a Fast Calendar

As I mentioned earlier, a clock can tell us what time it is. If we take a mechanical clock and add a few more gears (a divide-by-24 from the hour hand shaft), we can make it count days. If months were of a regular length, we could reduce further and have a months dial. Months of irregular lenght may also be dealt with, even for leap years – far more complex mechanics would be involved though.

If we were not concerned about displaying hours and minutes (and possibly seconds) on our mechanical clock, we could turn it into a calendar simply by making it tick slower – much slower.

The Slow Tick

If we take the Tropical year as being 365.24219 to 8 significant figures, we can calculate:

ns = 365.242 x 24 x 60 x 60 = 31556925 = seconds in a tropical year, to 8 significant figures.

If we decided that 12 hours on our clock was to represent a tropical year, we can divide the above number of seconds by the number of 1-second ticks of the clock (assuming that it has a 1-second tick) required to rotate the hands by 12 hours:

nt = number of ticks required to rotate hands by 12 hours = 60 x 60 x 12 = 43200

So, to work out the length of the tick that we would need to rotate the hands once in a Tropical year:

t = ns/nt = 730.48438 seconds, to 8 significant figures.

That means that our Slow Tick would occur roughly ever 12 minutes, 10.5 seconds.

A Tricky Escapement

I will leave it to some clever-clogs to work out how to make a mechanical clock escapement that only ticks every 12-and-a-bit minutes (no down-gearing allowed!)

As I am not particularly interested in modifying a traditional, purely mechanical clock for these purposes, I will look at how an electro-mechanical clock may be used instead.

Quartz clock movements may be obtained cheaply from hobby suppliers. However, entire clocks can be obtained even more cheaply from 'cheap' shops. With the latter, you get a face and a case thrown into the bargain, so have little to do in the way of mechanical construction.

My practical research for this article has so far extended to obtaining and dissecting a quartz clock obtained from a local supermarket for $12 AUD. Once the movement is removed, it looks very much like every other cheap quartz movement that I have seen over the last few years. The drive, contrary to what I suspected, does not consist of a solenoid that is simply pulsed every second with some kind of pawl and ratchet mechanism, but of a cylindrical magnet between the poles of a solenoid that would require a reversing field every second. (If a simple pulse train of fixed polarity were applied, the magnet would move possibly once, then just twitch slightly every time a pulse came along.)

Part 2 details some thoughts on the pulse generator which will drive the Solstice Clock and how it can become more than just a Solstice Clock.

The Fate of Project Noddwr

Project Noddwr, which includes former work on the Tivis accessible touchscreen project has been shelved and the site taken down as of May 2007.

Project Noddwr was intended to be a repository of Open Source hardware and software components for independent living and also to encompass the scope of the Tivis project, originally designed for community/tourist information via touch-screens, and later to provide accessible kiosk solutions.

Examining the documentation that was online, I found it so out of date that I have simply removed it and created this page as a place-marker. Anyone seeking information on older content should contact me through the address at the end of this page or by my "real" e-mail address, should they know it. I still have a proposal available for the development of an accessible kiosk system; should anyone be looking to produce such a system and who may consider sponsoring this development, I would love to hear from them.

The spirit of Project Noddwr is not dead, just resting. I started the project early on in the stages of an ongoing illness, which has prevented me from pursuing the work that I had started. Of late, however, I have been working on the software component for my own use, to help manage time restricted by Chronic Fatigue and prop-up an impaired memory. Developments that would have found their way onto the Project Noddwr site will appear here, on Smiffy's Place.


2009-09-12: the domain was allowed to lapse at the end of last month and the domain which also pointed to this page will expire on the 8th of next month.  Whilst I will continue to offer related services to clients who might need them, as far as the Noddwr and Tivis projects are concerned:

"This parrot is no more. It has ceased to be. It's expired and gone to meet its maker. This is a late parrot. It's a stiff. Bereft of life, it rests in peace. If you hadn't nailed it to the perch, it would be pushing up the daisies. It's rung down the curtain and joined the choir invisible. This is an ex-parrot."

(Substituting "project" for "parrot".)

In touch with Freescale

And I wondered whether anyone actually read this stuff!

Over the last week, I have been in contact with a representative of Freescale, who had chanced upon this series of articles. I have to report that the communication I have received has been very positive and supportive. I am quite delighted to see a large company taking an interest in the small developer. but will try to retain my objectivity in the technical side of the evaluation.

One Brownie Point to Freescale.

Microcontrollers: Samples

The first of my articles in the series
The Big Microcontroller Question
deals with getting samples from the manufacturers.

Just to remind you, the players are Atmel, Freescale (Motorola) and Maxim Dallas; all three companies offer free samples to qualified developers – one of the three, however, hasn’t delivered.


Super fast – samples on FedEx the next working day. Super slick and speedy.

Maxim Dallas

No hassles with samples, although expedition is not a quick as Freescale (standard post used). What I really, really like about the Maxim Dallas system is how the e-mail confirmation comes with links to datasheets and application notes, rather than having to trawl back through the
site. Well cool.


I love the AVR devices (especially since I’ve invested in an STK500 development board an have spent quite some time working with AVRGCC), but I’m not so impressed with Atmel, the manufacturer. On two occassions (the first some five months ago) I have attempted to put through sample orders. Both said that the samples would be shipped to the local agent; perhaps they were – I never saw them, nor heard any more. Until I see some measureable improvment in customer service from this company, I won’t be looking at their devices for any new designs. (I will still finish my evaluation of the Atmel devices in this series of articles because AVRs are still pretty cool.)

The Big Microcontroller Question

Which 8-bit Flash microcontroller? Atmel AVR, Dallas 8051-based or Motorola, er, Freescale?

In a series of articles, in no specific order, I will be evaluating these three families based on various criteria:

  • Features
  • Helfulness of manufacturer
  • Ease/cost of programming
  • Development toolchain

Note that cost is not a consideration – this is all about the impact on me (or anyone else) as a developer without the resources of a large company.