ATmega328: Array-Daten gehen verloren

[Wolfgang Z. (wolfzi99)]

Hallo,

über die UART-Schnittstelle lese ich Daten von einem SD-Karten Modul 
zurück,
dazu benutze ich diese Funktion:

void GetSDString0(uint8_t* BUF)       // Bytes empfangen
{
        uint8_t NextChar;
  NextChar = UART0_getc();     // Warte auf das nächste Byte

  while(NextChar != '.')       // empfange Zeichen bis "." kommt
  {
    *BUF++ = NextChar;
    NextChar = UART0_getc();
  }
}

In einer Header-Datei steht:
 uint8_t RetSD[30];        // Bytes vom SD-Card Modul

Funktions-Aufruf:
 GetSDString0(RetSD);

Leider gehen die empfangenen Bytes verloren, sobald die Funktion 
verlassen wird. In RetSD steht dann nur Müll.
Meine Frage: wie kann ich auf die Array-Daten von RetSD zugreifen?

[Karl M. (Gast)]

Wolfgang Z. schrieb:
> In einer Header-Datei steht:
>  uint8_t RetSD[30];        // Bytes vom SD-Card Modul
>
> Funktions-Aufruf:
>  GetSDString0(RetSD);

Frage dich bitte, ob hier ein Pointer steht und wie das überschreiben 
des Arrays abgefangen wird. Bzw. der Füllgrad mitgeteilt wird.
für mich fehlen da noch vom Type size_t Angaben über die maximale Größe 
und die Anzahl der geschriebenen Zeichen als Rückgabewert einer 
Funktion.

[Patrick (Gast)]

Das

*BUF++ = NextChar;

 kommt mir komisch vor. Damit man es versteht, hätte ich es wie folgt 
gemacht (Wert an Adresse BUF schreiben, Adresse BUF erhöhen)

*BUF= NextChar;
BUF++;

Ansonsten die Startadresse als

GetSDString0(&RetSD[0]);

Übergeben.

Evtl noch die Zeichen zählen, dass du nicht über die Arraygrenzen 
schreibst.

[Wolfgang Z. (wolfzi99)]

Hallo Patrick,
Danke für die schnelle Antwort.
Habe ich, wie von Dir vorgeschlagen umgesetzt, leider ohne Erfolg.
Bin für jeden Tip dankbar!!!

[Einer K. (Gast)]

Patrick schrieb:
> Evtl noch die Zeichen zählen, dass du nicht über die Arraygrenzen
> schreibst.
Und noch eine nul ans Ende hängen

[Patrick (Gast)]

Ich kenne die Funktion UART0_getc() nicht. Ich gehe mal davon aus, dass 
die dafür gedacht ist, nach Empfang eines Bytes aufgerufen zu werden (im 
Empfangsinterrupt zB). Wenn du die Funktion einfach in der 
while-Schleife runterratterst und diese dann am Ende nur stumpf das 
Empfangsregister ausliest, steht da freilich nur Unfug und du rauschst 
auch mit absoluter Sicherheit über die Arraygrenzen hinweg.

[Sebastian S. (amateur)]

>*BUF++ = NextChar;
und
>*BUF= NextChar;
>BUF++;
sind identisch.
Würde mich nicht wundern, wenn der Compiler aus beidem das Gleiche 
macht.

Bist Du Dir sicher, dass der Datentyp "uint8_t", praktisch für alles, 
der Richtige ist? Theoretisch sollte es zwar gehen, aber...

[Patrick (Gast)]

UART0_getc() liest einfach nur den von der UART-Bibliothek mitgebrachten 
Ringpuffer aus und setzt den Zeiger ein Element weiter. Im Highbyte 
liefert die Funktion eine Fehlerinformation mit. Du musst also 
auswerten, ob du überhaupt schon was empfangen hast, bevor du 
UART0_getc() aufrufst. Das ufert in deiner Funktion zu einem Polling - 
Massaker aus, oder du musst die umschreiben, dass du sie über mehrere 
Zyklen verteilen kannst.

Alles in allem schätze ich, dass du dich erstmal bisschen mit der 
Bibliothek auseinandersetzen solltest.

[Sebastian S. (amateur)]

Nachtrag:

Natürlich MUSS sichergestellt sein, dass weniger (gleich) als 30 Zeichen 
vor dem Punkt kommen. Sonst wird es spannend.

Wie Patrick geschrieben hat: Was passiert, wenn kein Zeichen empfangen 
wurde, oder Du zu schnell abfragst (noch kein Zeichen da)? Ich kenne die 
verwendete Funktion auch nicht.

