Lebensdauer von lokalen Variablen

[Christian J. (Firma: privat) (christianj)]

Hallo,

aus der leidigen Erfahrung eines "Stackoverflow" heraus bei den winzigen 
2k eines AVR328 muss nun optimiert werden. Stringverarbeitung hat es 
leider in sich, auch sprintf nimmt sich einen fetten Batzen des Stacks.

Versuche mit malloc und calloc waren fruchtlos, nach 4-5 Durchläufen kam 
nur noch ein NULL Zeiger zurück, obwohl alles ge-free()'t wurde. Keine 
Ahnung wieso, beim stm32 lief das alles immer prima. ich weiss aber auch 
nicht wie gross der Heap beim Arduino eingestellt worden ist.

Annahme:

void nixgut() {
  int a,b,c;
  (.....)
  {
     int e,f,g;

  }
  (weiter im Text)
}

a,b,c, liegen in einer inneren Klammer und sind außerhalb dieser nicht 
sichtbar. Aber reduziert sich damit auch wirklich der Stack, damit das 
Nachfolgende mehr Platz hat? Ich versuche alles nur solange leben zu 
lassen wie es gebraucht wird und keine Variable mehr am Anfang zu 
deklarieren.

Christian

[Niklas G. (erlkoenig)]

Christian J. schrieb:
> Versuche mit malloc und calloc waren fruchtlos

Die machen es eher schlimmer. Der Verwaltungsoverhead und die ggf. 
suboptimale Aufteilung erhöhen den Bedarf.

Christian J. schrieb:
> beim stm32 lief das alles immer prima.

Die haben ja auch viel mehr Speicher...

Christian J. schrieb:
> Aber reduziert sich damit auch wirklich der Stack, damit das
> Nachfolgende mehr Platz hat?
Nein. Compiler optimieren Funktionsaufrufe meist so, dass einmal zu 
Beginn alles benötigte allokiert wird. Es werden aber durchaus 
Stack-Plätze wiederverwendet, falls möglich.

Schau dir doch einfach den erzeugen Assembler-Code an, der räumte alle 
Zweifel aus. Und zeig mal den ganzen Code, die paar Integer-Variablen 
sind überhaupt kein Problem.

[Oliver S. (oliverso)]

Niklas G. schrieb:
> Nein. Compiler optimieren Funktionsaufrufe meist so, dass einmal zu
> Beginn alles benötigte allokiert wird.

Oder auch nicht.
Vielleicht hält der Compiler die auch gar nicht auf dem Stack, sondern 
nur in Registern. Da ist alles möglich.

Oliver

[Niklas G. (erlkoenig)]

Daher eben den Assembler-Code anschauen und sich das Raten ersparen.

[Christian J. (Firma: privat) (christianj)]

Niklas G. schrieb:
> Daher eben den Assembler-Code anschauen und sich das Raten ersparen.

Geht leider nicht in der Arduino IDE und selbst bei EmBitz ist das ein 
Problem, was nicht ohne Skripte lösbar ist :-(

Hätte ja sein können, dass die Klammern eben ein Abbauen des Stack Top 
verursachen.

Der Code soll so schonend wie möglich für den Speicher geschrieben 
werden.

/* Sende eine sms an das Ziel mit Text
  Mode FLASH = Text ist im Flash zu finden
       RAM   = Text wird im RAM übergeben
     
  AT+CMGS="[phone]"<CR>
  <CR><LF>><Space>     
     
*/
int SIM800_SendSMS(const char* text,int mode)
{
  char MsgToSend[160];
    
  /* MsgToSend = MsgStatusLine + MsgContent */
  
  /* Zeitstempel als Erstes vorbauen */
  if (flags.TimeStampIsValid ) {
    char signal[6];
    switch (CSQuality) {
      case 1: strcpy(signal,"-");   break;
      case 2: strcpy(signal,"+");    break;
      case 3: strcpy(signal,"++");  break;
      case 4: strcpy(signal,"+++");  break;
      default: strcpy(signal,"NA");  break;
    }

    /* Low Power oder Full Mode */
    char lowpower[6];
    if (flags.LowPowerMode)  strcpy(lowpower,"Eco");
    else           strcpy(lowpower,"Full");

    // /* LEDs ein oder aus */
    char leds[8];
     if (flags.ShowLED)    strcpy(leds,"LED");
     else           strcpy(leds,"NoLED");

    sprintf(MsgToSend,"%02u.%02u, %02u:%02u, %s, %s, %02u%%, %s\r\n", 
            timestamp.day, timestamp.month, timestamp.hour,
            timestamp.min, lowpower, leds, BattProzent,  signal);
  } else
    sprintf(MsgToSend,"--.--.--, --:--, %02u%%, ---\r\n",BattProzent);

  /* MsgContent existiert nur zwischen diesen {} */
  {
    /* SMS Text aus Progmem oder RAM lesen und verketten */
    char MsgContent[MAX_MSG_LENGTH+2];
    if (mode == FLASH)
      ReadFromFlash(MsgContent,text);
    else {
      if (strlen(text) > sizeof(MsgToSend)) {
        debugln(F("Text zu lang!"));
        return 0;
      }
      strcpy(MsgContent,text);
    }
    
    /* Hauptstring zusammen fügen */
    strcat(MsgToSend,MsgContent);
  }

  /* In MsgToSend steht jetzt, was gesendet werden soll, entweder ein
    String aus dem RAM oder ein indirekter Inhalt aus dem Flash */
  
  debugln(F("----------------- SMS ---------------------"));
  debugln(MsgToSend);
  debugln(F("-------------------------------------------"));

  /* Pending Alarme löschen, da False Alarms möglich */
  cli();
  flags.RadarAlarmHold = false;
  /* GSM bleibt an, alle Timer zurücksetzen */
  ResetAllWDTTimers();
  sei();
  
#ifdef SEND_SMS
  /* Empfangsbereitschaft des GSM prüfen */
  if (!SIM800_SendAT("AT\r\n","OK"))
    return 0;

  /* Text Mode sms */
  SIM800_SendAT("AT+CMGF=1\r\n","OK");
  
  /*AT Command und Zielnummer senden */
  char atcmd[40];
  strcpy(atcmd,"AT+CMGS=\"");
  strcat(atcmd,admin_number);
  strcat(atcmd,"\"\r\n");
  serialSIM800.print(atcmd);
  serialSIM800.flush();
  
  /* Warte bis "\r\n> " empfangen wird */
  SIM800_GetChars(atcmd);
  if (!(strstr(atcmd,"\r\n>")))
    return 0;
  
  /* Cntrl-Z als Schlusszeichen */
  serialSIM800.println(char(26));

  /*Bis zu 60s kann es dauern, bis mit CMGS:<zeichenzahl> geantwortet wird */
  while (1) {
    SIM800_GetChars(atcmd);
    if (strstr(atcmd,"GMGS")))
      return 1;
  }
#endif

  return 1;
}

[Niklas G. (erlkoenig)]

