RST bei Buffernutzung

Bei aller Liebe.

Aber was ist jetzt die Frage?

Timo P schrieb:
> "" entspricht doch '\0' was einem C-String-Ende entspricht. warum kann

Nein das tut es nicht.
"" enstpricht an dieser Stelle der Startadresse eines leeren Strings, 
der irgendwo im Speicher liegt.

Strings kann man nicht einfach so zuweisen.


Die Frage ist aber eigentlich:
Was ist eigentlich genau deine Frage?

Floh schrieb:
> Timo P schrieb:
>> int main()
>> {
>>   uart_puts("RST\r\n");
>>   kill_buffer();
>
>   while(1)
>     {
>     }
>
>> }
>
> Da fehlt die abschließende Endlosschleife, da sonst das weitere
> Verhalten des uC nicht definiert ist (Reset, Programmneustart,...)

Im Grunde hast du recht.
Allerdings schickt die gcc-Runtime nach einem return von main() den µC 
in eine Endlosschleife. So gesehen ist das Verhalten (beim gcc) 
definiert.

Timo P schrieb:
> ps:
>
> mein main hat eine for(;;) schleife in der der UART-RX-buffer abgefragt
> wird

Dann zeig bitte das richtige Programm. OK?

Dein Absturz wird höchst wahrscheinlich hier seinen Ursprung nehmen

    sprintf(s,"<%s> \r",buffer);uart_puts(s);

dein killBuffer hinterlässt nun mal in buffer keinen leeren String. 
Damit knallst du mit Sicherheit zuallererst einmal weit über die Grenzen 
von s drüber.

Das es mit Buffergrößen kleiner 60 scheinbar(*) funktioniert ist Zufall. 
Da erwischt du nur einfach nicht das richtige Byte um das komplette 
System zum Crashen zu bringen.

Um einen Buffer, der sowieso nur einen String aufnehmen kann zu löschen, 
vulgo den String auf einen Leerstring zu setzen, genügt es das erste 
Byte davon auf '\0' zu setzen. Man muss nicht durch das Array durchgehen 
und jedes einzelne Byte auf '\0' setzen.


(*) wie gesagt: scheinbar
Du hast trotzdem einen Fehler. Du siehst ihn nur nicht, weil du zufällig 
die falschen Bytes im Speicher zerstörst.

Timo P schrieb:
> Karl heinz Buchegger schrieb:
>> Um einen Buffer, der sowieso nur einen String aufnehmen kann zu löschen,
>> vulgo den String auf einen Leerstring zu setzen, genügt es das erste
>> Byte davon auf '\0' zu setzen. Man muss nicht durch das Array durchgehen
>> und jedes einzelne Byte auf '\0' setzen.
>
> ich überprüfe, ob ich ein config:start\n empfangen habe. dazu nutze ich
> strstr(). Wenn ich aber nun den Buffer nur an [0] auf '\0' setze, sind
> die anderen Zeichen nicht automatisch weg oder?

Richtig - Sind sie nicht.
Aber wen kümmerts?

Ein String ist mit dem ersten '\0' Zeichen zu Ende. Was dann noch 
dahinter kommt interessiert keinen. Auch die str... Funktionen wissen 
das und halten sich daran. So sind Strings in C nun mal definiert.

> Oder sucht die Funktion strstr() nur bis zum \0 Zeichen?

An dieser Stelle ist dann der Hinweis auf ein C-Buch angebracht

> Dann wäre das eine Lösung, mit kill_buffer nur die erste Stelle auf das
> Stringendezeichen zu setzen...

Und mach dein s größer!
Wenn im Extremfall dein Buffer voll ist, dann ist da ein String der 
Länge 70 drinnen. Der wird aber kaum in s (mit 22 Zeichen) reinpassen!

Oh Himmel

1

      while(buffer[i] != '\t')

2

        {

3

          ssid[j] = buffer[i];

4

          i++;

5

          j++;

6

        }

7

        kill_buffer();

8

        sprintf(s,"<%s>",ssid);  uart_puts(s);

Da fehlts ja an allen Ecken und Enden in der Stringverarbeitung

Timo P schrieb:
> ok, s ist vergrößert.
> ich habe nun in der kill_buffer() nur noch buffer[0] = '\0' gesetzt.
>
> Nun empfange ich nur noch Müll!

Aber du hast keinen Absturz mehr.

