2008 December 24 19:45

I missed an historic opportunity

I’m working on porting Forth to Freescale’s 908 and 9S08 parts. I got my first samples in 2006, got discouraged, and stopped working on the project. For mostly unknown reasons I’ve been recently inspired, and have picked the work back up.

Now that it’s the end of 2008, I wish I had worked on it in 2007 and early 2008 so that on 2008-08-08 I could have released my code to the world!

Oh well. Better late than never?

2008 December 19 13:54

Why am I bothering with Freescale’s HCS08?

If I had any sense, I would be using Atmel AVR parts. Why do I say this?

Why, then, am I concentrating on Freescale’s HCS08 instead?

I’ve mentioned elsewhere that I like the 6800 heritage. It’s nostalgic for me. But that’s a ridiculous reason, right? So what are some compelling reasons to use these parts?

Attractions of the S08

Cost

They are quite cheap – cheaper than comparable PIC or AVR parts – and you get a lot of bang for your buck. For instance, the S08QG parts in DIPs have a UART, SPI, and I2C, all standard, a good selection of timers, 8 channel 10 bit ADC, and some nice add-on features, such as clever compare logic in the ADC that causes an interrupt only when a value crosses a threshold. The USB parts have 12 bit ADC, 2 UARTS, and 2 SPI ports.

Also, it’s quite easy to get free samples, directly from Freescale, and also to buy directly from them, for very competitive prices, even down to quantity one.

Flash

Unlike Atmel’s Flash, which is only good to 10k cycles (if you’re lucky) and has a short retention lifetime (10 years?), Freescale’s Flash, like much of Microchip’s, is good to 100k cycles and has a retention of more like 100 years. This might not sound like a big deal, especially for hobbyists, but philosophically I find it unappealing to use something so obsolescent as Atmel’s chips.

Von Neumann architecture

A feature that is here in the “pro” column but also has a dark underside. Since RAM and Flash exist in the same memory map, it’s possible to execute code out of RAM – and in fact it is necessary to do so when executing code to program the Flash. Code in RAM makes several things possible:

Built-in debug architecture

This is an attractive feature, especially if you’re going to use Freescale’s development software, which can take full advantage of it.

Basically, every S08 part – even the lowliest 8 pin part – has not only a background debug mode (BDM) single-pin interface (which can be used to Flash empty parts, to reprogram parts, and to debug running code!) but also a tiny built-in in-circuit emulater (ICE). There are two code breakpoints and one data watchpoint available in hardware, with sophisticated chaining available between two of them. There is also an 8 entry trace buffer, allowing the capture of address and data bus values.

Considering how “low-end” some of these parts are, this is quite a stunning feature.

Quality peripherals

It’s more “gut feeling” than real empirics, but the quality and flexibility of the on-chip peripherals seems very high, compared to AVR and PIC. Maybe when I re-develop all my code for AVR I’ll have harder data on this one. ;-)

Upward migration path

Freescale have introduced several new S08 families with the so-called Flexis architecture. The new USB parts – the S08JM family – are Flexis parts.

Flexis families have both S08 members, and 32-bit ColdFire members, which are pin-compatible and only a bit more expensive than their 8-bit cousins, making it easy (assuming your code is not in assembler!) to upgrade to a fast 32-bit core. The peripherals are exactly the same 8-bit peripherals in the S08 parts, so all that code – again, assuming it’s in a high-level language – will port over trivially.

Or so the story goes. It’s a nice idea, and if you’re not interested in ever using the 8-bit version, it’s a way to get quite cheap 32-bit parts.

And since ColdFire is essentially 68k, it’s a good target for Forth and C (and everything else) and also nice for nostalgia buffs.

Distractions of the S08

Ok, so how about downsides to the HCS08? There are several, and a few are big ones.

I think the hardest for me right now is the lack of development hardware. I have some chips, but I have to do some work to be able to try them out. I’m currently busy writing code, but soon I’ll want to try it on some real hardware!

2008 December 17 13:33

Freescale USB parts are on their way

My samples of the S08JM16 and S08JM32 parts are on their way. Sadly I don’t have a way, when they arrive, of doing anything with them. I lack the breakout boards to make them useful – they are in LQFP32 and LQFP44 packages – and I lack a way to talk to and program them. S08 parts use a Background Debug Mode (BDM) – a single-wire, half-duplex interface that is used both to program the Flash and also to debug live code.

One annoyance with Freescale is that there isn’t a single super-cheap board to talk to BDM via USB. Each subfamily (such as JM) has its own DEMO board (costing $30 to 90), which has a USB to BDM connection, but usually somehow castrated to work only with that subfamily. The one “universal” BDM board is about $99. I may have to get one. It’s the AVR Dragon of the S08 world – but more expensive!

I just realized that a fun way to play with this stuff might be the JMBADGE. These are quite cheap ($30 I think), and have loads of possibility. The JM family is one of the “Flexis” families, which consist of S08 (8 bit) parts on the low end (8k to 60k Flash), and ColdFire V1 parts on the high end (50MHz CPU, 64k to 256k Flash). I could misuse this to program other parts via BDM. And it looks like a fun gizmo.

2008 December 13 16:40

I’m currently exploring the idea of using Freescale’s S08JM family of USB microcontrollers – in part because they are retro & nostalgic (for me – I wrote my first program for the 6800), and in part because they are true von Neumann machines (one memory space for both code and data), rather than Harvard machines like their AVR and PIC competitors. A true Harvard architecture makes interactive Forths difficult to write, since RAM is always in data space, and Flash is in code space. For interaction I want to be able to execute code out of RAM – but I can’t.

There are some serious downsides to using these Freescale parts. First, Freescale’s toolchain – the bloated Codewarrior – while free is not open source, and is Windows-only. Second, there isn’t a single piece of cheap hardware – like the AVR Dragon or PICkit2 – that can program all of Freescale’s HC08 parts. Each family has its own DEMOxxx board, and each one costs $50. There is a nifty thing called the USBSPYDER08, but it only works with lowest-end parts – not with the JM family.

Wondering about this once again, I did the following Google search: “open source hc08 tools” and landed on a Freescale forum devoted to the OSBDM08 – an “open source programming cable”. Sadly, it seems to be supported only under Codewarrior. But, rather interestingly, the latest thread is by “Brad R” who “writes Forth compilers” and is interested in Linux support for the OSBDM08!

This is, of course, none other than Brad Rodriguez, long-time Forth author and explainer, who created the CamelForth series of 8-bit Forths.

Pretty cool.