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...

Back to softer thoughts...

I'm pretty burnt out. So, instead of hacking in my home lab, this past weekend I perused books. I grabbed some (mostly) math and programming books off of the shelf. It was both a reminder of some of the things I miss since I started doing exclusively embedded work and some of the things I don't miss.

What I don't miss is the plethora of general purpose programming languages that vie for my attention. What I do miss is the ability to express math concepts (especially geometry) in a high level manner. My lack of education in domain specific languages (specifically: math) is at fault here.

I think that my "general purpose" language exploration days are truly over. For general purpose programming I don't see what going beyond C and awk (or Tcl) gives me. Domain specific languages (DSLs) are interesting. For example, I use Dot (via Graphviz) for producing directed graphs all of the time. I use Scratch to work out simple animation/graphics oriented ideas (but, curse you Scratch: no parametization or recursion yet!) and I use it to teach kids how to program.

Right now, my son is interested in going beyond Scratch, so we may start playing with GameMaker (a commercial game building tool). That sounds like a DSL to me.

I've also been toying with doing a DSL in awk that will render graphic primitives (to some screen viewer/plotter via pipes) so I can work through Turtle Geometry without having to find/re-learn some Logo variant.

For work I am using awk to do some quick power consumption calculations. Excel is what we normally use, but I'd like to see the math all in one view (not by clicking on cells).

I am considering doing a short DSL in awk to coordinate between Dot/Graphviz state machines and actual code. I'd like to keep the Dot state machine up to date as the code evolves.

For now, I am exploring these softer thoughts...

MSP430 + FC30 (Orientation Sensor)