Christian J. schrieb:
> Geht leider nicht in der Arduino IDE

Kann man sehr wohl:
Beitrag "Re: Auf Arduino erstelltes Programm in C und Assembler anschauen"


Christian J. schrieb:
> Der Code soll so schonend wie möglich für den Speicher geschrieben
> werden.

Jaa.

Christian J. schrieb:
> char MsgToSend[160];

Christian J. schrieb:
> char signal[6];

Christian J. schrieb:
> char atcmd[40];

Du kannst auch berechnete kurze Strings oder einzelne Zeichen sofort 
absenden, statt sie erst komplett zwischenzuspeichern. Du kannst statt 
sprintf itoa und strcpy nutzen. Du kannst den Code auf einzelne 
Funktionen aufteilen, die nacheinander aufgerufen werden. Du kannst die 
Puffer ggf. global allokieren damit der Linker den Speicherverbrauch 
berechnet.

[Christian J. (Firma: privat) (christianj)]

Niklas G. schrieb:
> Du kannst den Code auf einzelne
> Funktionen aufteilen, die nacheinander aufgerufen werden.

Das habe ich schon gemacht. Eine Funktion berechnet die Strings, ein 
Flag, Die nächste nimmt das Flag und arbeitet werden, damit keine 
Verschachtelungen
entstehen. Und ja, das GSM Modul wartet solange bis alles da ist nach 
dem ">". Das liesse sich auch noch ausnutzen. Global ist die letzte 
Lösungh, wenn alles nicht geht. Ein Puffer für alles, sind ja ein paar 
Module, die sowas machen. Aber nie alle gleichzeitig.

Am liebsten wäre ja calloc (strlen(....))) gewesen aber das haute gar 
nicht hin, 2 Std für die Katz. Ich lese mir das nachher mal durch, 
scheint ne größere Baustelle zu sein. Beim stm32 habe ich mixed Code im 
Debug Fenster, da ist da sehr schön zu sehen und vor allem  per JTAG und 
nicht Bootloader...


Weisst du vielleicht auch warum man mit strstr nicht nach dem "+" 
Zeichen suchen kann? Er nimmt alles, nur das nicht.

[Christian J. (Firma: privat) (christianj)]

Naja, global weiss man wenigstens wo man liegt. Es wird knapp :-)

[Frank M. (ukw) (Moderator)]

Niklas G. schrieb:
> Du kannst auch berechnete kurze Strings oder einzelne Zeichen sofort
> absenden, statt sie erst komplett zwischenzuspeichern.

Er könnte zumindest Pointer verwenden. Es gibt keinen Grund dafür, die 
String-Konstanten erst in einen Buffer zu kopieren.

Beispiel:

const char * signal;

switch (CSQuality) {
      case 1: signal = "-";   break;
      case 2: signal = "+";    break;
      case 3: signal = "++";  break;
      case 4: signal = "+++";  break;
      default: signal = "NA";  break;
    }

> Du kannst statt sprintf itoa und strcpy nutzen.

Jepp. Das hier:

sprintf(MsgToSend,"%02u.%02u, %02u:%02u, %s, %s, %02u%%, %s\r\n", 
            timestamp.day, timestamp.month, timestamp.hour,
            timestamp.min, lowpower, leds, BattProzent,  signal);

könnte man so umschreiben.

Aber auch das hier:

  {
    /* SMS Text aus Progmem oder RAM lesen und verketten */
    char MsgContent[MAX_MSG_LENGTH+2];
    if (mode == FLASH)
      ReadFromFlash(MsgContent,text);
    else {
      if (strlen(text) > sizeof(MsgToSend)) {
        debugln(F("Text zu lang!"));
        return 0;
      }
      strcpy(MsgContent,text);
    }
    
    /* Hauptstring zusammen fügen */
    strcat(MsgToSend,MsgContent);
  }

schmeisst nur mit RAM so um sich. Da muss überhaupt nichts erst in ein 
Array kopiert werden.

Könnte man zum Beispiel so machen:

    /* SMS Text aus Progmem oder RAM lesen und verketten */

    if (mode == FLASH)
      ReadFromFlash(MsgToSend + strlen (MsgToSend),text);
    else {
      if (strlen(text) > sizeof(MsgToSend)) {
        debugln(F("Text zu lang!"));
        return 0;
      }
      strcat(MsgToSend,text);
    }

Den Kunstgriff mit den umschließenden Klammern kann man hier direkt 
vermeiden und man braucht kein Array. Zudem ist der Code kürzer.

