2013 August 28 11:37
I’ve added short introductions to Freescale’s HC08 and S08 8-bit microcontroller families. The links don’t all work, but the basics are there.
I’ve been working on supporting the S08 (in muforth) since late 2008, and I still really like these chips. I think they are a lot of fun. I’ve been meaning to get an overview online for some time. ;-)
So here it is.
2013 August 19 16:57
My off-and-on obsession with commercial restaurant ranges has returned.
A few years ago, when reading and thinking about house trucks and micro houses, I noticed that people seemed to favor using old, circa 1930s or 1940s four-burner apartment ranges. (We’re talking about gas ranges here.) Given my sister’s recent bad experience with the low quality of new small ranges – she installed one in a mother-in-law apartment and the top rusted completely through in a few years – I started thinking about what one could buy new that wouldn’t fall apart in short order, and thereby lit on the idea of using a small (24” wide) restaurant range.
These are still, in their way, behemoths: they weigh hundreds of pounds and produce tons of heat, carbon dioxide (and monoxide), and water vapor, and would need good ventilation – thus probably way overkill for a house truck or micro house – but the obsession was born.
And after using a friend’s Montague Grizzly (sadly, no longer manufactured), I was hooked.
2013 August 09 11:11
I’ve added a page with a short list of cheap ARM Cortex-M development boards. All but the Teensy 3.0 are, or will soon be, supported by muforth.
2013 August 08 16:55
After piecemeal work on it over the last few months, I’ve been intensively working for the past week or so on Cortex-M support in muforth.
In order to try to understand the CMSIS-DAP code – in particular, how one writes an OpenSDA application – I ended up adding almost all the “everyday” ARMv7-M instructions to the disassembler – ALU ops, memory loads and stores, but none of the floating point or exotic SIMD instructions.
I finally finished the Cortex-M0 (ie, ARMv6-M) assembler, and just two days ago added basic debug support for the Stellaris Launchpad, a bright red ten-dollar board with an 80MHz ARM Cortex-M4F processor on it.
I’m working on a native Forth compiler that initially will target the Cortex-M0, but that means it will run fine (just slower than ideal) on Cortex-M3 and -M4 parts. (I can always tweak and improve it later to support the M3 and M4.)
The CMSIS-DAP support – for the Freescale Freedom board – is working fine, but seems a bit slow. I think doing debug over HID packets is a mistake; using bulk endpoints, or even doing control transfers (like I do for the S08JS16) seems much faster. Since I have access to the CMSIS-DAP source code, I know that they have up to 32 packets in a ring. In an effort to get things to go faster, I changed my code to have up to 16 packets “in the air” at a time; sadly, a large transfer (reading 128KiB of flash) went only two times faster.
Fundamentally I don’t care about the performance of CMSIS-DAP – or any of these built-in debug protocols. I plan to use them only to explore the board and chip, and to get my debug stub code onto the chip. Once I’ve done that I can ignore their firmware entirely. Of course this means mastering the curiousities of (currently) three ways to program the flash and talk to the USB. One reason I’m working on getting my Forth meta-compiler working is that I’d ideally like to write my USB debug stub in Forth. The stub – and all other little USB “apps” – I’ve written for the S08JS16 is assembler (all 512 bytes of it. ;-)
All in all, I’m pretty happy with my progress. Once the Forth (meta)compiler is done, I can start thinking about adding ARMv7-M instructions to the assembler.
2013 February 06 11:46
After a few recent breakthroughs, I’m now able to connect to the CMSIS-DAP firmware on my Freescale Freedom board and successfully read and write core registers and memory – using muforth!
Two days ago, after modifying the OSX USB support in muforth (to support USB HIDs), I was able to turn the “connect” LED on the board on and off. This meant that the connection between muforth and the HID firmware was working.
Then, yesterday afternoon I successfully read the IDCODE from the on-chip SW-DP. This required getting the connection sequence right – sending a binary string to the SW-DP. ARM’s documentation – the ARM Debug Interface v5 spec and the ADI v5.1 supplement – disagreed on what this sequence should be. I settled on sending 56 ones followed by 8 zeros, and this seemed to work.
My next hurdle was to try to read the chip’s memory. But any access to AP (access port) registers failed, returning a FAULT. It turns out that it is necessary to first turn on the CSYSPWRUPREQ and CSYSDBGREQ bits in the DP.CTRLSTAT register... Once I did this, the chip was mine!
Very cool.
2013 January 23 13:01
A new start?
I’m putting this crufty old site online again, but in an entirely new way: it’s now statically generated – using Lua! – and then pushed to GitHub, to be served by their (free!) GitHub Pages service.
I’m not sure how much time I’m going to spend in the near future grooming this site, since my next project is to tackle some form of blog for muforth, but I’m happy to have it online again.
Read the 2010 journal.