[Dirk B. (dirkbilland)]

>In einer Header-Datei steht:
> uint8_t RetSD[30];        // Bytes vom SD-Card Modul

Wenn Du die Variablen-Definition in die Header-Datei schreibst, wird für 
jede Datei, die die Header-Datei einbindet, eine Variable gleichen 
Namens angelegt. Das erklärt den beobachteten Effekt.

Die Variablen-Definition gehört in die c-Datei und die Deklaration mit 
einem vorangestellten "extern" in die Header-Datei. Dann sollte es 
funktionieren.

[foobar (Gast)]

> In einer Header-Datei steht:
> uint8_t RetSD[30];        // Bytes vom SD-Card Modul

Ich vermute, du hast mehrere RetSD.

In die .h-Datei gehört nur die Deklaration (mit einem "extern" davor), 
in einer .c-Datei dann die Definition so wie oben ohne "extern".

[Wolfgang Z. (wolfzi99)]

Danke für die zahlreichen Rückmeldungen dazu.

Habe jetzt folgende Änderungen vorgenommen:
1. alle Variablen Definitionen stehen jetzt in der C-Datei
2. in der h-Datei steht: extern void GetSDString0(uint8_t* BUF);
Leider ohne Erfolg!

Hier die Funktion zum Empfang von Zeichen (Bytes):
uint8_t UART0_getc(void)    // Byte empfangen
{
  while (!(UCSR0A & (1<<RXC0)));  // warten bis Byte verfügbar
  return UDR0;      // Byte aus UDR zurückgegeben
}

Zur Kontrolle gebe ich den Array-Inhalt RetSD so über HTerm aus:

  for(i = 1; i < 25; i++)
  {
         UART0_putc(RetSD[i]);
         i++;
  }

Vielleicht liegt der Fehler in der Ausgabe der Bytes?

void UART0_putc(uint8_t xB)    // Byte senden
{
  while (!(UCSR0A & (1<<UDRE0)));  // warten bis Senden möglich
  UDR0 = xB;      // sende Byte
}

[Stefan F. (Gast)]

Es könnte auch ganz trivial an einem Stack-Überlauf liegen. Ausgelöst 
durch zu viele verschachtelte Funktionsaufrufe bzw. Funktionen mit zu 
vielen lokalen Daten.

[Wolfgang Z. (wolfzi99)]

Hallo Stefan,

okay, aber wie kann ich das feststellen?

[Stefan F. (Gast)]

Wolfgang Z. schrieb:
> okay, aber wie kann ich das feststellen?

Es gibt zwei Zeiger, die sich aufeinander zu bewegen. Einer vom Stack 
und einer vom Heap. Wenn sie sich in der Mitte treffen, ist der Speicher 
voll.

Dort erklärt das jemand im Detail: 
https://rn-wissen.de/wiki/index.php/Speicherverbrauch_bestimmen_mit_avr-gcc

extern unsigned char __heap_start;
uint16_t momentan_frei = SP - (uint16_t) &__heap_start;

Das Ergebnis könntest du innerhalb jeder Prozedur ausgeben.

[Frank M. (ukw) (Moderator)]

Wolfgang Z. schrieb:
> uint8_t UART0_getc(void)    // Byte empfangen
> {
>   while (!(UCSR0A & (1<<RXC0)));  // warten bis Byte verfügbar   return
> UDR0;      // Byte aus UDR zurückgegeben
> }

Ist das richtig, dass "return UDR0" im Kommentar steht, oder ist das ein 
Copy&Paste-Fehler?

Das muss so aussehen:

uint8_t UART0_getc(void)    // Byte empfangen
{
  while (!(UCSR0A & (1<<RXC0)));  // warten bis Byte verfügbar
  return UDR0;      // Byte aus UDR zurückgegeben
}

Hast Du hier auch alle Warnungen, die der Compiler ausgibt, hier 
mitgeteilt?

[Stefan F. (Gast)]

Frank M. schrieb:
> Ist das richtig, dass "return UDR0" im Kommentar steht, oder ist das ein
> Copy&Paste-Fehler?

Der Kommentar stammt wohl von einem anderen µC Modell das nur einen UART 
hat.

[Frank M. (ukw) (Moderator)]

Stefan ⛄ F. schrieb:
> Der Kommentar stammt wohl von einem anderen µC Modell das nur einen UART
> hat.

