Feste Größe ändert sich beim Programmablauf (="Suchspiel" Memoryüberschneidung)

[sast]

Markus könntest du das mal bitte an einem konkreten Beispiel zeigen, was du meinst?

Danke
sast

[Hubert.G]

Hallo Joe
In deiner *com*.h da hast du so was definiert

volatile s16 M12ocr;
hier wirst du wohl ein int brauchen, aber bei allen anderen Variablen auch?
Mit so was habe ich mich schon einige male in ein Schlamassel gebracht und bin daher sehr vorsichtig.
Wenn nach dem compile Data mehr als 60% braucht werde ich schon hellhörig.

[oberallgeier]

Markus könntest du das mal bitte an einem konkreten Beispiel zeigen, was du meinst ...

Ja, bitte, das würde mir auch helfen. Ich saß grad ne Weile an dem Vorschlag von sast - und bin natürlich und notwendigerweise schnell in die entsprechenden Tutorials vom RN und m-controller-net reingeschliddert. Zum Glück kam Markus - und ich hatte erstmal "Pause" gemacht - - - die Beispiele in RN und m-controller-net haben mich noch nicht zu ner funktionierenden Lösung gebracht.

... volatile s16 M12ocr ... int brauchen, aber bei allen anderen Variablen auch? ...

Hubert - mal mein "warum so" dazu.
Die MotorPWM wird aktuell mit 8 Bit gefahren - am Timer 1 (*gg* - klingt nach weiterer Vergeudung von Ressourcen).

  TCCR1B |=  (1<<WGM12);                // Fast PWM, 8 Bit TOP=0xFF=dez255     133
  TCCR1B |=  (1<<CS11);         // Prescaler ist clk/8 =>  9,8 kHz             135
        // theoretisch: 20 MHz / 8 / 255  =>  9,803922 kHz, DMM-Messung 9,78 kHz

  volatile s16  M12ocr; // temporärer Stellwert für OCR1A        -255...255

Beabsichtigt, vermutet, ist die spätere Verwendung von mehr als 8 Bit, weil die Regelung durchgehend von -fahrt (rechtsdrehend) bis +fahrt (linksdrehend) geplant ist - und da wären mir die verbleibenden 127 Ticks zu wenig. Die Lösung mit Fallunterscheidung "vor" oder "zurück" bzw. "re" oder "li" habe ich im MiniD0 und Dottie mit den vollen 255 Ticks praktiziert - sie gefällt mir eben nicht, weil ich wegen der Hin- und Herschalterei z.B. bei Langsamfahrt so etwas - - eben unschön finde. Um mir spätere Störmöglichkeiten durch vergessene Anpassungen zu ersparen, ist die Vorgabe der Fahr-PWM auf signed 16 ausgelegt (mehrere Größen). Ich hoffe, dass mir dieses Vorhaben gelingen wird. Ich versuche schon meist das Zahlenformat klein zu halten - - genau wegen des eher begrenzten SRAM-Platzangebots.

... Wenn nach dem compile Data mehr als 60% braucht werde ich schon hellhörig ...

Genau so gehts mir auch, ich wollte ja schon ne eigene Platine statt der RN-MotorControl bauen mit nem mega1284. Aber das gäbe schon wieder ne zusätzlichen Zeitaufwand ohne wirklichen Fortschritt . . . Sogar an einen 1284er-Huckepack-ersatz für den 328er hatte ich gedacht - aber nicht lange *gg*.

Hubert - ich hoffe dass damit Deine Bedenken behoben sind?

[markusj]

Markus könntest du das mal bitte an einem konkreten Beispiel zeigen, was du meinst?

Naja, die enum-Variante ist einfach. Im wesentlichen dein Code, nur statt uint16_t strnum ein strnum_t str. Und dann eben

typedef enum {
   str_info = 0,
   str_space,
   str_menu1,
   ...
} strnum_t

// Verwendung dann so:
get_str_from_flash(str_info, str); 

Damit gewinnst du etwas mehr Übersichtlichkeit, hast aber immer noch die unnötige Indirektion strarray1->*str->Flash. Der direkte Weg wäre einfach, die Strings direkt mit sprechenden Namen zu versehen und dann zu referenzieren. Damit scheidet dann auch die Möglichkeit weg, versehentlich einen nicht existierenden String zu referenzieren.

const char str_info[] PROGMEM = "INFO allgemein";
const char str_space[] PROGMEM = "              ";//14 Leerzeichen
const char str_menu1[] PROGMEM = "Menue 1";

...

// Verwendung, get_str_from_flash wird überflüssig
strcpy_P(str, &str_menu1); 

mfG
Markus

[sast]

Hallo Markus,

die erste Variante unterscheidet sich ja nicht wirklich von meiner, bis auf die Namen. Ursprünglich war bei mir auch angedacht, z.B. über eine Zählschleife einen Block aufzurufen. Da das jetzt nicht mehr so ist, gefällt mir deine Variante 2 sogar noch besser.

Danke für die Ausführung
sast

[damfino]

Ich habe die Strings ins Flash einfacher gehalten, mit PSTR:
zB.:
String im SRAM:
lcd_puts(" Warte GPS");

String im Flash:
#include <avr/pgmspace.h>

lcd_puts_p(PSTR(" Warte GPS "));

das "_p" zur Funktion dazuschreiben damit die Daten aus dem Flash geholt werden.

Mit der Zeigertabelle spart man etwas mehr Flash Speicher, dafür kann man hier ohne große Änderungen alles ins Flash bringen, und da man den Text direkt im Code sieht weiss man auch was man rausschickt, und muss nicht in einer Tabelle den richtigen Text suchen.

LG!

[markusj]

die erste Variante unterscheidet sich ja nicht wirklich von meiner, bis auf die Namen.

Habe ich auch nie behauptet Die enums sollen ja nur die Wartbarkeit durch sprechende Namen verbessern.

@damfino: Danke für den Hinweis zu PSTR, damit hatte ich mich noch nicht beschäftigt.

mfG
Markus

[sast]

@damfino wird dann auch erkannt, wenn der gleiche String mehrmals verwendet wird, oder gibt es dann jedes mal einen neuen Eintrag?

Der Vorteil einer Tabelle liegt für mich auch darin, dass ich im nachhinein nicht alle Strings im gesamten Quelltecxt suchen muss, um eine textliche Änderung vorzunehmen. Ich muss es nur einmal ändern und sofort sind alle ensprechenden Aufrufe angepasst.

sast

[damfino]

Ich gehe davon aus dass es jedesmal einen neuen Eintrag gibt, aber wenn so wie hier nur 33% vom Flash belegt sind ist das kein Problem.
Wenn sich Textausgaben oft wiederholen kann man ja auch Makros oder inline-Funktionen benutzen.

Meiner Meinung nach kann man mit PSTR schnell den vorhandenen Code umschreiben, einfach mal an unwichtigen Stellen ausprobieren, etwas RAM freischaufeln, vielleicht geht es dann schon fehlerfrei. Dann kann man immer noch elegantere Lösungen einführen.

Habe selber auch Tabelle für zB Fehlermeldungen, aber kurz mal zum debuggen erweitern geht einfacher mit PSTR.

LG!