2

I recently started rewriting a program to make it more easy to understand and I started using enums for describing the different states my program can be in.

byte VoltageLimit(byte progState, word voltage)
{
    switch(progState){
        case Charge:
        case DiagCharge1:
        case DiagCharge2:
            if(voltage>ConstUMax)
                {return 1;}                  
            else 
                {return 0;}
        case Diagnose:
            if(voltage<ConstUMin)
                {return 1;}
            else 
                {return 0;}
        default:
            return 0;
    } 
}

Here is the enum:

enum EnumProgramState
{
    Idle,
    Charging,
    Done,
    DiagCharging1,
    DiagBattery,
    DiagCharging2,
    DiagDone,
    Error
}

I thought I could get away with passing it as byte to the function since the values are actually integers, but I am not sure if this causes the problem or something else, I have been modifying this function for ages now.

The error I get when compiling (2 errors on the same line), the error appears always on the first line I write in a specific case. I have no idea what it is trying to tell me .

main.c:159:Error [1113] integer constant expected for case label value
main.c:159:Error [1113] integer constant expected for case label value

The question: What am I doing wrong, how can I get my code working?

Grossu Iulian
  • 275
  • 1
  • 2
  • 10
  • Learn to use source control systems as they allow you to have "save points" that you can easily go back to or compare your existing code to to see "what changed since the last time it worked" – YePhIcK Sep 23 '15 at 17:20
  • this section never worked, however I have another select case in my main routine that uses enums and that works. – Grossu Iulian Sep 23 '15 at 17:40
  • 2
    A couple of style suggestions: Don't use a `byte` for the `progState` in the function signature, but declare it to be of type `enum EnumProgramState` -- this will help communicate the intent of the parameter. (You might also consider re-declaring the enumeration to be something like `typedef enum {...} ProgramState` so you can leave off the `enum` in such declarations). Likewise, if your return type is a boolean, make it a `BOOL` or something instead of `byte`, so the usage intent is clearer. These changes would give you: `BOOL VoltageLimit(ProgramState progState, word voltage)` – paul Sep 23 '15 at 18:11

2 Answers2

3

Unsigned chars will work as expected. You have several typos or undefined labels:

case Charge: but the enum is Charging

case DiagCharge1: but the enum is DiagCharging1, etc.

jolati
  • 700
  • 11
  • 19
  • 1
    I changed the enum while writing the program and forgot to check the rest of the code >.< now I feel so stupid for overlooking such a simple thing , ugh – Grossu Iulian Sep 23 '15 at 18:05
  • 1
    @GrossuIulian, don't worry about it. It's the kind of mistake we all make from time to time. Sometimes a bug just needs someone else to look at it. Additionally, I'm sure that the enum and the code being so near to eachother in the question here made it a lot easier to spot... – Wouter Verhelst Sep 23 '15 at 23:26
1

You can also give this a try:

typedef enum
{
    Idle,
    Charging,
    Done,
    DiagCharging1,
    DiagBattery,
    DiagCharging2,
    DiagDone,
    Error
} ProgState;

byte VoltageLimit(ProgState xMyProgState, word voltage)
{
    switch(xMyProgState){
        case Charge:
        case DiagCharge1:
        case DiagCharge2:
            if(voltage>ConstUMax)
                {return 1;}                  
            else 
                {return 0;}
        case Diagnose:
            if(voltage<ConstUMin)
                {return 1;}
            else 
                {return 0;}
        /*
        default:
            return 0;
        */
    } 
}

It will give you specific errors like this:

Build error: 'Charge' undeclared (first use in this function)

and If you comment the default case then you can keep track of that whether you have implemented each case statement or not.

  • Good to know, I was thrown off by the fact that the compilator gave me a vague error. Doing it like this will help me identify such errors more easily. – Grossu Iulian Oct 01 '15 at 19:18