SiLabs C8051 and SwiftX Forth

It's been a while since I've posted... I am very busy these days. :-(

I am currently playing with SiLabs C8051F344 with a purchased copy of Forth Inc's SwiftX (under Windows -- my Linux development effort never fully cooked).

I am impressed with the speed of this "lowly" 8051 derived 8-bitter. It isn't meant to do big things, but for small things it fairly rocks.

I've previously played with the C8051F93x very lower power MCU, but given my current interests (GPS tracking), the difference in power consumption between that very low power part and the more power hungry F344 is minimal. The GPS consumes so much current when running that the MCU is just "noise" in any power chart plots.

When asleep, the difference between consuming 1uA (sleep mode) on the F93xx vs 25-50uA on the F344 (clocking way down to around 40Khz) is not worth considering (we are talking years of battery life for either).

More on my current project later... but for now I am just enjoying crafting Forth on a 8-bit MCU :-)

SwiftX Forth and 8051 and Linux

Maybe 3 other people in the world would probably be interested in hearing that I have gotten the evaluation copy of SwiftX Forth running under Linux (Wine) talking to Silab's USB Toolstick's C8015F931 daughter card.

I had to steal the daughter card UART and re-route it to a separate USB->UART bridge for SwitfX's XTL (programming still works through the Toolstick), but it all works (so far) under both Windows and Linux (Ubuntu!).

I am playing around with 8051s because I am feeling retro and a bit weary of the TI MSP430 family. The C8015F931 has some impressive low power numbers and some neat features to make even a lowly 8051 appealing.

I have to remember to do a post on my newest interest: Augmenting sensors with tiny low power MCUs to make them smarter.

uForth 0.99 -- almost there....

A bit fatter, but more capable... Plus there is some initial refactoring of the code. Download the latest here .

case statements in uForth

case .. of .. endof .. endcase was surprisingly easy to implement:

\ Variable used to keep track of how many 'of' clauses we have.
\
variable _endof

: case ( n -- )
   0 _endof !
   [compile] >r
; immediate

: of ( n -- )
   [compile] r@
   [compile] =
   postpone if
; immediate

: endof ( -- )
   _endof incr
   postpone else
; immediate

: endcase ( -- )
   _endof @ 0 do postpone then loop
   [compile] r>
   [compile] drop
; immediate

And, an example:

: test  ( number -- )
    case
       1 of ." one" endof
       2 of ." two" endof
       3 of ." three" endof
       ." none"
    endcase
;

Hexbug + MSP430 = Robotrophic Parasitism

It's been almost 2 years since I wrote about my interest in Biotrophic Parasitism in robotics...

In Biotrophic Parasitism, the parasite and host co-exist with (potentially) mutual benefits.

In what I am calling Robotrophic Parasitism, the parasite (in this case a MSP430 based $3 EZ430-T2102), and the host (an original $10 Hexbug) live happily together.

In this case, the parasite was minimally invasive: the EZ430 lives between the battery switch and the Hexbug circuit, controlling the power. It also has a bi-directional line tapped to the antenna sensors so it can detect a "bump" or steer (the original hexbug only turns clockwise).

The parasite seeks light and steers the bug in that direction. When you first apply power, the parasite turns the hexbug clockwise (up to 6 times) looking for any light bearing direction. It then drives the hexbug in that direction. If the light wanes, it will then do another set of clockwise searches looking for a stronger light source.

I've got some fine tuning to do...

The parts list:

1. 1 EZ430-T2102 board.
2. 1 Hexbug.
3. 1 photoresistor and 1 voltage dividing 1/8 watt resistor (from my parts bin).
4. 1 TS5A3127DBVRG4 analog switch (free sample from TI).

Total Cost: ~ $15

This is the first of (hopefully) many Hexbug Robotrophic Parasites!

Unschooling days...

Wednesday early afternoon...

Claire in her tree.

Annie drawing worms (science).

Nate hacking Python.

