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.

Forth on the Cortex-M3?

I can't seem to find any Forth running on a Cortex-M3 (let alone an ARM Thumb).  This is the reason why I started to look at C++ again.  I'm getting sick of plain old C -- great for little things, but I have bigger fish to fry.

I won't bother to convince myself that I have time to craft/port a Forth to the Cortex.  However, I wonder if porting a Forth written in C is an acceptable compromise?

Hmm...

Stroustrup's new book

I swore I would never do C++ programming again (3 yrs ago). Never say never. I realize that I miss some of the abstractive capabilities compared to C. I don't miss OO, I miss Generic Programming.

I was browsing Reiters a couple of weeks ago and was shocked to find this book. C++ as a first language? I was intrigued. I think that Stroustrup is a good concise writer and I wondered what an "intro to programming" book would look like (coming from his hands).

I purchased the book last week.

The book is interesting. I don't know how well it would do with a newbie, but I tend to like his no-bullshit approach. It is quite refreshing. He is very pragmatic and I liked how STL (generic programming) takes a front seat.

I am also a fan of Alexander Stepanov. He has a book coming out this month. I've already pre-ordered it.

This nicely meshes wth my current interest in Cortex M3 microcontrollers. I don't want to resort to C programming when I start messing with my Primer.

IAR, STL and the MSP430

Apparently, the IAR MSP430 compiler supports C++'s STL.  My jaw drops.

In my previous post, I alluded to the desire to try generic programming on a Cortex M3.  Out of curiosity, I wondered whether or not it would be possible/practical to do C++ on an MSP430.

Well,  after some deep digging I've found that IAR has "some" C++ support that includes the STL!

How efficient can it be? Well, I don't like resorting to dynamic memory allocation when I don't have to (and certainly not on an MSP430) but I decided to give some basic STL algorithms a try.  I am less concerned about performance than about code size. STL is (undeservedly, IMHO) notorious about being a source of bloat.

Here is the sample code:

#include  <msp430x54x.h>

#include <numeric>

#include <functional>

static volatile int res;

int main( void )

{

  int a[] = { 9, 1, 5, 6, 7, 8};

  

  // Stop watchdog timer to prevent time out reset

  WDTCTL = WDTPW + WDTHOLD;

  

  res = accumulate(a,a+sizeof(a)/sizeof(int),0);

  res = accumulate(a, a+sizeof(a)/sizeof(int), 1, multiplies<int>());

  return 0;

}

This compiles to 250 bytes of CODE, 162 bytes of DATA and 12 bytes of CONST  with default compile settings. (Some of the DATA is pre-sized stack and heap.)

With the highest optimization settings this compiles to 180 bytes of CODE, 162 bytes of DATA and 12 bytes of CONST.

I am impressed.

Sure this was a contrived test, but I am amazed that I could even do this.

Is this more efficient than a hand written accumulator? No. There are function calls here that wouldn't exist if I were to do it by hand. However, this may scale better than I could muster by hand:  By cherry picking STL algorithms I am choosing to be more type "aware".  I am also avoiding writing stuff like:

  for (int i=0; i < sizeof(a)/sizeof(int); i++)

    res += a[i];

Simple, right? But do you see the two potential problems? First, I never initialized "res". Second, I introduced another variable "i".  While the STL code has the overhead of function calls, it uses the more space efficient technique of incrementing through "a" rather than indexing.

I'm not planning on using the STL for any real MSP430 work. That would be overkill.  But the Cortex M3 is a different issue...

C++ on ARM Cortex-M3?

I've been wondering how many people use C++ on ARMs. I don't mean C++ as in a "better C", but C++ in full (sans dynamic memory management and exception handling -- both casting non-determinism on systems seeking deterministic behavior).

