2021-09-13

Announcements

  • Lab 2 this Thursday

  • No class Friday *

Class time

RIBS state machine coding style from Figure 3.4.1

image20210913131443 
#include "RIMS.h"

enum LA_States { LA_SMStart, LA_s0, LA_s1 } LA_State;

void TickFct_Latch()
{
  switch(LA_State) {   // Transitions
     case LA_SMStart:  // Initial transition
        LA_State = LA_s0;
        break;

     case LA_s0:
        if (!A0) {
           LA_State = LA_s0;
        }
        else if (A0) {
           LA_State = LA_s1;
        }
        break;

     case LA_s1:
        if (!A0) {
           LA_State = LA_s0;
        }
        else if (A0) {
           LA_State = LA_s1;
        }
        break;

 default:
        LA_State = LA_SMStart;
        break;
  } // Transitions

  switch(LA_State) {   // State actions
     case LA_s0:
        break;

     case LA_s1:
        B0 = A1;
        break;

 default:
        break;
   } // State actions
}

void main() {
   B = 0x00;              // Initialize outputs
   LA_State = LA_SMStart; // Indicates initial call

   while(1) {
      TickFct_Latch();
   }
}

Observations:

All outputs are initialized to some intentional value. This requires thinking about the consequences of pins and configuration set to these values to avoid accidents.

? When does B0 change? Does it change back to something else when exiting state s1?

The states are given symbol(ic value)s instead of integers directly, using an enum . This allows the compiler to help find typos!

OPINION: reaching the default case should be an ERROR — always. Don’t care really means "didn’t check." This will be a hard requirement for code in this course that is not in the zyBook.

The first switch happens before the second switch. So…​ when, exactly, does the outputs change in this system?

image20210913134336 
#include "RIMS.h"

enum CR_States { CR_SMStart, CR_Init, CR_WaitRise, CR_Increment, CR_WaitFall } CR_State;

void TickFct_Carousel()
{
  switch(CR_State) {   // Transitions
     case CR_SMStart:  // Initial transition
        CR_State = CR_Init;
        break;

     case CR_Init:
        CR_State = CR_WaitRise;
        break;

     case CR_WaitRise:
        if (A1) {
           CR_State = CR_Init;
        }
        else if (!A1 && !A0) {
           CR_State = CR_WaitRise;
        }
        else if (!A1 && A0) {
           CR_State = CR_Increment;
        }
        break;

     case CR_Increment:
        CR_State = CR_WaitFall;
        break;

     case CR_WaitFall:
        if (!A0) {
           CR_State = CR_WaitRise;
        }
        else if (A0) {
           CR_State = CR_WaitFall;
        }
        break;

 default:
        CR_State = CR_SMStart;
        break;
  } // Transitions

  switch(CR_State) {   // State actions
     case CR_Init:
        B = 0;
        break;
     case CR_WaitRise:
        break;
     case CR_Increment:
        B = B + 1;
        break;
     case CR_WaitFall:
        break;
 default:
        break;
   } // State actions
}

void main() {
   B = 0x00;              // Initialize outputs
   CR_State = CR_SMStart; // Indicates initial call
   while(1) {
      TickFct_Carousel();
   }
}

Keurig state machine

Determine the operational states. Need a strategy to determine what, exactly, we mean by a state.

Categories of things:

  • Event

    • Button pushed (+released?)

    • Temperature threshold (rising/falling edge)

    • Lid open / closed

    • Pump pressure measurement?

    • Brew cycle finished

    • more events?

References

https://barrgroup.com/embedded-systems/how-to/state-machines-event-driven-systems

vocabulary in the article: