Saturday, July 01, 2006

LogStick new ui

Time to consider the software design of the LogStick and start writing some code. I have been considering where to start, and a good place seems to be the user interface! In the classic MVC paradigm the Model will be the logging, upload and download software, the Audio and LEDs will be the View and the Controller will be the one-button user interface. Well, actually the Controller would be a state machine whose state could be changed by the button and other things, such as being USB docked, timing out etc.

The fun bit with developing embedded software is that it is (for me at least) an oscillation between top-down and bottom-up design. Top-down, the highest level of this design is probably going to be a state machine. My first stab at the state machine from a button perspective is listed at the end of this posting.

Looking at it now in the cold light of posting, this seems rather broken to me since it doesn't cater for false starts in the field, for example. I will have a go at rewriting this shortly in a more readable syntax for those who aren't Smalltalk hackers and try to cater for a more real world scenario. Meanwhile: Bottom-up, I need a button to control the state changes in a state machine, so I'll try that next. 

logStick button isPressed
ifTrue:[logStick docked
        ifTrue:[logStick upLoading
                ifFalse:[logStick empty. logStick setTime]]
        ifFalse[logStick recorder isRecording
                ifTrue:[logStick button isPressed
                        ifTrue:[logStick recorder stop]]
                        ifFalse:[logStick recorder begin]].

posted by Rod @ 7:46 PM   2 comments

2 Comments:

At 1:32 AM, Anonymous Anonymous said...

Statemachines and handwriting C code. Why don't you use Rhapsody in C by I-Logix? And yes, you can program your ARM with the tools you are using, fully integrated! But let Rhapsody generate your C code.
See http://www.willert.de/page/en

 
At 9:32 PM, Blogger Rod said...

Dear Anonymous -- You raise a good question here. I think using a UML design tool to create the software for what is effectively a hidden protocol of states and transitions caused by external stimuli (timers and other software resources considered as such) could be a good solution for a problem of this nature.

Prior to this kind of CASE tool (way back in the 80s) I was working with a customer with a rack of modems and rack controller (all 6809). He wanted a readable, executable notation that would define the modem protocols and the rack's behavior. I took a look at some of the research used for natural language processing and found that Augmented Transition Networks (ATNs) offered a good route to support protocol definitions where you could implement actions on the transition arcs as well as calls to sub-networks during transition. I published the notation at euroFORML '88 here http://dec.bournemouth.ac.uk/forth/euro/ef88.html .

Winding forward... last year I went to the Embedded Systems Show in Boston and spent some time looking at the I-Logix tool and Rational Rose. They both are most impressive. I also bumped into Jean Labrosse at the show and he mentioned Miro Samek's book which I am currently trawling through with great interest.

As far the LogStick is concerned, perhaps I need a simple state machine, perhaps I need an Quantum Programming Framework, perhaps I need a UML CASE tool. My mind is open; there is much to be considered.

 

Post a Comment

<< Home