Obwohl ich nicht ganz diese Prüfung auf die Länge verstehe. Der TO 
arbeitet hier mit strcat(), setzt also zwei Strings zusammen. Er prüft 
aber nur auf die Länge von text. Das reicht aber nicht. Es müsste 
heißen:

      if (strlen(text) + strlen(MsgToSend) >= sizeof(MsgToSend)) {

Beachte auch ">=" statt dem falschen ">".

Warum diese Prüfung überhaupt gar nicht gemacht wird, wenn der Text aus 
dem Flash kommt, ist mir auch schleierhaft.

[Christian J. (Firma: privat) (christianj)]

Frank M. schrieb:
> Er könnte zumindest Pointer verwenden. Es gibt keinen Grund dafür, die
> String-Konstanten erst in einen Buffer zu kopieren.

Das erzeugt genau 34 Bytes mehr "globale Variablen" und reduziert den 
Platz für lokale um 34 Bytes.

Aber ansonsten setze ich deine guten Ideen grad mal um.... man fängt ja 
erst an zu sparen, wenn es eng wird. Die Funktion ist ja erstmal da.

[Rolf M. (rmagnus)]

Christian J. schrieb:
> if (flags.ShowLED)    strcpy(leds,"LED");
>      else           strcpy(leds,"NoLED");

Dir ist klar, dass hier die Strings "LED" und "NoLED" beide erstmal vom 
Flash in den RAM kopiert und dann je nach Ergebnis der if-Abfrage einer 
davon per strcpy noch ein zweites mal im RAM kopiert wird?
Lies dich mal darüber ein, wie man Stringliterale im Flash benutzt und 
was strcpy_P macht.

[Christian J. (Firma: privat) (christianj)]

Rolf M. schrieb:
> Dir ist klar, dass hier der String "NoLED" erst vom Flash in den RAM
> kopiert und dann per strcpy noch ein zweites mal im RAM kopiert wird?

Ja... weiss ich .... irgendwo muss es ja liegen und das kann nur im 
Flash sein und bei der Init Sequenz wird es zugewiesen. Das sind 
ellenlange Sequenzen bei jeder Funktion am Anfang.

[Falk B. (falk)]

Christian J. schrieb:
> iklas G. schrieb:
>> Daher eben den Assembler-Code anschauen und sich das Raten ersparen.
>
> Geht leider nicht in der Arduino IDE und selbst bei EmBitz ist das ein
> Problem, was nicht ohne Skripte lösbar ist :-(
>
> Hätte ja sein können, dass die Klammern eben ein Abbauen des Stack Top
> verursachen.
>
> Der Code soll so schonend wie möglich für den Speicher geschrieben
> werden.

Dann sollte man sich mal mit dem Thema PROGMEM vertraut machen, beim 
Arduino ist das die Funktion F(). Damit werden konstante Strings in den 
Flash gepackt. Im jetzigen Zustand verschwenden all deine konstanten 
Strings viel RAM. Klingt komisch, ist aber so.

https://www.arduino.cc/reference/en/language/variables/utilities/progmem/

[Rolf M. (rmagnus)]

Christian J. schrieb:
> Rolf M. schrieb:
>> Dir ist klar, dass hier der String "NoLED" erst vom Flash in den RAM
>> kopiert und dann per strcpy noch ein zweites mal im RAM kopiert wird?
>
> Ja... weiss ich .... irgendwo muss es ja liegen und das kann nur im
> Flash sein und bei der Init Sequenz wird es zugewiesen.

Es reicht aber, wenn es einmal im Flash liegt und nicht zusätzlich dazu 
noch einmal im ja eh schon so knappen RAM.

[Christian J. (Firma: privat) (christianj)]

Naja, kenne ich schon, sämtliche Nachrichten liegen da auch und werden 
erst geholt, wenn sie gebraucht werden. Aber so ganz bin ich da noch 
nicht durch, geht vielleicht noch besser.

const char flash_sysdown[]      PROGMEM = "Shutdown!";
const char flash_alarm_off[]    PROGMEM = "Alarm ist jetzt AUS!";
const char flash_alarm_on[]     PROGMEM = "Alarm ist jetzt scharf!";
const char flash_lowpower_on[]  PROGMEM = "Lowpower Mode aktiv!";
const char flash_lowpower_off[] PROGMEM = "Fullpower Mode aktiv!";

....

/* Kopiert einen Text aus dem Flash ins Ram */
void ReadFromFlash(char* target, const char* source)
{
  for (uint16_t k = 0; k < strlen_P(source);k++) {
    *(target + k)    = pgm_read_byte_near(source + k);
    *(target + k + 1) = '\0';  /* NUL Terminieren */
  }
}

[Rufus Τ. F. (rufus) (Moderator)]

Christian J. schrieb:
> Aber so ganz bin ich da noch nicht durch, geht vielleicht noch besser.

Statt die Strings aus dem Flash ins Ram zu kopieren, um sie dann 
irgendwo hin auszugeben, könntest Du auch eine Variante Deiner 
Ausgabefunktion bauen, der direkt ein String aus dem Flash übergeben 
wird.

[Christian J. (Firma: privat) (christianj)]

Frank M. schrieb:
> if (strlen(text) + strlen(MsgToSend) >= sizeof(MsgToSend)) {

Danke für den Hinweis auf den Fehler!

[Rolf M. (rmagnus)]

Probier mal statt:

strcpy(leds,"NoLED");

dass hier:

strcpy_P(leds,PSTR("NoLED"));

PS: Oder was Rufus schreibt.

[Christian J. (Firma: privat) (christianj)]

Rufus Τ. F. schrieb:
> Statt die Strings aus dem Flash ins Ram zu kopieren, um sie dann
> irgendwo hin auszugeben, könntest Du auch eine Variante Deiner
> Ausgabefunktion bauen, der direkt ein String aus dem Flash übergeben
> wird.

Das Schleudern fing erst an als ich um meine Bastelei aufzubohren anfing 
Flash Strings und sprintf dynamische Strings zu sammen zu bauen. Ab da 
wurde es immer unübersichtlicher und ich habe diesen Monat bereits 50 
Euro nur an sms kosten verbraten auf der Pay Card, weil das kaum 
simulierbar ist. Wird Zeit ne flat zu bestellen.....

[Christian J. (Firma: privat) (christianj)]

strcpy_P(leds,PSTR("NoLED"));

---->

Der Sketch verwendet 15114 Bytes (49%) des Programmspeicherplatzes. Das 
Maximum sind 30720 Bytes. Globale Variablen verwenden 1397 Bytes (68%) 
des dynamischen Speichers, 651 Bytes für lokale Variablen verbleiben. 
Das Maximum sind 2048 Bytes.

vs

Der Sketch verwendet 15096 Bytes (49%) des Programmspeicherplatzes. Das 
Maximum sind 30720 Bytes.
Globale Variablen verwenden 1403 Bytes (68%) des dynamischen Speichers, 
645 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

Spart also die 6 Bytes RAM ein!

Junge, Junge, ihr habts echt drauf.... !

[(prx) A. K. (prx)]

Christian J. schrieb:
> Junge, Junge, ihr habts echt drauf.... !

Ungefähr so? "Jungs und Mädels, hier habt ihr ein paar Zeilen meines 
Programms. Es funktioniert nicht, weil das Grundkonzept im Umgang mit 
Speicher von A bin Z vergurkt ist und jede Korrektur wie beim Mikado 
endet. Löst mein Problem, aber dalli, sonst setzt es Spott."

Wenn man merkt, dass das Pferd tot ist, sollte man absteigen (*). 
Passiert öfter, dass man nochmal ans Reissbrett muss.

*: Für Freunde der Bürokratie, eine nette Sammlung alternativer 
Lösungsvorschläge: http://www.roland-schaefer.de/totespferd.htm

[Christian J. (Firma: privat) (christianj)]

A. K. schrieb:
> Löst mein Problem, aber dalli, sonst setzt es Spott."

Ich befasse mich seit 4 Wochen mit Arduino.... vorher habe ich damit 
nichts zu tun gehabt. Das nur dazu.

[(prx) A. K. (prx)]

Christian J. schrieb:
> Ich befasse mich seit 4 Wochen mit Arduino.... vorher habe ich damit
> nichts zu tun gehabt. Das nur dazu.

Kein Problem damit. Aber ob es zur Lösung beträgt, in dieser Lage die 
bisherigen Hilfesteller zu verspotten?

Mein Tipp mit dem Reissbrett war ernst gemeint. So lange du kein Konzept 
zustande bringst, das radikal RAM einspart, wird das bestenfalls 
Flickwerk.

[Frank M. (ukw) (Moderator)]

Christian J. schrieb:
> Spart also die 6 Bytes RAM ein!

Du hast ja nicht alles umgesetzt, ich habe Dir beschrieben, wie Du 
dieses hier komplett einsparen kannst:

char MsgContent[MAX_MSG_LENGTH+2];

Das sind weitaus mehr als 6 Bytes, die erst mal auf dem Stack angelegt 
werden wollen!

Desweiteren kannst Du auch dieses hier

 char MsgToSend[160];

komplett einsparen, wenn Du die Strings und numerischen Werte sofort 
rauspustest, statt sie erstmal in diesem Array zu sammeln.

Das sind schon mal 160 + 162 = 322 Bytes weniger auf dem Stack.

> Junge, Junge, ihr habts echt drauf.... !

Setze doch erstmal alles um und präsentiere Deinen korrigierten Code, 
bevor Du ein Urteil fällst.

[(prx) A. K. (prx)]

Vielleicht nützt das was, vielleicht nicht: Seit vielen Jahren gibts im 
AVR Compiler auch managed pointer, ich weiss nur nicht mehr wie die da 
heissen. Sind Pointer, die auf ROM und RAM zeigen können und zur 
Laufzeit anhand des Wertes entsprechend drauf zugreifen. Etwas 
langsamer, etwas mehr Code, aber weniger nervend.

[Frank M. (ukw) (Moderator)]

Auch das hier:

  char atcmd[40];
  strcpy(atcmd,"AT+CMGS=\"");
  strcat(atcmd,admin_number);
  strcat(atcmd,"\"\r\n");
  serialSIM800.print(atcmd);
  serialSIM800.flush();

kann man so schreiben:

  serialSIM800.print("AT+CMGS=\"");
  serialSIM800.print(admin_number);
  serialSIM800.print("\"\r\n");
  serialSIM800.flush();

Und schon wieder 40 Bytes eingespart.

Und komm mir jetzt nicht mit dem Output vom Linke/Compiler. Ich glaube 
nicht, dass der Arrays, die auf dem Stack liegen, überhaupt mitzählt.

Da gibt es noch jede Menge mehr dieser Codeoptimierungen, die gemacht 
werden könnten. Ich werde Dir aber jetzt nicht alle Stellen vorlesen. Du 
musst obiges nur auf die anderen Stellen genauso übertragen.

[Frank M. (ukw) (Moderator)]

Christian J. schrieb:
> strcpy_P(leds,PSTR("NoLED"));
>
> ---->
>
> Der Sketch verwendet 15114 Bytes (49%) des Programmspeicherplatzes.

Falscher Ansatz, statt die Strings in lowpower[], leds[] zu sammeln, 
kannst Du auch hier direkt die Strings ausgeben.

[Oliver S. (oliverso)]

A. K. schrieb:
> Vielleicht nützt das was, vielleicht nicht: Seit vielen Jahren
> gibts im
> AVR Compiler auch managed pointer, ich weiss nur nicht mehr wie die da
> heissen. Sind Pointer, die auf ROM und RAM zeigen können und zur
> Laufzeit anhand des Wertes entsprechend drauf zugreifen. Etwas
> langsamer, etwas mehr Code, aber weniger nervend.

__memx

Oliver

[Christian J. (Firma: privat) (christianj)]

Zwischenmeldung,

aktuell sind über 300 Bytes eingespart worden an RAM durch Die 
Ratschläge oben. dauert aber alles etwas...... da ist viel schief 
gelaufen.....

Ich glaube  nicht, dass der Arrays, die auf dem Stack liegen, überhaupt 
mitzählt.

Nein, tut er nicht.... daher ja die Abstürze.....

[Rolf M. (rmagnus)]

Christian J. schrieb:
> Spart also die 6 Bytes RAM ein!

Du musst das natürlich nicht nur mit einem String machen, sondern mit 
allen!

> Junge, Junge, ihr habts echt drauf.... !

Findest du es ok, andere für ihre Hilfe auch noch blöd anzumachen, statt 
zu versuchen, es zu verstehen?

Christian J. schrieb:
> Ich glaube  nicht, dass der Arrays, die auf dem Stack liegen, überhaupt
> mitzählt.
>
> Nein, tut er nicht.... daher ja die Abstürze.....

Natürlich nicht. Der Stack ist keine globale Variable. Die Arrays 
existieren zur Compilezeit noch nicht.

[Christian J. (Firma: privat) (christianj)]

Findest du es ok, andere für ihre Hilfe auch noch blöd anzumachen, statt
zu versuchen, es zu verstehen?

Es scheint unmöglich zu sein, sich hier normal zu unterhalten, ohne dass 
früher oder später irgendjemand kommt, der irgendwas falsch auffasst und 
dann in den persönlichen Angriff übergeht. Das gilt auch für Mods. Das 
war ein Lob, aber egal.

[Rolf M. (rmagnus)]

Christian J. schrieb:
> Das gilt auch für Mods. Das war ein Lob, aber egal.

Der letzte Satz liest sich halt mal überhaupt nicht so, mit dem "Junge, 
Junge" und den drei Punkten. Aber wenn's nicht bös gemeint war, dann ist 
ja alles gut.

[Christian J. (Firma: privat) (christianj)]

Hier haut das nicht hin mit dem Makro, gibt nur Müll auf der 
seriellen.... nehme ich das PSTR weg ist alles wieder gut.

  /* Setze 9600 baud */
  SIM800_SendAT(PSTR("AT+IPR=9600\r\n"),"OK");
  /* Meldungen abschalten */
  SIM800_SendAT(PSTR("AT+CCWA=0\r\n"),"OK");
  /* Echo abschalten */
  SIM800_SendAT(PSTR("ATE0\r\n"),"OK");

da ich gut 100 dieser Sequenzen haben sind das die größten Ram Fresser.

[Rolf M. (rmagnus)]

Christian J. schrieb:
> Hier haut das nicht hin mit dem Makro, gibt nur Müll auf der
> seriellen.... nehme ich das PSTR weg ist alles wieder gut.

Du darfst das PSTR nur mit Funktionen verwenden, die den String auch im 
Flash erwarten. Deshalb musst du ja auch strcpy_P statt strcpy 
verwenden.

[Christian J. (Firma: privat) (christianj)]

Rolf M. schrieb:
> Du darfst das PSTR nur mit Funktionen verwenden, die den String auch im
> Flash erwarten. Deshalb musst du ja auch strcpy_P statt strcpy
> verwenden.

Ok, danke! Dann werde ich mir dafür mal ein Makro schreiben oder es 
sonst wie kapseln..... mir qualmt die Birne aber jetzt, erstmal vor die 
Türe gehen.....

SIM800_SendAT("AT+CSCLK=0\r\n","OK");

Denke mal eine Kapselung wäre das beste, das sind über 120 wie ich grad 
gezählt habe von diesen Aufrufen...

[Christian J. (Firma: privat) (christianj)]

Sag mal Meister,

baue ich jetzt kompletten Blödsinn? Bin schon etwas erschöpft aber noch 
nicht fertig eben.... möchte diese konstanten Arrays weg haben und daher 
doch wieder auf malloc. Gibt zwei Sorten von SendAT, jene die konstant 
sind aber auch welche mit Parameter, die errehcnet werden. daher zwei 
Routinen jetzt. Läuft bisher....

int SIM800_SendFlashAT(const char* atc,const char* token)
{
  char res[128];
  char *kopie;
  
  /* Den Flash String ins Ram holen */
  kopie = (char*)malloc(strlen_P(atc)+1 * sizeof(char);
  strcpy_P(kopie,atc); 
  
  /* SIM800 Serial Buffer leeren */
  while (serialSIM800.available())
    serialSIM800.read();

  /* Sende AT Command */    
  serialSIM800.print(kopie);
  serialSIM800.flush();
  free(kopie);
  
  SIM800_GetChars(res);

  //debug(atc);
  // debug(res);

   if (strstr(res, token))    /* OK pruefen */
    return 1;
    
   return 0;
}

[Niklas G. (erlkoenig)]

Wie gesagt macht "malloc" verbrauchstechnisch alles schlimmer (und 
langsamer). Das solltest du komplett vermeiden! Das Problem an dieser 
Stelle ist ja nur, dass Arduino.print einen RAM-String braucht. Es soll 
aber angeblich auch einfach so gehen:

serialSIM800.print(F(atc));

Erspart die Kopie komplett.

sizeof(char) ist übrigens immer 1, denn die Einheit, in welcher sizeof 
die Größe angibt, ist in Vielfachen von char. Und da char immer genau 1 
char groß ist, ist sizeof(char)=1. Gilt analog auf für signed char und 
unsigned char.

[Christian J. (Firma: privat) (christianj)]

Ok, das mit dem char weiss ich, ich schreibe auch if (a==true) statt nur 
das a, damit es leslicher ist.

Jut, so langsam rieselt der Kalk und morgen gehts weiter im Text, heute 
ist Ende Gelände, Festplatte voll nach 7h vor der Kiste.

Danke nochmal an alle für die wertvolle Hilfe!

[Niklas G. (erlkoenig)]

Christian J. schrieb:
> Ok, das mit dem char weiss ich, ich schreibe auch if (a==true) statt nur
> das a, damit es leslicher ist.

Jeder C++-Programmierer weiß aber dass das so ist, stolpert über den 
unnötig umständlichen Code und fragt sich ob da noch mehr 
"falsch"/unnötig ist...

[Christian J. (Firma: privat) (christianj)]

Niklas G. schrieb:
> serialSIM800.print(F(atc));

Lässt sich nicht kompilieren.... angeblich ist macro F dafür nicht 
geeignet. Hmmm

K:\ArduinoSoftware\radar_gsm_wachhund\simctrl.ino:260:21: note: in 
expansion of macro 'F'

  serialSIM800.print(F(atc));

74: error: array must be initialized with a brace-enclosed initializer

Das aber schon:

serialSIM800.print(F("Hello"));

[Niklas G. (erlkoenig)]

Hm, versuch's mal so:

serialSIM800.print(reinterpret_cast<const __FlashStringHelper *> (atc));

Kenne mich mit Arduino auch nicht so gut aus. Das sind so die Gründe 
warum ich ARM bevorzuge :-)

[Christian J. (Firma: privat) (christianj)]

Niklas G. schrieb:
> Kenne mich mit Arduino auch nicht so gut aus. Das sind so die Gründe
> warum ich ARM bevorzuge :-)

Ach.... das ist aber eine Neuigkeit... :-)))) Ich prügel mich damit auch 
nur herum, weil der F103 auf dem Bluepill Board zu gross ist....

