Wednesday, April 28, 2010

myforth, 8051 and iRobot Create

At the end of my previous post I entertained the idea of using a SiLabs C8051 for controlling the Create. Of course, I can't run Lua on that MCU, so the obvious alternative is Forth.

But which Forth? I have a copy of SwiftX for the 8051, but I decided to look at an interesting environment called MyForth that i found here. This is the, quite detailed, manual.
Its non-standard (I don't really care), influenced by colorforth (yeah!) and completely tied to the 8051.

In this day and age, who would use a language completely tied to a platform? Well, apparently, the point of MyForth was to produce a true 8-bit Forth that would match the 8-bit nature of the 8051. (Most 8051 Forths are 16-bit, while the registers and most efficient instructions on the 8051 are 8-bit based.)

After a while, I started to think: so what? As modern programmers we've embraced portability over efficiency. No, its more that that: We strive to avoid software that locks us to a particular piece of hardware.

Is this a real problem (all of the time)? If I want to augment Create (or other consumer robots) with an MCU and some code, should I strive to make it portable? Or do I just concern myself with the problem at hand: Making the robot do interesting things.

Another plus for MyForth is its development environment: It uses gforth as a cross-compiler. I have full access to the cross (meta) compilation. I can craft MyForth to become "my forth". So, who says I can't re-target it for another MCU? Or, at the very minimum, use it as a model for cross-compilation.

Interesting reading and hacking for the weekend.

Saturday, April 24, 2010

eLua and mbed and iRobot Create

Mbed is 5V tolerant. This means I should be able to connect a board directly to the iRobot Create that has been sitting gathering dust for a couple of years. I couldn't get motivated to write in C for it; I didn't have a viable Forth option at the time (although now I do).

Since the Create sucks big power as it is, the addition of an mbed shouldn't be a problem.

While I am quite deep into Forth these days, development may be better suited for eLua (since it is free). Maybe? Something to think about.

Of course, the SiLabs C8051F340x is also fully 5V tolerant (including power supply) with fewer external circuit requirements and much lower power consumption. I can't run eLua on it, but I've got my trusty SwiftX 8051 Forth....

So many options, so little time.

eLua and mbed

Sometimes I get lost in the whole "low power" thing. I've been focused so much on power saving processors that I forget what fun it is to just program. Forth is great for getting the job done, but sometimes I just want to play around with algorithms and want something a little more... infix.

So, eLua fits the bill, especially on mbed. (Lua on Cortex-M3! Yay!)

Monday, April 12, 2010

mbed (Cortex-M3) and MPE Forth

Mbed is a neat little NXP LPC1768 based Cortex M3 development environment. It has a web based IDE, but I'm not interested in that. You can flash it by dragging a *.bin file to its embedded flash drive. Once you drag, you reset (via pushbutton) and a second or two later the device is reprogrammed.

This made a nice target for MPE's Forth 7 Cortex-M3 cross compiler. (I purchased the inexpensive "Stamp" version for ~ $115).

There was no included Mbed support, so I attempted a port. The port was easy -- I got the LEDs to blink. Now to figure out what to do with the thing...

While the LPC1768 has some interesting low power modes, the extra programming/flash-drive circuitry of the mbed doesn't allow full exploitation. However, until the Gecko Starter Kit becomes available, the mbed will do (for development purposes).