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.