State Machine in MCU

[cr0sh]

I especially liked the opening paragraph of that article:

"Developers, Software Engineers, and Programmers are logical, rational, reasonable people right? Sure they are…until you disagree with something they believe in. Then they can become the most enflamed, outraged, foaming-at-the-mouth, intolerant, lunatics you've ever had the pleasure of meeting."

Seems that is exactly what happened in this thread. I for one learned something. Arguing with Software Engineers is just like arguing religion. Fortunately, in my working life, I was always in a position where I managed software engineers, and was in a position to fire them.

Mike, throughout this thread, I have never said you should never use goto. Not even K&R said that. As a software developer, though, I have found when to pay attention to certain development patterns; when to use what, and where. In my opinion, goto is a tool that should be used sparingly, and with adequate justification. If the application calls for extremely high processing speed, and goto is the only way to achieve it, then you can argue for the use. I have learned, though, you shouldn't always assume this is the case; instead, you write up benchmarking tools to gain a quantitative analysis of the issue, for all possibilities under examination.

I for one, am not arguing with you; I have felt this discussion overall to be quite informative and educational; for instance, thru this thread I learned of misterT's interesting solution, and 3v0's updates to it; I found that to be a highly interesting solution (it has an OOP feel to it). Even your contributions with the goto statement was an interesting look at a different solution to a problem. I am always interested in learning new things, and I found this thread to be abundant with such opportunities.

At every opportunity in this thread, I have tried my best to be fair, to look at what was presented and weigh the possibilities. I still stand by my original opinion: There are times when you should/need/must use goto; those times should be few and far between. Know when to use the best tool for the job. That's all I've tried to convey.

Finally, I sincerely hope you aren't suggesting that you'd fire a person just because they have a difference of opinion? Its one thing if the project demands something that only goto can provide, and the programmer dogmatically sticks to their guns instead of doing per the specification, without demonstrating via benchmarking or other means their justification. If they can justify it, then you should have adequate justification with similar backup to argue your position. Firing a person otherwise (on this point alone) seems extreme, IMHO.

 

[MikeMl]

...
Finally, I sincerely hope you aren't suggesting that you'd fire a person just because they have a difference of opinion? Its one thing if the project demands something that only goto can provide, and the programmer dogmatically sticks to their guns instead of doing per the specification, without demonstrating via benchmarking or other means their justification. If they can justify it, then you should have adequate justification with similar backup to argue your position. Firing a person otherwise (on this point alone) seems extreme, IMHO.

It was a joke, however, since the State Machines I was responsible for were destined for ultimate implementation in a VLSI chip, and the implementation in software was just a simulation to check for unanticipated behavior, to verify if all the transitions were accounted for, and to generate test vectors for logic simulation of the VLSI design, and sometimes for producing test vectors used for testing the finished chip, the whole goal was to have the software version as a bridge from the State Transition Diagram (the spec) to the VLSI Logic (the finished product). If a programmer didn't understand that, and insisted on coding in a way that didn't map well onto an "present-state", "next-state" Mealy or Moore logic (D-flipflop, gates) implementation, then they either learned to do it that way, or they were of no use to the project.

 

[3v0]

In general I try to be language neutral. But I am rather adamant about wanting to write in a way that is transparent, and least prone to bugs. Once you adopt this religion it is a bit like being a recovering alcoholic.

I have read that simple code results in smaller objects because in compilers are better able to optimize less complex statements. Given that I can live with source file that is somewhat longer but easier to read.

MikeMl

In c if you do not transfer control out of a case it falls through and does the test for the next case.

C# has changed that. You have to end each case with "jump-statement", break, or goto. The fall through behavior was responsible for a lot of bugs so maybe this is a good thing.

This Microsoft page has an example of switch case use. Some of you may enjoy it, but it make me a little queasy.

// statements_switch.cs
using System;
class SwitchTest 
{
   public static void Main()  
   {
      Console.WriteLine("Coffee sizes: 1=Small 2=Medium 3=Large"); 
      Console.Write("Please enter your selection: "); 
      string s = Console.ReadLine(); 
      int n = int.Parse(s);
      int cost = 0;
      switch(n)       
      {         
         case 1:   
            cost += 25;
            break;                  
         case 2:            
            cost += 25;
            goto case 1;           
         case 3:            
            cost += 50;
            goto case 1;         
         default:            
            Console.WriteLine("Invalid selection. Please select 1, 2, or 3.");            
            break;      
       }
       if (cost != 0)
          Console.WriteLine("Please insert {0} cents.", cost);
       Console.WriteLine("Thank you for your business.");
   }
}

 

[misterT]

The problem with switch-case structure (in C) is that all cases are optional and any form of label is allowed. You could write something like

switch (i) {
case 5+3:
do_again:
case 2: printf("I loop unremittingly \n"); goto do_again;
default: i++;
case 3: ;
}

