Menu
Categories
Social Media
Content Tags
Recent Tutorials
Effectively, your code will consist of a giant loop that never ends, going round and round, each time doing what you need to do for that state. This is good because your code is never sat waiting for things. In the case of firmware for micro-controllers, you're going to need to scan the hardware for changes of input state that could trigger a state transition (for example, you may be reading switches and de-bouncing the inputs to make sure the user has really pressed the button). In the case of a game, you can use this time for rendering, reading the controls or performing the calculations for your latest and greatest physics simulation.
So let's consider a relatively simple example, the card vendor. The following pseudo code represents a few simple states:-
Code: [View]
WHILE (1=1) DO
READ AND DE-BOUNCE INPUTS
CASE CURRENTSTATE OF
.....
STATE_WAITING : BEGIN
IF (VEND SIGNAL SET) THEN
NEXTSTATE:=STATE_BEGIN_VEND
END IF
END
STATE_BEGIN_VEND : BEGIN
START MOTOR IN VEND STATE
START JAM TIMER
SET LED PROGRAM TO PROG_VENDING
NEXTSTATE:=STATE_WAITING_FOR_CARD_ENTRY
END
STATE_WAITING_FOR_CARD_ENTRY : BEGIN
IF JAM TIMER EXPIRED THEN
STOP MOTOR
SET LED PROGRAM TO PROG_FEED_JAM
NEXTSTATE:=STATE_JAMMED_UNRECOVERABLE
ELSE
IF (CARD IN FEED SIGNAL SET) THEN
STOP JAM TIMER
START JAM TIMER
NEXTSTATE:=STATE_WAITING_FOR_CARD_EXIT
END IF
END IF
END
.....
END CASE
IF (NEXTSTATE<>0) THEN
CURRENTSTATE:=NEXTSTATE
NEXTSTATE:=0
END IF
END WHILE
vBulletin Message