At 18:37 25/10/99 -0700, you wrote: >You want to detect "invalid" states in embedded systems, and re-boot (so >to speak), also use the watchdog for if hardware latchup happens, and in >addition put some "fence" values out in RAM (i.e. write 0xA5 to one >location, 0x5A to another, then come back & test these values - if one >changes, reboot.) As the state register's in PIC Ram on PICs, you >cannot do much in the way of "refreshing" it (unless you copy OldState = >CurrentState = {NextStateNumber} at each time you set the upcoming state >for the next "pass", then compare them at the top of the loop, which >would let you know it was time to re-boot!) - though it will change >fairly regularly, usualy, this would catch situations like waiting for >successive keypresses when you had jumped invalidly from some other >state, due to a cosmic ray hit, etc. > >SCR Latchup isn't handled by the WDT, of course, so you try to prevent >that in critical circuits! > >And, for the finnicky: yes, my state machine that I tacked together & >showed was a hybrid, but such hybrids are eminently PRACTICAL, IMO, so >I'm not apologizing > > Mark Grey coding of hardware is not a simple task. The idea of monitoring two points in RAM for a "Kill roy" is not quite such a good idea. If the RAM is corrupted in eitehr these two locations, there is no guarentee implied or otherwise that the rest of the RAM is either OK or BAD. I can remember doing such a search through code like this for a system that reset itself once every few months or so, just to find out that the thig was over writting (Software bug) Now this is normaly NO CAUSE for a reset, WARM boot or process restart. In such the system at a higher level needs to analyse the current data and past activites and then pose the question of what will this make me do in future activites and does this meet critera esstntialy the same as past paths have lead to. After this is done the L.E.D may be turned on What I am trying to say is that simplistic approaches offer simplistic results, and the software engineer must assume a cirtain state of operation at all times. The detection of failure should be the detection of erratic behaviour, not Oh gee, I have a bad value in RAM=> I have to reset as the value may have been written wrong, or the location may be faulty not the system. After all how many of you do defensive coding? No realy how many of you do 7-3, do you check to see that the result is less than 5 and greater than or equal to 0? Dennis > >Richard Prosser wrote: >> >> 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 >> > > >> > > >