And if you mistype something the compiler might not notice it, because any label is allowed. I can't test this now, but I hope that a label named "break:" is not allowed. I know that a label named "brake:" is allowed, but what are the odds of mistyping that much. Mistyping the "default" label can definitely cause a major bug.

Also, what will happen if you try to break out of a while-loop inside switch-case structure? Like this

switch (i) {
case 1:
    break;

case 2:
    while(1){
        do_something();
        if(not_done) continue;

        break; // where will the execution jump from here?
    }

    important_stuff();
    break;

default:
    do_default();
}

It is a silly example, but where will the code break from the while-loop? Will the "important_stuff();" get executed? The answer is no. The code will break out of the whole switch-case structure.

Actually, for state machines, a switch-case structure is just a more complicated way of using goto (or hiding the use of goto), because both use labels to "go around". Switch-case structure just has the extra loop around the whole thing. This is what DirtyLude did in post #23. He just didn't know that it is possible to use something like "goto case UP2;" inside a switch-case structure. That does exactly what "state=UP2; break;" does.

 

[3v0]

In general c gives one enough rope to hang oneself. Not a problem if you respect the rope.

I recall an example where the break produces unexpected results but it seems it is not the one you provided.

The break statement terminates the execution of the nearest enclosing do, for, switch, or while statement in which it appears. Control passes to the statement that follows the terminated statement.

In the example the nearest enclosing is the while(1) inside the case 2:.

For state machines I favor putting the switch inside a while and executing one case/state per trip through the loop. You can do this with a break terminating each case or use the function pointer method illustrated earlier. One advantage is that we can place code following the switch to do something useful between each state. Reporting what state the machine is in is a good example.

 

[DirtyLude]

He just didn't know that it is possible to use something like "goto case UP2;" inside a switch-case structure. That does exactly what "state=UP2; break;" does.

Wait, what? What didn't I know? How did you get out of my code that I didn't know you can use a goto within a switch? Anyway, you are mixing up your C and C#. "goto case label" is only a C# convention, it does not work in C. Your example with the break will break out of the current control, so it will break out of the while loop and do the important_stuff().

 

[Mr RB]

3V0-

This Microsoft page has an example of switch case use. Some of you may enjoy it, but it make me a little queasy.

Queazy is how my PC feels anytime it is running Microsoft apps. Surely if there is one thing we have learned over the years is that Microsoft should never be allowed *anywhere near* writing code... Ever!

CS guys are taught how to make those bloated sluggish C# PC apps, so I'm not too sure about letting CS guys near programming microcontrollers either, unless they have done a few years apprenticeship programming them in assembler. And it can be completely up to them whether or not they lower their principles and start using those evil gotos.

 

[3v0]

The problems at MS in part are due to hi-tech management style rather then the skill of the people who write code. Shifting goals and engineers who change jobs mid project have resulted in a sequence of restarts and abortions resulting in MS flavored code.

Classical hi-tech management expect good engineers to switch jobs/projects every two years. Longer projects suffer greatly in that few if any of the people who started the project are there at the end. Understanding of the existing code base diminishes with each departing engineer.

CS guys are taught how to make those bloated sluggish C# PC apps, so I'm not too sure about letting CS guys near programming microcontrollers either, unless they have done a few years apprenticeship programming them in assembler. And it can be completely up to them whether or not they lower their principles and start using those evil gotos

I agree that a programmer who only knows how to write C# programs would be a poor choice to write most embedded code. By the same token the programmer you favor would be a bad choice to write a protocol stack or similar in that complexity range.

When hiring an engineer to write embedded code it makes sense to choose one with asm experience even if he project is HLL. I agree with you on this. If possible get one that understands digital logic too.

The use of structure as used by C does little to contribute to bloat. Used correctly it does provide code that is more readable, maintainable, reusable, and scaleable.

A good programmer knows what he/she/it is doing. A crappy one does not. They come in all flavors. They are people.

RB I am quite sure you understand how wide the field of EE has become. I find it strange that you fail to see how CS too is a diverse field, and that one should not be putting round pegs in square holes.

 

[misterT]

CS guys are taught how to make those bloated sluggish C# PC apps, ...

Those "sluggish" C# PC apps are compiled from intermediate language to machine code the first time they are executed. After five years your "high performance C/C++" PC apps will be still stuck with five year old technology while C# apps are compiled at runtime to take full advantage of the current modern processors at hand.

 

[BrownOut]

The thing I love the most about ETO is how it's members are so passionate about thier technology.

The thing I hate the most about ETO is how it's members are so passionate about thier technology

 

[Mr RB]

3V0-

RB I am quite sure you understand how wide the field of EE has become. I find it strange that you fail to see how CS too is a diverse field, and that one should not be putting round pegs in square holes.

What I said was quite "tongue in cheek". I should have probably added a after the line that ended with "those evil gotos".

Any CS guy that can throw down some decent assembler (and knows when to) gets a big thumbs up from me.