Häh? die UART0_getc-Funktion ist definiert als uint8_t, da hat sie auch 
gefälligst was zurückzuliefern. Tut sie aber nicht, da das 
return-Statement auskommentiert ist.

Schließlich wird auch der Rückgabewert benutzt:

NextChar = UART0_getc();

[Stefan F. (Gast)]

Frank M. schrieb:
> die UART0_getc-Funktion ist definiert als uint8_t, da hat sie auch
> gefälligst was zurückzuliefern. Tut sie aber nicht

Da steht doch "return UDR0", nicht auskommentiert:

Wolfgang Z. schrieb:
> uint8_t UART0_getc(void)    // Byte empfangen
> {
>   while (!(UCSR0A & (1<<RXC0)));  // warten bis Byte verfügbar
>   return UDR0;      // Byte aus UDR zurückgegeben
> }

In deinem Zitat fehlt jedoch ein Zeilenumbruch. Vielleicht ein 
Darstellungsproblem im Web Browser?

[Wolfgang Z. (wolfzi99)]

Hallo Frank,
aber das ist nichts auskommentiert:
uint8_t UART0_getc(void)          // Zeichen empfangen
{
  while (!(UCSR0A & (1<<RXC0)));  // warten bis Zeichen verfügbar
  return UDR0;      // Zeichen aus UDR0 zurückgegeben
}
Der Inhalt von UDR0 wird zurückgeliefert!
Der ATmega328 hat zwar nur einen UART, aber trotzdem heißt das Register 
UDRn.

[Wolfgang Z. (wolfzi99)]

Hallo Stefan,

jetzt zu dem Speicherverbrauch.
Ich habe die Funktion eingesetzt und bekomme als Ergebnis eine 0.
Also kein Speicher-Überlauf?

[Frank M. (ukw) (Moderator)]

Stefan ⛄ F. schrieb:
> In deinem Zitat fehlt jedoch ein Zeilenumbruch.

Als Moderator kann ich Beiträge editieren. Da ist kein Zeilenumbruch 
drin. Aber so viele Leerzeichen, dass es in einer nicht-proportionalen 
Schrift so aussieht, als ob das Return-Statement darunter stände. Steht 
es aber nicht.

Deshalb fragte ich den TO, ob das ein Copy&Paste-Fehler sei.

Besser ist auch, C-Code in

[c]C-Code[/c]

einzubetten.

[Frank M. (ukw) (Moderator)]

Wolfgang Z. schrieb:
> Der Inhalt von UDR0 wird zurückgeliefert!

Das sehe ich anders, siehe Screenshot. Und auch im Editor-Fenster sehe 
ich keinen Zeilenumbruch.
Bitte verwende

[c]C-Code[/c]

um C-Code hier zu veröffentlichen.

[Oliver S. (oliverso)]

Wolfgang Z. schrieb:
> Also kein Speicher-Überlauf?

Zeig mal dein ganzes Programm. Normalerweise läuft der Speicher alleine 
durch Funktionsverschachtelungen nicht so schnell über. Heap wirst du 
auch keinen benutzen, und die 30 Byte für den Puffer sind unkritisch.

Was aber schnell blöd werden kann, ist sind Daten, bei denen der '.' 
erst nach mehr als 30 Zeichen erkannt wird. Deine Empfangsroutine 
schreibt ja fröhlich immer weiter in den Puffer, ohne Größenbegrenzung.

Oliver

[Wolfgang Z. (wolfzi99)]

Hallo Frank,

vielen Dank für den Hinweis.
Da ich nur selten Fragen im Forum stelle, war mir das nicht bewusst, 
sorry!

[Wolfgang Z. (wolfzi99)]

Hallo Oliver,

das mit der Zeichen-Menge habe ich vorher geprüft.
Es werden nur Datei-Namen mit .txt zurückgeliefert und
für mich sind nur die Namen ohne .txt relevant.
Die max. Dateinamen-Länge beträgt 18 Zeichen, somit ist ein 
Array-Überlauf nicht möglich.

Wolfgang

[Oliver S. (oliverso)]

Wolfgang Z. schrieb:
> Die max. Dateinamen-Länge beträgt 18 Zeichen, somit ist ein
> Array-Überlauf nicht möglich.

Famous last words ;)

Oliver

[Frank M. (ukw) (Moderator)]

Wolfgang Z. schrieb:
> Die max. Dateinamen-Länge beträgt 18 Zeichen, somit ist ein
> Array-Überlauf nicht möglich.

Warum benutzt Du dann einen Buffer mit 30 Zeichen? Aus Angst?

[uwe (Gast)]

