On Sun, 30 Dec 2007 18:45:20 +0100, Martin Griffith
<mart_in_medina@ya___.es> wrote:

>On Sun, 30 Dec 2007 19:18:32 +0200, in comp.arch.embedded Anton
>Erasmus <nobody@spam.prevent.net> wrote:
>
>>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
>Ah, there was I happily writing a 16 case switch.
>
>Generally speaking, should you keep code in a case statement short?

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

On Sun, 30 Dec 2007 19:18:32 +0200, in comp.arch.embedded Anton
Erasmus <nobody@spam.prevent.net> wrote:

>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
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<<1;
temp=temp&0xff;
*LCDdata=temp+47;
break;
}

sort of thing

Sorry if the question seems a bit 101ish, but they didn't have
computers for humans when I was a lad.


martin

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

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

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

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.

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