PIC Programming : Finite State Machines are awesome!

Discussion in 'Off-Topic' started by Robin Mitchell, Mar 25, 2016.

  1. Robin Mitchell

    Thread Starter Well-Known Member

    Oct 25, 2009
    734
    200
    Hi everyone,

    What I would like to know from you lot is what you think about finite state machines and if you have ever used them :). Here is my mini story of the day:

    So I am still working on the ZBM and decided that a boot loader was needed (sick to death of pulling out 28 pin DIP chips and shoving em back in).

    The boot loader uses a PIC18F45K22 that reads from an I2C device and then transfers the data into memory (WIP). But when I tried to get the I2C Module to work it just never did, complete fail. I have used I2C a fair number of times and only once ever got an on-board peripheral to actually work.

    So instead of sitting there spending once again hours of time trying to debug and track code I decided to bit bang. I know its bad practice considering the use of the module (which I could not get to work), but I also thought that it would be a good bit of practice to change my style of code from:

    "conditional loops where you sit there and wait for something to happen before you move on "

    To

    "Everything is always running and constantly checking for updates"

    In other words, a finite state machine.

    So today I have a bit bang I2C module working as a finite state machine and my main function literally only consists of this (so far):

    Code (Text):
    1.  
    2. do
    3. {
    4.     i2c_update();
    5.     memory_update();
    6.    
    7.     if(i2c_get_flag() == MACHINEIDLE)
    8.     {
    9.         memory_read(0,1);
    10.     }
    11. }while(1);
    12.  
    The awesome thing about this code is that it is impossible (I hope), that the code gets stuck somewhere. When I say this I mean that if the I2C module gets stuck in a state it will not affect any other running systems. There are no loops or conditional loops and just about everything is in the form of an if statement.

    All the best,
    Robin
     
  2. DickCappels

    Moderator

    Aug 21, 2008
    2,659
    632
    Congratulations on getting the I2C module working.

    Is your last instruction on line 11 a while loop?
     
    Robin Mitchell likes this.
  3. Robin Mitchell

    Thread Starter Well-Known Member

    Oct 25, 2009
    734
    200
    @DickCappels

    The I2C Module is not in use, I am bit banging the SDA and SCL lines.

    The while loop you see is simply the program loop for the PIC. If that was not there then once all the states and services have been executed then the PIC would sit there idle. With that exception of the loop there are NO loops or do whiles or wait until something has happened.

    All the best,
    Robin
     
    Last edited: Mar 25, 2016
    DickCappels likes this.
  4. DickCappels

    Moderator

    Aug 21, 2008
    2,659
    632
    Thank you for clearing that up.
     
  5. Papabravo

    Expert

    Feb 24, 2006
    10,152
    1,794
    There is a subtle difference between do{}while(condition); and while(condition){}.
    In the first case the body of the loop is executed at least one time before the condition is checked. In the second case the body of the loop will not be executed if the condition is false.
     
    Last edited: Mar 26, 2016
    DickCappels and Robin Mitchell like this.
  6. Robin Mitchell

    Thread Starter Well-Known Member

    Oct 25, 2009
    734
    200
    I use the do while mainly out of habit. When I started learning C about 6 to 8 years ago I must have come across an example with that instead of just while{}.
     
  7. JohnInTX

    Moderator

    Jun 26, 2012
    2,347
    1,029
    Not sure about I2C modules in later chips but the basic I2C slave left much to be desired. There were issues with the S/P flags (data was buffered but not the flags,etc.). I indeed used a FSM to work the I2C and decode messages after much fussing with the flags. I use FSMs for pretty much everything anyway. If you need some help getting the SSP slave working maybe I can help.

    Back when I did a lot of 8085/Z80 stuff, we used a firmware monitor/debugger that among other things, managed the download of Intel hex into RAM for execution. The monitor also provided debug functions such as single step, register inspection and change, code modification (in hex) and a breakpoint capability that allowed you to poke a RST instruction into the code to trigger the breakpoint. We also used external hardware to be able to set up hardware breakpoints by decoding the address on the bus and comparing it to one set on thumbwheel switches. Later, we used a ROM emulator that had breakpoints built in. At any rate, a firmware monitor/boot loader would come in handy especially if you are contemplating adding a disk.

    If any of this tickles your fancy, I can root around to see if I can find some source for the basic monitor - it would be 8085 assembler but would give you a starting point for a Z80. Shoot me a PM if you are interested.
     
    Robin Mitchell likes this.
  8. Robin Mitchell

    Thread Starter Well-Known Member

    Oct 25, 2009
    734
    200
    @JohnInTX

    Hmm, tickles my fancy it does!
    I would love to see what you have lying around.

    Regards,
    Robin
     
Loading...