Hallo, Was bedeutet es wenn ich die selbe Meldung in äuserst kurzen Abständen immer wieder auf dem Terminal Programm zu lesen bekomme? Es scheint, dass das Programm stecken bleibt! (Schleife ist sicher nicht schuld) das Programm hat schon funktioniert. Als ich noch eine Erweiterung schreiben wollte, trat plötzlich das Problem auf! Jezt hab ich diese wierder rückgängig gemacht, fehler ist immer noch, da hab ich vllt. was übersehen. kann es sein, dass der RAM voll ist? könnte sein. Wie kann ich das kontrollieren? mfg J.K
Springt eventuell der Watchdog-Timer an? Zu wenig RAM müsste ja dein Kompiler anmeckern.
Kompiler hab ich AVR Studio mit GCC Plug in. mir ist nichts aufgefallen, dass dieser meckert, wo würde das stehen? Watchdog ist nicht aktiviert!
Keine Ahnung, wo das steht, ich arbeite nicht mit AVRs, beim MSP430 GCC kann man das ausgeben lassen mit msp430-ram-usage oder msp430-size. ich denke mal die Befehle wirds beim AVR-GCC auch geben?
>Was bedeutet es wenn ich die selbe Meldung in äuserst kurzen Abständen >immer wieder auf dem Terminal Programm zu lesen bekomme? Es scheint, >dass das Programm stecken bleibt! Langsam, da blickt ja kein Mensch durch: Was für ein "Terminalprogramm", wo läuft es ? Was genau ist "Dein Programm" ? läuft es auf einem µC (welcher ?) Wenn du eine "Meldung" "auf" dem Terminalprogramm siehst wird es ja von irgendetwas anderem gesendet ? Fast genauso gut hättest du schreiben können "Mein Auto springt nicht mehr an, woran liegt das ?", das hätte ähnlich viele Antworten zugelassen...
sry, Programm läuft auf nem mega16. Diese sendet über USART Meldungen. Terminalprogramm läuft auf PC (selbstgeschrieben). an Terminalprogramm liegt es nicht Schleife ist wie gesagt auch keine vorhanden. Dh. der µC sendet in kurzen Abständen (quasi dauernd) die selbe Meldung und bleibt stecken.
>Was bedeutet es wenn ich die selbe Meldung in äuserst kurzen Abständen >immer wieder auf dem Terminal Programm zu lesen bekomme? Das bedeutet erst mal, dass irgendetwas die selbe Meldung in kurzen zeitlichen Abständen über die serielle Schnittstelle schickt. Mehr kann man auf deine Fehlerbeschreibung nicht gesichert sagen. Meine Vermutung: amoklaufender Pointer, der dir den Stack zerschiesst.
Die Meldung soll auch 1x gesendet werden, aber nur 1x. Kann das passieren wenn der Stack voll ist? Kann man das irgendwie testen. Vllt. interessant: Programm beschreibt ne SD-Karte. Wenn ich File erstellen möchte hängt er. ich weiß, das das mit nem mega16 Speichermäsig sehr knapp ist. Jedoch hat es schon funktioniert. Ich habe schon Messwerte aufgenommen und in File gespeichert. Jetzt hängt er schon bei Fileerstellung. (fopen_) SD-Funktionen sind von mikro-control.de und low-level von Ulrich Radig
Ganz einfach: Aufgrund der exakten Fehlermeldung, die genau dieses eine Terminalprogramm anzeigt, und nachdem ich mir dein gepostetes Programm angesehen habe, kann der Fehler nur in Zeile 42 liegen. Man Man Man...
Klingt so als ob Dein µC dauernd einen Reset macht sobald er in die Funktion läuft. Bau Dir UART-Debugmeldungen an geeigneter Stelle ein damit du exakt weißt wo es genau scheppert.
P.S.: Die Meldung "zu wenig RAM" fällt ja auch nicht vom Himmel, sondern steckt irgendwo in Deinem Programm, also ist mit den von Dir gegebenen Informationen für uns hier wieder nur Rätselraten möglich. Schau in Dein Programm wo die Meldung erzeugt wird und welche Bedingungen erfüllt sei müssen dass selbige ausgegeben wird.
Am Terminalprogramm steht keine Fehlermeldung.
Es steht (stand) nur
FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT
OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT
OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT
OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT OK!FAT
OK! ...
jetzt schreibt er nur mehr FAT OK!
und bleibt in
myfile = fopen_("abcdef.txt",'a');
stecken.
1 | File * fopen_(s8 *fname, s8 mode) |
2 | {
|
3 | File *file; |
4 | |
5 | file = ReserveFilePointer(); // reserve a filepointer. |
6 | |
7 | if(file != NULL) // A free filepointer was found. |
8 | {
|
9 | file->mode = mode; // mode of fileoperation (read,write) |
10 | |
11 | if(SeekFileInDirectory(fname, file)) // if file was found |
12 | {
|
13 | if(mode == 'a') // open existing file for writing (append data at the end of the file) |
14 | {
|
15 | fseek_(file, 0, SEEK_END); // fseek points to the end of the file |
16 | }
|
17 | }
|
18 | else
|
19 | {
|
20 | if((mode == 'a') || (mode == 'w')) // specified file doesn't exist so create new file for writing data. |
21 | {
|
22 | if(CreateFileInDirectory(fname,file)) // Could an entry for the new file in the rootdirectory be created? |
23 | {
|
24 | return(file); |
25 | }
|
26 | else
|
27 | {
|
28 | FreeFilePointer(file); // free the filepointer. |
29 | file = NULL; |
30 | }
|
31 | }
|
32 | else // file with mode 'r' not found |
33 | {
|
34 | FreeFilePointer(file); // free the filepointer. |
35 | file = NULL; // file not found |
36 | }
|
37 | }
|
38 | }
|
39 | return(file); |
40 | }
|
jetzt hab ich das file vorher mit cardreader auf karte erstellt jetzt schluckt er es! komisch, vorher musst das nicht sein. CreateFileInDirectory(...) muss also fehlerhaft sein! danke für eure geduld! Gibt es jetzt eine Möglichkeit den Ramverbrauch zu ermitteln?
> uart_puts("** Keine MMC/SD Karte gefunden!! **\n");
Solche Meldungen sind wunderbar geeignet RAM zu verschwenden.
37 Bytes gehen nur für diese eine Zeile drauf. Bau dir mal
ne uart_puts_P() die Text aus dem Flash ausgibt.
OK, es liegt wohl an SD-Card momentan lässt sich nicht mal mehr per PC ein File drauf erstellen...
die Karte lässt sich nicht mal mehr formatieren! hab ich die Karte geschossen? das file, das sich drauf befindet lässt sich noch bearbeiten und speichern, der rest geht nicht mehr! kann ich die Karte noch retten?
Data: 943 bytes (92.1% Full) (.data + .bss + .noinit) Ich glaube nicht das du mit 81 Bytes Stack auskommst ;)
> Gibt es jetzt eine Möglichkeit den Ramverbrauch zu ermitteln?
Die Belegung des RAM durch data und bss findest du im MAP-file. Wenn ich
mal davon ausgehe, daß du keine dynamische Speicherverwaltung hast,
bleibt noch der Stack.
Da der Stackverbrauch vom Programmablauf und den beteiligten Funktionen
abhängt, ist eine statische Codeanalyse hierfür ungeeignet. Eine
statische Analyse ist zwar sinnvoll um den Bedarf einer einzigen
Funktion zu ermitteln, sagt aber nichts über die Summe der Belegung
durch alle Instanzen im worst-case aus. Das ist aber genau, was dich
interessiert.
Daher mußt du denjenigen Programmablauf ermitteln, welcher die für den
Stack ungünstigste Kombination an Instanzen irgendwelcher Funktionen
hervorbringt. Wenn du diese Kombination herausgefunden (oder in der
Praxis bei komplexeren Programmen wohl eher abgeschätzt) hast, kannst du
dir den Gesamtverbrauch ausrechnen. Da mir persönlich diese Rechnerei
allerdings zu aufwendig bzw. zu fehleranfällig ist würde ich folgendes
empfehlen:
1.) Programm ganz zu Beginn der Ausführung anhalten
2.) den gesamten Stack (soweit er noch nicht verwendet wurde) mittels
Debugger mit einem Füllpattern initialisieren (Vorsicht: wirklich nur
den Stack und nicht irgendwelche globale Variable überschreiben, ein
Blick ins MAP-file sollte hier helfen)
3.) Programm im worst-case ausführen und am Ende anhalten
4.) Speicher auslesen und interpretieren (Vorsicht bei irgendwelchen
größeren Arrays auf dem Stack. Manchmal hat man das Gefühl das Ende
gefunden zu haben, dabei ist es nur eine "Lücke" die nicht verändert
wurde. Aus diesem Grund sollte man sich auch nie auf's Byte genau auf
das Ergebnis verlassen.)
Das ganze funktioniert natürlich nur bei einem korrekten Programmablauf
und nicht, wenn der Stack bereits irgendwo überläuft. Auch sollte das
Ergebnis nur ein grober Anhaltspunkt sein der so gut ist, wie die
vorherige Abschätzung des Programmablaufs. Dynamische Codeanalyse ist
nunmal ein schwammiges Gebiet und zudem sollte der RAM auch nie in dem
Maße verplant werden, wie man das beim Flash tut. Wenn mein Programm zu
99% den Flash füllt.... schön, es hat noch rein gepaßt. Wenn ich vermute
daß mein Programm 90% des RAM benötigt würde ich persönlich mich (je
nach Komplexität der Anwendung) nicht mehr wirklich wohl fühlen.
Viel Erfolg beim Messen,
odic
Hallo, ich hab jetzt die sinnlosen uart ausgaben minimiert, bin jetzt auf ca 85 % RAM (ok, 15%frei ist nicht die Welt). Das Programm funktioniert auch soweit auch wieder, ich bemerke nichts das Stack überläuft Hab mir auch ne neue SD-Karte besorgt. Komisch ist, dass ich auch auf dieser dieser keine Dateien mit dem µC erstellen kann. Mit dem PC gehts aber. Ich kann aber Dateinen öffnen (auch zum hinzuschreiben). Das neu hinzugeschriebenen wird aber nicht gespeichert, wenn ich das File wieder schließe. An was könnte das liegen?
>ich hab jetzt die sinnlosen uart ausgaben minimiert, bin jetzt auf ca 85 >% RAM (ok, 15%frei ist nicht die Welt). Du kannst noch mehr RAM freimachen! Füg mal dieses #include ein: #include <avr/pgmspace.h> Statt sprintf() nimmst du dann sprintf_P() sprintf_P(zeit,PSTR("%2i.%2i.%2i %2i:%2i:%2i\t"),y,m,d,h,min,sek); Texte dann mit PSTR("text") umgeben.
thx mit sprintf_P und uart_P bin ich jetzt auf 77% RAM auslastung. ich glaub jetzt kann ich wieder beruhigt schlafen ^^ mein Probem ist, wie gesagt, dass das Schreiben mit der Karte nicht mehr geht. Kann es sein, das die Liberys nicht mehr als 128MB verwalten können? Auf Ulrich Radigs HomePage steht, dass er es mit 3 verschiedenen Karten mit 128MB getestet hat. Meine "neue" hat 256MB. Platz brauch ich <1MB schätz ich.
So jetzt hab ich das Problem wieder O.o Ich hab jetzt das SD Programm von Ulrich Radig in seiner Grundform nochmal gestartet. http://www.ulrichradig.de/home/index.php/avr/mmc-sd über RS232 wird gesendet: Karte gefunden!! System Ready! Karte gefunden!! System Ready! Karte gefunden!! System Ready! Karte gefunden!! System Ready! Karte gefunden!! System Ready! ... das deutet wahrscheinlich darauf hin, dass stack zerschosse wurde?! Im AVR Studio hab ich nur geringe ram auslastung: (45 bytes, 4,4%) was eigentlich aber nicht sein kann, wenn schon folgende zeile vorkommt: unsigned char Buffer[512]; ?? mfg J.K
ich hab jetzt den Buffer reduziert (212) und noch mal gestartet.
Hat soweit funktioniert. Ausgegeben wurde:
System Ready!
Karte gefunden!!
MBR Signatur found!
VBR Signatur found!
0 36 0 32 17 59 81 e3 36 db 7f 81 96 40 0 5
Directory
Cluster = 2036 DirA = 4e FileName = ›Œ
Directory Ende
FERTIG!!
sieht meiner Meinung nach ganz gut aus oder?
Außer: was bedeutet das Directory?
>Cluster = 2036 DirA = 4e FileName = ›Œ
sollte da die Ordnerstrucktur angezeigt werden?
Thread beobachten
Seitenaufteilung abschaltenBitte 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.