The embedded development community/industry seems stuck in C.  (I'm talking truly embedded here -- not Linux gumsticks, not "single board computers", etc.)

How about C++ with STL (but without vector and other containers that use new/malloc)?

Does this buy you anything?

There has to be an alternative to C.  I wish it was Forth, but there doesn't even seem to be a Forth for Cortex.

I love C, but it doesn't scale very well (when it comes to abstractions and type safety).

How would generic programming (templates) look on an MCU?  Would I be able to come up with a template that would let me abstract away SPI and UART code?

Is Embedded C++ (with templates) inevitable?

The prospect almost makes me want to buy this: http://www.digikey.com/scripts/dksearch/dksus.dll?Detail&name=497-6049-ND&enterprise=12 (a Cortex M3 demo/devkit for < $40).

Biotrophic Parasitic Computing and sensor nets

Biotrophic Parasitic Computing is still fascinating to me. The parasite needs to be efficient and highly adaptable. Now, in addition, I think the parasite should be able to communicate with others (or a hive host).  Low power sensor net technology comes into play.
The smallest parasite will be the EZ430-T2012. It's tiny and cheap. It will need to be programmed in C (I'm avoiding assembly).Given that most new RF modules (like TI Chipcons and Zigbees) don't require much from outside microcontrollers, I could probablyget away with using a small parasite.
The next step up is the EZ430-RF2500T. It is more expensive (it includes an RF module). It can be programmed in Forth (SwiftX).
Each has its own particular appeal. I want to get back into Forth programming (I can't do this on the T2012 -- not enough RAM),but the T2012 is cheap ($3 a board) and hence has a certain ubiquity.  If I go with C, I can code both using Protothreads as my primary means of abstraction.
The advantage to using Forth on the RF2500T is that it will force me to understand the CC2500 RF module. I can't rely on a C library. I get the same advantage using C on the T2012 since it doesn't have enough space for a C library (like Simpliciti).

Eventually I'll roll my own board.

Forth and Microcontrollers

My second computer programming language was Forth. My first was BASIC.  I picked up Forth sometime around 1984. I used it first on Commodore 64 and then on a DEC2060 to do some graphic hacks for a Tektronix terminal (am I showing my age now?).  I remember tightly constrained resources. Despite spending a lot of time on a timesharing system (DEC20) I spent my youth trying to get every ounce of performance out of the likes of Commodore 64s and Atari STs.

By 1989 I  had moved on. I became a UNIX junkie. C became my "base" language and I had adopted TCL as my "scripting" language by 1995.  Over the years I've dipped my toe in many other languages including Perl, Python, Lisp, Smalltalk, Logo, Awk, Java, Lua, C++, Standard ML, etc.  By 2004 my main languages were TCL, C and (sometimes) Awk.  That is, whenever I could get away with using them.

So, now I am at full circle of sorts.  I work with 8/16 bit microcontrollers (tightly constrained resources!) and my primary language is C.

Over the years I kept abreast of what Forth was up to. Chuck Moore is something of a hero of mine. Of course, in the past 20 years I've dabbled in creating my own Forths (mostly in C). 

It was only recently that I've actually came back to actually using Forth to write applications/systems.

Forth is not dead, IMHO.  However,  while I don't think that it will make any resurgence, it does make me wonder why the Microcontroller world is still stuck using C.

If a tree falls in the forest... (SwiftX Forth)

I just finished an initial targetting of SwiftX Forth to the MSP430F5438.  I had to massage the older MSP430 configuration files that already existed to the "new" MSP430Fx architecture.

I am sure I didn't get everything right, although I managed to at least resize the interrupt vector table and define all of the major ports/registers.  Nothing too impressive, but I managed to get a blinking LED app running :-)

My original intent for playing with SwiftX Forth was to see if I could utilize it for board level testing within one of my day job projects. We don't have an effective way of poking/peeking all of the peripherals without writing a C app.  With SwiftX Forth we should be able to write a host (PC) resident test app that pokes and peeks through JTAG.  When I say "app" I really mean a handful of Forth words that test various aspects of the board.  Plus there is the added benefit of the interactivity of Forth.  Forth isn't resident on the MSP430, its just on the PC side doing JTAG.

One thing led to another and I found myself doing an actual "port" of SwiftX to the MSP430F5438 this evening.  It is an eval version of SwiftX I am messing with, but if it proves to be a useful tool for work we will be giving Forth Inc. some money.

I haven't done this much Forth in over 20 years! 

Quote of the day

"I am a design chauvinist. I believe that good design is magical and not to be lightly tinkered with. The difference between a great design and a lousy one is in the meshing of the thousand details that either fit or don't, and the spirit of the passionate intellect that has tied them together, or tried. That's why programming---or buying software---on the basis of "lists of features" is a doomed and misguided effort. The features can be thrown together, as in a garbage can, or carefully laid together and interwoven in elegant unification, as in APL, or the Forth language, or the game of chess."

-- Ted Nelson

Nuts, renegades and visionaries

The world needs more of them.  If not to force innovation, then to keep the world an interesting place.

Damn that smug Road Runner...

Why embedded operating systems are a dead end...

With the (re)rise of concurrency (in particular concurrent processors),  embedded operating systems are a dead end.  This is especially true in robotics. 

Why?

Once you get linux (or whatever) running on your embedded hardware (robot?) , you then spend some time getting all of the interrupts right and then compile your high level control language into C (and then compile that into the target MCU) and then... you emulate concurency via threading/tasks. If you go beyond C, you are probably running in a general purpose VM to boot.

For every lift of a mechanical leg, a megabyte or so of code abstraction, translation and OS task switching takes place. Ugh.

What is the alternative?

Very High Level Languages compiled directly to (or interpreted tightly within a simple VM upon)  hardware with an inter-device messaging protocol.  I want my Lisp/Oz/Haskell/Erlang/etc running on bare metal, baby! (And all programmed from within Emacs running on my laptop ;-)

Of course, Forth programmers already had this 20-30 years ago...

Scratch + iRobot Create?

I stumbled upon information regarding the mysterious Scratch Extension Protocol. This is very interesting.  It addresses a deficiency in Scratch that prevented integration with external things such as robots.

In my opinion, one of the greatest hinderances in getting kids involved with robots is the difficulty in programming them. The root of the difficulty is syntax: So you've got an iRobot Create, want to make it move? Use C, Basic, Python or whatever.   Scratch seems like a natural for this.

With the Extension Protocol, I can write a small piece of middleware that would talk to the Create via wireless (Bluetooth maybe?).

I'm not sure where I would put all of the Create protocol parsing and generation. The easy way would be to place it in the middleware, but there is something "just right" about putting it into a microcontroller that is attached to the Create.  I think I prefer that way because it offers a future hint of autonomy.  Adapting the Scratch Extension Protocol to Create Protocol can be more than a simple protocol translation excercise but evolve into a language of sorts. 

Imagine this: 

1. You develop your ScratchCreate script in Scratch, first controlling an on screen Sprite that represents the iRobot Create.  
   
2. You then launch the middleware and continue to debug the script but now control an actual Create wirelessly.  
   
3. Once you've got it working the way you want, you download the Scratch script into the microcontroller running the Create. 
   

Voila, you now have an autonomous robot!

This is a powerful concept.  I know there are similiar commercial variations on this, but there is something that resonates differently here for me. I'll have to figure out what and write in more detail as to why.

Modular Robotics (Bioloid)

A couple of years ago I dropped big bucks on a Bioloid robotic set.  My son has since lost interest in robotics (but I will try to ignite it again in a couple of weeks at RobotFest).  I lost interest in the set due to its cumbersome programming interface and (to me) flaky CM-5 processor brick.

This morning I was talking about robots with a co-worker who has done quite a bit himself in the past. I was curious to see if Bioloids were still being sold and... ooh, there are tech manuals now on the smart servos!  Protocol documentation too!  

I smell a CFT project. In particular, I should be able to pair a Bioloid sensor with an MSP430 or AVR (the CM-5 uses an AVR) and do interesting things.  Maybe I could do this with a few servos too.

Imagine: A Bioloid / Roomba (Create)  hybrid... oooh, think of the potential!

/todd

Modular HW

A new idea: Throw a bunch of MSP430F2012s at a problem.  I did this recently. Rather than deal with a bigger MCU to handle multiple sensors (which increases software complexity), I have been pairing individual MSP430s with sensors to make them "super sensors".

This allows me to "perfect" a sensor node, define a common I/O facility (bit banged 2400 baud) and then hook them to a single "controller" MSP430 (maybe a fatter chip).  An example super sensor would be a motion detector consisting of a F2012 and an accelerometer. All of the algorithmic work of determining true "motion" (vs tilt or vibration) would be handled by the dedicated F2012.  

More thoughts on this later...