[Niklas G. (erlkoenig)]

Christian J. schrieb:
> Ich prügel mich damit auch
> nur herum, weil der F103 auf dem Bluepill Board zu gross ist....

Wie, zu groß? Die gibt's in allen Größen...

[Christian J. (Firma: privat) (christianj)]

Es kompiliert mit dem cast.... und spielt auch!

[Christian J. (Firma: privat) (christianj)]

Apropos ARM, mit dem 407 habe ich vor 2 Jahren mal was gemacht... plus 3 
weitere Displayanzeigen im Haus... , alles DIY :-) Nur dem EEPROM, da 
hat nie hingenauen mit der eingebauten Technik. Jetzt Software Ic2. Hab 
da Tage mit verbracht :-(

[Niklas G. (erlkoenig)]

Christian J. schrieb:
> Jetzt Software Ic2.

Ja das Hardware-I²C der alten STM32 (inkl. F407) ist ziemlich vermurkst. 
EEPROM braucht man doch eigentlich nicht, man kann auch den internen 
Flash beschreiben, man muss sich aber eine Art Wear-Leveling basteln. Da 
gibt's aber sogar eine Bibliothek von ST für

[Peter D. (peda)]

Christian J. schrieb:
> Versuche mit malloc und calloc waren fruchtlos

Weil damit das Problem erst recht verschlimmert wird.
Ohne malloc wachsen beim AVR-GCC die Variablen von unten nach oben und 
der Stack von oben nach unten. Wenn es dann kracht, dann geht es 
garantiert nicht oder man war zu verschwenderisch mit Arraygrößen.

Mit malloc hat man dagegen immer die Arschkarte gezogen, denn es muß 
dafür extra Speicher reserviert werden. Das ist dann quasi, wie eine 
Festplatte partitionieren. Wie man es auch macht, man macht es falsch.
Malloc geht nur dann gut, wenn viel mehr als reichlich RAM verfügbar 
ist.

Auf nem MC darf man RAM nicht mit der Schöpfkelle austeilen. Man sollte 
ungefähr abschätzen, wieviel RAM ein Array auch wirklich benötigt.

Was man sich auf MCs unbedingt verkneifen sollte, sind unnütze 
Umkopierorgien. Viele Variablen braucht man nach der Verarbeitung eh 
nicht mehr, d.h. Umkopieren hat keinerlei Nutzen.

[Christian J. (Firma: privat) (christianj)]

Niklas G. schrieb:
> Ja das Hardware-I²C der alten STM32 (inkl. F407) ist ziemlich vermurkst.
> EEPROM braucht man doch eigentlich nicht, man kann auch den internen
> Flash beschreiben, man muss sich aber eine Art Wear-Leveling basteln. Da
> gibt's aber sogar eine Bibliothek von ST für

Sicher, mag sein aber damit wollte ich mich nicht befassen. Habe das 
BKPRAM benutzt und ne Kopfzelle drauf gelötet auf das Board. Hängt seit 
2 Jahren an der Wand und läuft und läuft, nur die Sommerzeit Umstellung 
habe ich nicht hingekriegt, rechne mit Unixtime und UTC, da das 
einfacher ist.

Ich habe hier mal die für den 103 angehängt, die läuft aber, hat ewig 
gedauert. Nur so alle 3-4 Wochen hängt es sich mal auf. Strom weg und 
neu starten und alles wieder gut.

[Frank M. (ukw) (Moderator)]

Christian J. schrieb:
> for (uint16_t k = 0; k < strlen_P(source);k++) {
>     *(target + k)    = pgm_read_byte_near(source + k);
>     *(target + k + 1) = '\0';  /* NUL Terminieren */
>   }

Terminieren muss man nur einmal, nicht nach jedem Zeichen. Zum zweiten 
kann die Offset-Berechnung mit k mehr kosten als ein simples 
Incrementieren des Pointers. Außerdem wird hier für jeden(!) 
Schleifendurchlauf die String-Länge von source ermittel. Das kostet 
unnötige CPU-Zeit - abgesehen von mehr Code durch die Offset-Berechnung.

Dieses sollte schneller gehen und auch weniger Code kosten:

  unsigned char ch;

  while ((ch = pgm_read_byte_near(source)) != '\0')
  {
    *target++ = ch;
    source++;
  }

  *target = '\0';

Warum Du dafür aber eine eigene Funktion schreibst, ist mir 
schleierhaft. Letztendlich macht diese Funktion nichts anderes als 
strcpy_P().

[Christian J. (Firma: privat) (christianj)]

Peter D. schrieb:
> Mit malloc hat man dagegen immer die Arschkarte gezogen, denn es muß
> dafür extra Speicher reserviert werden.

Den kenne ich, wenn ich das Linker File sehe aber das kenne ich eben 
nicht. Ich arbeite oft damit auf dem ARM, tut es auch alles. Und const 
... befördert Strings eben auch ins Flash. Was ich nicht weiss ob der 
Initilizer der startup sie wieder ins Ram holt.

[Christian J. (Firma: privat) (christianj)]

Frank M. schrieb:
> Warum Du dafür aber eine eigene Funktion schreibst, ist mir
> schleierhaft. Letztendlich macht diese Funktion nichts anderes als
> strcpy_P().

Ist aus dem Arduino Forum geklaut...... wenn es im Internet steht muss 
es ja richtig sein :-)

[Frank M. (ukw) (Moderator)]

Christian J. schrieb:
> Ist aus dem Arduino Forum geklaut......

Die Code-Qualität bestätigt das übliche Vorurteil, das den 
Arduino-Programmiern anhaftet. Und dann wird dieser Mist auch noch 
ungesehen kopiert.

Wenn schon klauen, dann auch verstehen. Da hat man wesentlich mehr von 
;-)

[Niklas G. (erlkoenig)]

Christian J. schrieb:
> Den kenne ich, wenn ich das Linker File sehe aber das kenne ich eben
> nicht.

Du siehst nur, wie groß der Heap insgesamt ist. Nicht, ob unter den 
unzähligen möglichen Programmabläufen jemals der Heap überlaufen kann.
Das Linker-Script ist irgendwo in der Arduino-Installation zu finden... 
Das sieht gut aus: arduino-1.8.8/hardware/tools/avr/avr/lib/ldscripts

Christian J. schrieb:
> Ich arbeite oft damit auf dem ARM, tut es auch alles.
Bis es dann halt irgendwann nicht mehr tut...

Christian J. schrieb:
> . Was ich nicht weiss ob der
> Initilizer der startup sie wieder ins Ram holt.
Nein. Zeiger auf String-Literale zeigen auf ARM direkt ins Flash.