Recently, I had purchased a few "orientation sensors" (the STMicro FC30 -- basically a dumbed down 3 axis accelerometer) from Sparkfun. Its a very tiny surface mount (LGA-14 3x5x0.9mm
SMD) package and there is no breakout board yet :-(

Hmmm, I thought: I have a small tip (0.016") for my OKi soldering station, so... well, why not?

So, after a few false starts (and a couple of ruined FC30s later), I decided to mount the chip on the bottom of one of my trusty MSP430F2012 EZ430 boards (3 for $10)

So, I used a dab of 5-minute epoxy to hold it in place and began to solder jumpers between the EZ430 and the FC30. Wire-wrap wire (30 AWG) proved to be to thick (and heavy), so I used individual strands of wire from an old test lead cable.

I used a 5 Diopter Luxo magnifier lamp so I could see what I was doing (Oh, those are so nice but pricey. But they are worth it. You position them and they don't move! I have a "low end" KFM1A).

It took a couple of nights (fora total of 2 hours) and I checked for bridges using my son's microscope at 40X. It didn't look pretty, but it held.

Since I was using bare wire strands, I had to be careful not to short them together, so I "layered" epoxy between wires that crossed each other.

I was very careful not to cover the contacts (yet) with epoxy in case I had to rework the solder. When I got all of the pins soldered (I basically ran the interrupt lines to P1.1, P1.3 and P1.4 on the MSP430) I did a quick continuity check to make sure nothing was shorted. Next, I wrote a little app to detect orientation and tested it in the IAR debugger. Things were looking good!

(At this point, I must admit that I have prior experience with this sensor -- with help I managed to kludge a similar wiring job but to a 1 inch protoboard, not directly onto an EZ430. So, I was already familiar with how the FC30 works.)

Once everything looked good, a added a liberal dollop of epoxy to the bottom of the MSP430, and now I have a nice little development board to play around with orientation sensing.

Breakout board? We don't need no stinkin Breakout board. (Yeah, right...)

This was an exercise inspired by the amazing Willard Wigan.

Wireless (portable) MP3 Player

Pictured here is a mock up of my "eternally in progress" MP3 player. It's 3x2 inches.

This time it is based on a TI MSP430 + 2.4Ghz wireless module (EZ430-RF2500T), a Sparkfun MP3 breakout board and a rechargeable CR2032 Lithium Ion 3V 250mAh button cell battery.

Two jacks: up top is the headphone / line-out jack and below is the power charger module jack.

Up on the right is a micro-sd holder for MP3 files.

The unit is controlled via wireless (player controls and status).

I am estimating battery life at around 8-10 hrs of play.

(And, yes, for those of you with sharp eyes, the proto board needs to be isolated from the battery holder because the topside of the board is one continuous plane and would short out the positive oriented holder.)

Compromises

It's a bit early to make 2009 New Year resolutions, but I am posting this to remind myself of one (professional) resolution I plan to make: No more compromises.

This doesn't mean that factors won't be considered. What I produce professionally (technically) will be indeed affected by time, monetary costs and, of course, family needs. But, the feeling that I may have compromised a design or solution due to technical decisions is something I want to put behind me.

If I were to produce a technological product in 2009, it will be the *best* product I could have produced, given time, monetary costs and family needs.

I look around at the stuff that I use and like (e.g. Tivoli radios, byerdynamic headphones and Grado headphones, sennelier oil pastels, copic outliners) and I see them as the wonderful products. They are just things, but as things go, they give me pleasure.

I make things. It is what I do, and I don't do enough of it. However, I also accept too many compromises (either out of indifference, tiredness, or even incompetence on my part). I have to stop that.

AWK based AFT redux?...

I've been maintaining the current incarnations of AFT in Perl for over 10 years now. I haven't updated the code base in almost 2 years now. I can't brag that is is bug free, but it certainly is stable (at least in some interpretation of that word).

Every few months I get a question (or two) from new users of AFT. I have no idea how many people are using AFT, but it is part of the Debian and FreeBSD software archives so it is very easy to download and install on those systems.

This search indicates that there are at least folks out there using a mostly unchanged AFT to publish documents to the Web. (They haven't bothered to remove the default advertisement).

I'm pretty much completely out of touch with Perl these days, so I am not very motivated to improve or extend the current AFT. The codebase has grown complicated and I wince at some of my awkward Perl techniques.

However, I do have a very decent corpus of AFT documents. I still use AFT to do general purpose documentation and then there is the previous mentioned cache of AFT documents that can be found through Google.

If I were to analyze this corpus, would I find a simpler subset of AFT that would do for most uses? And, if I identified that subset, is it time for a rewrite?

Frankly, I would probably do such a rewrite in AWK (or GAWK). I'd keep it simple and maybe make it a little more modular (shell pipes?). I would probably drop the Windows support (although it would still run under cygwin).

Regarding modularity, I'd probably develop it to run in two phases:

1. A single AWK script to produce
• An intermediate markup for Phase 2.
• Or vanilla HTML for quick view or incorporation into a larger HTML/CSS framework.
2. A translation from intermediate markup to HTML, LaTeX, etc.
• Similar to what I have now with the current AFT.

I definitely want to reduce the number of files needed to run AFT. For a minimal run, you would just need AFT.awk and an AWK interpreter. You could then bind/embed the invocation into your favorite editor (no locating support files or setting environment variables).

That would be sweet :-)

Interview wiith Alfred Aho on AWK

Here is a good interview with Aho on creating AWK.

High Level Languages for Prototyping

I want a high level language to try out ideas. Often the ideas I am interested in draws on things such as concurrency, symbolic computing, pattern matching, etc. I don't need a production capable language. This is just for fiddling around with -- a prototyping language if you will.

Tcl and Awk were my prototyping languages of choice for the past 10-15 years. Before that it was Forth and a little bit of Lisp.

However, I have found that I have five criteria for such a language now. The first three are firm, the last two are desired qualities:

1. Supports concurrency (lots of little processes/tasks) seamlessly.
2. Seamless support for Bignums. I don't want to think about silly limitations of native word sizes.
3. No fencing in (multi-paradigm support is a must!)
4. Interactive. I don't want to do a edit/compile/run cycle for simple things.
5. Portable. I want to install it everywhere.

Erlang comes to mind, but it fails for #3.

Logo is nice, but has too many incompatible variants. StarLogo meets #1, but it looks too busy (especially StarLogo TNG).

Item 2 sounds a bit ridiculous, but for languages that aren't bound by performance needs, I don't see why I should be trapped in 32/64 bits. I'll never forget the time, back in 1984, when I typed (fact 120) in Lisp.... oooh.

I've been meaning to learn Mozart/Oz ever since I read CTM a few years back. It's a wonderful book. Maybe if I concentrate *real* hard and drop my other CFT projects, I could pick it up again. :-)

Down with Crap!

Down with crap devices! An aside: My kids came home from watching Wall-E with free crappy rubber encased disposable Wall-E watches. Ah, the irony.

We don't need more crap devices. I am less interested in the new tech gadgets. I want permanent tech. I want tech that helps people. You know, stuff that saves lives and makes our lives less miserable.

I want tech that reduces my reliance on the power grid. I want to reduce my electric bill, not increase it.

I don't want a PC in my router. I want my router to be a router. I want it to work without a lot of flashing lights. I want it to consume very little power. I want it to go to sleep at night until it gets activity coming from within my home network.

I want a GPS tracker that lasts (at a low fix rate) months or years on a small non-proprietary battery.

I want an e-book reader that lasts over a year on one charge.

I want to come to grips with the fact that battery powered devices that require recharging on a daily basis are part of the energy grid. There is no free ride. It takes power to make power.

No, wait a minute. I've got it.... I want personal tech that can be effortlessly recharged through solar power.

I still use my 22 year old Cassio CM-100 calculator. It does hex/octal/binary/decimal and boolean operations. It runs off of solar power. I've never had to think about replacing a battery or plugging it in for recharging.

More MCU Fun.

I've been looking into the new MSP430F5xx. It looks really nice. I ordered the development kit. Now I have to figure out what to do with it. ;-)

/todd

New Literate Programming Hack: Knit

I can't really use CWEB or other disruptive Literate Programming tools at work. I want some of the benefits that Literate Programming brings, but I can't take the baggage (at least not at work).

Yet, when I code in a LP style, I tend to be much more precise and correct. My code does tend to be less buggy. I think it is because it forces me to really think about my code in such a way that I want to be able to explain (and understand) every variable and every line. After all, the code becomes something I have to talk about, not just pump out. Do I really need a variable here? Do I really understand how that library macro works?

So, a couple of nights of hacking and I have yet-another-pitiful-LP-inspired-code-markup technique. I call it Knit.

It is written in gawk and embeds its own documentation in the source code comments. I hope to have some C examples soon.

New Knuth Fascicles..

With Donald Knuth being trashed fairly recently on reddit and various blogs (mostly due to a recent interview), I realized that I haven't perused his site in a while.

Oooh. More fasciles!

In particular, I'll be trying to digest some of this one tonight.

(I am a huge fan of his work. Literate Programming is my all time favorite technical book. I read it back in 1992 and it has completely screwed me up for life. I read it whenever I get burnt out and need some inspiration. It has always been my model for excellence for both it's content and style.)

A half dozen uses for a Motion Sensing Accelerometer

So, you've got yourself an accelerometer...

1. Who walked off with my XXXX?
2. Handheld XYZ gadget's screen is facing down on the table. Turn off what cannot be seen.
3. My car is housed in a long time parking facility (I'm out of the country for a few months). Who moved it, and when?
4. Can't acquire GPS (or Comm Satellite) with a patch antenna when the patch isn't oriented correctly. Why waste the power?
5. No. Nobody simply bumped into or moved my bike out of the way. Ack! Somebody is riding away with it!
6. Out on a nice hike. Oops, I've fallen down the slope and can't get up... or.. OH MY GOD: I'm being thrashed about by a bear.

Okay, so #6 is a bit far fetched....

When is Forth no longer Forth?

If you follow Forth, you know that Chuck Moore is continually reducing what he considers to be Forth. But, I am intrigued by this 1991 article by Frank Sergeant.

I have a desire to do Forth on the MSP430, but there isn't a lot of memory. Even Forth expects more memory than most of the smaller MSP430s have available. There are commercial Forths that run on MSP430s, but what they offer is unclear.

I am trying to build a Forth-like language that will not only offer a tethered solution to MSP430 app development (run an interactive development environment on the PC that "controls" the MSP430), but have one that can save the results of tinkering as actually target code for the MSP430. I am taking the VM route (mainly because I don't have the CFT bandwidth for assembly). The C coded VM will have a target size of 2-4K and should execute the Forth bytecodes emitted by the PC based interactive development environment.

Just another CFT on the vine...