Dachte immer SD Karten haben ein SPI interface ;-)

[Einer K. (Gast)]

Wolfgang Z. schrieb:
> In RetSD steht dann nur Müll.

Warum uint8_t, wenn es sich doch um Text handelt?
Also char.
Oder?

Desweiteren vermisse ich immer noch die nul am Stringende.

So gibt es keine Information im Programm wie lang der String ist.
Neben anderem Ungemach, wundert mich nicht, dass da Mist ausgegeben 
wird, wenn kein Programmteil weiß, wie lang/groß irgendwas ist.

Wolfgang Z. schrieb:
> somit ist ein
> Array-Überlauf nicht möglich.
Is klar....

[Patrick (Gast)]

Vielleicht versuchst du es mal, den Empfangsinterrupt zu nutzen? Oder 
hast du den schon irgendwo drin und der schießt dir quer? Der würde vom 
reinen Code dann ca so aussehen, zeichenzaehler muss natürlich mit 0 
initialisiert werden:

uint8t empfange_SDString(void) {
extern volatile uint8t zeichenzaehler; // Zähler für empfangene Zeichen
extern volatile uint8_t RetSD[30];
uint8t *tempzeiger; // Hilfszeiger, wo das nächste empfangene Zeichen hinsoll
uint8t retval;

tempzeiger = &RetSD [0] + zeichenzaehler; //Zeiger auf nächstes freies Zeichen ermitteln
*tempzeiger = UDR0; // Empfangsregister an freie Stelle kopieren
if (zeichenzaehler < 29) { // Überlauf abfangen
zeichenzaehler++;
}
if (*tempzeiger == '.') {  // bei Empfang Stopzeichen Stringlänge zurückgeben
retval = zeichenzaehler;
zeichenzaehler = 0; // Zeichenzähler zurücksetzen
}
else {
retval = 0; // Null zurückgeben, wenn kein Stopzeichen empfangen
}
return retval;
}

Der Code der ISR wäre dann

extern volatile uint8t empfangsstring[30];
extern volatile uint8_t RetSD[30];
uint8t retval;

retval = empfange_SDString();
if (retval ) {
for (uint8t i = 0; i < retval; i++) {
empfangsstring[i] = RetSD[i];
}

Alles bisschen unsauber, aber zum testen sollte es tun.

[Oliver S. (oliverso)]

Patrick schrieb:
> ... maximal umständlichen Code ...

Was genau ist denn jetzt das Problem im Code des TO, das du durch deinen 
Code löst?

Oliver

[Stefan F. (Gast)]

Wolfgang Z. schrieb:
> Ich habe die Funktion eingesetzt und bekomme als Ergebnis eine 0.

Das ist aber ein seltsamer Zufall. Bis du sicher, dass du die richtige 
Zahl ausgibst?

0 ist jedenfalls zu wenig. Damit kannst du keine einzige Funktion mehr 
aufrufen, denn Funktionen brauchen Stack.

[Wolfgang Z. (wolfzi99)]

Ja, war am Anfang so.
Habe ich jetzt auf 20 reduziert.

[Wolfgang Z. (wolfzi99)]

Hallo Uwe,

das ist keine normale SD-Karten Ansteuerung.
Ich benutze ein Modul der Firma Artekit (Italien) und das hat eine
UART-Schnittstelle.

[Wolfgang Z. (wolfzi99)]

Hallo,
das Problem ist, dass das SD-Modul einen Mix aus ASCII und Bytes
zurück sendet.
Daher der Typ uint8_t, also kein normaler String, somit kann ich das 
nul-Zeichen auch nicht anfügen.

[Wolfgang Z. (wolfzi99)]

Hallo an alle,

dank der vielen sehr nützlichen Hinweise, macht das Programm jetzt genau 
das, was es machen sollte.

Vielen, vielen Dank für Eure Unterstützung!

Gruß
Wolfgang

[Oliver S. (oliverso)]

Und was war jetzt das Problem?

Oliver

[Wolfgang Z. (wolfzi99)]

Hallo Oliver,

die Lösung war eine Kombi aus verschiedenen Fehlern.
Dieser Hinweis von foobar

foobar schrieb:
> Ich vermute, du hast mehrere RetSD.
>
> In die .h-Datei gehört nur die Deklaration (mit einem "extern" davor),
> in einer .c-Datei dann die Definition so wie oben ohne "extern".

Und der Tip von Dirk B.

Und einen Fehler den ich selbst eingebaut und zuerst nicht gefunden 
habe.