Je kan inderdaad ipv row = bin[count] direct count gebruiken en het hele array gebeuren weghalen. Dit doet hetzelfde en is efficiënter.
Nu we het toch over efficiëntie hebben, je gebruikt nu overal integers voor kleine waardes. De AVR is een 8-bit processor en in AVR C is een integer 16 bit. Dit betekend dat de compiler nu twee bytes voor iedere waarde reserveert en ook nog eens een hoop extra assembly code genereert om 16-bit berekeningen uit te voeren op een 8-bit core.
Beter is om, wanneer je toch geen waardes gebruikt hoger dan 255, om unsigned chars te gebruiken ipv int. Een unsigned char heeft een grootte van 1 byte en de AVR core kan hier direct efficiënt mee rekenen.
Dit gedeelte is overigens ook niet heel efficiënt:
r0 = row & 0x01; // tricky bitshifterism copy/pasted
r1 = (row>>1) & 0x01; // tricky bitshifterism copy/pasted
r2 = (row>>2) & 0x01; // tricky bitshifterism copy/pasted
De variabelen r0, r1 en r2 worden nu vooraf gedeclareerd (buiten de functie). Dit betekend dat ze nu ergens in SRAM komen te staan. De compiler genereert assembly code die steeds met behulp van een pointer de waarde in SRAM ophaalt, berekend en weer opslaat in SRAM. Werken met variabelen uit SRAM kosten veel meer CPU cycles dan variabelen in registers. Gezien je de variabelen niet buiten de functie gebruikt is het beter om r0, r1 en r2 niet buiten de functie maar binnen de functie zelf te declareren. De compiler gebruikt dan een register ipv een SRAM locatie. (tenzij de variabele als static in een functie wordt gedeclareerd, maar dat is een ander verhaal.)
de decimale 0-7 waarden die met "count" en "row" worden gedefinieerd zijn pointers om de binaire waarden in de "bin" array op te halen.
Soort van pointers inderdaad. Op assembly niveau zullen het wel pointers worden. In C praat men meer over index (of offset). Een 'echte' pointer naar een element in de array zou er ongeveer zo uit zien: unsigned char *myPointer = &myArray[someElement];
Hopelijk heb je iets aan deze info!
