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
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.
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
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.
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
@ 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.
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.
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:
1 | int main(void) { |
2 | init(); |
3 | puts("Feldmuehle Reloaded\r\nTeste PUTS...OK\r\n"); |
4 | printf("Teste PRINTF...OK\r\n"); |
5 | printf("DCF77..."); |
6 | DCF77_init(); |
7 | printf("OK\r\n"); |
8 | printf("SD-Karte..."); |
9 | MMC_IO_Init(); |
10 | printf("initialisiert\r\n"); |
11 | if(GetDriveInformation()!=F_OK) // get drive parameters |
12 | { |
13 | puts("\nFehler bei der SD-Karte!\r\n"); |
14 | RED_ON(); |
15 | GREEN_ON(); |
16 | while(1); |
17 | } |
18 | printf("Interrupts..."); |
19 | sei(); |
20 | printf("OK\r\n"); |
21 | puts("Starte Schleife\r\n"); |
22 | while (1) { |
23 | RED_ON(); |
24 | GREEN_OFF(); |
25 | |
26 | puts("\nSchreibe Daten ..."); |
27 | |
28 | //data initialisieren |
29 | data.jahr=year; //Jahr |
30 | data.monat=month; //Monat |
31 | data.tag=day; //Tag |
32 | data.stunde=hour; //Stunde |
33 | data.minute=min; //Minute |
34 | data.sekunde=sec; //Sekunde |
35 | data.E=readADC(0); //Elektr. Feldstärke |
36 | data.T=readADC(1); //Temperatur |
37 | data.H=readADC(2); //Luftfeuchtigkeit |
38 | cli(); |
39 | if(Fopen("messung.txt",F_WRITE)==F_OK){ |
40 | written=Fwrite((U8*)&data,sizeof(struct messDaten)); |
41 | Fclose(); |
42 | } |
43 | sei(); |
44 | puts("OK.\r\n"); |
45 | GREEN_ON(); |
46 | RED_OFF(); |
47 | _delay_ms(500); |
48 | } |
49 | return 0; |
50 | } |
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
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.
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
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
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.