Friday, October 02, 2009

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

Thursday, October 01, 2009

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.

Wednesday, September 30, 2009

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.

Sunday, September 27, 2009

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

Wednesday, August 26, 2009

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?

Friday, July 03, 2009

Living my values...

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


Thursday, July 02, 2009

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 :-(

Monday, June 15, 2009

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.

Thursday, June 11, 2009

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.



Monday, June 08, 2009

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

Sunday, June 07, 2009

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.

Friday, June 05, 2009

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


Wednesday, June 03, 2009

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

Tuesday, May 26, 2009

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.

Tuesday, April 14, 2009

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! 


Friday, April 10, 2009

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


Monday, March 30, 2009

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.


Friday, March 27, 2009

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

Sunday, March 15, 2009

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

Monday, March 09, 2009

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

Thursday, February 05, 2009

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.

Saturday, November 29, 2008

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

Thursday, October 23, 2008

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.

Tuesday, August 12, 2008

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.

Wednesday, August 06, 2008

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

Sunday, July 27, 2008

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

Tuesday, April 29, 2008

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.

Monday, April 28, 2008

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

Wednesday, April 23, 2008

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

Thursday, April 03, 2008

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

Tuesday, March 25, 2008

Maplefish Labs



I finally finished my creating my electronics workspace. It's in our "art room" and my electronic workspae is shared with a ton of art supplies, an easel and couple of craft tables for the kids.

To the left you can see how the art supplies have crept into my workspace. That's an airbrush compressor.

Sunday, March 16, 2008

The Quiet

This is a long post of little interest.

About an hour ago, I read to my two five year old girls. We read Jon Muth's Zen Shorts. I don't know if they really enjoyed it, but it was a quiet read. My wife and nine year old son are out of town.

The watercolor artwork of the book was soothing and provided an easy transition to bed time. While I read, from the kitchen Yo-Yo Ma could be heard playing the works of Ennio Morricone. The music was both spectacular and relaxing. This collection of soundtracks always seem to quiet the girls. They seem to know that when classical music is heard, bedtime is nearing.

They drifted off to sleep a half an hour ago. There were no final protests, only a question about whether tomorrow will be Tuesday. No, sweeties, Tuesday is the day after tomorrow.

It is evening. The earlier part of the day was about family. The girls played hard and could not be convinced to help with house cleaning. They behaved their age, as expected.

The morning was rainy until about 10am, when the sun finally made its appearance. In celebration, I cleared the living room floor of unfolded clothes. We then danced to an adhoc mix of R&B. We danced to some Lauryn Hill, Michael Franti (Spearhead), and old-school Chaka Khan (with Rufus). After dancing, the girls took a bath and I whisked them off to spend a couple hours with their cousins, aunt and uncle.

The late afternoon saw me tinkering around with microcontrollers and solder at my workdesk. At a particularly difficult solder junction, I was interupted by the return of the girls, their cousins, aunt and uncle.

Then, quickly, came their supper, teeth brushing and nighttime book.

There was something about the book, the Zen Shorts book, that seemed to break any desire to return to the workbench. Nighttime is not for engineering. At least not for me tonight.

My supper is simple and not very refined. A bagel, some sunflower seed butter, a glass of cheap Pinot Noir. The house is quiet.

My thoughts turn to art, the books I bought recently to read, and the quietness. The unusual quietness that would have not existed with whole family present.

The books were purchased yesterday on a whim from Second Story Books in Rockville. This is a huge warehouse full of used books. I spent a hour and a half browsing the science, computer, engineering and math sections. I left with three books: The Tale of the Scale, The Introspective Engineer, and The Art of Mathematics.

As a modern technological man, I feel compelled to fill quiet voids with ideas, tinkering and programming. All of this, I am compelled to dive into with a panic -- I only have a few hours before sleep and the week will begin.

Another glass of wine and this feeling should dissipate. A little cello swooning and swaying in the background should set the mood for reading.

The week ahead is full of projects and spirited engineering. There are difficult deadlines looming.

But tonight, there are clothes to be folded, a bed to be made and books to be perused.

Yet, in the quiet there is still a tug of loneliness. I keep expecting to hear my son giggling or his inevitable "what can we do together tonight?". But, that will soon return. It will be a welcome return, but tonight there is just me, my gently sleeping girls and the quiet.

Saturday, March 08, 2008

2nd Quote of the day, also from SICP

Why can't a day have two quotes?

From the Foreward of "Structure and Interpretation of Computer Programs":

"The source of the exhilaration associated with computer programming is the continual unfolding within the mind and on the computer of mechanisms expressed as programs and the explosion of perception they generate. If art interprets our dreams, the computer executes them in the guise of programs!"

- Alan J. Perlis

Quote of the day, from SICP

"I think that it's extraordinarily important that we in computer science keep fun in computing. When it started out, it was an awful lot of fun. Of course, the paying customers got shafted every now and then, and after a while we began to take their complaints seriously. We began to feel as if we really were responsible for the successful, error-free perfect use of these machines. I don't think we are. I think we're responsible for stretching them, setting them off in new directions, and keeping fun in the house. I hope the field of computer science never loses its sense of fun. Above all, I hope we don't become missionaries. Don't feel as if you're Bible salesmen. The world has too many of those already. What you know about computing other people will learn. Don't feel as if the key to successful computing is only in your hands. What's in your hands, I think and hope, is intelligence: the ability to see the machine as more than when you were first led up to it, that you can make it more.''
Alan J. Perlis (April 1, 1922-February 7, 1990)

Friday, March 07, 2008

The most brilliant paper I have read in a while...

The paper referenced here.


It's about the art form known as mathematics.

Sigh, time to break out my Turtle Geometry book again.

Thursday, March 06, 2008

Not a "Maker"


Not that anyone has asked, but...

I am not a "Maker".

I've alternated between awe and respect in regards to the things I've seen "Makers" make, but I am not one of their clan. Neither am I one of the closely related "Dorkbots".

I don't think I actually "like" to make things. I am driven to make things. It's in my blood.

I don't have a lot of things to show at this time because I tend to obsess. I hate the idea of spending 8 hours a day working on stuff that doesn't interest me, so I tend to get (and stick with) jobs that allow me to obsess. And, that tends to suck away at my CFT.

So, I am less interested in making really cool stuff like you can see here. But I do seem drawn to making (or at least thinking about) stuff that has more tangible impact.

That sounds rather "engineer-y", but I am (at times) equally consumed by art (music, books, drawing and painting). Sometimes I've even been known to do a drawing/painting or two.

Keep an eye on this space and hopefully I will find the CFT to work on something I am passionate about. It may not be earth-shattering, but hopefully it will be interesting, well engineered and full of beauty.

Enough talk... I should be working on something.

Wednesday, February 27, 2008

Life is too short to idle away in a cube...

Not much is getting done in my office cube today. I like my job; I hate my cubicle. (I hate *all* Cubicles).

I've got some serious mental blocks happening right now. I'm not feeling 100% healthy, so that is definitely a contributor.

I'm going home to hang with my son.

Inspiration... Knuth & TeX

My interests are odd (for a computer geek). I don't think I'm retro, but I've learned Ruby, Lua, Erlang, ML, OCaml and a bit of haskell in the the past 7-8 years (yep, I first picked up on Ruby in 2000). I really haven't learned a new language (or done any real programming in the above languages) in the past 4 years.

I'm interested in [La]TeX again. A couple of posts ago I mentioned working on AFT. That could be fun, but (if I had the CFT) I'd rather hack around with TeX. In particular, I am interested in learning MetaPost (look it up). There is a nice $50 LaTeX graphics book that covers MetaPost.

So, I am thinking to myself, wouldn't it be fun to do some hardcore typesetting? (Remember, my interests are odd.)

Fundamentally, I love the idea of TeX (and LaTeX). The end result is very tangible: A (potentially) beautiful typeset document. Maybe make a book out of my kids' artwork or something. TeX (and LaTeX) is a complex enough system that it would be fun just to get lost hacking in it.

Emacs is a large hackable system too, but the end result is some editing tools.

Unix is a large hackable system, but the end result is doing some process/text manipulation.

With TeX, the end result is a piece of paper. A well typeset piece of paper.

Quote for the day

Twenty years from now
you will be more disappointed
by the things that you didn't do
than by the ones you did do.

So throw off the bowlines.
Sail away from the safe harbor.
Catch the trade winds in your sails.

Explore, Dream, Discover

-- Mark Twain

Tuesday, February 26, 2008

AFT Stuff

It's been a couple of years since I've done anything with AFT. I have a few ideas I've wanted to implement for a while, but I am tiring with mucking with the core of AFT and causing distress with any of my (few) users who wonder if they should upgrade. Sometimes a new feature may break old stuff or sometimes I roll in fixes with the new features.

As far as I can tell, AFT users install the version of AFT current to when they discovered it, use it and then resist upgrading (why upgrade when the tool does what you want)?

So, I am going to freeze AFT against any new features and add features by way of AFT add-ons.
These add-ons will be separately download-able and work with the AFT you have installed.

Here are some of the potential AFT add-ons:
  • aft-indexer -- Create an index on an AFT file against words in a separate document, write out a new AFT file that includes AFT markup for an index and run AFT against that.
  • aft-fixtabs -- Take an AFT document and smartly fix any tabstop errors. Output a new AFT document with tabs or N spaces for tabs.
  • aft-ft -- Convert "free text" (somewhat intelligently) to AFT format.
  • aft-simple -- A newer, simpler markup format (influenced by lessons learned) that produce standard AFT output.
The add-ons will be written in Perl or C and conform to AFT's current policy of not requiring any additional Perl modules outside of a standard 5.x distribution.

Tuesday, February 19, 2008

Idea of the week #1: Scramble Box

This would be a small handheld device powered by a AAA battery that has 1 SD slot, two buttons and 1 tri-color LED.

Let's say you've just taken some prize-winning pictures and want to "secure" the SD card from copyright thieves.

You just pop in the SD card, press the "scramble" button and all content on the SD card is encrypted (in place) using AES-256. The LED lights yellow while this is happening and then turns green when done.

(The key was crafted by you and programmed into the device earlier by putting it into a file called "CFG/KEY.CFG" on a blank SD card).

When you want to unscramble the SD, you pop it in and press the "descramble" button. The LED lights yellow while this is happening and then turns green when done.

The device holds onto the "key" in flash memory. You can use a different key anytime by placing CFG/KEY.CFG on either the enrypted or yet-to-be-encrypted SD card. At the end of encryption/decryption the CFG/KEY.CFG is securely deleted (don't want to store keys in the clear, now do we?). If the CFG/KEY.CFG is supplied on a blank SD card, the flashed key is changed.

This is less secure (if someone steals your Scramble Box AND your encrypted SD cards then they can decrypt the cards so as long as they were encrypted with the currently flashed key). However, this at least allows encryption/decryption to occur without creating the key file
(so you can go directly from camera to Scramble Box).

Now, photos are probably not the best use case here. A better, although less dramatic, example would be to put a bunch of "important" documents on the SD card and run it through the Scrambler.

However, since we are just using a fairly standard AES-256 technique (CBC w/ CTS), you could always do the encryption/decryption on a PC (with the right software).

In this case, the Scramble Box can be used for batch encryption/decryption.

Oh, and for usability, the key is a simple password/passphrase that is run through a hash function, so you don't have to memorize a 32 bit key ;-)

Lambda the Ultimate links to some of my old ideas

These links are mainly here for my own bookmarking purposes, but they expound ideas I can't seem to let go of:


In the second link, Luke Gorrie ported his "untar" program from scheme shell to bash. I tried to make it more beautiful (or perhaps just more obfuscated). Here is his ported script, and here is my rewrite.

Wednesday, February 13, 2008

The End of the Analog Television Era: Sad...

The end of an era is coming. On Feb 17, 2009 analog television broadcast is supposed to come to an end. The US government has mandated that all over the air broadcasts will be digital. They are giving away coupons for free converters for analog TVs. After March 1, 2009 all newly manufactured TVs must be digital.

Since 1941, the analog broadcast standard has pretty much remained the same. The same signal broadcast then can be received now. For over the air broadcasts, the era of NTSC will end after a 68 year run.

Children in a post 2009 world will never know about "snowy" pictures. With poorly received digital, you get frame drops, stutters and pixelation.

The days of hacking analog TV signals are also gone. This is not quite as dramatic as the (eventual?) loss of analog AM/FM radio, where with just a crystal and a few parts any kid can tune in a grainy signal and thrill to the discovery of turning inaudible radio signals into sound!

I haven't figured out yet what the plan will be regarding "emergency broadcasting". When the next flood or tornado hits what do folk who didn't get the "free voucher" upgrade (or are just too far away to get a decent signal) do? In the middle of swampy Lousiana, or in a remote farmhouse in Kansas you may be able to currently get a grainy noisy signal warning you of disaster. Come 2009, how well will the same tower broadcast digital? Will you be able to make out the news when the digital stalls and drops?

None of this affects us cable/satellite users. But, I want to tune in when the moment comes and we witness the silence of the analog signal. I wonder how many uninformed people will take the silence to mean an invasion from space or Armageddon?

Monday, February 11, 2008

Cutting Code in a Coffee House

I need to remind myself that its all about creative problem solving. The Web and internet is all just a facade. Software is all about a manifestation of concepts. It's a tool for creative thinking. If you can web-enable it then you are trendy.

While doing embedded development, I am limited by what can be physically rendered. I can only get things smaller up to a point. I can only do what physics deem possible (for today at least). I can be creative, but I can't fly.

Current thinking in Web technology threaten to clip my wings too. I left IT development for the embedded world because I felt bogged down by XML, HTML and the Web programming juggernauts (Java, Javascript, Ruby, etc).

The effort of putting things on the Web didn't seem all that sexy anymore.

The effort of building complicated backend servers was no longer appealing.

Building embedded thingies gives me some immediate satisfaction. People use the stuff I build. I can measure the impact. It's real. It is physical. It has a form.

But, I kinda miss pure software. Coding in coffee houses is fun. Developing something useful while sipping on coffee and eating sweet breads (doughnuts, danishes, pie, oh my) is heaven. I just need an idea.

At times, when I got wrapped up in just hacking for the sake of hacking (e.g. getting awk/ksh/bash to do things they really weren't meant to do), I didn't feel like I was contributing much. Hey, I was a member of the language-of-the-week club (Erlang, Haskell, ML, etc)!

In reality, the languages I am the most productive in has been (in no particular order): C, Tcl, Awk and Perl. I've built production systems in Tcl/C and have written my only contribution to open source in Perl (see AFT). So, why do I insist on learning new languages? Why can't I just cut code in what I know best?

I need to take the time to visit a coffee house. Just me, my laptop and some ideas.

Pure Software vs Embedded Hybrid

Visions of purchasing the Asus EEE has grabbed me lately. It would probably be useless for embedded development, but if I imagine myself somewhere on an island (or in a mountain cabin) hacking away at my latest ideas. There wouldn't be much embedded work done there.

At the minimum, embedded work would take a PC, some sort of JTAG interface and a target board (and maybe a power supply). To do embedded I am chained to my house (or the lab/cube at work). With a nice portable, I could be sitting in a coffee shop or in an airport terminal, jamming to tunes while I hack away.

This is a different kind of development, though. As much as the embedded devices I hack during the day will impact people (I design pagers, satellite based trackers, etc), writing pure software (that either runs on a server or someone's PC) has the potential to impact far more people (and hopefully for good, not evil!).

Thursday, February 07, 2008

(Simple) Single Wire Protocols

My current favorite MCU is the MSP430. In particular, I like the ones that stretch the longest lifetime out of small batteries (like a CR2032 coin cell). Unfortunately, there aren't a lot of "communication" options for such a low power design (think: how do we get logged data out of a tiny low power processor?). RS-232 is too heavy, SPI/I2C is too complex, Bluetooth and other RF is too expensive (money and power-wise).

How about a simple single wire protocol?

Dallas/Maxim has such a protocol (called One-Wire) that is very interesting, but its very proprietary (you can't legally create a slave -- they reserve the right to be the sole provider of slaves that are compliant to the protocol). Among other things, this protocol supports multiple slaves and can even be used to power them. You just need a single wire (normally pulled up) and a common ground. The single wire is used for *all* communication (bi-directional).

I'm looking at doing something similiar to this, but greatly simplified: Only one slave supported.

(Random) Copious Free Ideas

A few random ideas for someone's Copious Free Time: (All of these projects involve very low power circuits -- the idea is that these things will run a long, long time without changing batteries).

Cold Bot

Augment a Roomba (or iRobot Create) with a temperature sensing parasite that navigates the Roomba to the coldest spot(s) in a room. If the temperature sensor was mounted on a small probe/arm, then you could pin point insulation leaks. The parasite also controls the power to the roomba thereby extending runtime by shutting the roomba off when the coldest spot has been reached.

For extra credit, make it a warm bot, place a gold fish bowl on top and let it take the fish to the warmest part of the room ;-)


Temperature Throwies



Tape a MSP430F2012 to a coin cell battery and use the internal temperature sensor to log temperature data to its internal flash. Make a bunch of them and place them in parts of the room or house that you are interested in monitoring for temperature trends. Create a single wire interface (data) to transfer data to a collector. The collector has two probes (ground and data) that you touch against the sensor in order to transfer logged data (along with an associated sensor ID).

Plot collected data on a PC.

Mom, my little sisters are messing with my stuff!

Couple a tilt sensor (accelerometer) with an MSP (or AVR) to make a small alarm. Use a piezo buzzer and coin cell battery. Make it small enough not to be easily noticed. Put on top of (or inside of) the item you want to monitor. If someone moves the item, the piezo screams.... for a long time.

Alternatively: Remove buzzer and use a watch crystal to build a fairly accurate RTC. Silently log the time the item was jostled. Collect this info later with single wire interface.

Tuesday, December 11, 2007

Never power down

Low power consumption computing is an interest of mine. While we have things plugged into AC that never really go off, they still consume a fairly high amount of power.

No, I'm talking about devices that never truly cut off. Or, at least, some portion of a device that never cuts off. How about a pico power AVR or MSP430 that runs off of a small coin cell battery for months/years. Running while quietly collecting data or waiting for a command from you to turn on it's host (we are still talking about parasitic computing here).

What useful things can we do actively under 1mA, while periodically sleeping at under 10uA?

Friday, November 23, 2007

... or is this more appropriate?



Someone at work (thanks, Rob K.) pointed out how maybe my "Biotrophic Parasitic Computing" idea is similar to the relationship between Remy and Linguini in the movie Ratatouille.

Does that sound more pleasant?

Wednesday, November 14, 2007

Biotrophic parasitism as a computing strategy

Biotrophic parasitism is a form of symbiosis between a parasite and it's host. The parasitic organism doesn't destroy it's host, but co-exists with it.

This presents an interesting strategy for embedded computing, or more precisely, the augmentation of existing embedded computing devices. This has, lately, become a consuming interest of mine. But, before I dive into that, here is something a bit more lurid.

This was the basis for my original line of thought: Parasitic fungi that control the behavior of the host. Unfortunately, this is not symbiotic, as the host is ultimately consumed or destroyed. I don't seek to replicate that type of relationship in my embedded augmentation experiments. But, outside of the grisly demise, it's pretty close to what I am talking about.

Consider this: You want to modify the behavior of your Roomba. You attach a microcontroller that feeds off of the Roomba's power and augments the Roomba's behavior through the "Open" serial interace. That microcontroller can be said to be parasitic. If the microcontroller is small enough (e.g. consumes little power from the host) and is well behaved (e.g. won't cause the Roomba to ignore it's cliff sensors), then it is a Biotrophic Parasite.

There are some microcontrollers (and of greater interest: microcontroller boards) that are well suited to biotrophic parasitism. For example: the Lilypad and this (3 for $10) board from TI, that can be programmed by this $20 development board.

Interestingly, I've been doing something along the lines of parasitic computing at my day job.

As I play with my iRobot Create (and forthcoming Roomba), I hope to exploit this technique further.

I like to call it Biotrophic Parasitic Computing.

Wednesday, May 23, 2007

Crypto for Everyone: Scripting and truly transparent systems

The idea of writing tools using standard unix scripting facilities (e.g. sh, awk, sed) may seem like a exercise for idle minds, but it has certain qualities that may make it beneficial to the end user at large.

That benefit is transparency.

For example, consider a simple blowfish encrypt/decrypt application. There are dozens of implementations in C, Perl, Tcl, Python, Ruby, etc. But, each comes with a certain amount of baggage. For Perl, Tcl et al, you have to make sure you have the right version of the interpreter installed as well as the right libraries. With C and C++ you have to make sure you have the compiler on hand with the correct libraries (unless you are willing to install an opaque binary).

However, a blowfish application that is written using always available OS facilities (under the assumption that your OS comes loaded with standard GNU utilities) is both portable and transparent. A blowfish implemented in gawk and bash/sh is very transparent. The user can see what is going on and even make modifications. Beyond that, adopting the "unix way" could make the usage of such an application transparent: it operates as a typical unix filter command where you can use pipes (and redirection).

This is an interesting idea (to me at least). Download blowfish.sh and you have an encrypt/decrypt solution (assuming you have gawk installed). Now, just use it. Pipe to it. Put it in /usr/local/bin (or some other convenient path) and use it as often as you would "cat" or "ls". It's not terribly fast, nor is it terribly efficient, but you can see what it does and can change it, play with it and make it do what you want it to.

This is all part of a copious free time deep thinking effort I've been up to. I am trying to figure out how to offer the simplest tools (simple in terms of installation, configuration and modification) to environments that lack such tools. It seems that everytime I (we?) think of an easy (usually GUI based) way of doing things, such as encryption, I (we?) get caught up in trying to provide the most sophisticated solution. Either that solution is never completed or simply doesn't "take".

Sure, blowfish.sh has vulnerabilities (mostly regarding typing passwords on command lines and buffering decrypted output), but for most users who do not do encryption, this offers some level of protection.

Now, you could argue that most "users" don't know how to use the unix shell or simply don't use unix (MS Windows is used by most of the computing world). But, you could wrap blowfish.sh in a BAT file or simply add a little more scripting to automatically encrypt samba mounted directories from a unix box (see my last post). This too sounds unsafe, but it is much safer than keeping your currently unencrypted list of credit cards, bank account numbers and passwords sitting around on a laptop drive.

Tuesday, May 22, 2007

Never underestimate the power of a small unix + lots of shell scripts

I've been wondering how to solve some home "IT" problems. You know, things like backup, password management, picture management, encryption of financial documents, etc.

I wonder what the combination of FreeBSD, bash (or ksh93!), gawk and samba would do for me.

Well...

If I could samba mount all of the primary Windoze harddisks (kitchen, guest room, etc), I could write a few scripts to do all of the dirty work. There is quite a bit of power and flexibility in having a smallish unix server controlling all of the MS beasts.

This would solve so many problems...

Tuesday, April 24, 2007

Cool eval board


This has caught my interest:

It's the Atmel AVRUSBKEY eval board. It does USB 2.0 as both host and controller. 16MB Flash on board with a joystick and a couple of LEDs.

Just $30. But, for some reason digi-key has upped their price to $50. What gives?

Monday, April 02, 2007

Mailsavant

My current CFT activities have been consumed by Mailsavant. Mailsavant is a dual purpose CFT project. On the one hand, it wants to be a haven for email junkies like me. On the other hand it is meant to be the manifestation of some ideas I have regarding writing software.

As a haven for email junkies, I am building Mailsavant to offer what may be regarded as a retro interface for the internet. I already use email to post/manage content to my other blog. But, I would like to leverage email as a replacement for other casual web site interactions. In particular, I am building an event notification service that can be fed primarily via an email interface (no clicking on calendars, when I want to be notified "next Tuesday at 3pm" of a particular event, I *say* exactly that in an email subject line. The system acknowledges that it received my notification request and then dutifully notifies me of that event as it nears.

The idea that such software would not only be useful, but well designed/implemented is the other focus of this CFT. I am taking a very minimalistic "Software Tools" approach to development. Most of the software will be written in a combination of AWK and (posix compliant) Unix shell (along with stock programs that come with Unix -- ls, grep, find, etc). My programming methodology will follow the "Unix Way" (small tools with each tool accomplishing just one thing). I have my own bizarre reasons for doing this, one of which I want to avoid software bloat and *seriously* contemplate how to build an internet service from scratch with no preconceived notions or shortcuts.
Yes, everything will be written in AWK, including the SMPT mail server and mail delivery agent. And it will be built to be robust and stable (with decent performance too).

Very few open source libraries will be utilized. I expect the calendaring app will take less than a couple thousand lines of code.

Stay tuned.

Tuesday, March 13, 2007

Cure for the programming humdrums.

This book never fails to inspire me to write code. It is one of the few computer books (perhaps along with this) that I can say actually affected my perspective on programming. Since programming is as much a part of me as performing music is a part of a musician, these two books have had profound effects on my life.

As much as I like toying with hardware, at the end of the day I am a programmer. I may no longer care to follow the current fads and coding crazes, but I still love to code.

I'm hoping some bedtime reading of the former (Literate Programming) will help cure my current programming humdrum.

Tiny, tiny interpreter

I've yet to find a suitable scripting language for the Turtle. Its probably about time to consider rolling one of my own. I will probably use Tcl (circa 6.7) as a model. Rather than be "string" based, this language will be "array of byte" based, which will require some additional parsing. However, parse-on-the-fly model of early Tcl will be used (i.e. no intermediate byte code, no complex parse tree).

Friday, March 09, 2007

(Re)Kickstarting the Turtle

I've been taking a break from the Turtle (the iCreate robotic platform). But, now I'm trying to get myself back into the groove.

The way my mind works: I'm not motivated very much by hobbyist pursuits. That is, my CFT is usually grounded in building something practical. This is not a criticism of the wonderful Maker mentality. It's just that I don't seem to possess that gene (the one where you hack/make for just the intellectual gratification).

Now, mind you, when I draw or paint I am doing it solely for my own gratification. But, these days, with such limited CFT, I tend to want to make stuff that has some practical purpose (even if it is just to further my knowledge -- so I can do greater things). Maybe its my 40 year old brain screaming "do something useful".

I am working on some C functions to allow the AVR chip to control the Turtle. Of course, there is nothing special about this. I just really need to get something running so I can start programming the Turtle to do something "interesting".

Over the next few days, I need to determine what "interesting" is.

Wednesday, March 07, 2007

Logo is Lisp (sort of)

I've had an interest in Logo for the past 20+ years. Or, more specifically, I've known about Turtle graphics for over 20 years. I never really immersed myself in the Logo language though. I've always end up implementing Turtle graphics in my favorite language du jour.

Now that I have kids, I have to ask myself: When it is time for them to learn how to deeply interact with the computer (beyond browsing, games and paint programs), is Logo still the language I want to introduce to them?

Scratch is amazing, but something is missing when you don't "talk" to the computer in a written language (Scratch is a visual programming environment). Most of what you need is there, but there is no poetry.

I am very fond of Logo (and not just from a teaching kids perspective). I like its simplicity. I like the way it has a low entry level but no apparent "top" that would cause you to defect to another language. Logo is a dialect of Lisp. It's a simple Lisp with syntax added and parens removed.

I still think it is relevant. Do you?

P.S.
My 8 year old son plays with Scratch from time to time. We haven't tried any "educational" stuff with it yet. Still, my son has an aptitude for math. Does he need it hidden by the layered GUI facade of Scratch?

Distracted by interesting books... again.

For a little nighttime reading, I've been re-reading Mindstorms. This led me to purchase Turtle Geometry. Both books were published around 1980, but are still more than just historically interesting documents.

Currently, I am mini-obsessed with working through at least some of Turtle Geometry. I know -- this is hurting my CFT projects, but I've been sleepy and too focussed on my day job to do any C & micro controller hacking at night.

Back soon...

Friday, March 02, 2007

BLOGnBOX

I've been spending time bouncing between here and BLOGnBOX (a blog about blog software).

I've obviously have too much Copious Free Time ;-)

Saturday, February 24, 2007

HLL - High Level Languages?

Here's a cool idea: The turtle is programmed by having the brain (ATmega128) read scripts off of an SD card. So, this can't be C. I need a simple (s-i-m-p-l-e) scripting language running on the ATmega128. Something Lisp-y would be nice. Forth is a bit too low level (I don't want to hack the hardware with this language, I just want to use it to send commands to the turtle).

Still searching....

Simplicity

Software is tricky stuff. I do it for a living. Integrating lots of open source code is very tricky stuff. Nothing ever quite configures the way you exactly need it.

Circuit design and soldering is tricky stuff to. Even breadboarding gets tricky when you have to hunt down that 48 ohm resistor and mail order it. Then, half way through the delivery time you realize that you need a 22pf cap too.

I'm going to try and minimized the tricky stuff for my iRobot (turtle) hacking. Where I can buy a "module" I will (rather than code up work-a-rounds or do any major soldering).

For example, I decided to go with a simple ATmega128 board rather than the butterfly. Why? Well, the butterfly already required me to solder header pins (for UART, JTAG and ISP to start). Plus the UART has a voltage converter (14v RS232) where the turtle wants TTL level serial. I would have to hack the butterfly (either with solder: put another level converter in or through software: utilize the SPI ports for UART). Hacking the butterfly was starting to look ugly.

With the ATmega128, so far everything is about jumper cables. This is simple and clean. I should be able to just hook it up directly to the turtle.

Now, regarding software...
I want the turtle's brain (the ATmega128) to be able to take instruction from files on an SD card. I need an SD card holder that has header pins I can connect to the SPI on the ATMega128. Okay, that was simple. But... How do I interface the SD and 128? Well, I need an SD driver and a FAT file system. There are some free implementations out there (of varying quality), but the real question is whether or not I want to take the time to "port and integrate" as well as if I want to suck away a significant portion of my precious 4K RAM (on the ATmega128).

Sigh. Money to the rescue? I am looking at this. It does everything I would normally do on the ATmega128 (regarding filesystem and driver mgmt). I have to think about this. Simplicity = Money? Complexity = Time/Effort?

Friday, February 23, 2007

The Butterfly has been set free.


The Butterfly will be freed to work on other projects. The new brain for the turtle is an ATmega128 from MicroController Pros:

Tuesday, February 20, 2007

Alternates to the Butterfly

Creating a decent DSL that consumes no more than 1K RAM is a challenge (for me at least). Certainly coding the runtime/VM in C adds to the challenge (and bloat).

However, all I really need is a looping facility, conditionals and some primitive form of global variable creation (1K is not a lot of space to get fancy and do closures, recursion and other forms of state capture).

First, thing is first: I need to study the iRobot Create Open Interface and see what kind of commands I need to send and responses I need to react to.

In the meantime, I stumbled upon this ATMega128 board. Nice price, more memory (4K RAM) and perhaps more suited to my task than the Butterfly.

Saturday, February 17, 2007

DSL for Butterfly/Turtle

So far, the few languages I've seen for the AVR chipset are too general. I want to program the Butterfly to manipulate the Turtle. This is the only domain that I need to deal with. I could use a Domain Specific Language (DSL) that only addresses fundamental language constructs such as iteration and branching. The domain specific part just needs to manipulate the Turtle by way of the iCreate command set... And, all of this in 16K program (flash) space and 1K dynamic (RAM) space.

This should get interesting.

Thursday, February 15, 2007

The little problem of RS-232 interfacing...

The turtle wants 0-5V (TTL) serial communications. The AVR butterfly has a level shifter that brings it's UART to RS-232 levels. A simple jumper between the butterfly and turtle would have been nice. Instead I have to look into using the turtles level shifting DIN connector.

But wait! According to this I can use the USI pins to emulate UART. This would be nice. Just 3 plain jumpers between the butterfly and turtle and a lot of tricky software ;-)

How to program a butterfly..

The AVR Butterfly is based on the Atmel AVR ATMega169. This mcu has 16K of program space and 1K RAM. That 1K of RAM isn't too bad when you consider that this chip is expected to be programmed in C.

I'm getting pretty good at cutting C for the AVR chips. But, this would prove to be too cumbersome to really do anything "interesting" with the iRobot iCreate (which I refer to as "the turtle"). I could write C code to do some basic tasks, but I'd rather have a means of scripting the turtle. On a bigger mcu (ARM7, etc) I'd just load up Lua or Tcl (or some implementation of Scheme). But, 1K isn't a lot of space for dynamicism.

So, I am going to scour the web for any decent alternative programming languages for the AVR (but not BASIC and what FORTHs I've seen don't do much for me). If I can't find one, I may have to roll my own!

Scratch!

It has finally been released to the public. This is very cool and (hopefully) very important. I always thought that Logo was tremendously interesting and important as a tool for kids to learn modeling and problem solving, but the reading/typing requirements were to high for, say, a 6 or 8 year old.

So, a graphic oriented way to program sounds about right these days, especially if capable of doing multimedia. Squeak Etoys seemed to have to high of a bar for beginners, but Scratch seems just about right...

Friday, February 09, 2007

Jumper wires?

How come these simple things are so hard to find? I see vendors that sell jumper pins. I see vendors that sell controller boards with mounted jumper pins. But these same vendors never carry jumper wires.

Okay, found one.

I need about 25 jumpers for the Turtle's cargo bay connector.

Thursday, February 08, 2007

Choosing an AVR C compiler

This blog is lacking in pictures. I need to fix that. Unfortunately, for this post, C compilers don't make good photo material...

Choosing a C compiler should be a trivial matter, right? Hobby project? Limited budget? WinAVR or the GCC/AVR toolchain under linux are the sane choices.

Unfortunately, at work, I am using the world's most expensive C compiler (IAR) for my AVR work (its over $2000 for a full version; a "free" version is limited to 4K of code) and I am more familiar with it than the GCC/AVR toolchain.

A couple of other vendors offer 2K code limited "free" versions and aren't too pricey, but we are still talking about over $500.

Then, there is Rowley Crossworks AVR.

Rowley comes with a 30-day evaluation and a "personal" edition costs $149. From what I can tell it is the full blown version, but you can't use it for non-hobby projects. And, it has some "migration" compatibility with IAR! Plus, it is supported under Linux as well as Windows.

But, why in the world would I pay for a compiler?

Let's look at the potential negatives and my answers to them:
  1. My source code won't be of use to those without the commercial compiler. True, but I am emphatically NOT trying to do a software project here. Binaries are royalty free and people will be able to "port" my code to GCC if they wish.
  2. There are more libs (and support) for GCC/AVR out there. Arguable. Besides, I am going with "lightweight" here. No external libs, no OS.
  3. No Emacs. Well, IAR supports external editors, but the other IDEs don't. I've been using emacs for 20+ years now... hard to give it up.
A big plus for a commercial IDE/compiler: JTAG support. Sure, I could use Atmel's free AVR studio with WinAVR to do this, but I am looking to spend less time hacking my development environment and more time hacking robots.

I'm currently evaluating the Rowley compiler.

Monday, February 05, 2007

Potential Butturtle Project

I won't kid myself and think that people actually read this blog, which makes it all the more unusual that I actually wrote this sentence....

But, I digress. While I am waiting for parts, I have started thinking about what I would have the AVR Butterfly do to the iRobot Create (which I re-christened "Turtle").

One thought is to have the butterfly use its new host (sounds parasitic, eh?) to roam around a room. I could mount a simple proximity sensor and have it head toward any object it detects until it hits it (and then it veers off to another direction). This would meant to model a butterfly flitting from flower to flower.

Or maybe it should have "moth-like" behavior and use the AVR Butterfly's built in light sensor to head toward light -- no wait, I would need 2 sensors (one left and one right) to do this, but you get the idea.

I don't have any practical plans for this Butterfly/Turtle hybrid, which makes it all the more fun.

Sunday, February 04, 2007

Interfacing hardware needed

It looks like I'll be able to butcher the RS-232 shifter cable that came with the Turtle to adjust line levels between it and the Butterfly. Rather than use the DIN connector, I'll just remove the inline shifter board from the cable and hook it up to the Cargo connector (DB25). (Picture coming soon.)

Now, about that DB25... I am ordering this to provide an easy breakout to standard header pins.
So, I'll be waiting for USPS snail mail to arrive (this week?).

Saturday, February 03, 2007

The Turtle has arrived.

The iRobot Create has arrived. It looks pretty durable and steady. The AVR butterfly will swim in the cargo bay.

The first thing I've noticed that I'll have to deal with is that the Cargo DB-25 connector supplies 5vDC (TTL) for serial communication. The butterfly has an RS-232/TTL level converter on board, so they are currently mismatched.

I'll either need to route around the butterfly RS-232 level converter or bring the Cargo connector up to RS-232 levels (blech). Temporarily, I can use Create's serial cable (which plugs into a side mounted DIN) -- it has a built in level converter.

Monday, January 29, 2007

Butterfly on a Turtle



I just ordered an iRobot Create. I didn't order the command module because I want to use my AVR Butterfly instead. What am I trying to build? I don't know. I'll just figure it out as I go ;-)

Robots, Robots, Robots

I've been gone for a couple of years (not that anyone would have noticed -- wow, blogger still has my stuff). Since this is easier than updating my personal website (despite the fact that I developed a full blown content management system to do that -- see this for an example), hopefully there will be robot stuff appearing here.