[Christian J. (Firma: privat) (christianj)]

Niklas G. schrieb:
> ein. Zeiger auf String-Literale zeigen auf ARM direkt ins Flash.

Führt zwar ein wenig weg aber darum schreibe ich die Dinge gern selbst, 
damit ich auch weis was passiert. Bei diesem Arduino weiss ich das eben 
nicht! Beim DIY Z80 mit dem sdcc habe ich das gemacht, wo der Heap hin 
gehört, wo der Stack und wie sie sich nicht in die Quere kommen. Die 
ganze Startup selbst geschrieben, ein gewisser Leo das aufwendige Linker 
Script. Und da tut es das auch.

Aber ansonsten ist Arduino ein tolles System, gar keine Frage.

    ;///////////////////////////////////////////////////////////
    ; Anordung der Segmente fuer den Linker, ab hier nur relative
    ; Adressen

      .area  _CODE
      .area  _INITIALIZER
      .area  _HOME
      .area  _GSINIT
      .area  _GSFINAL
      .area  _DATA
      .area  _INITIALIZED
      .area  _BSEG
      .area  _BSS
      .area  _HEAP

; ---  Defintion der Heap Groesse
__sdcc_heap_start::
      .ds heap_size

      .area _HEAP_END
__sdcc_heap_end::
      .ds 1

[Niklas G. (erlkoenig)]

Christian J. schrieb:
> damit ich auch weis was passiert

Der Sinn von Arduino ist, dass man sich damit eben nicht 
beschäftigen muss. Es steht dir frei, das Teil direkt mit AVR-GCC 
und/oder Atmel Studio zu programmieren...

[Christian J. (Firma: privat) (christianj)]

Frank M. schrieb:
> Die Code-Qualität bestätigt das übliche Vorurteil, das den
> Arduino-Programmiern anhaftet. Und dann wird dieser Mist auch noch
> ungesehen kopiert.

Frank.... ich (50, Jg. 1968) gehöre in meinem Team zu den besten 
Programmierern. Nicht für CPUs (!), aber für Prüfautomaten, solche 
großen Schränke für den Endtest bei automatischen fertigungslinien. C# 
benutzen wir dafür mit Visual Studio und das HP Bus API für Oszis, 
Relais Matrizzen, Voltmeter usw. Die Stationen laden sich übers 
Firmennetz die Software, je nachdem was grad geprüft wird. COBOTS, 
fahren bald auf kleinen Wagen von allein an die Arbeitsplätze, weichen 
den Leuten aus und werkeln dann, rüsten ihre Werkzeuge selbst. Industrie 
4.0 ist das Thema.

Trotzdem kommen auch die Quereinsteiger zu Ergebnissen, die grad von den 
Schulen kommen, mit Arduino angefangen haben und die Summe aller Leute 
(34 sind wir) im Team behebt auch die Fehler, so dass das Ganze 
funktioniert. Einzel-Spitzenleistungen sind weniger gefragt. Du bist 
"spitze", wenn Du andere zum Erfolg anleiten und motivieren kannst.

[Toll ein anderer machts (Gast)]

Christian J. schrieb:
> Frank.... ich (50, Jg. 1968) gehöre in meinem Team zu den besten
> Programmierern.

Dir ist hoffentlich klar, dass das nichts über dich aussagt.
Vielleicht ist auch euer Team sehr schlecht.

[Christian J. (Firma: privat) (christianj)]

Toll ein anderer machts schrieb:
> Dir ist hoffentlich klar, dass das nichts über dich aussagt.
> Vielleicht ist auch euer Team sehr schlecht.

Sicher, darum fliegst du auch sicher mit Airbus Flugzeugen in den Urlaub 
und die stürzen nicht ab, weil wir die technische  Ausstattung 
fehlerhaft gebaut haben..... aber vielleicht ist ja eine Tupolew besser.

[Ich wer sonst (Gast)]