uForth 0.96 -- getting closer...

I've simplified uforth.c in this release. Some words coded in C were moved to core.f and init.f.

This made the C code smaller, so you can now compile uForth with the free IAR MSP430 Kickstart Edition!

Still no DOES> (not sure how to do this without dictionary rewriting which is a no-no in my MSP430 flash approach).

It is nicely shaping up though. I am really enjoying rewriting parts of uforth.c in uForth itself (see core.f and init.f in the distribution).

Downloads are here.

uforth 0.921 -- more pre-release goodness

Visit uforth for the latest "on your own for now" pre-release. I've included a link to a prebuilt binary for the MSP430 ez430-rf2500 board.

It's more robust and comprehensive. Plus it supports direct word compiles to the MSP430 flash.

It weighs just over 8KB flash + 900 bytes RAM. It support an 8KB (4096 cell) dictionary, so there is plenty of room to play.

The PC/Unix version still works well too. I use it for new dictionary development and create a TI file of the compiled dictionary for the MSP430.

Nothing automated yet and very little documentation. But, hey you can define words, loop and do some "meta" stuff.

uForth 0.7 pre-release

Last night I finally made some progress with compiling to the MSP430 flash dictionary: I can now compile words on the MSP430!

I also moved the MSP430 development to the more widely available (and cheaper!) ez430RF module (MSP430F2274 based).

Unoptimized, the VM/interpreter is 6.6KB and the RAM footprint is 844 bytes (essentially leaving room for 90 one cell variables on the MSP430F2274). I made the dictionary 4092 words (~8KB) to leave room for C app code. The uForth dictionary is (by architecture) limited to 32KB.

