AVR Studio: Großes Projekt aus mehreren kleinen erstellen

[Philip H. (lephilip)]

Liebe Community,

seit Tagen versuche ich ein Projekt zu realisieren, aber ich komme 
einfach nicht weiter. Deshalb möchte ich hier um Hilfe bitten.

Ein ATmega32 soll selbstständig eine Spannung messen, parallel per DCF77 
die Funkzeit empfangen und in regelmäißgen Abständen die Messdaten 
zusammen mit einem Zeitstempel auf eine SD-Karte schreiben.

Projekte jeweils zum reinen DCF77-Empfang, zum reinen Spannungsauslesen 
und zum reinen auf-SD-Karte-Schreiben funktionieren tadellos. Jetzt 
möchte ich die drei "Module" zusammenführen (siehe Anlage).

Leider passiert gar nichts - die LED, die DCF-Empfang signalisiert, 
blinkt zwar tatsächlich im Sekundentakt, aber das Gerät schreibt nichts 
auf die SD-Karte.

Vielleicht kann sich das jemand von euch schnell ansehen und mir Tipps 
geben, wo ich ansetzen könnte.

Herzlichen Dank und viele Grüße,
Philip

[Karl H. (kbuchegg)]

Philip H. schrieb:

> Vielleicht kann sich das jemand von euch schnell ansehen und mir Tipps
> geben, wo ich ansetzen könnte.

Tja.
das nennt man dann wohl "debuggen".

Du hast offenbar eine serielle Schnittstelle zur Verfügung. Benutze sie, 
damit dir das Programm dort Texte ausgibt an denen du ablesen kannst was 
es gerade treibt.

(Auch wenn du eine Datei lcd.c auf deinem Verzeichnis hast, so wird 
diese doch nicht compiliert und gelinkt. d.h. du hast gar kein LCD. Da 
frag ich mich doch gleich: Was macht diese Datei auf diesem 
Verzeichnis?)

> seit Tagen versuche ich ein Projekt zu realisieren,
> aber ich komme einfach nicht weiter.

Der Code sieht so aus, als ob du ihn zusammengeklaut hättest. Qualitativ 
sieht der Code sogar ziemlich gut aus, so dass ich die Feststellung 
wage: Du hast ihn nicht selbst geschrieben. Jetzt hast du gelernt, das 
es einfach nicht funktioniert, wenn man ohne Ahnung von der Materie 
einfach Teile klaut und zusammenzustellen versucht.

[Philip H. (lephilip)]

Lieber Karl Heinz,

Danke für deine Antwort. In der Tat habe ich versucht, die serielle 
Schnittstelle zum Debuggen zu nutzen. Leider gibt es aber irgendwo einen 
Konflikt, sodass beim HyperTerminal gar nichts ankommt. Per LED habe ich 
dann versucht, einzelne Punkte im Ablauf zu visualisieren. Aber das 
Programm kommt schneinbar nur bis zum Initialisieren des DCF77-Moduls. 
Egal, was ich versuche - die while-Schleife (in der ja die Daten auf die 
SD-Karte geschrieben werden), wird nie erreicht.

Deine Beobachtung, dass ich Großteile des Codes nicht selbst geschrieben 
habe, ist zutreffend. Warum soll man auch das Rad neu erfinden? 
Allerdings musste ich viele Passagen überarbeiten, so dass sie mit 
meinem System harmonieren. Von daher ist es wirklich nicht so, dass ich 
"mal eben was zusammen bastle" :-)

Über weitere Ideen freue ich mich sehr!

Viele Grüße,
Philip

[Karl H. (kbuchegg)]

Philip H. schrieb:

> Danke für deine Antwort. In der Tat habe ich versucht, die serielle
> Schnittstelle zum Debuggen zu nutzen. Leider gibt es aber irgendwo einen
> Konflikt, sodass beim HyperTerminal gar nichts ankommt.

Dann würde ich hier erst mal den Hebel ansetzen.

Wenn du aus der 'Ratephase' rauskommen willst, musst du erst mal deine 
Hilfsmittel zum Laufen bringen, damit das stochern mit langen Stangen im 
Nebel aufhört.

