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
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.
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.
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?
> 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?