The brave can grab at snapshot (or look at documentation) here. If you have an ez430RF and you want to poke about (you're on your own for now), you can grab this big TI format flash file here. This file contains both the VM/interpreter and a dictionary.

Development Support words for uForth

Support words shouldn't be in the core. As smaller as it could be to write in C, I am resisting the urge of making the core larger. Take for instance "words". It is very, very useful for debugging but not so useful in a "finished" system. Why should it eat precious RAM or Flash if you don't need it?

Here is a quick definition of words in uForth. You can place it in init.f (for BOOTSTRAP versions) or pass it to "uforth_interpret()". It depends on a few words I've already shipped in init.f:

( Implementation of words in pure uForth! )

create _ ( dummy "known length" entry )

variable last_word

variable ccnt ( keep track of # of characters on a line)

: words ( -- )

_ 6 - @ last_word ! ( We know where the prev word link is inside of _ )

0 ccnt !

last_word @ ( pointer to last word )

begin

dup ( keep it on the stack )

1+ count 63 and dup ccnt +! ( get length of word's name )

ccnt @ 70 > if cr 0 ccnt ! then ( 70 characters per line )

type 32 emit 32 emit ( print word's name )

2 ccnt +! ( add in spaces )

@ ( get prev link from last word )

dup -1 = ( -1 link means no more words! )

until

drop ;

Simulating MSP430 I/O on PC uForth (Solution?)

One horrible solution (but may work for me) is to simulate the MSP430 I/O under PC uForth.

Keep in mind: uForth is about scripting, not about writing system level Forth stuff on an MCU. It is meant for slinging around C functions and libraries. I don't intend on doing much bit banging in uForth. There will be no UART driver, no interrupt handler, no deep notion of MSP430 power modes. SwiftX Forth (and others?) is the best fit for that.

I want to take existing C app (maybe already running on an MSP430) and manipulate it.

However, some times I may want to toggle some ports. I can do this with a minimal RAM_DICT uForth on the MCU. That may be adequate. This would allow me to hack the MSP430. Maybe I should create a special "hackers" dictionary for the MCU that allows me to bit bang ports and interact with peripherals. (This *should* be a writable dictionary.. try blinking an LED without some sort of DO .. LOOP construct -- this requires compilation!)

If I really do need the ability to do bit banging in the full "scripted application", I should be able to simulate it on the PC uForth. This wouldn't be a full MSP430 simulation, but maybe just enough so that I can compile the word, test it (maybe textual output: "LED bit0/port1 is ON!") and then dump/flash the dictionary.

Just a thought... but, uh it sounds oh so "batchy".

uForth MSP430isms

I'm trying to figure out how to best do uForth word compilation on the MSP430. Right now, if you want to do that you must use the RAM_DICT option (RAM based dictionary). This is inconvenient at best. A typical MSP430 part will have between 1KB to 8KB of RAM. Your initial dictionary may be larger than that!

Then there is the problem that compilation often involves rewriting memory (resolving BEGIN, DO .. LOOP references, etc). The MSP430 main memory is divided into 512 byte segments. And, each segment must be erased before writing (technically, you can write twice safely without an erase). What if the word definition spans two segments? I would need at least 512 bytes of RAM for buffering. Will I need more?

Another approach is to use a "tethered" development environment. With this, I would attach the PC uForth to the MSP430 uForth, compile the word locally and send the byte codes to the MSP430 to be flashed. This simplifies Flashing since there doesn't need to be a concern for rewriting bytes. However, this means that the PC and MSP430 uForths must be tightly bound.

SwiftX Forth takes a more formal tethered approach, but I like the more standalone nature of uForth right now.

The batch approach I take right now is to develop and test the word on the PC uForth, dump the dictionary and recompile the MSP430 Forth with this dictionary (flash based). The big problem with that can be summarized by the following example -->

: led-on bit0 port1 mem! ;

Ugh. There is no analogue for this on the PC uForth. My only recourse is to use a RAM based MSP430. But, after defining "port1", "mem!", etc. a 1KB RAM MSP430 part won't be big enough to support the dictionary. (And, obviously, using a Flash based MSP430 uForth, I won't be able to define led-on !)

Solution to follow... hopefully...

uForth 0.4 ... more preliminary madness

Still very, very alpha. But here is another tarball: version 0.4

I got FLASH based MSP430 support working. No interactive compiling into Flash, but you can build a dictionary on the PC and then rebuild the MSP430 version with a Flash based dictionary.

Default still uses RAM_DICT under MSP430. The quick reference is still the best way to make sense of what you've downloaded.

uForth preliminary release... very, very alpha

This probably won't be usable for anyone and it isn't organized well at all. In fact, you could view it as a drunken pseudo-intellectual ramble captured as source code. It may mean something, or it just could be plain useless. For me, personally, it is an achievement.

I am sitting here right now, enjoying a Taylor Fladgate 10 year old Tawny Port, listening to a heady mix of Abdullah Ibrahim, Michael Franti, Dinosaur Jr. and Arcade Fire, considering if I should release this.

Aw, hell. If you want to muck with it, go ahead. Here is the (probably uncompilable) tarball of uForth.

P.S. I actually got it to run on an MSP430 today (via Rowley Crossworks). I can't promise support, nor can I promise a steady stream of releases, although it is geared to become the basis of some stuff at my day job.

u4th - Forth for microcontrollers

Okay, I got tired of searching and waiting. I decided to roll my own "portable" Forth targeted for microcontrollers with limited resources. I want to do a Forth that would work on MSP430s, ARM Cortex and desktop PCs.

This would be more of a "scripting" Forth vs a full bottom up programming language. It would expect to be embedded in C and able to call C functions (like a scripting language!).

Right now I have something working on both a PC and MSP430 (simulator). u4th is written in C and makes no presumption about I/O (you can extend and add UART support, but it is happy to just work with a dictionary and an init() function). It supports a RAM or ROM/Flash resident dictionary (but no Flash writing support built in). It compiles a position independent dictionary that can be transfered to/from a PC and MCU without modification.

It does not implement ANSI Forth.. it is it's own beast geared for scripting, not system building.

I have a few more things to add (no DO .. LOOP yet) , but right now it runs (interpreter + VM) just under 4KB RAM (with a 2KB RAM resident dictionary -- so if the dictionary is Flash based, we are talking well under 2KB RAM!) and around 7KB of program (flash resident code).

More to follow!

/todd

compose-tex vs AFT

I've been doing some AFT hacking for a person who needed some text support. There are many AFT alternatives out there these days but he says that AFT hits the spot because it produces LaTeX as well as HTML.

There are some decent LaTeX to HTML converters out there too (have been for years).

I've been thinking about making a simple "free-ish text" converter that produces only LaTeX. It would be a LaTeX helper of sort. It would allow a casual user the ability to produce very high quality print without the learning curve of LaTeX.

The trick is, the "almost free text" format markup would have to be beautiful. The idea is "beautiful plain text in", "beautiful print out".

What if everyone could produce beautiful print? What would you typeset?

Living my values...

This old blog entry struck a chord. I followed a bunch of links from TED.

Colorforth as inspiration

I always keep up the best I can with what Chuck Moore (inventor of Forth) is up to. I've always found colorforth to be fascinating.

Mr. Moore has started a couple of blogs. Of particular interest is his recent blog for tracking progress with his latest creation.

This reminds me why playing with hardware is so much fun. I am a bare-metal guy at heart, although there isn't much opportunity for doing this type of work (for me) these days.

How do I make a career out of bare metal progamming? Forth gives me some of this thrill. I like to poke and peek hardware to see it work. Something about batch compiling/loading (C and C++) through an IDE loses that feel.

I don't really want to "roll my own" Forth these days. Language design as a thrill has come and pass.

I got a buzz out of using SwiftX Forth (for the MSP430) at work a while back. Getting an unsupported MSP430 (the MSP430F5XX) working with SwiftX was a blast.

If I can scrape together $395 for a SwiftX MSP430 license (for non-work use), I'd like to kickstart an idea I had for doing a Simpliciti clone in Forth.... but my wife's van needs new tires :-(

More on (embedded) C++

Interesting paper regarding using C++ for embedded work by Stroustrup. I wonder how much of this is taken to heart by embedded developers.

Evaluating the Cortex-M3

So, I have 2 evaluation kits: the stm32circle and the stm32-performancestick. Each under $100 and each with interesting features and annoyances. I've spent around $130 between the two.

I suppose it would have made more sense to just get the Olimex header board ( STM32-H103) for $40, a $70-100 JTAG, and GCC, but the point of the evaluation excercise is NOT to spend hours doing the "let's build everything from scratch". When the right integrated environment is chosen it sometimes worth the money. I still (and will continue to) do my source code editing in emacs but I have become pampered by the often richer experience of debugging with a decent IDE.

I would still like to just use emacs + gdb + gcc for development, but while I'm learning the chip I'd rather have an IDE with integrated documentation and GUI hand holding. My days of grunting manly about how I built all my tools by hand and debug via gdb command line is probably over. I will probably never replace my beloved emacs (used mainly out of habit) for editing and browsing code, but the point here is to hit the ground running and focus on the Cortex.

So far... stm32circle and Raisonance is nice, but I have no interest in CircleOS, so I've yet to see what it offers me in turns of raw EABI programming. Raisonance Ride is limiting me to 32KB debugging. I suppose I won't be using a lot of the advanced features of the stm32circle (color LCD, sound, etc) but it is a very rich platform (for only $40).

The smt32-performance sticks comes through Hitex (which is promising me unlimited debugging after I send them email). No response yet. The older license key (I am using the most up to date version of the debugger) doesn't work. They said I should email them a request for a new license. I was able to run their "dashboard" which allows me to do some performance/power tests. This is very informative.

At some point I will choose one or the other to do some development with. I guess I am hoping that the stm32circle will "win". Ride7 looks nice (reminds me of Crossworks). I need to see how well it does without forcing me into CircleOS.

I'll post updates in the next couple of days.