switch case "umgehen"

International Deutsch
1

Hi,
da mir bei meinem aktuellen Projekt langsam der Flash knapp wird, bin ich gerade am grübeln wo ich einsparen kann.
Ich hab da eine ewig lange switch case Anweisung, die mir gar nicht so gefällt, weil das bestimmt besser programmiert werden kann. Aber nur wie?

Hier mal ein Auszug aus meinem Code:

#define TempMask B10000011
#define Temp16 B00000100
#define Temp17 B01000100
#define Temp18 B00100100
.......
int SollTemp

      switch (SollTemp) {
         case 16:
            setBitPattern (irString[6], TempMask, Temp16);            
         break;
         case 17:
            setBitPattern (irString[6], TempMask, Temp17);            
         break;
         case 18:
         ....

Also abhängig von Solltemp soll das Unterprogramm setBitPattern mit anderen Parametern aufgerufen werden.
Ich könnte jetzt schon einen C-string aus 'Temp' und der Integer zusammenbauen, damit er so heisst, wie der dritte Übergabeparameter, aber das wird wohl kaum funktionieren, dass dann in dem Unterprogramm der zugehörige Bitcode verwendet wird.

Evtl. könnte ich die Bitcodes in ein Array packen.
Etwa so:

byte TempByte[] = { B00000100, B01000100, B00100100...}

Und das dann über TempByte[Temp] abrufen. Für Temp = 16....30
Aber kann ich ein Array so definieren, dass der erste Wert des arrays mit index-16 abgerufen werden kann?

Hmm da bin ich wieder an meine Grenzen angekommen :~

2

deine idee ist dazu ganz gut zu gebrauchen.
benutze einfach sowas wie ein offset.

TempByte[deinindex + 16]  //deinindex = -16

somit ist der erste wert bei 0.

3

Zeig uns doch den vollständigen Code, da gibt es sicher noch mehr zu holen. Die Arraylösung ist nicht schlecht belastet aber das SRAM unnötig. Lies mal unter PROGMEM nach wie man das noch besser macht: http://arduino.cc/en/pmwiki.php?n=Reference/PROGMEM. Und hier ein Beispiel wie man das einsetzen kann: Persistence of Vision | Blinkenlight.

4

PhunThom:
deine idee ist dazu ganz gut zu gebrauchen.
benutze einfach sowas wie ein offset.

TempByte[deinindex + 16]  //deinindex = -16

somit ist der erste wert bei 0.

Oh man, wie doof von mir. Da hab ich den Wald vor lauter Bäumen wieder nicht gesehen :stuck_out_tongue_closed_eyes:
Müsste aber dann [Index -16] sein!?

Die Arraylösung ist nicht schlecht belastet aber das SRAM unnötig.

Ja, ich wollte das eh noch ins Flash packen. Muss dazu noch etwas in meinen alten Threads etwa nachlesen, wo mir Serenifly geantwortet hat.
Ich glaub der programmiert immer so, dass er mit 100Byte SRAM auskommt. LOL
Aber ist das nicht wieder kontraproduktiv zu meinem Vorhaben? Durch das Verlagern ins flash muss ich wieder mehr Code schreiben, der mir die Daten aus dem Flash liest. -> pgm_read_byte_near usw...

Noch ne Frage:
Wenn ich die Bitkombination mit define für mich lesbarer mache, kann ich dann auch die defines im Array verwenden?

byte TempByte[] = { Temp16, Temp17, Temp18...}

Sollte doch der Präprozessor dann umsetzen. Oder?

5

Wenn Du die Daten "aus dem SRAM liest", was glaubst Du wie die da hinkommen? Der Compiler generiert Code damit die da hinkommen. Und wie liest Du Daten aus dem SRAM? Auch das kostet Platz. Würde mich wundern wenn PROGMEM mehr Platz kostet.

6

hk007:

PhunThom:
deine idee ist dazu ganz gut zu gebrauchen.
benutze einfach sowas wie ein offset.

TempByte[deinindex + 16]  //deinindex = -16

somit ist der erste wert bei 0.

Oh man, wie doof von mir. Da hab ich den Wald vor lauter Bäumen wieder nicht gesehen :stuck_out_tongue_closed_eyes:
Müsste aber dann [Index -16] sein!?

Ich habe deinen wert als negative zahl gelesen. also -16. wenn du doch erst bei 16 anfängst dann statt + natürlich -.

7

Ein kleiner Overhead ist glaube ich vorhanden, da man die Makros braucht um die Daten aus dem Flash auszulesen.

Siehe auch hier:
http://www.nongnu.org/avr-libc/user-manual/pgmspace.html

The macros and functions used to retrieve data from the Program Space have to generate some extra code in order to actually load the data from the Program Space. This incurs some extra overhead in terms of code space (extra opcodes) and execution time. Usually, both the space and time overhead is minimal compared to the space savings of putting data in Program Space.

8

Na dann fragen wird doch mal den Compiler:

Am Beispeil von Persistence of Vision | Blinkenlight

Mit Progmem:

/tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.eep 
avr-objcopy -O ihex -R .eeprom /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.elf /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.hex 
Binary sketch size: 1066 bytes (of a 30720 byte maximum)

Ohne Progmem:

void blink() {
    static uint16_t index = 0;

    PORTC = pov_pattern[index++];
    PORTB = pov_pattern[index++];
    PORTD = pov_pattern[index++];

    if (index >= sizeof(pov_pattern)) { index = 0; }
}

/tmp/build3560765376939368227.tmp/core.a -L/tmp/build3560765376939368227.tmp -lm 
avr-objcopy -O ihex -j .eeprom --set-section-flags=.eeprom=alloc,load --no-change-warnings --change-section-lma .eeprom=0 /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.elf /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.eep 
avr-objcopy -O ihex -R .eeprom /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.elf /tmp/build3560765376939368227.tmp/Blinkenlight_301_persistence_of_vision.cpp.hex 
Binary sketch size: 1082 bytes (of a 30720 byte maximum)

1082 - 1066 = 16

--> Man sollte bei Optimierungen IMMER den Compiler fragen und nicht irgendwelche Halbwahrheiten aus dem Internet zitieren. Das Problem ist, daß die oben zitierte Stelle verschweigt, daß das initiale Umkopieren vom Flash in den SRAM auch Platz braucht.

Es hängt immer von der jeweiligen Programmstruktur ab was mehr oder was weniger Platz braucht.

9

Also:

const byte TempByte[] PROGMEM = {Temp16, Temp17, Temp18, Temp19, Temp20, Temp21, Temp22, Temp23, Temp24, Temp25, Temp26, Temp27, Temp28, Temp29, Temp30};   
setBitPattern (irString[6], TempMask, pgm_read_byte(&TempByte[SollTemp-16]));

gegenüber:

const byte TempByte[] = {Temp16, Temp17, Temp18, Temp19, Temp20, Temp21, Temp22, Temp23, Temp24, Temp25, Temp26, Temp27, Temp28, Temp29, Temp30};   
setBitPattern (irString[6], TempMask, TempByte[SollTemp-16]);

Ergebnis:
Flashbedarf: identisch
SRAM: mit Progmem 16Byte weniger. Was zu erwarten war.

Aber was mir am besten gefällt: Ich hab ohne die Case-Anweisung über 40 Zeilen weniger Code :slight_smile: :slight_smile: :slight_smile: