PROGMEM und Optimierung

[Ceos]

Hardware ATXMEGA64 @ 32MHz

Ich sitze hier an einem sehr interssantem Thema und habe auch schon einiges an Tatsachen hervorgeholt und wollte mal eure Meinung dazu hören.

Ich habe eine quasi Konstante Tabelle (Array) const somestruct_t data[SOMESIZE] = {...} welche ich per PROGMEM in den ROM befördert habe

Nun stellt sich das Problem dar, dass ich von extern einen 16bit Wert erhalte den ich mit einem 16bit Wert innerhalb der Struktur vergleichen muss um anschließend je nach Lage die ein oder andere Funktion via FPointer aufzurufen.

ich habe insgesamt 4 Ansätze probiert und das Disassembly dazu studiert um die Laufzeit zu ermitteln

1. memcpy_P in eine statische tempvariable welche ich in einem if() vergleiche -> 32 Zyklen

2. direkter memcmp_P im if() -> 28 Zyklen

3. if(pgm_read_word() == extern) -> 25 Zyklen

4. lookup im RAM über die Keys -> 9 Zyklen und später dann Zugriff auf die Pointer (in den Fällen 1-3 würde exakt dasselbe passieren)

die Schleife sieht im moment unschön aus und soweit ich das Disassembly überschaue ist sie quasi nicht optimiert worden!

Mein erster Gedanke war es den Vergleich zu optimieren (Option 3 oder 4) und aus der SChleife heraus einen Call zu starten um die passende Reaktion zu starten und dem Compiler das optimieren zu überlassen.

Option 5: Mein zweiter Gedanken jedoch ging in die Richtung einen unschönen Switch() aufzubauen, ihn aber per Precompiler strukturiert zu definieren, da ich im moment für die Tabelle eh schon relativ viel funktionspointer einsetze!

Seht ihr aus der sicht extremer RAM knappheit und eingeschränkter ROM Verfügbarkeit(mehr ROM als RAM aber nicht sehr viel mehr) noch andere Optionen oder Ansätze? Kann man eventuell noch anders Daten im ROM ablegen und effizient darüber iterieren welche ich vielleicht übersehen habe? Oder hat jemand noch einen Assembler Ansatz in der Hinterhand?

MfG

Ceos

[Wsk8]

Seh ich das richtig, dass dir diese ~25 Zyklen für den Zugriff zu lange sind oder worauf willst du hinaus?

mfg

[Ceos]

korrekt, ich versuche gerade eine ISR zu optimieren, leider ist der restliche Teil des Programms relativ komplex und eine Neugestaltung erscheint mir aus derzeitiger Sicht unmöglich sonst hätte ich schon am Design optimert, aber es ist mir nun leider im Moment vorgegeben dass ich über eine PROGMEM Tabelle zu suchen habe um einen geeignete Reaktion auszulösen .... die eigentliche ISR ist weit größer und unnötig kompliziert weswegen keien Optimierung gelingt, zumindest daran kann ich was ändern wenn ich die Schleifen entsprechend umgestalte!

Am liebsten wäre mir die Tabelle durch ein, per Precompiler übersichtlich gestaltetes, Switch Case zu ersetzen um dem Compiler die Optimierung voll und ganz anzuvertrauen!

54 Einträge mit jeweils mind. 50 Zyklen für PROGMEM Zugriffe auf diese Einträge sehe ich kritisch wenn man versucht nebenbei einen 200us Cycle-Prozess laufen zu lassen und im worst case 84us nur für das Durchlaufen der Tabelle draufgehen

[Wsk8]

Wie siehts mit externer HW aus? Vlt nen extra RAM-IC?

Ansonsten kann ich dir nur raten, dein Design zu überprüfen. Eine ISR sollte immer sehr kurz gehalten werden. Hört sich bei dir jetzt nicht so kurz an.

mfg

[Ceos]

"dein Design zu überprüfen" das ist der Haken ich fress mich gerade durch das Programm weils eben nicht mein Design ist und versuch es zu schmieren! Und nochmals back to Topic bitte, ich hatte schon mehrere Ansätze gebracht und hoffte auf ein wenig Feedback zu denen oder vielleicht doch noch eine optimalere Lösung ...

Die Kommunikation ist nicht anders als wie oben beschriebe zu lösen im Moment, das Timing ist und bleibt kritisch und der timed Prozess hat schon exklusiv höhere prio als die com ISR! Trotzdem muss ich die Com ISR in einem gewissen zeitrahmen bearbeiten und mich durch eine commandliste fressen welche im moment ineffizient in einem progmem array steckt

[Wsk8]

Was sind denn das für Werte in der Tabelle? 1, 2, 3, ... oder völlig Random und wie entstehen die?

mfg