8051 and a C switch statement

Got  a 4k8 serial biphase signal being decoded by a at85c52 with an
external non retrig monostable (hc221), and I'm running out of time
occasionally waiting for the generic 2*8  LCD to clear it's busy flag.
The LCD is fed with the info from the incoming biphase 

To reduce the "reaction time" I could use  a long switch statement on
the signal's clock interrupt bitcount from the sync word, 80 per
frame, do just a little bit each interrupt.

The real question is

" how big can I make the switch statement?"
Whats the limit?
I'm using the rasionance C compiler.

'scuse typos, a bottle of wine was preferable to staring at my
lamentable code


martin

Martin Griffith <mart_in_medina@ya___.es> writes:

> Got  a 4k8 serial biphase signal being decoded by a at85c52 with an
> external non retrig monostable (hc221), and I'm running out of time
> occasionally waiting for the generic 2*8  LCD to clear it's busy flag.
> The LCD is fed with the info from the incoming biphase 
>
> To reduce the "reaction time" I could use  a long switch statement on
> the signal's clock interrupt bitcount from the sync word, 80 per
> frame, do just a little bit each interrupt.
>
> The real question is
>
> " how big can I make the switch statement?"
> Whats the limit?
> I'm using the rasionance C compiler.

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.

> 'scuse typos, a bottle of wine was preferable to staring at my
> lamentable code


-- 

John Devereux

On Dec 28, 4:39=A0pm, Martin Griffith <mart_in_medina@ya___.es> wrote:
> " how big can I make the switch statement?"
> Whats the limit?
> I'm using the rasionance C compiler.


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.

robertwessel2@yahoo.com wrote:

> 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.  

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.

On Dec 28, 4:39=A0pm, Martin Griffith <mart_in_medina@ya___.es> wrote:
> Got =A0a 4k8 serial biphase signal being decoded by a at85c52 with an
> external non retrig monostable (hc221), and I'm running out of time
> occasionally waiting for the generic 2*8 =A0LCD to clear it's busy flag.
> The LCD is fed with the info from the incoming biphase
>
> To reduce the "reaction time" I could use =A0a long switch statement on
> the signal's clock interrupt bitcount from the sync word, 80 per
> frame, do just a little bit each interrupt.
>
> The real question is
>
> " how big can I make the switch statement?"
> Whats the limit?
> I'm using the rasionance C compiler.
>
> 'scuse typos, a bottle of wine was preferable to staring at my
> lamentable code
>
> martin

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.

On Sat, 29 Dec 2007 02:23:09 -0800 (PST), in comp.arch.embedded Wayne
Farmer <usenet@endymionsystems.com> wrote:

>On Dec 28, 4:39&#4294967295;pm, Martin Griffith <mart_in_medina@ya___.es> wrote:
>> Got &#4294967295;a 4k8 serial biphase signal being decoded by a at85c52 with an
>> external non retrig monostable (hc221), and I'm running out of time
>> occasionally waiting for the generic 2*8 &#4294967295;LCD to clear it's busy flag.
>> The LCD is fed with the info from the incoming biphase
>>
>> To reduce the "reaction time" I could use &#4294967295;a long switch statement on
>> the signal's clock interrupt bitcount from the sync word, 80 per
>> frame, do just a little bit each interrupt.
>>
>> The real question is
>>
>> " how big can I make the switch statement?"
>> Whats the limit?
>> I'm using the rasionance C compiler.
>>
>> 'scuse typos, a bottle of wine was preferable to staring at my
>> lamentable code
>>
>> martin
>
>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

Martin Griffith wrote:

>> 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.

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.

On Sat, 29 Dec 2007 13:03:09 +0100, in comp.arch.embedded Arlet Ottens
<usenet+5@c-scape.nl> wrote:

>Martin Griffith wrote:
>
>>> 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.
>
>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

robertwessel2@yahoo.com wrote:
> On Dec 28, 4:39 pm, Martin Griffith <mart_in_medina@ya___.es> wrote:
>>" how big can I make the switch statement?"
>>Whats the limit?
>>I'm using the rasionance C compiler.
> 
> The C standard (C89/90) requires that the implementation support at
> least 257 labels in a switch statement.

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

On Fri, 28 Dec 2007 23:39:04 +0100, Martin Griffith
<mart_in_medina@ya___.es> wrote:

>Got  a 4k8 serial biphase signal being decoded by a at85c52 with an
>external non retrig monostable (hc221), and I'm running out of time
>occasionally waiting for the generic 2*8  LCD to clear it's busy flag.
>The LCD is fed with the info from the incoming biphase 
>
>To reduce the "reaction time" I could use  a long switch statement on
>the signal's clock interrupt bitcount from the sync word, 80 per
>frame, do just a little bit each interrupt.
>
>The real question is
>
>" how big can I make the switch statement?"
>Whats the limit?
>I'm using the rasionance C compiler.

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