Back on the Blog

Apologies for the lack of posting last week; I had to return to the mother ship which is quite a trek. Still it did give me some time to hook up with some of the engineers at ARM and chat about my ideas. One of the most entertaining inputs I received was regarding real world usage.

Faced with a tool that looks like an electric toothbrush with a sensor on the end instead of a brush, which can measure temperature or humidity or light levels, what are school children going to do with it behind the teacher's back?
Answer: Stick it up their left nostril and compare the temperature with their right nostril.

The picture that formed in my mind of children in the emergency room with LogSticks stuck in different orifices, accompanied by angry parents on cell phones to their legal counsel, was somewhat daunting. Still, if you invented the bicycle today you'd have a hard time getting it to market due to all the "dangers" that it posed to riders and pedestrians. And on that note, I will conveniently segue into the next posting...

Simulator Test

Having looked through the examples and the website, the creators of the RealView Microcontroller Development Kit seem to put great store in the integrated simulator. From what I can see, you are pretty much encouraged to develop and debug as much of your application on the simulator before committing it to real hardware. This is a little scary to me. I grew up in an embedded world, where simulators where untrustworthy; where Forth ruled because it ran on real hardware and that's where you started out -- porting Forth to the real hardware.

Leery though I have been of simulators, I thought I would give it a go and see if I could break it. A good way of doing this is to stick in a binary of a real application that you know runs on real hardware and see what happens. Sometimes the simulator makes assumptions about the world around it -- access to symbol tables, knowledge of the source code etc. Giving it a pure binary makes those kinds of "simulators" choke.

So, as you might expect, I gave the simulator in the RealView Microcontroller Development Kit a complete real-time, multi-tasking, interactive, target development environment binary to boot -- Forth! Something that I knew ran on Philips LPC Microcontrollers standalone, from my old friends at Microprocessor Engineering (MPE). (Cue shameless plug for my previous employers)
http://www.mpeforth.com/arena.htm

This initially was problematic. "Aha!," I thought. "Gotcha." I couldn't invoke the debugger without a project written using the IDE. I then created a null project with no code in it and this, too, didn't work. Things were looking black. Still, people don't always use project managers; some people use makefiles and some people just end up with code as binary, hex or the like -- there had to be a way...

I looked under help in the IDE and found "Internet Support Knowledgebase." This took me to the online knowledgebase on the web: Entering: "Loading Hex" did it! The fourth item, entitled uVISION DEBUGGER: DOWNLOADING HEX FILES," was what I wanted. As I suspected, creating a null project was the right idea. I just had to tell the debugger not to try and load the (non-existent) code at startup.

So that's what I did: once in the debugger, I used the command line (Hooray! Every debugger should have one) to load an Intel hex file of Forth built standalone for the LPC family of microcontrollers into the simulator and then pressed go. Hey Presto! Up came MPE Forth. What was more impressive was when I pressed the button in the IDE representing the LPC's reset pin, up came Forth again and again. I then tried to write a hello world word such as
: Hi ." Hello World" ;

This compiled "ok" but when I tried to execute Hi, the simulator complained telling me I was trying to execute code in a data space. Not surprising but pleasing since the simulator certainly knows where code and data should be on the LCP2148 if it's written in C. It was easy enough to get the debugger to set the RAM memory map of 0x40000000 ... to be executable as well as writable and readable; after that Forth just ran fine.

So I am now beginning to believe in the simulator, now on to some code which I can run on it...

Tune in shortly for some C code running on the simulator :-)

The Look of the LogStick

Over the weekend I spent some time considering what the LogStick would look like. By its name, it should be stick-like and I chose that concept because children do a lot with sticks. Not least of which, they poke at stuff with them to see what happens. That is exactly what I want children to do with LogStick. The dimensions will be dictated by a combination of practicalities -- how small can I make it with decent battery life and how big should it be to make it easy to handle by children?

It seems to me that the shape and interface of an electric toothbrush are the right way to go. After all, electric toothbrushes live in pretty hostile environments: our bathrooms. They get dropped, they get submersed, they get dirty but still they do the job (and since they don't have any crevices they are easy to clean). I also like the idea of the pulsing LEDs beneath the skin and the simple one-button interface.



I'll need to work out what the user feedback should be in terms of LED and/or audio. I note that even my toothbrush can beep at me, despite being a sealed unit.