Copious Free Time

True Modular computing

2012-01-23T21:19:00.003-05:00

I want to tie together my past 3 posts.
In Multi-computers vs multitasking vs interrupts I stated a problem (concurrent processing within the embedded realm) and teased you with a solution (GreenArray's GA144).

In Costs of a multiple mcu system I backed a bit away from the GA144 and wondered if a bunch of small, efficient and cheap MCUs could solve the problem.

In Building devices instead of platforms I offered a rationale to my pondered approaches.

So, here I sit composing an interrupt for an 8051 to service a GSM modem's UART (essentially to buffer all the incoming data). And... everything has just gotten complicated. I've been here before. I am no stranger to such code and the approach I am taking is text book. This is how code starts to get hairy and unpredictable.

But, really now... maybe I *should* consider breaking my tasks down into hardware modules (with each module consisting of dedicated software). If I dedicated an 8051 (tight loop, no interrupts) to just talking to the modem, collecting responses and sending just the relevant information to another 8051 (perhaps through I2C or SPI), then I build that module once, debug it once and be done with it.

This is modular design, isn't it?

So (during design) every time I find a need for an interrupt, I just fork another processor?

(This would work with a single GreenArray's GA144 as well as $3 Silabs 8051 MCUs)

Building devices instead of platforms

2012-01-23T09:08:00.000-05:00

The title of this posting is a concept that flies in opposition to conventional wisdom. Everything seems to be a platform these days. When you buy a gadget or appliance you are not buying a device, you are investing in a platform. Refrigerators are appearing with Android embedded. We are looking at a future of doing "software updates" to our appliances!

Of course, there is big talk about the "Internet of Things", and that could be grand (my washing machine could one day query my fridge about the tomato sauce stain it encountered on my shirt and then place an order on Amazon for the correct stain treatment product).

But, the consider the "elephant in the room": these devices will suffer from that dreaded of all software plagues: "ship now; fix later in an update".

This doesn't tend to happen when you talk about your appliances and devices containing "firmware" (in the original sense). My washing machine has embedded microprocessors but there is no evident way to upgrade the firmware. Hence, the engineers have got to get it right before it ships. The software is apparently sophistica Of course, this is not always the case, but the "get it right" mindset is there. You don't want to tell people they have to call a service technician and "upgrade" their washing machine when it locks up.

For all the smarts my washing machine has, it is still a "device" (not a platform).

This rant bleeds into the common "old fogy" rant that a cell phone should be (just) a phone. I don't think we need to start limiting the potential of our devices, but there are some that should just "work".
We are losing that when we start designing a device and our first step is to choose an OS.

Costs of a multiple mcu system (back of envelope)

2012-01-20T23:21:00.000-05:00

If physical size isn't an issue (you don't want the tiniest of footprints) and unit cost isn't measured in cents, have you considered a multi-mcu system? If your system is highly interrupt driven (receiving lots of I/O from more than 1 place), then you'll need either an OS or at least some solid state based design to handle the concurrency.

If I can get 3 Silabs 8051 variants for between $12-$15, I would need just around 6 caps and resistors to get it up and running. So, total MCU costs would be $15 max. These old 8-bit workhorses are self contained systems. They rarely need an external crystal, often come with built in regulators, and are meant to have a low passive component count. You can just "drop" them in with just a few millimeters of board space.

What does this get me? Potentially less complexity for the software. Consider assigning your MCUs as thus: Each I/O subsystem gets its own MCU for processing. You can design, code and test each subsystem separately. With a means of message passing (SPI, shared memory/flash, etc) you now have an integrated system.

This is hardware based functionality factoring. The industry already does this. If you have bought a GPS module, a cellular modem or even an (micro)SD card you have bought an MCU+X (where X is the functionality). Peripherals often come with their own embedded MCUs (with custom firmware) . However, we expect those peripherals to be (relatively) flawless.

Software, on the other hand, is under constant revision, bug fixes and improvements.

Consider this: If you buy a memory hardware module that has built in support for FAT filesystems (maybe accessed via a UART or SPI), then you expect that hardware module to work perfectly. It is a $5 piece of hardware that should work out of the box. There is no notion of "field" upgrades.

However, if you have bought (or downloaded) a FAT filesystem as a software library, you'll see a few revisions/improvements with a release cycle. It doesn't have to work perfectly. You are expected to upgrade occasionally.

Hardware is getting cheap enough that (for small unit counts) we should seriously consider multiple MCU systems.

Curiously, GreenArrays has side stepped this issue and simple incorporated a bunch of small MCUs into one package.

Multi-computers (GA144) vs multitasking (ARM) vs interrupts (8051/MSP430)

2012-01-20T20:51:00.002-05:00

You've got a system to design. It is a multi-sensor network that ties to a small, efficient battery run base station. The sensor nodes are straightforward. You start thinking about the base station:

I've got a barrage of data coming at me over the air at 433Mhz. I have a simple 2 byte buffer on the SPI connected transceiver so I don't have a lot of time to waste on the MCU. I must be there to receive the bytes as they arrive.
Once I've received the data, it must be parsed into a message, validated, logged (to persistent storage) and perhaps correlated with other data to determine if an action must be taken. An action can also be timer based (scheduled). Oh, and I must eventually acknowledge the message receipt or else the sender will keep sending the same data.
Additionally (and unfortunately), the action I need to perform may involve dialing a GSM modem and sending a text message. This can take some time. Meanwhile, data is flowing in. What if a scheduled event must take place and I'm in the middle or processing a new message?

Now, this is the sort of thing that you would throw a nice hefty ARM at with a decent OS (maybe linux) to do multitasking and work queue management. But, let's think a second... Most of what I've just described works out to a nice simple flow diagram: Receive data -> parse data into message -> reject duplicate messages -> log message -> correlate message with previous "events" -> determine if we need to send a text message -> send text messages at specific times -> start over.

Each task is pretty straight forward. The work is not CPU bound. You really don't need a beefy ARM to do each task. What we want the ARM to do is to coordinate a bunch of concurrent tasks. Well that will require a preemptive OS. And then we start down that road... time to boot, link in a bunch of generic libraries, think about using something a little more high level than C, etc. We now have a fairly complex system.

And, oh... did I mention that this must all run nicely on a rechargeable battery for weeks? And, yank the battery at any time -- the system must recover and pick up where it left off. So, just having a bunch of preemptive tasks communicating via OS queues isn't quite enough. We will probably need to persistent all queued communication. But I am getting distracted here. The big system eats a little bit too much power...

Okay, so we get a bit smaller. Maybe a nice ARM Cortex-M3 or M0. Okay, the memory size is reduced and its a bit slower than a classic ARM. A preemptive OS starts to seem a bit weight-y.

So, how about a nice MSP430 (a big fat one with lots of RAM and program space). Now start to think about how to do all of that without a preemptive OS (yes, I know you can run a preemptive time-sliced OS on the MSP430, but that is a learning curve and besides you are constraining your space even further). Do you go with a cooperative OS? Well, now you have to start thinking about a states... how do you partition the tasks into explicit steps? At this point you start thinking about rolling your own event loop.

So, then there are the interrupts:

Oh, I forgot about that. The SPI between the MSP430 and transceiver. The UART to the GSM modem. And the flash. Don't forget the persistent storage. And check pointing, the system needs to start where we left off if the battery runs out.

Okay, you are getting desperate. You start thinking:

What if I had one MCU (MSP430, C8051, whatever) dedicated to the transceiver and one dedicated to the GSM modem. The code starts to get simpler. They'll communicate via the persistent storage.... But, who handles the persistent storage? Can the transceiver MCU handle that too?

This is where thoughts of multi-computers come in. Not multi-cores (we are not CPU bound!), but multi-computers. What if I had enough computers that I could dedicate each fully to a task? What if I didn't have to deal with interrupts? What would these computers do?

- Computer A handles the transceiver
- Computer B handles logging (persistent storage interface, indexing, etc)
- Computer C handles the GSM modem (AT commands, etc)
- Computer D handles parsing and validating the messages
- Computer E handles "scheduling" (time based) events
- Computer F handles check pointing the system (for system reboot recovery)
etc etc etc

This is where I start really, really thinking that I've found a use for my GA144 board: Performing and coordinating lots of really simple tasks.

It becomes GA144 vs ARM/Cortex + Linux.

Now if I can only figure out how to do SPI in arrayForth...

arrayForth notes Part 1

2011-11-20T11:44:00.001-05:00

I haven't had a lot of time to work on my EVB001 eval board. The time between sessions can go weeks and I tend to forget a lot of stuff. These are notes to myself... sort of dead simple exercises to use as restart points. So...

Here is an example of just attaching to a node and getting it to do some computation. What you type into arrayForth is displayed in Courier font.

First, you need to make sure a-com is set to the attached COM port.
a-com (this should display the com port number)

If the com port is incorrect, you must change it. Do this:
def a-com (enter into the editor)

Navigate to the value, make the change, type save and exit/re-enter arrayForth.
(Hint: Press ';' to position the cursor just after the number; press 'n' to delete it; use 'u' to insert the new number; press ESC to leave that mode; press SPACE to exit editor and then type save )

Check the value again (a-com).

Now, let's go ahead and hook into node 600:
host load panel (load host code and display the panel)
talk 0 600 hook upd (talk to the chip, wire up to node 600 and update the stack view)

You should now see a bunch of numbers on the stack, starting with line 3.

Now, let's throw a couple of numbers onto the node's stack:
7 lit 2 lit (lit pushes the numbers off of the x86 arrayForth stack and onto the node's stack)

You show now see 7 and 2 as the last two values on the 4th line.
Remember, the stack display is in hex and the values you are entering is in decimal.
(If you wish to enter values in Hex mode, press F1 and precede hex numbers with a zero (0).)

Now, let's add the two numbers:
r+ (the "r" distinguishes the F18 addition word from the x86 "+" word)

You should now see 9 on top of the stack.

Simple.

Now, let's try one more contrived exercise. Let's load some data into the node's RAM:
55 0 r! (take 2 values off of the x86 stack: 55 goes into location 0)

You won't see the changed memory until you type:
?ram

So, at last, we have something working "hands on". The example in the arrayForth user guide is great, but sometimes a good start is to just to be able to interactively talk to the chip.

Another GreenArrays blog

2011-11-20T10:21:00.001-05:00

I've stumbled upon: http://greenarrays.blogspot.com

Oh, and also, look to the right of this entry (under Links) for the permanent home of my arrayForth cheat sheet (just revised today).

GreenArrays arrayForth Keyboard cheat sheet

2011-10-01T18:08:00.000-04:00

I'm having trouble wrapping my head around the arrayForth editor keyboard layout diagram in section 3.1 of the arrayForth user guide, so I am trying to put together a slightly modified version that more tightly associates the keyboard keys (and position) to function. I am also dropping the grouping-via-color since I don't have a color printer at hand. Here is a link to the PDF.

My GreenArrays EVB001 Eval Board Adventure

2011-09-27T19:38:00.002-04:00

Okay, so I broke down and purchased an eval board last week. I got my shipment notice last Friday (which included a nice personal note from Greg Bailey mentioning that he saw my last blog post -- thanks Greg) and the board arrived Monday.

Now, to answer my own question (from that post): What to do with 144 cores? I guess I'm going to have to figure that one out...

I've got a big learning curve ahead of me, and although I'm not the type to post daily updates on "learning experiences", I'll probably post now and then how it is going. If I get an overwhelming burst of energy, then I may even fork my EVB001 adventures to a new blog dedicated to just that.

Anyway, what are my current plans?

Learn enough arrayForth (ColorForth) to be dangerous.
Work my way around the board (nodes and I/O).
Begin world dominating project.

Regarding #1, I have followed ColorForth for years, but I never really used it. That being said, I am using Charley Shattuck's MyForth on my day job (shhh.. don't tell them) and that is different enough from ANS Forths that the arrayForth "culture-shock" is low.

Working around the board (#2) is critical as I have to figure out what my peripheral hook up options are. I figure that I would try and get the board talking to an accelerometer (or other sensor). This would be a good goal.

Now, world domination (#3) is a bit vague.

Now, here is what I am thinking.... My usual approach of building tiny/simple things that can be replicated (low volume production runs) won't work here. I simply can't afford to dedicate a $450 eval board to a single task. Then again, I hate the idea of just using it as a "prototyping" board for various ideas. I need a more singular goal.

So, I am viewing the eval board as a "platform". But, a platform for what?

When someone (for passion) designs and builds their own car, plane or boat, they are creating something unique. They are not making something with the end goal of mass production. They are building a "system" that satisfies their own needs. Now, if that "system" later results in replication due to demand, then that is great. But, it is all about building something unique -- something unlike the other guy's car, plane or boat.

You may see where I am getting... the usual place: Robotics.

But, here I use the word "Robot" in loose terms. I am thinking about building a platform to support the integration of sensors and actuators. I want to load up the EVB001 with as many sensors as possible and have it collect, correlate and react through the manipulation of actuators. However, I want to do this within the tightest time constraint possible: I want a tight coupling between sensors and actuators. I want a feedback mechanism. I want... my flocking Goslings (or at least one of them at this point).

Integrating lots of sensors with a single fast running ARM is certainly possible. But this would be interrupt hell (or polling hell or linux process/thread management hell). This is why I (and other sensible people) incorporate tiny 8051s, AVRs and MSP430s into dumb sensors -- to make them independently smarter. Unfortunately, when you have a bunch of microcontroller enhanced sensors (and actuators) you have a communication nightmare. And you need a separate master CPU to integrate all of the "smart" data and manipulate the actuators.

None of this is new. None of this is rocket science. However, the robot I design would be my bot. It would be unique.

More deep thoughts later... For now, I just need to figure out how to talk to my new toy ;-)

GreenArrays G144 - What to do with 144 cores?

2011-09-19T21:13:00.000-04:00

I've been following the GreenArrays G144 since its inception. Now a kit is available... programmable in colorforth (and eforth). Forth chips aren't new to me. I remember devouring the Novix NC4000 back in the mid-80s (I couldn't afford one...).

So, the kit costs $450. I don't really have that kind of money to drop on a dev kit, but... if I did manage to scrape up the cash, what would I do with 144 computing cores?

Seriously, that is a good question for deep thinking. From an embedded computing perspective, what could one do with 144 computing cores?

If I can come up with some good ideas, this kit may be on my birthday wishlist.... ;-)

Smart Things

2011-09-09T15:30:00.000-04:00

I want to design Smart Things.

Smart Things are small devices that do specific things to augment our own intelligence and abilities.

A Smart Thing communicates with the outside world (and other external Smart Things) via protocols like NFC, Bluetooth or TCP/IP.

Co-located Smart Things may use SPI, I2C, UART or even bit banging GPIO.

A Smart Thing is never too smart, although it should require very little human intervention. It should be just smart enough to justify its own existence (as a gadget or parasitic module).

A Smart Thing is usually energy efficient. It should run off of a battery or a host's power.

Some examples of a Smart Things:

A UV monitor that samples sunlight, calculates UV Index and can be queried through by an NFC Reader (like the Google Nexus S phone).
A motion detector that sends alerts through Bluetooth or Wi-Fi.
A light detector that keeps a log of when a room light has been turned on and for how long. It too could be queried through NFC.
Sensor modules for gardens. The Smart Things could measure soil moisture and temperature. They could pass the information on through Ant or Zigbee to another Smart Thing that collects and correlates the data (for collection via smart phone).

A Smart Thing should not be too expensive: The more, the merrier.

A Smart Thing should last for at least 10 years (with at most 1 battery change per year) -- it should be embedded and "forgotten".

A really small Smart Thing could be built around a low power 8051 running MyForth or maybe an MSP430 running uForth/fil. The point here being: You don't care what the platform is. It just needs to work... and be smart.

Tethered Forths

2011-09-08T08:18:00.000-04:00

In my last post I talk about writing my new language fil in uForth via 3 stage metacompilation.
I want to note here that there is an alternate approach I am considering: Tethering.

I don't need to metacompile fil in order to get it running on a small MCU. If I retain the C code that does interpreting/compiling (bootstrap.exe) and write a new stripped down VM that doesn't understand interpreting/compiling (fil.exe), I only have to port the stripped down VM to the MCU. I would do all of my development/compiling on the PC (with bootstrap.exe -- renamed pc-fil.exe). The resulting byte code image (from compilation) would be moved to the MCU and run by the ported fil.exe.

This approach is a subset of what uForth already does. However, uForth also allows for the C based interpreter/compiler to run on the MCU. This is a bit weighty, but essentially gives me the ability to interactively develop directly on the MCU (interacting through a serial interface).

A better approach is tethering, and fil will prefer this approach even if I do re-implement the interpreter/compiler in uForth. In tethering, you do your development on the PC (using fil.exe/bootstrap.exe) and craft a MCU VM that listens on a serial port for special "commands". These commands can be as simple as "store byte-code" and "execute byte-code". You maintain a mirror of the dictionary between the PC and MCU. All the MCU VM needs to do (from an interaction perspective) is write PC compiled byte-code to its dictionary and to be able to execute it. No interpreter is needed.

This is the brilliant method used by various Forths including MyForth, and Riscy Pygness.

If I run into too many walls doing my 3 stages, I may take a break and just go tethered. I do have MCU CFT projects I want to get done!

My new language: fil (Forth Inspired Language)

2011-09-08T07:56:00.000-04:00

My last Forth was uForth. I wrote it to run on PCs (Linux, Cygwin, etc) and MCUs (TI MSP430 and any other Harvard architecture). The implementation was a subset of ANSI and most of the Forth words were coded in Forth. The interpreter, compiler and VM were coded in C.

Since then, I've become (re)fascinated by more minimalistic Forths like ColorForth and MyForth. uForth isn't a good playground for minimalistic experimentation, so I am writing a new Forth inspired language to be called fil.

Like uForth, fil will work on small MCUs as well as big PCs. It will work on Harvard based memory architectures (separate flash/ROM and RAM address spaces) as well as the more familiar linear address space. It will have a 16 bit instruction space (limited currently to a 64KB dictionary -- quite large in Forth terrms) and a 32 bit stack/variable cell size. Using a 32 bit instruction space will force a trade off of code bloat (double the size of code) or speed/complexity (right now I used a switch based code interpreter that assumes each token is 16 bits). In the future I may silently upgrade to a 32 bit dictionary. This shouldn't require a rewrite ;-)

But, where do I start? Well, uForth is a good place. I figured I would bootstrap fil off of uForth. In an ideal world (and ideal implementation of Forth), I would metacompile fil straight from uForth. Unfortunately, there are some limitations/assumptions in the uForth C-based core. So, instead, I am taking a hybrid approach of modifying the core (C) code and the uForth (Forth) code. In essence, I am rewriting uForth to support metacompiling my new language (fil).

Metacompiling is not new. It is a time honored Forth technique of building Forth from Forth. However, while traditional metacompilers target machine code, I am targeting a strip down version of uForth's VM (bytecode interpreter).

My approach is has three stages:

1. I implement as much of uForth in Forth so that I can remove any underlying "C" assumptions and basically simplify the VM. What I'll have left is a uForth/fil with the interpreter/compiler/VM written in C. Let's call that C based executable "bootstrap.exe".

2. I rewrite the interpreter/compiler in uForth/fil.

3. I submit the uForth/fil (Forth) source code to itself (the new interpreter/compiler) and produce a new byte code image. I can then strip the interpreter/compiler out of the C code and produce a simple C VM that doesn't know squat about interpreting or compiling. This new VM executable (fil.exe) and byte code image will be fil. I no longer use "bootstrap.exe".

After this, I can port the new VM to various MCUs.

I have already finished Stage 1, but I reserve the option to spiral back in order to remove further C assumptions that prevent progress on Stage 2. I am also not being very careful to retain full uForth backward compatibility. At the end of Stage 1 I already have a "hybrid" fi/uForth language.

Once fil is complete, I will probably revisit the 16 bit dictionary and consider extending it to 32 bit. If I do this, I don't want to break the idea of fil running on small (8/16 bit) MCUs efficiently. I may consider a bank switched approach instead (multiple 16 bit dictionaries). Don't forget: You can pack a lot of code into a 16 bit Forth!

Software defined... Radio, GPS, ... etc?

2011-08-29T08:14:00.000-04:00

Most comms modules (e.g. Bluetooth, GPS, etc), memory peripherals (e.g. SD cards, USB sticks, etc) and other sophisticated "chips" have embedded processor cores. These cores may be based on stock 8051 or specialized ARM designs. They are smart devices that save system designers a lot of integration time by being "drop ins" (i.e. you talk with them via simple protocols over UART, I2C or SPI) and they do all of the hard work.

Recently, reading about Software-defined Radios (replacing hardware based tuning/filtering with software) and this article (dumber GPS modules where satellite correlation/fusion is done by back end computers), makes me wonder if the future will present dumber peripherals in trade for more processing on our main CPUs.

How many processor cores are there in an average smart phone? You've got the primary CPU running the OS, but have you considered what is powering your Bluetooth, Wi-fi, GPS, cellular modem, display and touch interface? Having sophisticated software in these peripheral chips certainly aids time to market (less programming for the integrator). But, I rely on the craftiness of the chip designer to meet my needs.

Sure, its all software (even when on individual hardware modules), but rarely are these things upgradeable. They have a limited product life (even if the analog part of it is still relevant). This is good for hardware companies, but not good for us (the end user/consumer).

I remember playing with early MEM accelerometer chips. They usually just output a voltage for an axis. There were no "interrupts" or SPI or I2C protocols. They were analog devices. It was up to me to figure out what they were spitting out and deal appropriately.

Now I use smart digital accelerometers that notify me when an event (e.g. tilt, acceleration exceeding a threshold, free fall, tap, etc) occurs. Sometimes they can be frustrating if they don't quite provide what I need -- lots of register based tuning usually takes care of this, but still...

Imagine a smart phone where all of the processing was done on the main CPU. Sure, that would bog it down significantly, but imagine a much faster (and power efficient) main CPU (maybe even with 4 or 5 cores). Now, your GPS/Bluetooth/Cellular-modem are just analog transceivers that streams bits or analog signals. Your smartphone would just have a bunch of antennas, transceivers and sensor hardware. All of the software resides somewhere on the main CPU. Imagine having access to that software.

UV Index monitor prototype #1

2011-08-03T08:02:00.000-04:00

I don't know if I mentioned it here before, but I've been working on a personal UV (Index) monitor.
Folks who have skin cancer (or those at high risk) need to make sure they limit their sun exposure.

The general approach is to just lather up with sunscreen every time you leave the house, but this is impractical (plus you have to re-apply every couple of hours). This becomes more of an annoyance when you consider spending hours riding in a car: Are the windows UV protected? How well? Do you have to lather up every time you drive?

You can get UV index forecasts on your smartphone, but these are just forecasts (for your area and for the whole day). When you are out in the sun, you'll need to know how much UV intensity is hitting you "right now".

Another solution is to carry a UV monitor.

The only ones I've seen on the market are overkill (too large and complex) or vague (how does this work and is it reliable -- where is the sensor?) .
I am aiming at something so small that you'll always carry it with you, but also clear and as accurate as possible. My target form factor is a key fob:

My target UI is based on colored LEDs. There are official colors for the UV index scale and I have an LED for each level. I would like to have (at most) 2 buttons -- one for "instant read" (point at the sun and an LED will light up for 2 seconds indicating UV index level) and one for setting a countdown timer (for sunscreen re-application).

My current prototype has 1 button, 5 high-intensity LEDs (green, yellow, orange, red and blue/violet) and is a little bulkier than a key fob. Amazingly, the LEDs are quite readable in bright sunlight! If you are colorblind you can always read index based on which LED lights up (right?). The current layout ramps "upwards" depending on UV intensity.

It takes a single coin cell battery and is based on a very low power 8051 from SiLabs. It should get 3-5 years off the battery with casual usage.

I need to do lots of tuning/calibration and I know it won't be "demo worthy" for the rest of this summer, but I am making progress. Apparently, the calculations done for UV Index forecasting aren't very practical for small single UV sensors. Somehow, the personal UV monitors make due though. I think I'll use one of the better ones to aid in my calibration.

Maybe I'll have case design and a formal board spin ready for next summer?

Tiny computers that fit on your fingernail...

2011-07-15T07:44:00.000-04:00

Here is a thought:

Pick up a microSD card. Place it on a fingernail. Look at how small it is. How much does it hold? 1GB? 2GB? 8GB? More? Amazing. That is a lot of storage. These things are examples of how storage keeps shrinking while maintaining incredible capacity. You could fit a whole library on a microSD, right?

But consider this: Inside all microSD cards lie an MCU core . (It may be an 8051. The 8051 MCU is still a popular flash memory controller that you'll find in a majority of your USB thumb drives, SD and even (as a naked die) microSD cards.) Each MCU contains some small amount of RAM too.

So, on your fingernail you have an 8 or 16 bit computer (typically running > 50Mhz) with high speed I/O, RAM, gigabytes of persistent storage, and firmware that was probably written in C.

Mind blown.

Android: Bluetooth Low Energy vs USB

2011-06-09T09:08:00.000-04:00

With all the hype about adding devices/peripherals to Android via USB, I desperately want a low energy wireless means of adding devices. A number of my (yet-to-be-started) CFT projects involve collecting sensor data for correlation/display on smart phones. ANT has always looked appealing, but with next to nothing in way of smartphone support, the new Bluetooth 4.0 BLE support looks like it may capture the market.

This year promises new Android devices with BLE. On the peripheral/sensor front, we seem to have 2 major vendor choices: Nordic and TI.

I'm not ready to drop money on a kit just yet, but my "body worn" sensor projects may get a kickstart knowing that a suitable means of data display is coming soon.

Ultrasonic goslings: Sensors and software

2011-05-01T12:21:00.001-04:00

I'm starting to get back into low level embedded systems. I'm back to see what 8-bits can do in a 64-bit world.

Part of this reboot is to cast a fresh eye towards some of the sensor enhanced systems I've been mulling around for the past couple of years.

In particular, I am re-investigating some ultrasonic tracking stuff. In a nutshell, I want to to build a flock of robots (does 3 constitute a flock?) that will follow me around. Think: Mother goose and goslings.

Imagine that you have an ultrasonic transmitter, attached to your belt, that transmits a short "beep" every second. If your robots have 3 ultrasonic sensors each, then they can use hyperbolic positioning (Multilateration) to figure out where you are. (The time difference between the 3 received beeps gives you direction; the receive time between each transmitted beep gives you distance).

Now, every decent circuit I've seen for ultrasonic transducers tend to be fairly complex to build (mostly for clean amplification and rectification of the received signal). Just throwing a transducer onto a (relatively) clean MCU with a sensitive ADC won't cut it. Or can it?

We tend to want to put the cleanest, most linear signal into the ADC, but nature doesn't work that way. Nature uses a ton of error correction (software). Even without perfectly working ears or eyes, the brain adapts to form a "picture".

Given a noisy, weak, poorly rectified signal from an ultrasonic receiver, can software make sense of it?

Forth for ARM Cortex M3...

2011-04-11T11:23:00.000-04:00

This news makes me happy :-)
I should break out my old STM eval boards and give it a try.

The last Forth (ignoring mine) that I've used was Charlie Shattuck's MyForth. Well it looks like he has created a new MyForth for the Arduino crowd. Slide here and sources here.

The nice thing about minimalism within the microcontroller world is that your end result is a "device". You don't have a lot of extra stuff (software standards, etc) to deal with.... so as long as your device interfaces correctly with outside world, the question is: Does it do something useful/interesting? Not: Did you use CouchDB, MongoDB or SQL?

Ah, the simple life.

Also, a shout out to GreenArrays for releasing initial measurements in their G144A12 spec sheet.

Ugh. I really need to find the time (and money) to play with the dev kit.

/todd

File under "Elegant": Factorial in Plan 9 rc (under Linux)

2011-04-10T16:54:00.000-04:00

I've posted before that I find Plan 9's rc shell elegant. I've been using a "slightly" modified (I've made read and echo builtins) version for a few months now and have been doing extensive scripting. I hope never to go back to bash.

Here is a small script to compute factorials. Since "bc" deals with arbitrary precision, we can go much higher than the 32 or 64 bits.

Chew on this:

#!/usr/local/plan9/bin/rc
fn fac {
num=0 factorial=1 frombc=$2 tobc=$3 {
for (num in `{seq $1}) {
echo $factorial '*' $num >$tobc
factorial=`{read <$frombc}
}
echo $factorial
}
}
fn fixlinebreaks {
awk -F '\\' '{printf("%s",$1)}
$0 !~ /\\$/ {printf("\n"); fflush("");}'
}
fac $1 <>{bc | fixlinebreaks}

There are several interesting things here:

Concurrent processing (co-processes actually).
Messaging through unix pipes.
Lazy computation (generator).

The last line launches bc as a coprocessing service (filtering output through fixlinebreaks which is needed due to a "feature" of bc where it breaks up long numbers into multiple lines -- blech). We treat bc as a service and send it requests (steps in the factorial computation) and it responds with our intermediate results.

This factorial algorithm is iterative rather than recursive, but rather than using an incrementing counter loop, we generate all numbers using the 'seq' program and loop through that lazily generated list!

How slow do you think this script will run? Well on my Toshiba Portege r705 notebook with a Core i3, factorial of 1024 takes 2.4 seconds. Is that slow?

Earlier I said that I had enhanced rc with "echo" and "read" as builtins (normally they are external). Using the non-builtin "echo" and "read" increases the run time to 5.1 seconds.

Of course this isn't production code, but here is the take-away: "bc" gives you a bignum calculator for free. Use it.

Tackling the Simple Problems: The domain of the minimalist

2011-03-14T20:23:00.000-04:00

The hard problems are more interesting by nature and the world is full of hard problems. This blog post isn't about them. Instead, I want to talk about simple problems.

Simple problems are still problems, they just don't have world shaking impact (or so you would think).

To be honest: most simple problems are only simple on the surface. Underneath, complexity is always lurking.

Take, for instance, my desire to (re)build a very simple blogging system (for my own personal use). Blog software isn't all that hard to build. If you don't care about performance and scalability, then it is pretty straightforward. That is, until you get down to building one. As soon as you start thinking about security, feeds, multimedia, etc. you start to expose the underlying complexity of "working" software.

Now, as I said earlier, this is still something of a simple problem. Developing blogger software isn't rocket science. But, in some ways, that makes it harder.

When something is so simple (conceptually), it can be quite difficult to "get it right". Getting it right is about hitting that sweet spot. Blogging software needs to do its simple job correctly and intuitively. If it is hard to install, or has "hard to grok" idiosyncrasies, then it doesn't solve the "simple problem" of blogging.

Consider another "simple problem". I have around 40GB of music (mostly in MP3 format) that I want to play on my living room stereo (away from a computer). There are solutions I can buy, but none quite fit. I don't need streaming (although I would like to listen to online radio sometimes) and I don't need a "total entertainment solution". I tend to listen to whole albums, not mixes or "randomized" selections based on genre.

All I need is a single MP3 storage device, the ability to add/delete queued albums from any of my household PCs (web browser NOT a hard requirement), and a simple "remote" (pause, play, next song, previous song). What I want is a music "server" and it only has to serve one sound system. (Wi-fi streaming of music is broken in my house -- too much sporadic interference).

There are server based (free!) software solutions out there, but they usually solve (only) 90% of my "simple problem". They then throw UPnP, webservers, GUIs and all sorts of networking into the mix. This is more than I want (after all I am a minimalist).

Note: Before computers, my problem was solved 100% by a CD player w/ 200+ CDs and before that it was solved by vinyl LPs. Now I have a bunch of MP3s and less capability to enjoy music than when I had CDs.

Simple problems are harder than you think.

uForth Dump...and run

2011-03-14T20:21:00.000-04:00

uForth has been mentioned here several times last year. It was my attempt at a very, very portable Forth (no dynamic memory allocation, ANSI C, bytecode generator for portable images, etc). It has been run successfully on MSP430s as well as Windows/Linux. No MSP430 code here unfortunately. I did most of the MSP430 code as part of my day job in 2010. It isn't mine to give away.

However, you can get a dump of the generic ANSI code here. I haven't touched it in months and it needs documentation (and some general lovin'). Unfortunately, I don't have access to MSP430s anymore and so that is left as an exercise for the reader :-(

Notes on Mail header (and MIME) parsers...

2011-03-07T21:14:00.000-05:00

I'm trying to resurrect my old gawk based blogging system BLOGnBOX. It (ab)uses gawk to do everything from POP3 mail retrieval (you email your blog entry...) to FTP based posting of the blog (it is a static html blog).

I intend on cleaning it up by doing away from the gawk abuses. I am either going to make it (Plan 9) rc based (with Plan 9 awk and some C for the networking) or perhaps Haskell. That is quite a choice, eh?

I've done a bit of Haskell over the past few months and feel strong enough to do the next generation BLOGnBOX, but the main problem is actually getting the thing going. (This is a nighttime CFT and, well, I have to get into a Haskell frame of thinking).

The first task up is a parser for mime encoded email. I plan on using regular expressions (yes, I know -- use Parsec or something more Haskell-ish). Awk is somewhat of a natural for this, but Gawk has a little more "oomph". I can visualize how I would do it in Awk, but the Haskell is not coming naturally.

Well, it isn't all that difficult to get started in Haskell:

module MailParser where
import Text.Regex
import qualified Data.Map as Map
type Header = Map.Map String [String]
header_regex = mkRegex "^(From|To|Subject)[ ]*:[ ]*(.+)"
parseHeader :: String -> Header -> Header
parseHeader s h = case matchRegex header_regex s
of Nothing -> h
Just (k:v) -> Map.insert k v h

Well, that is a beginning. Of course, I should be using ByteStrings for efficiency... and, yes... I know... I know... I should be using Parsec

/todd

Rc - Making shell scripting suck less

2011-02-24T17:26:00.000-05:00

There are some tremendous ideas behind the ubiquitous Unix shell (um, that would be Bourne, bash, (d)ash or maybe ksh?). The problem is that a lot of these ideas are very, very dated. Bash is probably the best example of how to keep a Unix bourne dialect alive. Ksh was beastly (tons of features), but I think bash has finally passed it. But is this a good thing?

As I start writing more complex scripts I begin to feel the age of Bourne. I have been using (d)ash (due to it being the Busybox shell and much smaller than bash -- GNU seem to be set on add the kitchen sink to every tool.) You can pretty much do general purpose scripting with Bash, but still with the legacy syntax of Bourne. You might as well go with Perl or Python (and their associated huge installation footprints).

Then there is rc (the Plan 9 shell). It starts with Bourne and "fixes" things rather than tack on stuff around the edges. It is very minimalistic and has a certain elegance I haven't seen since Awk. Plan 9's toolbox minimalism was an attempt to get back to the origins of Unix (lots of small single purpose tools). The famous anti-example of this is probably GNU ls. Look at the options, the many, many options.

Rc isn't actively supported much (Plan 9 has since faded -- if it ever shone brightly to begin with), but it has the feel of something well thought out.

You'll hear more from me about that in upcoming posts.
Time to shut up and code.

Exceptions and Errors in embedded systems

2011-02-21T08:13:00.001-05:00

These past few posts have been ramblings to myself at the cusp of starting a new CFT (Copious Free Time) project. I am weighing an "elegant" path (Haskell) vs a "Old Unix hacker" path (Shell scripts).

While the Haskell approach is alluring, there is a lot of learning to do there and I am an "Old Unix hacker". I am very familiar with the benefits of functional programming and have found the past 3 months doing Haskell (some on my day job) a lot of fun.

But, I know I can get more accomplished sooner if I take a "Unix hacker" approach.

Now, for the meat of this post (and an often arguing point against using shell scripts in critical environments): Safety.

Or, more specifically, what about all of the points of unchecked failure in a shell script?
Doesn't this betray the notion of an embedded system?

Well, there is the dangerous situation of uncaught typos, but let's say we are real careful. How do we handle problems like:
1. A process in the pipeline dies unexpectedly.
2. The filesystem becomes 100% full.

Interestingly, while something like "dd if=$1 | transform | gzip >$2" looks like it can be full of the above problems, I could argue that you have this problem using any programming language/approach.

However, because it is so difficult to catch "exceptional" errors in the shell, it starts to make me wonder how I would handle this in a language that supports "exceptions".

This is where things start to unravel (for me). What do you do in that exception? How do you recover?
Let's look at some approaches:

1. Unix approach: Wrap the "dd" line in a script and have a monitor start it, capture and log stderr and restart it if necessary (but not too aggressively -- maybe at some point give up and shutdown the system).
2. Erlang approach: Interestingly similar to above.
3. Language w/ exceptions: Catch the error, close the files and.... um, restart?

In the Unix approach, the cleanup is mostly done for you. Good fault tolerance practice (as suggested by Erlang) is pretty much handled by variants of init (I believe that daemontool's supervisor has been doing this well for years).

I am sure there are holes in my argument, but for my CFT, I am persisting all important data on disk (an event queue is central to my system). Every change (addition, execution, removal) of an event is an atomic disk transaction. If any process dies, it can be relaunched and pick up where it left off.

For fault tolerant (embedded) systems I am not sure what I would do in an "exception" handler... outside of clean up and die.

/todd

Haskell scripting for robust embedded systems...

2011-02-21T07:36:00.002-05:00

A convincing (unrelated) counter view to my prior posts here: Practical Haskell: scripting with types.

Unix Shell scripting for robust embedded systems

2011-02-20T15:57:00.000-05:00

The summary/ramification of my previous post:

Shell scripting (in this case Busybox) is a viable approach to developing robust, long running embedded systems.

If you can afford to run a (multi-tasking, memory managed) Linux kernel in your embedded system and Busybox is there, then the shell (ash in this case) becomes a potential basis for a system architecture.

Of course, this is not breaking news. But I think it gets lost when we start taking a " single programming language" view of system development (as advocated by almost every modern programming language). If you are trying hard to figure out how to get your favorite programming language to do what the shell does, then maybe it isn't the right tool for the job.

Sure, the "shell" isn't elegant and is full of pitfalls and gotchas when you use it beyond a couple of lines, but when your shell script starts to grow, you too should consider looking elsewhere for help (i.e. commands beyond what is built into the shell).

An example: Don't get caught up in gawk/bash's ability to read from TCP sockets, leverage netcat (nc).

/todd

Haskell vs Busybox (for an embedded soft-realtime control system)

2011-02-20T15:45:00.000-05:00

I'm building an embedded soft-real-time control system. It will handle sensor events and provide feedback to the user using voice synthesis.

I really want to use Haskell for this CFT project, but I can get something running so much quicker by shell scripting. There won't be a lot of sophisticated algorithms and I don't see scalability as a concern.

When it comes down to it, I am find it harder and harder to do system programming in a "programming language" vs something in a shell (with support from awk and friends). It doesn't matter if it is C or Haskell, it starts to feel like (once again) re-inventing a wheel.

As an example (and it has nothing to do with this current CFT project), consider this problem: I want to transform 1024 byte chunks of a file and write the results as a compressed file. The transformation doesn't matter, but let's say the transformation is written in C (or Haskell for that matter) and takes 50-100 ms per 1024 byte chunk.

I want to do this task as fast as possible. I have (at least) 2 CPU cores to work with. Let's look at two approaches:

Approach A: Write a Haskell/C program to read 1024 bytes at a time, perform the translation, then the compression and write the 1024 bytes to an output file.

Okay, so I need to link in a decent gzip compression library and I use an appropriate "opt" parser to grab the input and output file. Done.

Approach B: dd if=$1 bs=1024 | translator | gzip > $2

This assumes that I write the same core "translator" code as above, so we can ignore that and focus on reading, compression and writing.

You can guess which will take shorter to implement, but which is the more efficient?

Well, my wild guess would be Approach B. Why? Well I already have a couple of things going for me. One is that I have automatic concurrency! While "dd" is just sitting there reading the disk, translator is running and gzip is also doing its thing. If I have 3 cores, then I have a good chance that each process can run in parallel (for at least a little while before they block). There is some cost in the piping, but that is something that linux/unix is optimized to perform. Given that, "dd" has a good chance of causing more efficient file input buffering than my single threaded app in Approach A. The dd process has disk buffering + pipe buffering working for it so it may fetch (and dispatch) several 1024 byte chunks before it blocks on a full pipe. A similar (but reverse) caching is happening with gzip too.

So, you then consider rewriting Approach A but using a concurrency module/library. Ugh. Let's not go there.

So, if I take a scripting approach, my "controlling" part of the system can be written using the Shell and I can optimize to Haskell (or C) as needed.

The Wisdom of Unix shell scripting for systems

2011-02-20T15:12:00.000-05:00

Prototype with Perl, Ruby, Python, Tcl, etc and to optimize you have to dive into using an FFI (foreign function interface).

Prototype with a Unix/Linux shell (bash, ash, ksh, etc) and to optimize you rewrite proc/commands in your favorite (compiled?) language and use stdin/stdout as the interface.

When piping makes sense (or concurrent processes with lightweight I/O requirements), 30+ years of shell wisdom is your friend.

If shell scripts can be trusted to boot your Unix/Linux distribution, can the shell be trusted as the controller/glue for your application?

/todd

Haskell Revelation -- Optimizing via refactoring

2011-02-07T16:25:00.000-05:00

I have some code that lazily transforms a fairly large list of data (from an IO source) that must be search sequentially. Since it is lazy, the list isn't fully transformed until the first search. Since, I presume, a rather large stack of thunks are constructed instead, this first search takes a really, really long time. (It would be faster, I surmised, to strictly transform the list as it was being built, rather than lazily upon the first search).

I started playing with `seq` but couldn't quite get the strictness right -- the code represented some of my first attempts at Haskell. So, I decided to refactor the code (replace naive tail recursion with maps, filters, folds, etc). I figured at this point I would be able to see more clearly how to avoid the lazy list.

Surprisingly, this refactoring was enough for the compiler to "do the right thing" and sped my application up significantly. What was the compiling doing here? Did it remove the laziness? Or did it just optimize the hell out of what I thought was a lazy vs strict problem?

/todd

How low can Haskell go? (Or what should I do with Haskell?)

2011-01-24T21:10:00.001-05:00

Is Haskell a suitable language for programming robots? Would a robot with a strictly functional brain be safer? I have run a fairly hairy 2K line Haskell app on a target as small as an Atom based netbook. It ran reasonably.

I suppose, for a linux target, that a Haskell executable is pretty much like any other executable.

What is the benefit to taking a purely functional approach to robotics?

For some pioneers (think Greenblatt, Stallman, etc) Lisp was a "systems programming" language. Is Haskell a reasonable successor?

These are questions I am pondering. I am doing some Haskell (here an there -- prototyping stuff at work, etc), but I keep wondering what the killer application would be *for me*.

Important techniques for (future) multi-core embedded development

2010-12-05T23:09:00.000-05:00

These three approaches intrigue me: Staapl, Lava and MyForth. They don't address "multi-core embedded processors ", but I think their "meta system" approach will be integral in making it easier to developer for embedded multi-core controllers.

The Lonely Programmer (Hacker)

2010-11-23T21:37:00.000-05:00

I've been noticing books on the market (and some blogs too) that speak of our newly emerging "Maker" culture -- a culture where people fed up with intangible abstract work (do you sit in a cubicle pushing numbers?) are turning to the gratification of hands on creation. They say that working on physical things can give you a deep sense of accomplishment that nurtures our primordial tool building minds.

I put forth that some programmers can get this feeling from the intangible and abstract. I grew up working with my hands (art, electronics, and just generally building stuff). Programming became an extension of that. It my mind, my code held the same sense of accomplishment and gratification as building something with my hands. I became enamored with virtual worlds!

Nowadays, however, I find that a lot off programmers spend significant time worrying about languages, syntax, test coverage and code re-use. These are topics of varying importance, but they are just about honing your skills. At some point you have to produce something. Hopefully it is beautiful (not just on the outside but inside too). How you managed to create it (the language, test approach, etc) is secondary to the thing itself. And, oh, if it is malleable and can be adapted to do new exciting things, is that proof enough you used good coding techniques?

We spend so much time talking about the tools, we forget that it is the result that matters. We forget about the joy and awe of working code. We instead tend to form language advocacy groups, cult-like methodologies and obsess over software licensing.

Really, if someone were to create a fully aware artificial being capable of not only passing the Turing test but able to engage us in deep conversation, would we (the programmers) nitpick over how poorly the code is structured, the lack of test coverage and how terrible it is that it was implemented in a crappy programing language?

MP3 ID3v1 tag reading in Perl and in Haskell

2010-11-11T15:50:00.001-05:00

I am building an MP3 jukebox for my home...

I know that I am supposed to use ID3v2, but my MP3 collection (CD ripped, Amazon and Emusic) still sports ID3v1 tags, so I thought it would be a safe bet to just parse it.

I quickly wrote an ID3v1 tag parser in Perl (yes, I know CPAN has several solutions for this but I wanted to write my own just for the fun). Here is what it looks like:

use strict;
use warnings;
use Fcntl qw(:seek);

my @genre = (
'Blues','Classic Rock','Country','Dance',
'Disco','Funk','Grunge','Hip-Hop',
'Jazz','Metal','New Ag(e','Oldies',
'Other','Pop','R&B','Rap',
'Reggae','Rock','Techno','Industrial',
'Alternative','Ska','Death Metal','Pranks',
'Soundtrack','Euro-Techno','Ambient','Trip-Hop',
'Vocal','Jazz+Funk','Fusion','Trance',
'Classical','Instrumental','Acid','House',
'Game','Sound Clip','Gospel','Noise',
'AlternRock','Bass','Soul','Punk',
'Space','Meditative','Instrumental Pop','Instrumental Rock',
'Ethnic','Gothic','Darkwave','Techno-Industrial',
'Electronic','Pop-Folk','Eurodance','Dream',
'Southern Rock','Cult','Gangsta','Top 40',
'Christian Rap','Pop/Funk','Jungle','Native American',
'Cabaret','New Wave','Psychadelic','Rave',
'Showtunes','Trailer','Lo-Fi','Tribal',
'Acid Punk','Acid Jazz','Polka','Retro',
'Musical','Rock &','Hard Rock','Folk',
'Folk-Rock','National Folk','Swing','Fast Fusion',
'Bebob','Latin','Revival','Celtic',
'Bluegrass','Avantgarde','Gothic Rock','Progressive Rock',
'Psychedelic Rock','Symphonic Rock','Slow Rock','Big Band',
'Chorus','Easy Listening','Acoustic','Humour',
'Speech','Chanson','Opera','Chamber Music',
'Symphony','Booty Brass','Primus','Porn Groove',
'Satire','Slow Jam','Club','Tango',
'Samba','Folklore','Ballad','Power Ballad',
'Rhytmic Soul','Freestyle','Duet','Punk Rock',
'Drum Solo','A Capela','Euro-House','Dance Hall' );

my $id3v1;
my $id3v1_tmpl = "A3 A30 A30 A30 A4 A28 C C C";

while (my $filename = ) {
   chomp $filename;
   open my $fh, '<', $filename or next;
   binmode $fh;
   seek $fh, -128, SEEK_END and read $fh, $id3v1, 128;
   close $fh;
   my (undef,$title,$artist,$album,$year,$comment,undef,$trk,$genr) =
unpack($id3v1_tmpl,$id3v1);
   print "$filename|$title|$artist|$album|$year|$trk|".$genre[$genr]."\n";
}

Basically it takes a stream of MP3 filenames over stdin, opens them and dumps out a pipe delimited summary of what it found. Here is how it is run:

$ find /home/todd/music -name "*.mp3" | perl mp3info.pl >mp3_data.txt

Here is a line from the output (mp3_data.txt):

I am considering using Haskell for my jukebox, so I was curious what this would look like in Haskell. Here is my newbie Haskell implementation:

import Text.Printf

import Data.Array

import Char

import System.Environment

import System.IO

-- Create a array of genres

genres = listArray (0, l-1) genres_l

where

genres_l = [

"Blues", "Classic Rock","Country","Dance",

"Disco","Funk","Grunge","Hip-Hop",

"Jazz","Metal","New Age","Oldies",

"Other","Pop","R&B","Rap",

"Reggae","Rock","Techno","Industrial",

"Alternative","Ska","Death Metal","Pranks",

"Soundtrack","Euro-Techno","Ambient","Trip-Hop",

"Vocal","Jazz+Funk","Fusion","Trance",

"Classical","Instrumental","Acid","House",

"Game","Sound Clip","Gospel","Noise",

"AlternRock","Bass","Soul","Punk",

"Space","Meditative","Instrumental Pop","Instrumental Rock",

"Ethnic","Gothic","Darkwave","Techno-Industrial",

"Electronic","Pop-Folk","Eurodance","Dream",

"Southern Rock","Cult","Gangsta","Top 40",

"Christian Rap","Pop/Funk","Jungle","Native American",

"Cabaret","New Wave","Psychadelic","Rave",

"Showtunes","Trailer","Lo-Fi","Tribal",

"Acid Punk","Acid Jazz","Polka","Retro",

"Musical","Rock &","Hard Rock","Folk",

"Folk-Rock","National Folk","Swing","Fast Fusion",

"Bebob","Latin","Revival","Celtic",

"Bluegrass","Avantgarde","Gothic Rock","Progressive Rock",

"Psychedelic Rock","Symphonic Rock","Slow Rock","Big Band",

"Chorus","Easy Listening","Acoustic","Humour",

"Speech","Chanson","Opera","Chamber Music",

"Symphony","Booty Brass","Primus","Porn Groove",

"Satire","Slow Jam","Club","Tango",

"Samba","Folklore","Ballad","Power Ballad",

"Rhytmic Soul","Freestyle","Duet","Punk Rock",

"Drum Solo","A Capela","Euro-House","Dance Hall" ]

l = length genres_l

main = do

hSetEncoding stdin latin1

hSetEncoding stdout latin1

fname <- getContents -- lazily read list of files from stdin

mapM print_id3v1 (lines fname)

print_id3v1 fname = do

print fname

inh <- openBinaryFile fname ReadMode

hSeek inh SeekFromEnd (-128)

dat <- hGetContents inh

printf "%s|%s|%s|%s|%s|%d|%s\n"

fname

(extract 3 30 dat) -- Title

(extract 33 30 dat) -- Artist

(extract 63 30 dat) -- Album

(extract 93 4 dat) -- Year

(Char.ord (head (extract 126 1 dat))) -- Track

(genres !(Char.ord (head (extract 127 1 dat)))) -- Genre

hClose inh

-- extract and trim a range of elements from list

extract idx ln s =

trim0 (take ln (drop idx s))

-- Trim nulls from list

trim0 s = filter (/= '\0') s

You run it similarly. Frustratingly, it isn't very happy with filenames with non-ASCII characters :-(

$ find /home/todd/music/ -name "*.mp3" -print | ./mp3info >mp3_files.txt

mp3info: /home/todd/Music/music/Ch�ying Drolma & Steve Tibbetts/Selwa/Ch�ying Drolma & Steve Tibbetts_05_Gayatri.mp3: openBinaryFile: does not exist (No such file or directory)

I am not a Haskell expert, but I didn't expect it to choke there...

EDIT: Fixed the filename problem by adding:

hSetEncoding stdin latin1
hSetEncoding stdout latin1

Future runtime environment for Robots

2010-10-19T18:47:00.000-04:00

Embedded systems are getting smaller and more sophisticated. While there are currently bare ARMs and 8/16-bit micros controlling our mainstream robots, this won't do for the more sophisticated (domestic) robots of the near future.

When we consider sophisticated robots (whether ruled by a subsumption architecture or other invariably concurrent system), we won't think of Python, Java, Ruby or Perl. We will be thinking of something more Erlang-like or perhaps Unix-y.

Can you imagine jacking into your robot's debug port, typing "ps" and seeing a collection of inter-communicating processes running on a Linux kernel? Or will it be something like Erlang/OTP? (Erlang is the dark horse here... Unix may never go away as a platform.)

So, how about it? Erlang on a gumstix?

New AFT release!

2010-09-10T21:25:00.000-04:00

AFT development has dormant for about 1 year, so I decided to reboot it with a minor (experimental) release (5.098) that supports Indexing. This is mostly useful for LaTeX output. I'm not sure how useful the HTML output will be.

I've also started to clean up the Perl source for AFT. I am currently reading the new edition of Effective Perl Programming and hope to apply more idiomatic Modern Perl conventions to the 14+ year old AFT sources.

As always, AFT is available through "sudo apt-get install aft" under Ubuntu (and Debian?). But to get this new release, go to the AFT website. (For a quick look at Indexing in action, look at the aft reference manual and scroll to the last page).

I need to start archiving my art...

2010-09-10T10:49:00.000-04:00

This is an airbrush I made 23 years ago:

Miles Davis

I need to scan in all my old artwork and figure out the best place to post them.

I miss Perl...

2010-09-08T09:38:00.003-04:00

I've been going through my old books and came upon a stash of Perl tomes. I had a love/hate relationship with Perl. I wrote AFT in Perl, but have not used it as my language of choice in (almost) a decade.

Stumbling across these books got me wondering: Where have all the Perl hackers gone?

Well, I can't say where they have all gone (Ruby? Python? Retirement?), but I miss the funky vibe that Perl had in it's day. Perl was messy, but the language attracted the most interesting people. I've always seen it to be the language of poets (as opposed to engineers). Perl people loved wordplay. Perl people weren't just interested in producing interesting apps, but also making the app source code look interesting.

Well, Perl isn't gone. Apparently, strides have been made in Perl 6 and Rakudo is available for playing around with a lot of Perl 6 features.

But, will the hackers come?

I am reminded of a quote from Ratatouille (Colette introducing the kitchen staff to Linguine):

"... So you see: We are Artists. Pirates. More than cooks are we."

Scratch, Squeak and so Forth: Robot programming enviroments

2010-08-29T16:59:00.000-04:00

A thought experiment...

If I was going to teach kids how to control a Roomba by way of programming, where would I start?
Outside of Squeak and Scratch, I think the most common answer involves also teaching them how to use a source code editor.

This is unacceptable.

Squeak (as derived from Smalltalk-80) and Scratch (as derived from various Logos) integrates the programming environment with the language. This isn't about just being an "IDE".

Squeak let's you hack in a workspace without concern for files. It is persistent and natural. You write a little, see how it works out and continue. At some point you may save your workspace, but you aren't really thinking about files at this point.

Scratch has a similar (although not as radical) approach. My youngest kids (age 7 & 7) would script for a few hours and then pick some random series of characters as a "name" to save their project into (for later recovery). Eventually, they started using more descriptive words for naming their projects. But at no time did they think about files and file systems.

I think files and editors are distractions (and not necessary ones -- unless you want to get a mainstream programming job).

Forth had this idea decades ago (and so did Smalltalk). Forth had blocks (1K blocks to be specific) that held text and data. The early bare-metal Forths used blocks as the single abstraction from persistent storage devices (disks). Eventually, folks "enhanced" line oriented block editing with a visual screen (with single character cursor movement!).

Forthers in the early 1980s (my self included) were happy.

Now, in 2010, I face the prospect of teaching my oldest kid (age 12 -- expert Scratcher, beginning Python programmer) how to control a Roomba via programming that require the selection and mastery of files (and file systems) -- or at least some kind of file based IDE.

Of the languages I have been looking at, Forth, Python and Lua are the front runners.

I think Forth is a more natural fit. I have just downloaded VIBE and I am being transported back 30 years. I use to write (and extend) Forth editors like this. I am remembering how natural it felt to edit in blocks. (ColorForth continues this tradition, so Chuck Moore arguably never found much of an improvement in using file oriented environments ;-)

Forth has always made me feel "closer to the machine". Plus, with a built-in editor, I am no longer doing the context switch being external editor and Forth. VIBE (or any other Forth Screen Editor) keeps me in Forth.

I will be playing with VIBE under gforth (and perhaps extending it). I am curious to see if this feeling is simply nostalgia or if my 23+ years of Emacs (w/ language editing modes) has been a bad move.

Greenspun's Tenth Rule adapted to Unix

2010-08-24T12:12:00.001-04:00

Greenspun's Tenth Rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.
can be adapted to Unix:
Any sufficiently complicated Perl, Python, Ruby, Lua, etc script contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Unix.

And I don't mean the all of the "system" calls. I mean: concurrency, fault tolerance, data persistence, configuration and scalability.

It may be ugly, but combine ksh93/bash, awk, bc, etc (whatever you find on a standard Unix/Linux distro) and you'll find an analog to the features offered by the above mentioned languages. This does not include "abstractions" such as fancy data structures and other syntactical sugar. And, of course, fork/exec isn't going to beat a function call.

However, (and this will be the subject of the next post), Unix under control of advanced shell (such as ksh93 or bash) can have the following capabilities (at least!):

Coroutines (Co-processes in ksh93 or recent Bash)
Communicating Sequential Processes (CSP) via named pipes and co-processes
Dataflow processing (pipes)
Arbitrary precision math (bc or other calculator)
Reuse (command line apps)
File (database) support (ls, awk, find, grep, sqlite command line, etc)
List processing (command line args + ksh93/bash)
Functions/apps as first class objects

And more...

iRobot Create and Unix Programming

2010-08-21T17:21:00.000-04:00

In my previous post I talked about using Unix as an embedded programming "language" (as opposed to a hosting environment for embedded apps).

I started to think about where to begin. Well, let's consider the iRobot Create platform (Roomba too!).
Between your controller and the iRobot is a serial port and a binary command protocol.
If I wrote a small C app to talk over the serial port and convert to/from binary and text, I can utilize the Unix pipeline for some further down app that reads the robot's binary response as newline delimited text data.
For example:

echo "get sensors" | irobot-oi /dev/ttyS0 | some-later-app

The "irobot-oi" open "/dev/ttyS0", takes text commands as input ("get sensors"), converts it to an iRobot OI binary request, sends it, reads the binary response and converts it to text for "some-later-app". This app could be written in C, awk, perl, etc.

This approach is so obvious that I would be shocked to learn that no one has tried it. I know there are libraries available the iRobot Open Interface (OI) in python and other languages, but is there a Unix command line available?

From a traditionalist Unix position, "irobot-oi" is actually doing too much. You'd have to encode mappings between each binary command/response byte/bit and text. A more minimal approach would be to write an even simpler binary/text converter that simply understands the protocol encapsulation and accepts/emits a comma delimited representation of the binary data. (Since the OI response protocol is directly dependent on request -- there are varying length responses with no terminator -- we have to develop some smarts into the converter.)

So, instead we would have something like this:

echo "142,2,9,13" | irobot-oi-cvt /dev/ttyS0 | some-later-app

The above command requests the state of the left cliff sensor (9) and the virtual wall detector (13) and sends the result (in comma delimited text) to "some-later-app" (which may do the actual english text mapping or simply react to the numbers).

Unix as a Programming Language - Rethink Embedded Scripting (and CSP)

2010-08-21T14:57:00.000-04:00

As I look at eLua (on an mbed for one of my robot projects), my mind wanders... have I stumbled into another monolithic system approach?

eLua embedded systems are Lua and (maybe) some C. I like Lua, but am I just trading one language ( Forth, C, etc) for another?

This line of thinking keeps bringing me back to Unix. Under (traditional) Unix, I have a multi-process environment connected by pipes. I choose the appropriate language (or existing app) for the task at hand and glue it together with a shell.

Now, this would (most likely) be overkill for a small embedded device, especially in regards to power consumption. But, assume for the moment, that I had all of the Unix resources at hand and didn't concern myself with power consumption. What would my robot controller design look like?

I design and build GPS trackers during the day. I use C and (sometimes) Forth. I've thought about eLua, but I'd still have to write a NMEA sentence parser and fencing algorithm in a language not necessarily perfect for parsing. How would I go about doing this if I had awk at my disposal? Or grep/sed? Or... the whole unix environment tied together with pipes under a shell. Would something like BusyBox be a good foundation?

What is the smallest MCU (or embedded SBC) that I could run something like uCLinux and BusyBox on?
Could I do development under a fairly modest laptop Linux and port down to uCLinux and BusyBox?

Right now I am looking (again) at CSP (perhaps built upon Lua co-routines) as a mechanism for architecting embedded systems that integrate multiple (sensor) inputs. You can also build CSP upon Unix processes (and pipes). This is the way I've done it for 25+ years. Do I really need to cast my architecture into another monolith?
This is just me bring up Unix as a Programming Language again (but this time under the constraints of embedded computing)

Resurrecting BLOGnBOX

2010-08-11T08:47:00.001-04:00

I've been thinking about resurrecting my gawk based blogging system BLOGnBOX. I am getting tired of Blogger.

While BLOGnBOX doesn't have as many features, it lets me focus on what I want from a blog. Although this has changed over time, I think what I currently want is:

A way to publish my thoughts and ideas.
An archive of my thoughts and ideas.
A primary means of writing.

I am less concerned with the web aspects of a blogging system. I'd like to have a clean, simple (yet elegantly presented) blog that I can tinker with as needed.

What led me down this path of thought is the desire to extract blog entries (or the whole blog) as a PDF document. By PDF, I really mean LaTeX or TeX quality (not just a dump). AFT does this for me, but it might be overkill for a blogging system. Perhaps the next iteration of BLOGnBOX should leverage LaTeX directly?

And, of course, the next iteration should be composed as a Literate Program! (I'm leaning towards Noweb.)

Humans were not meant to...

2010-08-04T19:05:00.001-04:00

Humans were not meant to sit in cubicles.
Humans were not meant to spend 8 hours a day working on reports and clicking aimlessly on the web to relieve the tedium.
Humans were not meant to be imprisoned by a workforce that wants you to do repetitive tasks mindlessly.

Humans are meant to be adventurous and creative, with bursts of brilliance (whether through exuberant play or hard knuckled persistence).
Children understand this. As adults we unlearn this. We are taught to work hard, conform for the good of society, buy a house, put away money into a 401K and make a stable environment for raising our kids. We are taught to be "wage slaves".

Sadly, most humans will never break free. But that makes it even more important that you become that rare exception (at least for a while). You have a duty to be brilliant, exuberant and adventurous. Laugh hard, fight injustice (aka stupidity), be creative and kind.

Be passionate. Don't be afraid to piss off people. Sometimes people need to be shook up.

Draw, paint, dance, program -- set an example for your kids. Let them know that it isn't their duty to conform, accept the status quo or "work for the weekend". The best thing you can do for your kids is to show them what it means to be free -- to be truly human. Brilliant, volatile and utterly unique. Take chances. (You don't have to quit your job to do this.) Just do something to express your joy, your uniqueness, your value as a human.

F*ck your boss. No, not that person you report to at work. Your real boss: the mental shackles that keeps you "in line". Break those shackles.

Not everyone can do this. But it is your duty to try.

Sometimes, when your boss isn't looking... let go.

Myforth, 8051 and minimalism

2010-08-04T18:32:00.000-04:00

Programming in Myforth has given me a greater appreciation for minimalism. (I suppose programming in ColorForth would be even better, but I don't have access to the proper hardware...)

Using minimalistic (simple) tools forces you to approach a problem differently. I felt some of this back in the 80's when all I had was a little Commodore 64 and some big ideas, but coming back to minimalism from two decades of big iron is refreshing.

I now look at a problem and think "what is the simplest way to solve this?". This takes on a deeper meaning when you consider that the tools force you to find simpler ways. When all you have is 768 bytes of RAM and 8KB of flash, you have to think in simple terms.

Take, for instance, the problem of geofencing. I do GPS trackers (on 16-bit micros) for my day job. I have an MSP430, 16KB of RAM and 256KB of program space (flash). The trackers I build have a concept called geofencing. Here you define polygons or circles that affect how the GPS points are handled. Sometimes you want to log at a different rate based on the fence you are in; sometimes you want to "beacon" (transmit) at a different rate.

Programming a fence algorithm can be tricky (and computationally intensive). In addition, GPS coordinates are represented typically in (at least) scaled 32 bit values (w/ 5 decimal digit precision).

Thirty-two bit math is taxing for an MCU that only supports 8-bit math. What is a lowly 8-bit to do?
Well, if your "problem domain" only needs to deal with fences defined around just a few miles, you can truncate a lot of the math to 16 (or fewer) bits while retaining precision. Once you know that you are "in the ball park", you only need to look at the lower bits. You don't need to consider the whole 32 bits.

This is a good example of how refining the problem domain helps generate a simpler (smaller) solution. Even if I used 16 bit or 32 bit MCUs, this can save me some processing time. (My field is "low power consumption" solutions, so saving processing time equals saving power).

myforth, 8051 and robotics

2010-07-20T19:41:00.000-04:00

Just an update. I am quite taken by Charley Shattuck's myforth (click link and scroll to the bottom of the page). Porting it to an obscure 8051 part (for 24 bit sigma-delta ADC) greatly increased my knowledge of 8051 assembly. Myforth is more of a Forth-based macro-assembler than a Forth dialect. It is both minimalistic and rich.

I got great pleasure out of implementing a moving average over 24 bit ADC samples using just 8-bit operators for the math. It reminds me that I take a lot for granted when I toss about 32 bit integers using C on an MCU.

(I've previously used SwiftX Forthfor 8051 programming, but the part in question had only 768 bytes of RAM -- not quite enough.)

Ideas are dangerous things...

2010-06-06T15:23:00.001-04:00

A movement starts with an idea. A revolution starts with an idea. An invention starts with an idea.
Ideas are volatile things.

...There are thoughts enough
To blow men’s minds and tear great worlds apart

My thoughts were in embedded systems for the past 4 years. Four years ago I left behind large systems development. I went minimal -- 8-bits in fact. Improbable as it seems, I managed to get back into Forth development. I've spent the last 8 months writing Forth code on a 16-bit MCU (MSP430). The project is ending and the product is about to be delivered.

My thoughts now turn to vacation. But, once on vacation, my thoughts will wander back to computers. So, what's next?

I'd like to finish my embedded system CFT projects, but of course, my mind wanders.

My mind is wandering here and here.

A while back, I read (and mentioned) Reaching Escape Velocity (and Gonzo Engineering). Steven Roberts suggests that you find your all consuming project and pursue it.

The problem is, I don't have such a project in mind.
Maybe my true passion isn't making things.

I love ideas. I think I am a programmer (rather than inventor) because I often don't need to build something. Sometimes it is just enough to think it (and most importantly share it). Ideas are like.

So, I am not sure what I am going to do next.

So whatever your hands find to do
You must do with all your heart
There are thoughts enough
To blow men’s minds and tear great worlds apart

There’s a healing touch to find you
On that broad highway somewhere
To lift you high
As music flying
Through the angel’s hair.

Don’t ask what you are not doing
Because your voice cannot command
In time we will move mountains
And it will come through your hands -- John Hiatt, "Through Your Hands"

Posterous... BLoGnBOX

2010-06-04T18:43:00.000-04:00

I stumbled upon Posterous and it sounds a bit like my BLoGnBOX.
Posterous came out in 2008; BLoGnBOX went live in 2006.

BLoGnBOX was never hosted but the concept is the same: Email to Blog posting.

Posterous recently announced Markdown support.
Markdown is very similiar to my own AFT.

WikiReader Data Logger

2010-06-02T15:14:00.002-04:00

A quick hack. Here is a data logger I wrote for the WikiReader that I use at work. It uses my previously discussed WikiReader Serial port hack:

160 constant max-line-chars
variable byte
create line-buf max-line-chars chars allot
variable lbcnt
variable fd
variable linecnt

\ Base logfile
\
: logfile s" log.000" ;

\ Create a new logfile with new 3 digit numeric extension
\ (e.g. log.001)
\
: gen-logfile ( nnn -- caddr u) 0 <# # # # #> logfile + 3 - swap drop 3 cmove logfile ;

\ Does this log file exist or is it available (free)?
\
: logfile-free? ( caddr u -- f) r/o open-file ?dup if drop 1 exit then close-file drop 0 ;

\ Iterate through to a free logfile.
\ We support up to 1000 log files before we fail.
\ (Need a failure handler!)
\
: next-logfile ( -- ) 999 0 do i gen-logfile logfile-free? if unloop exit then loop ;

: wiki-logger ( -- )
   0 lbcnt !
   lcd-cls
   next-logfile
   logfile w/o create-file ?dup if
   cr lcd-." Can't create log: " lcd-. drop exit
   then
   fd !
   lcd-cr
   logfile lcd-type lcd-cr
   lcd-." Ready. Press any button to exit." lcd-cr lcd-cr
   begin
   \ sleep only between lines
   key? 0= lbcnt @ 0= and if wait-for-event then
   key? if
   key dup line-buf lbcnt @ + c! 1 lbcnt +! ( -- c)
   10 = if
   line-buf lbcnt @ 2dup fd @ write-line drop
   lcd-type lcd-cr
   0 lbcnt !
   then
   then
   button? if
   \ A button was pressed so clean up
   \ and exit.
   \
   button-flush
   fd @ close-file
   exit
   then
   ctp-flush \ not interested
   again ;
wiki-logger

WikiReader Serial Port Hack Pictures

2010-05-27T20:15:00.010-04:00

Per a recent request...

Here are some pictures of my small hardware hack.

First, I just added 3 header pin sockets to the already exposed debug port:

But that proved too cumbersome to maintain a good tethered connection to my laptop (plus the batteries would have to be exposed).

So, with the aid of a master machinist (Sandor -- a co-worker), I put a stereo "micro" jack on the top side of the device:

Here is the finished result:

You can see where I (badly) pried open the case ;-)

And here is where I am today:

Now, onto software...

So many CFT projects...

2010-05-19T22:16:00.002-04:00

Hands-off! - Small, mountable, personal alarm system. Attach to a bike, briefcase, computer bag, etc. Arm/Disarm with a key fob. Piercing alarm when someone "moves" your possession. Key fob also has a smaller alarm/buzzer to notify you (up to 10 meters away).
mooTracker - Ultra low power GPS tracker for livestock, pets, etc. Can be used with GSM/SMS module, Iridium modem, etc. Uses an accelerometer to detect motion before engaging GPS trackers. Standby current should be <>
UV Index Clip - Small (discrete) UV Index sensor (1" square max). Uses a button cell battery, SiLabs C8051F930, and ANT for communication to iPod/iPhone/Pocket-device to alert you when you've had enough rays. Can be clipped to clothing or hat.
Crop/Garden moisture monitor. Seed your garden (co-op, winery, etc) with low cost, very low power wireless sensors. They contact a hub (with GSM/SMS capability) to send you status/alerts as text messages. The hub should also support data logging/consolidation for summation or later retrieval.
Portable Power Consumption Data Logger. The key word is "portable" here. This data logger/monitor is designed to be used "in the field" with portable devices (sensors, auto accessories, robots, etc). Mainly for battery powered devices. Should be able to measure power consumption between 0-12volt and between 1uA and 3A.
WikiReader Portable Terminal - Use the WikiReader as a local/personal display and a controller of UART enabled devices. Maybe use Bluetooth to use it to query/control sensors.

So many CFT projects, so little time. Is there a way to tie them together?

Is there a common theme?

If I only built the things that "I" find useful, which would they be?

I could use #4 in my yard and I have friends that would find it useful.

My wife could use #3....

I could see where #1 would be useful, but it generally sounds pretty boring

(from an implementation point of view).

None of these projects are terribly unique. Maybe my approach is

"low cost / low power". I find it challenging to do a lot with a little.

Gonzo Engineering

2010-05-18T19:42:00.002-04:00

This manifesto strikes a chord. I am not as brave (or insane?) as Steven Roberts, but I do find resonance with his writings. I remember briefly encountering Roberts at InterOp Spring 1992 where he had a booth showing off his BEHEMOTH bike.

I just finished his book.

I need to do more about my crazy dreams.

WikiReader, Forth and Hacking

2010-05-16T16:29:00.002-04:00

It's old news, but I find the WikiReader very cool. It is an "offline" pocket size wikipedia reader (searches a mini-SD card of a wikipedia dump). It came out last fall (2009) and it has already been subject to a teardown and random hacks. What finally got me interested is knowing that it runs a cross compiled (almost ANSI) Forth.

I've been doing a lot of low level and high level Forth recently and wanted a "lighweight" hackable device for some mall programming (my 11 yr old son plays Warhammer 4K at a local mall and can be engaged for up to 3 hrs -- ugh, 3 hrs of waiting in a mall). The problem with most of my devices is that they have lots of wires, bare boards and LEDs. I don't need the attention (blinking LED.. somebody call the police!).

So, I got me a WikiReader and I've already opened it up to hack in a connector for a serial port (pictures later).

The toolchain and source code is free (developed under Linux w/ open source tools), so I installed ubuntu (once again: goodbye windows) and was quickly cross compiling new Forth engines!

More later, but some quick mini-stats:

The device works off of 3 AAA batteries and draws 11-13mA (avg) while "idle" (waiting for a touch screen or serial event) and 80-90mA (avg) while searching, handling I/O and doing wikipedia stuff.

Not bad.

/todd

myforth, 8051 and iRobot Create

2010-04-28T09:42:00.004-04:00

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

But which Forth? I have a copy of SwiftX for the 8051, but I decided to look at an interesting environment called MyForth that i found here. This is the, quite detailed, manual.

Its non-standard (I don't really care), influenced by colorforth (yeah!) and completely tied to the 8051.

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

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

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

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

Interesting reading and hacking for the weekend.

eLua and mbed and iRobot Create

2010-04-24T15:34:00.003-04:00

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

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

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

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

So many options, so little time.

eLua and mbed

2010-04-24T14:26:00.003-04:00

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

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

mbed (Cortex-M3) and MPE Forth

2010-04-12T22:46:00.003-04:00

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

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

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

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

SiLabs C8051 and SwiftX Forth

2010-03-13T13:59:00.002-05:00

It's been a while since I've posted... I am very busy these days. :-(

I am currently playing with SiLabs C8051F344 with a purchased copy of Forth Inc's SwiftX (under Windows -- my Linux development effort never fully cooked).

I am impressed with the speed of this "lowly" 8051 derived 8-bitter. It isn't meant to do big things, but for small things it fairly rocks.

I've previously played with the C8051F93x very lower power MCU, but given my current interests (GPS tracking), the difference in power consumption between that very low power part and the more power hungry F344 is minimal. The GPS consumes so much current when running that the MCU is just "noise" in any power chart plots.

When asleep, the difference between consuming 1uA (sleep mode) on the F93xx vs 25-50uA on the F344 (clocking way down to around 40Khz) is not worth considering (we are talking years of battery life for either).

More on my current project later... but for now I am just enjoying crafting Forth on a 8-bit MCU :-)

SwiftX Forth and 8051 and Linux

2010-01-05T21:01:00.002-05:00

Maybe 3 other people in the world would probably be interested in hearing that I have gotten the evaluation copy of SwiftX Forth running under Linux (Wine) talking to Silab's USB Toolstick's C8015F931 daughter card.

I had to steal the daughter card UART and re-route it to a separate USB->UART bridge for SwitfX's XTL (programming still works through the Toolstick), but it all works (so far) under both Windows and Linux (Ubuntu!).

I am playing around with 8051s because I am feeling retro and a bit weary of the TI MSP430 family. The C8015F931 has some impressive low power numbers and some neat features to make even a lowly 8051 appealing.

I have to remember to do a post on my newest interest: Augmenting sensors with tiny low power MCUs to make them smarter.

uForth 0.99 -- almost there....

2009-12-04T23:06:00.001-05:00

A bit fatter, but more capable... Plus there is some initial refactoring of the code. Download the latest here .

case statements in uForth

2009-11-02T21:10:00.003-05:00

case .. of .. endof .. endcase was surprisingly easy to implement:


\ Variable used to keep track of how many 'of' clauses we have.
\
variable _endof

: case ( n -- )
   0 _endof !
   [compile] >r
; immediate

: of ( n -- )
   [compile] r@
   [compile] =
   postpone if
; immediate

: endof ( -- )
   _endof incr
   postpone else
; immediate

: endcase ( -- )
   _endof @ 0 do postpone then loop
   [compile] r>
   [compile] drop
; immediate

And, an example:


: test  ( number -- )
    case
       1 of ." one" endof
       2 of ." two" endof
       3 of ." three" endof
       ." none"
    endcase
;

Hexbug + MSP430 = Robotrophic Parasitism

2009-10-30T20:46:00.004-04:00

It's been almost 2 years since I wrote about my interest in Biotrophic Parasitism in robotics...

In Biotrophic Parasitism, the parasite and host co-exist with (potentially) mutual benefits.

In what I am calling Robotrophic Parasitism, the parasite (in this case a MSP430 based $3 EZ430-T2102), and the host (an original $10 Hexbug) live happily together.

In this case, the parasite was minimally invasive: the EZ430 lives between the battery switch and the Hexbug circuit, controlling the power. It also has a bi-directional line tapped to the antenna sensors so it can detect a "bump" or steer (the original hexbug only turns clockwise).

The parasite seeks light and steers the bug in that direction. When you first apply power, the parasite turns the hexbug clockwise (up to 6 times) looking for any light bearing direction. It then drives the hexbug in that direction. If the light wanes, it will then do another set of clockwise searches looking for a stronger light source.

I've got some fine tuning to do...

The parts list:

1 EZ430-T2102 board.
1 Hexbug.
1 photoresistor and 1 voltage dividing 1/8 watt resistor (from my parts bin).
1 TS5A3127DBVRG4 analog switch (free sample from TI).

Total Cost: ~ $15

This is the first of (hopefully) many Hexbug Robotrophic Parasites!

Unschooling days...

2009-10-28T16:04:00.006-04:00

Wednesday early afternoon...

Claire in her tree.

Annie drawing worms (science).

Nate hacking Python.

uForth 0.96 -- getting closer...

2009-10-27T22:56:00.002-04:00

I've simplified uforth.c in this release. Some words coded in C were moved to core.f and init.f.

This made the C code smaller, so you can now compile uForth with the free IAR MSP430 Kickstart Edition!

Still no DOES> (not sure how to do this without dictionary rewriting which is a no-no in my MSP430 flash approach).

It is nicely shaping up though. I am really enjoying rewriting parts of uforth.c in uForth itself (see core.f and init.f in the distribution).

Downloads are here.

uforth 0.921 -- more pre-release goodness

2009-10-16T16:20:00.003-04:00

Visit uforth for the latest "on your own for now" pre-release. I've included a link to a prebuilt binary for the MSP430 ez430-rf2500 board.

It's more robust and comprehensive. Plus it supports direct word compiles to the MSP430 flash.

It weighs just over 8KB flash + 900 bytes RAM. It support an 8KB (4096 cell) dictionary, so there is plenty of room to play.

The PC/Unix version still works well too. I use it for new dictionary development and create a TI file of the compiled dictionary for the MSP430.

Nothing automated yet and very little documentation. But, hey you can define words, loop and do some "meta" stuff.

uForth 0.7 pre-release

2009-10-07T08:37:00.003-04:00

Last night I finally made some progress with compiling to the MSP430 flash dictionary: I can now compile words on the MSP430!

I also moved the MSP430 development to the more widely available (and cheaper!) ez430RF module (MSP430F2274 based).

Unoptimized, the VM/interpreter is 6.6KB and the RAM footprint is 844 bytes (essentially leaving room for 90 one cell variables on the MSP430F2274). I made the dictionary 4092 words (~8KB) to leave room for C app code. The uForth dictionary is (by architecture) limited to 32KB.

The brave can grab at snapshot (or look at documentation) here. If you have an ez430RF and you want to poke about (you're on your own for now), you can grab this big TI format flash file here. This file contains both the VM/interpreter and a dictionary.

Development Support words for uForth

2009-10-04T20:52:00.008-04:00

Support words shouldn't be in the core. As smaller as it could be to write in C, I am resisting the urge of making the core larger. Take for instance "words". It is very, very useful for debugging but not so useful in a "finished" system. Why should it eat precious RAM or Flash if you don't need it?

Here is a quick definition of words in uForth. You can place it in init.f (for BOOTSTRAP versions) or pass it to "uforth_interpret()". It depends on a few words I've already shipped in init.f:

( Implementation of words in pure uForth! )

create _ ( dummy "known length" entry )

variable last_word

variable ccnt ( keep track of # of characters on a line)

: words ( -- )

_ 6 - @ last_word ! ( We know where the prev word link is inside of _ )

0 ccnt !

last_word @ ( pointer to last word )

begin

dup ( keep it on the stack )

1+ count 63 and dup ccnt +! ( get length of word's name )

ccnt @ 70 > if cr 0 ccnt ! then ( 70 characters per line )

type 32 emit 32 emit ( print word's name )

2 ccnt +! ( add in spaces )

@ ( get prev link from last word )

dup -1 = ( -1 link means no more words! )

until

drop ;

Simulating MSP430 I/O on PC uForth (Solution?)

2009-10-02T07:13:00.002-04:00

One horrible solution (but may work for me) is to simulate the MSP430 I/O under PC uForth.

Keep in mind: uForth is about scripting, not about writing system level Forth stuff on an MCU. It is meant for slinging around C functions and libraries. I don't intend on doing much bit banging in uForth. There will be no UART driver, no interrupt handler, no deep notion of MSP430 power modes. SwiftX Forth (and others?) is the best fit for that.

I want to take existing C app (maybe already running on an MSP430) and manipulate it.

However, some times I may want to toggle some ports. I can do this with a minimal RAM_DICT uForth on the MCU. That may be adequate. This would allow me to hack the MSP430. Maybe I should create a special "hackers" dictionary for the MCU that allows me to bit bang ports and interact with peripherals. (This *should* be a writable dictionary.. try blinking an LED without some sort of DO .. LOOP construct -- this requires compilation!)

If I really do need the ability to do bit banging in the full "scripted application", I should be able to simulate it on the PC uForth. This wouldn't be a full MSP430 simulation, but maybe just enough so that I can compile the word, test it (maybe textual output: "LED bit0/port1 is ON!") and then dump/flash the dictionary.

Just a thought... but, uh it sounds oh so "batchy".

uForth MSP430isms

2009-10-02T06:54:00.002-04:00

I'm trying to figure out how to best do uForth word compilation on the MSP430. Right now, if you want to do that you must use the RAM_DICT option (RAM based dictionary). This is inconvenient at best. A typical MSP430 part will have between 1KB to 8KB of RAM. Your initial dictionary may be larger than that!

Then there is the problem that compilation often involves rewriting memory (resolving BEGIN, DO .. LOOP references, etc). The MSP430 main memory is divided into 512 byte segments. And, each segment must be erased before writing (technically, you can write twice safely without an erase). What if the word definition spans two segments? I would need at least 512 bytes of RAM for buffering. Will I need more?

Another approach is to use a "tethered" development environment. With this, I would attach the PC uForth to the MSP430 uForth, compile the word locally and send the byte codes to the MSP430 to be flashed. This simplifies Flashing since there doesn't need to be a concern for rewriting bytes. However, this means that the PC and MSP430 uForths must be tightly bound.

SwiftX Forth takes a more formal tethered approach, but I like the more standalone nature of uForth right now.

The batch approach I take right now is to develop and test the word on the PC uForth, dump the dictionary and recompile the MSP430 Forth with this dictionary (flash based). The big problem with that can be summarized by the following example -->

: led-on bit0 port1 mem! ;

Ugh. There is no analogue for this on the PC uForth. My only recourse is to use a RAM based MSP430. But, after defining "port1", "mem!", etc. a 1KB RAM MSP430 part won't be big enough to support the dictionary. (And, obviously, using a Flash based MSP430 uForth, I won't be able to define led-on !)

Solution to follow... hopefully...

uForth 0.4 ... more preliminary madness

2009-10-01T21:58:00.003-04:00

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.

uForth preliminary release... very, very alpha

2009-09-30T20:47:00.002-04:00

This probably won't be usable for anyone and it isn't organized well at all. In fact, you could view it as a drunken pseudo-intellectual ramble captured as source code. It may mean something, or it just could be plain useless. For me, personally, it is an achievement.

I am sitting here right now, enjoying a Taylor Fladgate 10 year old Tawny Port, listening to a heady mix of Abdullah Ibrahim, Michael Franti, Dinosaur Jr. and Arcade Fire, considering if I should release this.

Aw, hell. If you want to muck with it, go ahead. Here is the (probably uncompilable) tarball of uForth.

P.S. I actually got it to run on an MSP430 today (via Rowley Crossworks). I can't promise support, nor can I promise a steady stream of releases, although it is geared to become the basis of some stuff at my day job.

u4th - Forth for microcontrollers

2009-09-27T13:31:00.004-04:00

Okay, I got tired of searching and waiting. I decided to roll my own "portable" Forth targeted for microcontrollers with limited resources. I want to do a Forth that would work on MSP430s, ARM Cortex and desktop PCs.

This would be more of a "scripting" Forth vs a full bottom up programming language. It would expect to be embedded in C and able to call C functions (like a scripting language!).

Right now I have something working on both a PC and MSP430 (simulator). u4th is written in C and makes no presumption about I/O (you can extend and add UART support, but it is happy to just work with a dictionary and an init() function). It supports a RAM or ROM/Flash resident dictionary (but no Flash writing support built in). It compiles a position independent dictionary that can be transfered to/from a PC and MCU without modification.

It does not implement ANSI Forth.. it is it's own beast geared for scripting, not system building.

I have a few more things to add (no DO .. LOOP yet) , but right now it runs (interpreter + VM) just under 4KB RAM (with a 2KB RAM resident dictionary -- so if the dictionary is Flash based, we are talking well under 2KB RAM!) and around 7KB of program (flash resident code).

More to follow!

/todd

compose-tex vs AFT

2009-08-26T08:35:00.004-04:00

I've been doing some AFT hacking for a person who needed some text support. There are many AFT alternatives out there these days but he says that AFT hits the spot because it produces LaTeX as well as HTML.

There are some decent LaTeX to HTML converters out there too (have been for years).

I've been thinking about making a simple "free-ish text" converter that produces only LaTeX. It would be a LaTeX helper of sort. It would allow a casual user the ability to produce very high quality print without the learning curve of LaTeX.

The trick is, the "almost free text" format markup would have to be beautiful. The idea is "beautiful plain text in", "beautiful print out".

What if everyone could produce beautiful print? What would you typeset?

Living my values...

2009-07-03T22:47:00.002-04:00

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

Colorforth as inspiration

2009-07-02T21:48:00.003-04:00

I always keep up the best I can with what Chuck Moore (inventor of Forth) is up to. I've always found colorforth to be fascinating.

Mr. Moore has started a couple of blogs. Of particular interest is his recent blog for tracking progress with his latest creation.

This reminds me why playing with hardware is so much fun. I am a bare-metal guy at heart, although there isn't much opportunity for doing this type of work (for me) these days.

How do I make a career out of bare metal progamming? Forth gives me some of this thrill. I like to poke and peek hardware to see it work. Something about batch compiling/loading (C and C++) through an IDE loses that feel.

I don't really want to "roll my own" Forth these days. Language design as a thrill has come and pass.

I got a buzz out of using SwiftX Forth (for the MSP430) at work a while back. Getting an unsupported MSP430 (the MSP430F5XX) working with SwiftX was a blast.

If I can scrape together $395 for a SwiftX MSP430 license (for non-work use), I'd like to kickstart an idea I had for doing a Simpliciti clone in Forth.... but my wife's van needs new tires :-(

More on (embedded) C++

2009-06-15T07:32:00.002-04:00

Interesting paper regarding using C++ for embedded work by Stroustrup. I wonder how much of this is taken to heart by embedded developers.

Evaluating the Cortex-M3

2009-06-11T16:41:00.003-04:00

So, I have 2 evaluation kits: the stm32circle and the stm32-performancestick. Each under $100 and each with interesting features and annoyances. I've spent around $130 between the two.

I suppose it would have made more sense to just get the Olimex header board ( STM32-H103) for $40, a $70-100 JTAG, and GCC, but the point of the evaluation excercise is NOT to spend hours doing the "let's build everything from scratch". When the right integrated environment is chosen it sometimes worth the money. I still (and will continue to) do my source code editing in emacs but I have become pampered by the often richer experience of debugging with a decent IDE.

I would still like to just use emacs + gdb + gcc for development, but while I'm learning the chip I'd rather have an IDE with integrated documentation and GUI hand holding. My days of grunting manly about how I built all my tools by hand and debug via gdb command line is probably over. I will probably never replace my beloved emacs (used mainly out of habit) for editing and browsing code, but the point here is to hit the ground running and focus on the Cortex.

So far... stm32circle and Raisonance is nice, but I have no interest in CircleOS, so I've yet to see what it offers me in turns of raw EABI programming. Raisonance Ride is limiting me to 32KB debugging. I suppose I won't be using a lot of the advanced features of the stm32circle (color LCD, sound, etc) but it is a very rich platform (for only $40).

The smt32-performance sticks comes through Hitex (which is promising me unlimited debugging after I send them email). No response yet. The older license key (I am using the most up to date version of the debugger) doesn't work. They said I should email them a request for a new license. I was able to run their "dashboard" which allows me to do some performance/power tests. This is very informative.

At some point I will choose one or the other to do some development with. I guess I am hoping that the stm32circle will "win". Ride7 looks nice (reminds me of Crossworks). I need to see how well it does without forcing me into CircleOS.

I'll post updates in the next couple of days.

Forth on the Cortex-M3?

2009-06-08T10:24:00.002-04:00

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

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

Hmm...

Stroustrup's new book

2009-06-07T14:08:00.004-04:00

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

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

I purchased the book last week.

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

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

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

IAR, STL and the MSP430

2009-06-05T20:12:00.005-04:00

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

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

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

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

Here is the sample code:

#include <msp430x54x.h>
#include <numeric>
#include <functional>

static volatile int res;

int main( void )
{
  int a[] = { 9, 1, 5, 6, 7, 8};

  // Stop watchdog timer to prevent time out reset
  WDTCTL = WDTPW + WDTHOLD;

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

  return 0;
}

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

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

I am impressed.

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

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

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

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

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

C++ on ARM Cortex-M3?

2009-06-03T22:20:00.003-04:00

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

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

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

Does this buy you anything?

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

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

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

Is Embedded C++ (with templates) inevitable?

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

Biotrophic Parasitic Computing and sensor nets

2009-05-26T07:05:00.005-04:00

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

2009-05-26T06:18:00.003-04:00

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

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

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

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

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

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

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

2009-04-14T22:36:00.002-04:00

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

2009-04-10T08:31:00.001-04:00

"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

2009-04-10T06:34:00.002-04:00

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

2009-03-30T08:04:00.002-04:00

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?

2009-03-30T07:46:00.003-04:00

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:

You develop your ScratchCreate script in Scratch, first controlling an on screen Sprite that represents the iRobot Create.
You then launch the middleware and continue to debug the script but now control an actual Create wirelessly.
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)

2009-03-27T12:20:00.003-04:00

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

2009-03-15T15:51:00.002-04:00

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

2009-03-09T08:53:00.002-04:00

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)

2009-02-05T21:07:00.006-05:00

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

2008-11-29T16:47:00.004-05:00

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

2008-10-23T10:36:00.002-04:00

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

2008-08-12T09:39:00.005-04:00

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:

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.

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

2008-08-12T09:31:00.003-04:00

Here is a good interview with Aho on creating AWK.

High Level Languages for Prototyping

2008-08-06T15:00:00.004-04:00

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:

Supports concurrency (lots of little processes/tasks) seamlessly.
Seamless support for Bignums. I don't want to think about silly limitations of native word sizes.
No fencing in (multi-paradigm support is a must!)
Interactive. I don't want to do a edit/compile/run cycle for simple things.
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!

2008-07-27T15:53:00.002-04:00

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.

2008-07-27T15:46:00.002-04:00

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

2008-04-29T22:42:00.003-04:00

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

2008-04-28T22:29:00.003-04:00

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