Hi Tobias, in my opinnion, a direct representation of a TOS app using FSM is very difficult to be achieved due the "explosion of states", especially in an event-driven/time-based environment. I will comment below about my own experience with TOS and FSMs. Although the use of such representation takes time of your development, I really appreciatte a very formal approach in programming aiming an "almost bug free" application, with an easy maintanance.
My approach is the use of high-level FSM with "virtual states", where each virtual state actually is a state of the system but with a list of requirements to be verified by the software engineer/programmer. The main idea is based on the concept of VFSM ( http://en.wikipedia.org/wiki/Virtual_finite_state_machine), although with some modifications. For instance, one of my TOS applications has more than 3000 lines, but less than 20 virtual states. Actually, the number of well-defined states is more than 100, but with the virtual states, the complexity of the representation is very reduced. However, this approach has a "cost": you need to implement a very smart watch-dog procedure that must verify all the requirements and conditions to "certify" that the mote is in a recognized virtual state, allowing the respective procedure. If, for some reason, the mote has a set of variable's states that is not defined in any virtual state, the watch-dog procedure will do nothing (wait more time for a stable system) or will "reset" the mote to a well-defined state, normally the initial state after the start() procedure. In my TOS apps, the reception of messages, timeouts of timers, hardware.ready events, etc. are very simple procedures that 1) do nothing (in function of the actual virtual state) or 2) change the values of variables and save some values in global buffers. On the other hand, the procedures related to each virtual state (monitored and "certified" by the general watch-dog) have the "core" actions which eventually make calls to tasks and execute functions. To save energy and to favor the sleeping-mode in TOS, I usually dynamically change the value of the cyclical timeout of the "watch-dog" procedure. If this timeout value is very small, the TOS app is basically executing a loop without allowing the mote to sleep and the battery will not last very long. Finally, the lines connecting the virtual states are usually related to some important aspect of the application, like the RF reception of a specific message MSGx. However, in my FSM representation with virtual states, a single aspect/criteria usually never triggers a state changing. A perfect implementation would also require a check of all global variables. In this sense, the reception of the message MSGx AND a specif set of values for global variables will finally trigger the virtual state changing. I am now developing a TOS application with the concept of "transaction" similar to databases. Again, I am using the mentioned FSM representation with success. Regards, Agnelo Rocha da Silva University of Nebraska-Lincoln. procedureTo apply this conca very well-defined state in the application 2009/8/18 <[email protected]> > Hello again, > > I have some questions concerning Statemachines in TinyOS: > > I built a method for headercompression in TinyOS, which seems to work > OK. Since it's a two stage method that uses timeouts etc. I built a > FSM to do all the "control-stuff". > > Now that I've begun trying it with CTP I get into trouble... For > example removing a printf can screw the whole thing up. My guess is, > that that's due to errors in the statemachine or to an "unsafe" > implementation. > > Therefore I have the following questions: > -Can I implement a statemachine using just some state-variable and > switch-statements? Or do i need to use some module provided by TinyOS? > > -Do I need to read/write to that variable with atomics? What happens > if I don't? I always thougt TinyOS would return to the position in the > code where it was at when it received an interrupt. > > -Does anyone have a link to a tutorial on building statemachines? I > need to fix this asap (better yet: yesterday). > > Thank you in advance for your suggestions, > > Tobias > > > _______________________________________________ > Tinyos-help mailing list > [email protected] > https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help >
_______________________________________________ Tinyos-help mailing list [email protected] https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