Christian J. schrieb:
> Apropos ARM, mit dem 407 habe ich vor 2 Jahren mal was gemacht... plus 3
> weitere Displayanzeigen im Haus... , alles DIY :-) Nur dem EEPROM, da
> hat nie hingenauen mit der eingebauten Technik. Jetzt Software Ic2. Hab
> da Tage mit verbracht :-(

Mit welcher Lib oder GUI-Generator hast du den das Bund-Display zum 
laufen gebracht?

[Toll ein anderer machts (Gast)]

Christian J. schrieb:
> Sicher, darum fliegst du auch sicher mit Airbus Flugzeugen in den Urlaub
> und die stürzen nicht ab, weil wir die technische  Ausstattung
> fehlerhaft gebaut haben.

Ich glaube du überschätzt dich und deine Arbeit etwas.
Deine Antwort bestätigt das wieder einmal.

[Christian J. (Firma: privat) (christianj)]

Ich wer sonst schrieb:
> Mit welcher Lib oder GUI-Generator hast du den das Bund-Display zum
> laufen gebracht?

ILI9341 SPi Version für STM32F103, beim F407 sind die Prescaler anders 
zu setzen und der APB ist auch ein anderer für die SPI.

[Christian J. (Firma: privat) (christianj)]

Moin,

die obigen Sachen haben insgesa,t fast 400 Bytes an Eimsparungen 
gebract, also fast 1/3 weniger Ram als vorher!

Mit Strings tue ich mich noch etwas schwer, auch mangels Beispielen. 
Meine Lösung muss ja nicht die sein, die "optimal" ist.

Vorr: Der User - also ich erstmal - macht keine Eingabefehler! Die alle 
abzufangen dürfte erstmal jedes Maß sprengen. Kurz muss es sein.

Zeitfenster: 8.45 bis 17.30 Uhr
Eingabe: window<spc>08,45,17,30 oder
         window<spc>08.45,17.30

(<spc> = Leerzeichen)

ginge auch, da die Trenner nicht geprüft werden, Führende Null ist auch 
Pflicht, sonst murks....

Gibt es auch elegantere Lösungen? Das unten sind immerhin rund 240 Bytes 
Code ein paar Zahlen aus einem String zu ernten...

/* Start, Ende Uhrzeit */
typedef struct {
  byte hour;
  byte min;
} zeit_t;

int ParseWindow(char* buf, zeit_t* Start, zeit_t* End)
{  /*  window_08,45,17,30 */

  char* p = buf;
  
  /* Check cmd */
  if (!(strstr_P(buf,PSTR("window"))))
    return 0;

  /* Suche erstes Leerzeichen */
  p = strstr(buf," ");
  p++;
  Start->hour = ((p[0]-'0') * 10) + (p[1]-'0');
  Start->min  = ((p[3]-'0') * 10) + (p[4]-'0');
  End->hour   = ((p[6]-'0') * 10) + (p[7]-'0');
  End->min    = ((p[9]-'0') * 10) + (p[10]-'0');
  
  return 1;
}

[Rufus Τ. F. (rufus) (Moderator)]

Du könntest eine Funktion bauen, die eine bis mehrere Zahlen "schluckt" 
(bis ein Trennzeichen auftritt, das keine Zahl ist), und sowohl den 
numerischen Wert als auch die Anzahl gelesener Zeichen zurückgibt.

Die Funktion besteht aus einer Schleife, die bei Auftreten einer Ziffer 
den vorherigen Wert mit zehn multipliziert und die Ziffer addiert, und 
abbricht, sobald das aktuelle Zeichen keine Ziffer mehr ist.

Damit bist Du die führenden Nullen los (und würdest aber auch den Fall 
versehentlicher mehrfacher führender Nullen "überleben").

Diese Funktion rufst Du viermal nacheinander auf, begonnen mit Deinem 
Zeichen nach dem ersten Leerzeichen (Hinweis: strchr dürfte hier 
effektiver sein als strstr).

[HyperMario (Gast)]

Christian J. schrieb:
> Gibt es auch elegantere Lösungen? Das unten sind immerhin rund 240 Bytes
> Code ein paar Zahlen aus einem String zu ernten...

Evtl. eine andere Menüführung? Freie Eingaben weglassen und nur mit 
Cursor und +/- arbeiten. Dann entfällt das parsen, Fehleingaben und 
Vertipper sind nicht möglich und die Werte die der Anwender sieht sind 
nur nur Kopien vorhandener Variablen.

[Dirk B. (dirkb2)]

Christian J. schrieb:
> ich schreibe auch if (a==true)
> statt nur
> das a, damit es leslicher ist.

Das sind dann aber unterschiedliche Aussagen.

(a!=false) wäre der Ersatz

[ho ho ho (Gast)]

Dirk B. schrieb:
>> ich schreibe auch if (a==true)
>> statt nur
>> das a, damit es leslicher ist.
>
> Das sind dann aber unterschiedliche Aussagen.
>
> (a!=false) wäre der Ersatz

Was wieder beweist, wie sch... "C" ist. Sorry, muss sein, auch zu x-mas

[A. S. (achs)]

Dirk B. schrieb:
> Christian J. schrieb:
>> ich schreibe auch if (a==true) statt nur
>> das a, damit es leslicher ist.
>
> Das sind dann aber unterschiedliche Aussagen.
>
> (a!=false) wäre der Ersatz

Einmal das.

Zum anderen haben schon die Alten Griechen erkannt, wie blöd == true 
ist. Man kann das nämlich endlos weiter treiben zur Sicherheit und 
Klarheit,

If ((a==true)==true) {

[IstJaNochWeihnachten (Gast)]

Hallo,
das hier hat nix mit dem Thema zu tun, aber ich finde
den Link oben von A.K. (tote Pferd) super klasse!!!
und so real ;-)
Guten Rutsch Euch allen.

[Christian J. (Firma: privat) (christianj)]

Rufus Τ. F. schrieb:
> Diese Funktion rufst Du viermal nacheinander auf, begonnen mit Deinem
> Zeichen nach dem ersten Leerzeichen (Hinweis: strchr dürfte hier
> effektiver sein als strstr).

Naja, mit strtol klappt es auch, da fallen die führenden Nullen auch weg 
und wenn nichts bei raus kommt ist es 0. Die Tests sind 
vielversprechend, jetzt mal in Ruhe optimieren aus dem Test Bett heraus 
ganz am Anfang des Programms.

Und bei einer sms kann man natürlich keine Führung einbauen.... der 
ganze Spass wird eh langsam teuer, jeder versuch kostet 9 cent......

Bei der Portierung auf den Cortex wird es eh lustig mit den ganzen 
Arduino speziellen Befehlen.....

 const char* cmd = "window";
 char* p;

 /* Schlüsselwort suchen */
 debugln(F("Suche window"));
 if (!(p = strstr(satz,cmd)))
    return;
  p = p + strlen(cmd);
  
  char *ptr;
  unsigned long zahl;
  zahl = strtol(p,&ptr,10);
  debugln(zahl);
  p = ptr + 1;

[Christian J. (Firma: privat) (christianj)]

Nochmal zum Thema "malloc":

Ich verstehe nicht wieso man sich damit Probleme rein holen soll. Ich 
habe einiges ausprobiert und erstmal festgestellt, dass der 328P AVR es 
erlaubt

200 "belegt" Einträge zu machen
und 860 Bytes Heap zur Verfügung stellt, von 2k.

Eine Fragmentierung kann es nicht geben, wenn man nur 1 Zeiger verwendet 
und diesen auch sofort wieder frei gibt.  Auch niccht bei 2,3 und mehr, 
solange diese konsequent frei gegeben werden, bevor die Routine 
verlassen wird.

Der Heap liegt ja unter dem Stack, d.h. der Stack kann rein wachsen, 
wenn man ihn zu gross werden lässt.

Es funktioniert jedenfalls.... mit kleinen Größen, also derzeit maxiaml 
80 Bytes.

Ich finde diese dynamische Sache nämlich eigentlich prima, früher oft 
benutzt bei binären Bäumen in Pascal und C.

Gruss,
Christian

[Rolf M. (rmagnus)]

Christian J. schrieb:
> Nochmal zum Thema "malloc":
>
> Ich verstehe nicht wieso man sich damit Probleme rein holen soll. Ich
> habe einiges ausprobiert und erstmal festgestellt, dass der 328P AVR es
> erlaubt
>
> 200 "belegt" Einträge zu machen
> und 860 Bytes Heap zur Verfügung stellt, von 2k.
>
> Eine Fragmentierung kann es nicht geben, wenn man nur 1 Zeiger verwendet
> und diesen auch sofort wieder frei gibt.  Auch niccht bei 2,3 und mehr,
> solange diese konsequent frei gegeben werden, bevor die Routine
> verlassen wird.

Aber wozu dann malloc? Das braucht zusätzliche Rechenzeit, es produziert 
Overhead für seine interne Verwaltung, und man braucht letztendlich auch 
den zusätzlichen Pointer für den Zugriff. Weniger Speicher als wenn die 
gleichen Daten auf dem Stack liegen würden, braucht es nicht.

> Es stellt sich nur noch die Frage, wo der Heap sich denn so rum lümmelt?
> Vermutlich unter dem Stack, d.h. der Stack kann rein wachsen, wenn man
> ihn zu gross werden lässt.

Ja.

[Christian J. (Firma: privat) (christianj)]

Rolf M. schrieb:
> Aber wozu dann malloc?

Weil es das gibt? ... ähm.... nee, natürlich nicht. Ich vermute eher das 
das nur Sinn macht wenn man echt komplexe Datenbäume hat und viel 
Speicher. Aber auf einem AVR mit 2kB..... naja.. der baum würde sehr 
schnell über den kleinen Blumentopf hinaus wachsen wollen.

[Peter D. (peda)]

Christian J. schrieb:
> Ich verstehe nicht wieso man sich damit Probleme rein holen soll.

Nun, man muß zur Compilezeit festlegen, wieviel RAM darf Malloc und 
wieviel der Stack belegen. D.h. es kracht, sobald einer von beiden 
ausgeht, obwohl noch RAM übrig sein kann.

Christian J. schrieb:
> Auch niccht bei 2,3 und mehr,
> solange diese konsequent frei gegeben werden, bevor die Routine
> verlassen wird.

Dann nimmt man aber kein Malloc, sondern einfach lokale Variablen.
Malloc braucht man nur, wenn verschiedene Tasks die Variablen anlegen 
und freigeben sollen. Z.B. der Ethernetinterrupt speichert ein 
Datenpaket und die Mainloop parst es und gibt es wieder frei.

[avr (Gast)]

Hier ein Vorschlag, bei dem alles über den Command-String gesteuert 
wird. Sehr flexibel ist das nicht, aber müsste recht klein sein. In 
Assembler sollten es um die 60 Byte sein, bin gespannt was der Compiler 
draus macht.

// Aufruf
Parse("window 18.45,19.53","window \xC0\x80.\xC1\x81,\xC2\x82.\xC3\x83", buf);

int Parse(char* input, const char* command, uint8_t* buf)
{
  uint8_t cmd_ch, in_ch;
  do
  {
    in_ch = *input++;
    cmd_ch = *command++;
 
    if(cmd_ch & 0x80)
    {
      in_ch -= '0';
      if(cmd_ch & 0x40)
        in_ch *= 10;
      buf[cmd_ch & 0x3F] += in_ch;
    }
    else if(in_ch != cmd_ch)
      return 0;
  }
  while(in_ch * cmd_ch);
  return 1;
}

[Christian J. (Firma: privat) (christianj)]

Naja, das sieht schon elegant aus. Meine Lösung ist eher so wie man sie 
sich zuerst überlegt, ohne mit Bits zu basteln. Aber ich nehme den 
gesamten Header mit, den so eine sms hat. Hat den Vorteil, dass die 
führende Null egal ist. strtol verbraucht aber 1,2kb extra. p = ptr + 1; 
schiebt den Zeiger über das Komma weg.

Was ist das?

while(in_ch * cmd_ch);

int ParseWindow(char* buf, zeit_t* Start, zeit_t* End)
{  
  /*  window_08,45,17,30 */
      
  /* Schlüsselwort suchen */
  char* p;
  if (!(p = strstr_P(buf,PSTR("window"))))
    return 0;
  p = p + strlen_P(PSTR("window"));
  
  /* Zahlen extrahieren */
  char *ptr;
  byte res[4];
  for (int i = 0; i < 4; i++) {
    res[i] = strtol(p,&ptr,10);
    p = ptr + 1;
  }

  /* Bereichsprüfungen */
  if ((res[0] > 23) || (res[2] > 23))
    return 0;
  if ((res[1] > 59) || (res[3] > 59))
    return 0;
    
  /* Zuweisung */
  Start->hour = res[0];
  Start->min  = res[1];
  End->hour   = res[2];
  End->min    = res[3];
  
  return 1;
}

[avr (Gast)]

Christian J. schrieb:
> while(in_ch * cmd_ch);

Das ergibt genau dann 0 (also false), wenn mindestens eine der Variablen 
0 ist.

Im Endeffekt kodiert man im Command-String mit Platzhaltern, wo die 
Zahlen hingeschrieben werden sollen. Mit 0x8n wird die Zahl in das n-te 
Byte von buf addiert, mit 0xCn wird sie zusätzlich mit 10 multipliziert. 
buf muss daher auch zwingend vorher 0 sein.

[Rolf M. (rmagnus)]

avr schrieb:
> Christian J. schrieb:
>> while(in_ch * cmd_ch);
>
> Das ergibt genau dann 0 (also false), wenn mindestens eine der Variablen
> 0 ist.

Dann würde ich aber schreiben:

while (in_ch && cmd_ch);

oder von mir aus auch ausführlich:

while (in_ch != 0 && cmd_ch != 0);

Aber nicht so verklausuliert über eine Multiplikation.

[avr (Gast)]

Rolf M. schrieb:
> Aber nicht so verklausuliert über eine Multiplikation.

Die Frage ist, ob der Compiler daraus Multiplikation erzeugt und damit 
die besseren Maschinencode für den avr. Ich vermute nicht. Da der Code 
klein werden sollte, habe ich die Optimierung direkt eingesetzt.