Also: -> nächsten Fehler suchen! UNd du hast noch viele im Programm.

Timo P schrieb:

> ISR (USART_RXC_vect)
> {
>   buffer[pwrite]=UDR;
>   pwrite++;
>   if(pwrite >= BUFFER_SIZE) pwrite=0;
> }

Das ist deine Empfangsfunktion?

Dann kannst du das hier

1

    for(;;)

2

    {

3

    //if(RESET_PORT&(1<<RESET_PIN))EEPWriteByte(IS_CONFIGERD, 0x01);

4

    _delay_ms(10);

5

    sprintf(s,"<%s> \r",buffer);uart_puts(s);

nicht machen. In buffer ist zu diesem Zeitpunkt kein gültiger String.

Timo P schrieb:
> mein Programm hat ja mal gelaufen, als die Buffer kleiner waren!

Dein Programm hat höchstens zufällig keinen Absturz produziert.
Korrekt gelaufen ist das nie. Zumindest nicht solange, solange du keine 
korrekt terminierten Strings hast.

Als Quick-Fix ändere das mal

1

ISR (USART_RXC_vect)

2

{

3

  buffer[pwrite]=UDR;

4

5

  pwrite++;

6

  if(pwrite >= BUFFER_SIZE)

7

    pwrite=0;

8

9

  buffer[pwrite] = '\0';

10

}

damit hast du zumindest im Input-Buffer ständig einen insofern gültigen 
C-String, als das er nach dem zuletzt empfangenen Zeichen 0-terminiert 
ist.

Ago hat sich ins Boxhorn jagen lassen durch deine Variablen und der 
Tatsache dass du den Index am Ende des Buffers wieder auf 0 setzt. Er 
dachte das wäre ein Ringbuffer. Das ist er aber nicht. Sieht nur auf den 
ersten Blick so aus.

Ago schrieb:

> Ähm.. ist das so gewollt, das trigger nicht 0 werden kann?
>
> Oder wolltest du vielleicht schreiben
>
> if (trigger == 1) then
>   trigger == 0;
> else
>   trigger == 1;

mit dem else hat ers nicht so

       if(PORTA&(1<<PIN))uart_puts("00S1\n");
        if((PORTA&(1<<PIN)) == 0)uart_puts("00S0\n");

Was passiert eigentlich, wenn der Benutzer

1

      else if(strstr(buffer,"set:ssid\t"))  // set:ssid\ta1b2c3d4\t\n

2

        {  

3

        int i = 9,j = 0;

4

5

        while(buffer[i] != '\t')

6

        {

7

          ssid[j] = buffer[i];

8

          i++;

9

          j++;

10

        }

auf den Tab bei der Eingabe vergisst?

Dir ist auch klar, dass der Eingabetext

reset::ssid\t

(für \t drück ich natürlich den Tabulator)

auf diese Abfrage

1

     else if(strstr(buffer,"set:ssid\t"))

passt?

strncmp eignet sich für solche Auswertungen besser als strstr

1

   else if( strncmp( buffer, "set::ssid\t", 10 ) == 0 )

jetzt muss der String mit "set::ssid\t" anfangen, nur dann gilt der Text 
als erkannt. reset::ssid\t passt jetzt nicht mehr.

Vielleicht hängt ja am anderen Ende der Leitung kein Mensch, aber die 
Sache mit dem \t würde ich mir insgesammt nochmal überlegen. Es sei denn 
natürlich, das da ein anderes Programm deinen µC füttert und dort ist 
das schon so festgelegt.

Timo P schrieb:
> aus if...if ist längst ein if else geworden.
>
> Mir ist auch bewusst, dass ich ein Bit aus einem 8-Bit char einzeln
> toggeln könnte.

Eine Schreibweise, die mir persönlich gut gefällt

   trigger = 1 - trigger;

keine Ahnung warum, aber ich finde das hat was :-)

> Dann müsste ich aber wieder die Bitmasken nutzen, sowohl bei der
> Zuweisung, als auch bei der Abfrage des Flags...

na, na

    trigger ^= 0x01;

so schlimm ist das auch wieder nicht.
Besser als
        if(trigger == 1)trigger = 0;
        else if(trigger == 0)trigger = 1;
ist es allemal.

Timo P schrieb:
> dann frage ich aber auch das "0-te" Bit ab.... Dann gehts....

kannst du natürlich machen.
Aber bei all den Alternativvorschlägen ging es bisher immer nur darum, 
trigger zwischen 0 und 1 hin und her wechseln zu lassen. Das machen alle 
bisher hervorgebrachten Alternativen. Manche der Alternativen haben noch 
einen zuätzlichen Nebeneffekt bzw. zusätzliche Eigenschaften, der/die 
hier bei dir nicht zum tragen kommt, da trigger offenbar sowieso nur 0 
und 1 sein kann und auch das auch so sein soll.

Timo P schrieb:
> Hier habe ich genug speicher und nutze ein komplettes byte als flag aus.
> Missbrauch?!? ok, soll jeder so sehen, wie er es möchte.

Darum gehts nicht.

Das hier

1

    if(trigger == 1)trigger = 0;

2

    else if(trigger == 0)trigger = 1;

ist für deinen µC so ziemlich die aufwändigste Methode, das Gewünschte 
zu erreichen.

>
> Im übrigen sind alle commands, die hier zum tragen kommen, von einer GUI
> am PC über USB zum µC übertragen.

ok. nehm ich zur Kentniss. Also musst du nicht besondere Sorgfalt in der 
Auswertung walten lassen. Du kannst davon ausgehen, dass der String 
immer vollständig und wohl geformt ist (abgesehen von 
Übertragungsfehlern natürlich)

Timo P schrieb:
> Das ist doch mal nen Argument...
>
> strstr hätte den vorteil:
>
> &$?=config:start\n wird von mir auch interpretiert, falls sich diese
> Zeichen vor config:start\n einschleichen sollten.

die Frage ist ob du das überhaupt willst.
Falls sich da vor config::start\n ein paar Zeichen eingeschlichen haben, 
die da eigentlich nicht hingehören, woher willst du dann wissen, dass 
dieses config::start nicht eigentlich auch fehlerhaft ist und eigentlich 
gar nicht da hingehört?

> das strncmp klingt auch gut. (Welcher Vorteil ergibt sich praktisch
> durch das n, also die Angabe der Anzahl der zu prüfenden zeichen?)

Ich muss meinen String nicht in Einzelteile zerlegen
Dieser strncmp ist das Equivalent zu: Wenn die ersten n Buchstaben 
(sofern es überhaupt n gibt) diesen Text hier bilden, dann ist alles 
gut.

Timo P schrieb:

> auch mal mist zusammen. Sehen wir ja hier. Danke für eure Anregungen,
> nur so kann ich mich ja verbessern!

Das allerwichtigste bei der Arbeit mit Strings in C:

Du musst dir bei jeder Aktion immer im klaren sein, dass es kein 
Fangnetz gibt. Wenn du, aus welchem Grund auch immer, versuchst 20 
Zeichen in ein char-Array der Länge 10 zu quetschen, dann wird das 
grauslich schief gehen. Nicht nur das, es werden unter Umständen 
seltsame Phenomäne in deinem Programm auftauchen, Dinge die bisher schon 
funktioniert haben werden plötzlich nicht mehr funktionieren, 
Berechnungen liefern falsche Ergebnisse, Funktionsreturns landen 
plötzlich nicht mehr an der Stelle an der die Funktion aufgerufen wurde 
etc.

Daher: Bei jeglicher Stringaktion lieber konservativ arbeiten. Was kann 
schief gehen? Wenn du den String von einem Benutzer hast: Nicht darauf 
verlassen, dass der alles richtig eingibt. Wenn Strings über eine 
Leitung übertragen werden: Auch wenn es mitlerweile selten vorkommt, 
aber es gibt sie noch, die Übertragungsfehler.

Das mindeste, was man immer tun sollte, so lange man im Programm nicht 
sicher gestellt hat, das der String nicht zu lang sein kann:
Wenn man einen String (oder Teilstring) in ein anderes Array umkopiert, 
immer die Länge des Zielarrays im Auge behalten und notfalls das 
Umkopieren abwürgen, wenn man das Ziel überläuft!

Nicht wenige der frühen Hacker-Angriffe auf andere Rechner sind genau 
über solche Schlupflöcher gelaufen: Man hat ins Programm einen sehr 
langen String eingespielt, weil man genau wusste das dort und dort in 
der Umkopierschleife keine Sicherung gegen Überlaufen enthalten ist. 
Damit hat das Programm selber den Schadcode an die richtige Stelle im 
Speicher kopiert und das Tor aufgemacht.