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

[sast]

Hallo Joe,

das mit dem Progmem ist kinderleicht und bewahrt einen wirklich vor bösen Überraschungen. Ich hab hier mal ein kleines Beispiel, wie ich das implementiert habe um Statusmeldungen auszugeben.

int main(void)
{
unsigned char actual_page = 0;
char main_text[20];
...
get_str_from_flash(6, main_text);//"Menue 4"
tp_write_statusbar(&tp, main_text);
...

Die flash_mem.c:

#include <stdint.h>
#include <avr/pgmspace.h>
#include <string.h>

#include "main.h"
#include "flash_mem.h"

const char str1[] PROGMEM = "INFO allgemein";
const char str2[] PROGMEM = "              ";//14 Leerzeichen
const char str3[] PROGMEM = "Menue 1";
const char str4[] PROGMEM = "Menue 2";
const char str5[] PROGMEM = "Menue 3";
const char str6[] PROGMEM = "Menue 4";
const char str7[] PROGMEM = "Menue 5";
...

const char *strarray1[] PROGMEM = {
    str1,
    str2,
    str3,
    str4,
    str5,
    str6,
    str7,
    str8,
    str9,
    str10,
    str11,
    str12,
...
};

void get_str_from_flash(uint16_t strnum, char* str)
{
if(strnum>0)strcpy_P(str, (const char*)(pgm_read_word(&(strarray1[strnum-1]))));
else strcpy(str, "Invalid number!");
}

und in der flash_mem.h steht nur:

#ifndef _MEM_FLASH_H_
#define _MEM_FLASH_H_

extern void get_str_from_flash(uint16_t strnum, char* str);

#endif  /* _MEM_FLASH_H_ */

[markusj]

das mit dem Progmem ist kinderleicht und bewahrt einen wirklich vor bösen Überraschungen. Ich hab hier mal ein kleines Beispiel, wie ich das implementiert habe um Statusmeldungen auszugeben.

Leider nicht ganz, da das Timing in dem Fall sich verändert. Der EEPROM ist noch langsamer im Zugriff als der Flash, aber bei timingkritischen Anwendungen ist das eben ein relevanter Faktor. Außerdem: Warum so umständlich mit der zusätzlichen Zeigertabelle? Um von den zwei Byte des Pointers ein Byte einzusparen im Tausch gegen schlecht zu debuggende "Magic Numbers"? In dem Fall wäre es ratsam, anstatt der Zahlenwerte einen enum zu nutzen.

mfG
Markus

[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