8051 and a C switch statement

I don't fully comprehend what you are trying to do :)

However, a decent compiler will turn a long switch statement into a jump table equivalent - but you will want to look at the generated assembler output to be sure it is doing this.

I don't think there is a limit to length in the C language - certainly not one that matters on a 8052. Of course a defective compiler could impose it's own limit.

--

John Devereux

The C standard (C89/90) requires that the implementation support at least 257 labels in a switch statement. This is unlikely to be an issue for an 8052. Your compiler's conformance to the C standard is unfortunately a different issue, which you'll have to take up with the vendor.

To at least some extent it is. A jump table on an 8052 can only comfortably host about 120 entries, because of the limited reach of the indirect jmp and the length of the jmp instruction it leads to.

So a switch with more than those 120 entries will have to be slower than others.

I'm guessing that you're writing to the LCD in an interrupt routine. If waiting for the LCD busy signal to drop is creating a problem for you, then perhaps you should be writing to the LCD in background, rather than foreground.

Or, if the LCD is busy, why not just push the LCD data into a FIFO and perform the access at some time in the future?

Updating an LCD shouldn't be that time-critical an affair.

Yes, that is what I'm trying to do. After a night's sleep, it is a lot clearer now. The biphase signal is just a bunch of 8 bit characters and a sync word

I hope to use the clock from the biphase decoder, which are about

250uS apart, to just send one command to the LCD when required instead of trying to enter a complete string at once, and ignoring the busy flag, as 250uS should be ample, as my scope shows about 10uS is required for the busy flag to be cleared.

One less thing to worry about.

Thanks

martin

I would recommend still checking the busy flag to make sure the LCD is still responding. If not, send it a reset, and re-initialize it. You could check it just before sending the next command, for instance.

I've noticed on several occasions that the processor inside the LCD module can get stuck, leaving the screen in a dead state. One particular LCD module I had was so sensitive that it could be locked up by tapping the outside of the metal enclosure with a screwdriver.

This, of course, assumes you have the reset signal under control of your CPU.

Good point, I'll initialise using the "check busy flag", and maybe do one busy flag per frame check

martin

These limits aren't worth anything. A compiler is required to compile at least one program containing 257 case labels. This one and only program might look like this: int main() { switch (0) { case 1: case 2: ...... case 257: default: break; } return 0; } and the compiler is still conformant. Some others (like an object size of 32767) cannot be fulfilled at all by some architectures.

Stefan

There can be another problem, depending on your compiler. The older IAR C51 Compilers generated thread unsafe code for a switch statement for more than about 3 items, hence if one used big switch statements inside an interrupt routine and outside, the code crashed. This was for IAR C51 V4 and V5. I do not know whether this has been fixed, or if an option had been added to force the compiler to generate thread safe code.

You can always split a big switch statement into multiple smaller ones. This is a bit slower than one big one.

i.e. switch (var) /* Check bottom bits */ { case 0: break;

case maxsize: break; default: switch(var) { case maxsize+1: break; }

}

Regards Anton Erasmus

Ah, there was I happily writing a 16 case switch.

Generally speaking, should you keep code in a case statement short?

I was thinking that it should be like a interrupt, short and sweet

case 7: { temp=temp

If it is in an interrupt routine, then it normally should be short, not because it is in a switch statement, but because it is executed in an interrupt routine. I personally keep the segments in a switch statement reasonably short. I find that the code becomes difficult to maintain if one has huge sections in each case statement, especially if it is a switch statement with many cases. Also the switch statement is normally for decision making, while the contents of the case blocks are for controlling/action. I find it good practice to split these concepts.

[snipped]

Regards Anton Erasmus