This now has triggered a long-time query re these devices. As I understand it the basis of the state machine is a register containing data relating to the "state" of the device or process. This is updated by inputs and used to define the outputs. Now, the question is how often do I need to refresh it? In the ideal situation I would monitor the inputs and only change the state register when required but in the real world there is always the possibility of data corruption whether from cosmic rays, static discharge etc. So, the question is, how reliable is the ram in a PIC (or Atemel, Scenix, etc. etc.)? Once I've recognised an input condition and acted on it - do I need to continually refresh the internal registers or can I leave them alone until something changes. I've always been a bit on the conservative side - checking & updating as often as convienent but at times this does limit other options. If the registers should be refreshed at regular intervals - then what about the program - surely it is also susceptable to the same sort of thing - although possibly to a lesser degree. If the data is totally secure once written, then this is brilliant but somehow I don't really believe it! Does anyone have any figures and experiences as to this question? I realise that the operating environment will be a major factor but even in a benign environment there may be some corruption mechanisms. Thanks, Richard P > -----Original Message----- > From: Dan Larson [mailto:dlarson@CITILINK.COM] > Sent: Tuesday, October 26, 1999 10:28 AM > To: PICLIST@MITVMA.MIT.EDU > Subject: Re: Two topics - State Machines > > > >Software types are likely to > >cheat and cause their code to break by doing things only > when a state is > >entered or exitted. > > AS as "software type", I usually create three states in such > cases: One for the > "entry" state, one for "polling, looping, etc", and one for > the "exit" state. > > I don't know if *this* is cheating or not, but sometimes the > next state to > be transitioned to from the current state depends on the > previous state. > Sort of like subroutine calls within a state machine. I only > use such a > technique in order to avoid duplication of state. Avoiding > duplication > also avoids bugs cause by changes made to one of the any identically > functioning state but not the rest. > > I once wrote a state machine for a "game show" program which had > over 150 states! Mind blowingly complex, but it would have > been almost > impossible with traditional logic structures (if then else). > > State machines rule! > > Dan > > > > >BillW > > >