Nabend zusammen,
ich bin gerade dabei mir LED Equipment zum Jonglieren zu programmieren.
Also eigentlich relativ simpel 2 RGB LED´s und 4 Taster.
Einlesen und Ausgeben klappt alles. Nur nachdem ich jetzt 2h
Programmiert habe funtzt es plötzlich nicht mehr. Meine Vermutung ist
das ich den Speicher des ATMega16 voll habe.
Woran kann ich das erkennen das er voll ist?
Gruß
Nase
P.S: Ich porgrammiere mit dem AVR Studio und PonyProg über die Serielle
Schnittstelle meines PC´s
Bei AVR Studio siehst du nach dem Kompilieren normalerweise eine
Zusammenfassung wieviel Flash und RAM verwendet wird und dazu noch die
Prozentuale Angabe bezogen auf den verfügbaren Speicher.
Solange alles unter 100% ist, ist es ok. Jedoch ist die RAM-Nutzung ohne
Stacknutzung. Das heisst es kann je nach Programm dennoch passieren,
dass der Stack überläuft und dir andere Werte im RAM zerstört.
Welcher Speicher? Programmspeicher? Datenspeicher? Verwendest du
mallocs?
Beim Compilieren wird dir im Ausgabefenster des AVR-Studio die Größe des
compilierten Programms angegeben (Sowohl Programmspeicherbedarf als auch
Datenspeicherbedarf)
Besten dank für die Hinweise. Habe es zwar nicht gefunden wo es stehen
soll, musste aber feststellen das meine Programmierweise sehr
Speicherschluckend war. Über nacht alles nochmal umgeschrieben und
mithilfe von 2 Variablen ca. auf 1/10 gebracht, jetzt passt alles drauf
^^
Mit deinem Vorhaben solltest du weit weg davon sein, die 16k Flash
(Programmspeicher) und das RAM des Mega16 auch nur ansatzweise
vollzubekommen. Was hast du denn für Optimierung gewählt?
(Projektoptionen)
Ich glaub irgendwie dass du in deinem Workflow den Hund begraben hast...
Aufgrund dessen dass du nicht weißt wie die nachschaun kannst wie viel
Speicher von was benötigt wird denk ich nicht dass du mit Sicherheit auf
ein Speicherproblem schließen kannst ;)
Ähm, wie meinst du das, mit 2 Variablen?!
So, habe gerade festgestellt das ich noch mit dem AVR Studio4 arbeite..
nachdem ich aber bei AVR5.1 nach kopieren meines Codes fehler bekommen
habe das angeblich die "delay.h" Bibliothek fehler hat, werde ich wohl
doch bei AVR 4 bleiben ^^
Ok, wie ich jetzt festgestelklt habe, habe ich keine Optimierung
verwendet. Also O0..
Mit dem programmspeicher voll, denke ich weil man es bei Ponyprog auch
sehen kann. Je nachdem welchen Mikrokontroller man einstellt entspricht
ja die ANzahl an zeilen, die dargestellt werden (was ja die einzelnen
Bytes sind), wenn noch Bytes frei sin ("FF") in der letzten Zeil, dann
ist das Programm nicht zu lang ^^
Also mit 2 Variablen meine ich folgendes:
Anfangs habe ich die Ports für die RGB einzeln an und ausgeschlatet
bsp:
1
PORTB|=0x09
hier musste ich aber jede Kombination einzeln porgrammieren ^^
jetzt habe ich 2 variablen eingeführt
mode_o für die 1. RGB (die ersten 3 Pins PB0-PB2)
mode_u für die 2. RGB (4-6 Pin also PB3-PB5)
mode_o wurde durch taster1 um +1 erweitern
mode_u durch taster2 um +8 erweitert
a = mode_o +mode_u
und dann halt
1
PORTB|=a
somit kurzer Programmierungstext, und trotzdessen beide LED´s unabhängig
voneinander einstellbar
EDIT: Gerade mit mit Os Optimiert ausgeführt... ca die hälfte des
vorrigen Speicher (laut Ponyprog)
wie viel Speicher brauchst du denn jetzt? Hab so das Gefühl du weißt
nicht so wirklich was du da mit was tust und welches Programm was
erzeugt.
In 16k Programmspeicher solltest du einige tausend Zeilen Code
unterbringen. So ein PORTB |= 0x01 braucht ein paar Byte im Speicher, du
hast aber 16kB davon.... Poste mal deinen Code... oder den Output
(unterstes Fenster im AVR-Studio, da wo sich was rührt wenn du auf
übersetzen klickst) anschaun.
Und die delay.h ist nicht kaputt sondern arbeitet ohne Optimierung und
definiertes F_CPU Symbol nicht (richtig)
Was verwendest du für einen Programmer (Hardware)?
Noch mehr würd dein Mapfile evtl. Listfile helfen, aber ich denke du
weißt nicht was das ist oder? Könntest bei den Projektoptionen
einstellen dass das erzeugt wird.
Denke jetzt - ohne dass ich deinen Fehler weiß - du solltest dich ein
bisschen mit den Grundlagen von Mikroprozessoren, Entwicklungstools und
Compilation Toolchain auseinandersetzen... (AVR-Tutorial hier ist gut
geeignet dafür..)
Fabian Bade schrieb:> Ok, wie ich jetzt festgestelklt habe, habe ich keine Optimierung> verwendet. Also O0..
Benutze -Os. Dann klappt das auch mit delay.h. Ausserdem wird der vom
Compiler erzeugte Code auf ca. die Hälfte schrumpfen.
und ja ihr habt beide recht ^^ ... habe mapefile und listfile mit
erstellt... wo finde ich die denn jetzt??? bzw. welche endung haben
sie...
habe halt erst angefangen mit microcontroller programmieren... hatte
gehofft das mit mein 1 Semester einführung in C++ etwas weiterhilft,
aber das war eher ein trugschluss :D
Gruß
Fabian
P.S: Danke für die Hilfe
Hi
Also, wenn das bisschen Code es schafft, den Speicher von einem Atmega16
vollzurammeln, dann werd ich sofort vergessen, das ich mit dem Gedanken
gespielt hab, ein wenig C zu lernen.....
Da läuft etwas anderes schief. Könnte es sein, das hier Bibliotheken
eingebunden werden, die nicht erforderlich sind? Selbst dann ist es mir
ein Rätsel, wie mit so wenig Code ein Speicher voll werden kann.
Gruß oldmax
Fabian Bade schrieb:> _delay_ms (m2);
Das geht gar nicht. _delay_ms darf nur mit Konstanten benutzt werden.
Und dann poste deinen Code mal als Anhang.
Kompilierbar, 0 Errors, 0 Warnings.
mfg.
>c:\programme\atmel\avr tools\avr >toolchain\bin\../lib/gcc/avr/4.4.3/../../../../avr/include/util/delay.h :12>0:
error: __builtin_avr_delay_cycles expects an integer constant.
Man sollte die Fehlermeldungen des Compilers schon ernst nehmen.
delay geht NUR mit einer Konstante, ansonsten explodiert dein
Speicher...
Oliver
Thomas Eckmann schrieb:> Einzig richtig ist, daß dein Kommentar vollkommen überflüssig ist.
Nö, ist er nicht. Woher sollst Du sonst wissen, wie's richtig ist ? :D
Ja, stimmt, lesen der Doku würd' helfen.
Also liegt der ausgenutzte Speicher nur daran das ich im _delay_ms eine
variable verwende, anstatt eine Konstante ?!? Weil laufen tut das
Programm ja, nur das ich ( vor dem anschalten der optimierung) zu wenig
speicherplatz hatte... was sich jetzt ja auch erledigt hat dank eurer
hilfe
Fabian Bade schrieb:> Weil laufen tut das> Programm ja
aber vermutlich nicht mit den richtigen Zeiten. Die wartenzeiten werden
damit nicht eingehalten.
schreibt dir selber eine funktion wie:
void delay_ms( ms unsigned int ) {
while ( ms-- )
_delay_ms( 1 )
}
dann kann du sie mit einer variable aufrufen, und dein Programm wird
noch mal viel kleiner. Der Nachteil der dadurch ensteht ist das das
delay_ms immer etwas (ein paar µs ) länger derauert als vorgegeben,
sollte aber bei dir egal sein.
MWS schrieb:> Ja, stimmt, lesen der Doku würd' helfen.
Deine Kommentare werden leider immer überflüssiger.
Hilfreich wäre es aber, die aktuellen Tools zu benutzen, die bei
Verwendung einer Varaiablen eine Fehlermeldung ausgeben:
:28: error: __builtin_avr_delay_cycles expects an integer constant.
mfg.
Thomas Eckmann schrieb:> Hilfreich wäre es aber die aktuellen Tools zu benutzen, die bei> Verwendung einer Varaiablen eine Fehlermeldung ausgeben:
Ach, wenn Du etwas weniger eingebildet wärst und dem TO erklärt hättest,
warum der von ihm compilierbare Code nicht gehen soll, das wäre
hilfreich gewesen.
Und wenn Du schon meinst, er solle aktuelle Tools benutzen, warum
schreibst Du ihm das dann nicht einfach ?
Dicke Hose machen und nix dahinter.
Tatsächlich war der Code für den TO compilierbar und die variable
Zeitangabe hat ihm die Fließkommalibrary mit reingewurstelt und seinen
Code aufgebläht. Und dass der TO jetzt nicht der Profi ist, ohne das
abwertend zu meinen, sieht man doch bereits an der Codegestaltung. Wie
soll er da die Problematik des als Variablen übergebenen Parameters in
der _delay_ms kennen ?
Nimm Dir 'n Beispiel an Peter II, der hat wenigstens was konstruktives
gepostet.
MWS schrieb:> Dicke Hose machen und nix dahinter.
Du läufst ja richtig zur Hochform auf.
MWS schrieb:> Das ist falsch. Richtig wäre "sollte".
Vergiss' aber bitte nicht, daß du mit dieser kleinkarierten Kacke
angefangen hast.
mfg.
Thomas Eckmann schrieb:> Vergiss' aber bitte nicht, daß du mit dieser kleinkarierten Kacke> angefangen hast.
Nö, ist doch nicht kleinkariert.
Kleinkariert ist's dem TO zu sagen "darf nicht" und zu verschweigen
warum.
Denn in der Version des TO ging's offensichtlich, da würd' ich mich an
dessen Stelle auch fragen, "Wieso? Geht doch"
Also wurdest Du doch nur so behandelt, wie Du andere behandelt hast. Und
das ist ok so.