Also:
neues Projekt aufsetzen und damit die UART zum laufen bringen.
http://www.mikrocontroller.net/articles/AVR_Checkliste#UART.2FUSART

Das in diesem neuen Projet über die UART gelernte dann in dein 
eigentliches Projekt übernehmen, dort ebenfalls die UART in Betrieb 
nehmen und dann anfangen am eigentlichen Projekt zu debuggen.


Ein eigenes Projekt hat den Vorteil, dass du dann den Fokus einzig und 
alleine auf die UART legen kannst, und nicht von anderen Dingen ständig 
abgelenkt wirst.

[Oliver (Gast)]

Philip H. schrieb:
> Vielleicht kann sich das jemand von euch schnell ansehen und mir Tipps
> geben, wo ich ansetzen könnte.

"One or more project files could not be found"

Das würde ich mal als erstes beheben. Nicht vollständige Projekte 
einstellen ist wenig hilfreich.

Oliver

[Philip H. (lephilip)]

@ Karl Heinz:

Gut. Dann nehme ich das als erstes in Angriff. Hatte das ein bisschen 
vernachlässigt, da das Gerät später ohnehin autark arbeiten soll, ohne 
UART.

@ Oliver:

Sorry, hatte in den "included directories" externe Sachen angegeben. 
Jetzt müsste alles (außer dem AVR-Standards) drin sein.

[Karl H. (kbuchegg)]

Philip H. schrieb:
> @ Karl Heinz:
>
> Gut. Dann nehme ich das als erstes in Angriff. Hatte das ein bisschen
> vernachlässigt, da das Gerät später ohnehin autark arbeiten soll, ohne
> UART.

Das wird gerne übersehen:
Eines der ersten Dinge bei einem 'nicht trivialen' Projekt ist es, sich 
Debug-Kanäle zu bauen. Sich Möglichkeiten zu schaffen, wie sich das 
Programm bemerkbar machen kann.
Das kann eine einzelne LED sein, nur muss man sich darüber im klaren 
sein, dass es damit unendlich mühsam ist (wenn auch möglich), einem 
Programm über die Schulter zuschauen.

LCD ist nahezu perfekt, bis auf einen Punkt: Meistens hat man nicht viel 
Platz auf dem LCD und so etwa wie eine Historie zu studieren, kann 
extrem schwierig werden

UART ist auch fast perfekt, bis auf einen Punkt:
Sie muss erst mal laufen. Aber dann hat man: eine große Anzeigefläche 
und mit einem anständigen Terminalprogramm kann man auch zurückscrollen 
und sich ansehen wie sich eine Situation entwickelt ha, wie Variablen im 
Laufe der Zeit ihre Werte verändert haben, wie diese Veränderung mit 
Pin-Abfragen korrelieren etc (sofern man natürlich die richtigen 
Ausgaben zum Debuggen ins Programm eingebaut hat)

Sofern man natürlich nicht über direkte Debugger-Anbindungen wie JTAG 
verfügt. Aber selbst dann ist der Wert einer Historie nicht zu 
unterschätzen.


Aber egal was du tust: Geh niemals, und ich meine niemals, davon aus, 
dass ein Programm mit mehr als 10 oder 20 Zeilen auf Anhieb 
funktionieren wird. Selbst dann, wenn du Funktionen aus anderen 
Projekten übernehmen kannst. Diesen Fall gibt es nur äußerst selten. 
Irgendwelche Probleme gibt es immer! Und um denen auf die Spur zu kommen 
muss man entweder gut im Raten sein, langjährige Programmiererfahrung 
haben (damit man in der Lage ist die zig notwendigen Details auch über 
viele Programmzeilen hinweg im Kopf zu behalten und mit den jeweiligen 
Anweisungen abzugelichen) oder eben über Debug-Möglichkeiten verfügen.

Das geht mir auch nicht anders als dir. Nur das meine Programme (nicht 
auf einem µC) um ein paar Zehnerpotenzen größer sind. Aber auch dort ist 
es nicht ungewöhnlich, dass man sich eigene Funktionen schreibt, die 
komplizierte Datenstrukturen in einer lesbaren Form auf ein 
Anzeigemedium dumpen um überhaupt eine Chance zu haben Fehler zu finden.

[Philip H. (lephilip)]

Lieber Karl Heinz,

vielen vielen Dank, dass du dir so viel Zeit nimmst und mir Tipps aus 
deiner Erfahrung gibst. Das finde ich richtig klasse!

UART läuft inzwischen. Darüber weiß ich nun auch, dass das DCF77-Modul 
läuft. Die SD-Karte kann offensichtlich auch initialisiert werden, 
allerdings klappt das Schreiben nach wie vor noch nicht genau.

Ich weiß nun aber, wo das ganze hängt: Beim Befehl GetDriveInformation() 
stürzt das Programm ab. Von der Fehlermeldung "Fehler bei der SD-Karte" 
kommt gerade noch das "F", dann ist Schluss.

Hier nochmal der relevante Abschnitt:

int main(void) {
   init();
   puts("Feldmuehle Reloaded\r\nTeste PUTS...OK\r\n");
   printf("Teste PRINTF...OK\r\n");
   printf("DCF77...");
   DCF77_init();
   printf("OK\r\n");
   printf("SD-Karte...");
   MMC_IO_Init();
   printf("initialisiert\r\n");
      if(GetDriveInformation()!=F_OK) // get drive parameters
      {
       puts("\nFehler bei der SD-Karte!\r\n");
       RED_ON();
       GREEN_ON();
       while(1);
      }
   printf("Interrupts...");
   sei();
   printf("OK\r\n");
   puts("Starte Schleife\r\n");
   while (1) {
   RED_ON();
   GREEN_OFF();

   puts("\nSchreibe Daten ...");
 
  //data initialisieren
  data.jahr=year;  //Jahr
  data.monat=month;  //Monat
  data.tag=day;    //Tag
  data.stunde=hour;  //Stunde
  data.minute=min;  //Minute
  data.sekunde=sec;    //Sekunde
  data.E=readADC(0);  //Elektr. Feldstärke
  data.T=readADC(1);    //Temperatur
  data.H=readADC(2);    //Luftfeuchtigkeit
  cli();
    if(Fopen("messung.txt",F_WRITE)==F_OK){
    written=Fwrite((U8*)&data,sizeof(struct messDaten));
      Fclose();
    } 
  sei();
   puts("OK.\r\n");
   GREEN_ON();
   RED_OFF();
  _delay_ms(500);
   }
   return 0;
}

Details über GetDriveInformation() stehen in der fat.c
Hier werde ich mir jetzt Debug-Infos einbauen und per UART ausgeben. Mal 
sehen, wie weit ich komme.

Grüße,
Philip

[Karl H. (kbuchegg)]

Vergiss auch nicht, puts bzw. Texte die du nicht mehr brauchst, wieder 
zu entfernen. Ansonsten müllst du dir ganz schnell das SRAM zu und das 
kann dann wieder zu neuen Problemen Stackprobleme) führen.

[Philip H. (lephilip)]

Sehr guter Hinweis. Daran wird's wohl gelegen haben.

Ich habe testweise mal alle printfs etc. auskommentiert ... und siehe 
da:
ES LÄUFT!

An dieser Stelle ein riesen großes DANKESCHÖn an Karl heinz.

Was ich aus dieser Episode lerne:

- Immer an Debug-Kanäle denken
- printf haut mir den SRAM voll
- Fragen lohnt sich, denn es gibt nette Menschen, die einen an ihrem 
Erfahrungs-Schatz teilhaben lassen.

Es grüßt mit einem breiten Grinsen,
der Philip

[Karl H. (kbuchegg)]

Philip H. schrieb:

> Was ich aus dieser Episode lerne:
>
> - Immer an Debug-Kanäle denken
> - printf haut mir den SRAM voll
> - Fragen lohnt sich, denn es gibt nette Menschen, die einen an ihrem
> Erfahrungs-Schatz teilhaben lassen.
>


Du hast eines vergessen:

- keine deine Möglichkeiten.

Gerade konstante Texte kann man ganz einfach ins Flash verbannen, so 
dass sie keinen Platz im SRAM benötigen

http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Programmspeicher_.28Flash.29