videoPage structure poor memory utilization

[GoogleCodeExporter]

Using a single-buffered grayscale display, I can't tell a difference between 
"uint8_t pixels[SHADES][24]" and "uint8_t pixels[SHADES][48]" - and the 
subsequent commentary makes me suspect that 48 is simply 24 bytes per frame * 2 
frames.  As that means the leds structure takes up 768 bytes, the amount of ram 
available for user projects is limited unnecessarily.  Especially since that 
structure is allocated twice, once for the work buffer and once for the display 
buffer, but I haven't poked at it enough to be certain.

imac:bin pfriedel$ ./avr-objdump -t -j .bss OneTenClock.cpp.elf 

OneTenClock.cpp.elf:     file format elf32-avr

SYMBOL TABLE:
[...snip...]
0080027a g     O .bss   00000300 leds
[...snip...]

Versus:
imac:bin pfriedel$ ./avr-objdump -t -j .bss OneTenClock.cpp.elf 

OneTenClock.cpp.elf:     file format elf32-avr

SYMBOL TABLE:
[...snip...]
0080029e g     O .bss   00000180 leds
[...snip...]

With a related decrease in the bss allocation:
imac:bin pfriedel$ ./avr-size OneTenClock.cpp.elf 
   text    data     bss     dec     hex filename
  15208     376    1371   16955    423b OneTenClock.cpp.elf
imac:bin pfriedel$ ./avr-size OneTenClock.cpp.elf 
   text    data     bss     dec     hex filename
  16626     376     987   17989    4645 OneTenClock.cpp.elf

I'm not quite proficient enough with C header programming to make this do the 
right thing when it's not being used in a double buffered application, but it 
seems like it should be reasonably straightforward.  Ultimately it seems like 
it should allocate 48 when double buffered grayscale, 24 when single buffered 
grayscale, and (???) when double-buffered B&W and single buffered B&W. To be 
honest, the interrupt code makes my eyes cross.

There's also a spurious Serial.end() in Charliplexing.cpp that causes the 
serial library to get pulled in unexpectedly.  It wasn't until I started 
looking at an object dump trying to figure out where all my memory was going 
that I saw that Serial was getting pulled in that I took a closer look at my 
libraries.

Or I'm just missing a subtlety that only comes up when you're using all 136 
LEDs on an official LoL Shield that isn't apparently on my stripboard 110-LED 
project, in which case you can ignore this.

Original issue reported on code.google.com by pfrie...@gmail.com on 30 May 2012 at 1:15

[GoogleCodeExporter]

So some further testing (read: I ran out of ram again): If I set the videoPage 
structure to only 1 element in a single-buffered display, I don't see any 
visible degradation.  I suppose this shouldn't be too surprising since the 
second page is only ever called in DOUBLE_BUFFER mode.  I'm down to 192bytes 
according to avr-objsize.

However, dropping the pixels[SHADES][24] below 24 creates all kinds of 
corruption.  Heinous amounts of it.  24 seems to be the floor, which is obvious 
given the time slicing that goes on in the ISR.

So far, the diff looks like this:

46c46,47
<     uint8_t pixels[SHADES][48];  // TODO: is 48 right?
---
> // WAS: 48 - seems to be needed for double buffering, but since I'm only 
using the single page, I only need half the allocation.
>   uint8_t pixels[SHADES][24];  // TODO: is 48 right?
55c56,57
< videoPage leds[2];
---
> // WAS: [2] - [1] still seems to work, halves the memory utilization from 768 
to 384 to 192 bytes.  That's quite reasonable.
> videoPage leds[1];
373c405
<     Serial.end();
---
> //    Serial.end();

...along with some other work to make the library less LoL Shield specific.  As 
it's the nicest Charlieplex driving library I've run into, I've been tweaking 
it.

TO-DO: Work up a double buffered project and test the diet on it. Wrap my 
changes in something like if(displayMode & DOUBLE_BUFFER) { /* original code */ 
} else { /*smaller code*/ }

Original comment by pfrie...@gmail.com on 12 Jun 2012 at 3:29

[GoogleCodeExporter]

fixed (correctly) in revision 28

Original comment by r...@ihack.net on 20 Aug 2013 at 5:44

• Changed state: Fixed
• Added labels: Type-Enhancement
• Removed labels: Type-Defect