Hallo zusammen Bisher hab ich mitder AVR-Studio immer mit Assembler programmiert. Ging auch problemlos. Nun will ich es mal in C versuchen (Hab schon mit der C-Control2 von Conrad gearbeitet) Mein Problem: in der Main-Routine gibt es einen Funktionsaufruf, der die Inititialisierung des LCD erledigt. lcd_init(); diese Funktion sieht so aus: lcd_init() { char ausgangsbyte; DDRD = 0b11111111; //LCD-Register auf Ausgang _delay_ms(50); // lcdport = 0x3; _delay_ms(5); lcdport = 0x3; _delay_ms(5); lcdport = 0x3; _delay_ms(5); lcdport = 0b00000010; //$ Bit Modus einstellen return 0; }; steckt also noch in den Kinderschuhen. Sie ist in einer Datei "lcd.h" ausgelagert. Alles wird auch anständig ohne Fehler compailiert. Wenn ich den Debuger starte springt der gelbe Pfeil zum Funktionsaufruf. Mache ich dann mit F11 weiter, sollte der Pfeil in die LCD-Datei gehen, und dort auf dem ersten Befehl stehen. Macht es aber nicht. Der Pfeil verschwindet im Nirwana, Wenn ich F11 wiederholt drücke macht der Prozessorcounter große Sprünge, aber ich weiß nicht mehr wo ich bin. Breakpoints lassen sich auch nicht setzen. Hab ich irgendwo eine falsche Einstellung, oder eine falsche Programmversion oder stelle ich mich nur so blöd an? Die beiden Dateien hab ich angehängt
Karl heinz Buchegger schrieb: > Schalte als erstes mal den Optimizer ab. Dann funktionieren aber die Delays nicht mehr sinnvoll. Besser ist es, sich an optimierten Code zu gewöhnen und bspw. in entsprechenden Abständen passend breakpoints zu setzen, statt alles zu versuchen per Einzelschritt zu erledigen. Ggf. Assembler-Einzelschritte ausführen.
Dankr für die Antworten. Leider haben sie nichts gebracht. Jörg. Breakpoints lassen sich nicht setzen. Wenn ich die Breakpioints im Ruhezustand setze, sind sie noch da, aber sobald ich den Debuger starte, kommt eine Meldung "one or more Breakpoints could not b e set, and have been disabled... " Kann das sein, dass das mit den AVR-Studio nichtgeht?
Jörg Wunsch schrieb: > Karl heinz Buchegger schrieb: >> Schalte als erstes mal den Optimizer ab. > > Dann funktionieren aber die Delays nicht mehr sinnvoll. Jup. An die hab ich nicht mehr gedacht
Haderlump schrieb: > Kann das sein, dass das mit den AVR-Studio nichtgeht? Nein. Ist alles in Ordnung. Es ist nur so, dass der Optimizer des Compilers dein Programm so umgebaut hat, dass das enstandene Maschinenfile (das dann tatsächlich abgearbeitet wird) zwar funktional noch identisch ist, aber so gut wie keine Entsprechnung mehr mit dem ursprünglichen C-File hat. Wie soll der Simualator einen Breakpoint auf eine C-Codezeile setzen, wenn er sie in dem, was der Optimizer hinterlassen hat, einfach nicht mehr findet? Der Code, der dann tatsächlich auf der CPU zur Ausführung kommt, hat keine 1:1 Entsprechung mehr mit dem was du programmiert hast. Daher auch 'Optimizer abdrehen'. Jörg hat natürlich recht: die delays funktionieren damit nicht mehr richtig (die Zeiten stimmen dann hinten und vorne nicht mehr), wenn dir das aber egal ist und du mehr Wert darauf legst, dass du Debuggen kannst und dir den Programmablauf an sich ansehen kannst, dann ist es soweit ok den Optimizer abzuschalten. Sagen sollte man auch noch, dass es Programmier-Fehler gibt, die sich bei abgeschaltetem Optimizer unter Umständen nicht zeigen. Eben weil das Fehler sind, bei denen man dem Optimizer zu viele Freiheiten lässt (zb. vergessenes volatile) Wenn eine nicht optimierte Version läuft, heißt das daher noch lange nicht, dass eine optimierte Version ebenfalls laufen wird. Daher muss man nach Einschalten des Optimizers noch Testläufe machen.
1 | void delay_ms(ms_t ms) |
2 | {
|
3 | _delay_ms(ms); |
4 | }
|
in eine extra Übersetzungseinheit und nur die mit Optimierung compilieren, der Overhead für den Call ist vernachlässigbar im Vergleich zu den 5ms Wartezeit? Warum ist _delay_ms eigentlich nicht von vornherein eine Bibliotheksfunktion?
Danke für eure schnelle Hilfe. Also ein par Dinge gehen jetzt schon, Aber der Aufruf von Funktionen in der Datei LCD.h klappt noch nicht so recht. Ich hab mal ein paar Zuweiseungen, sowie Portabfragen hineingeschrieben. sie werden offensichtlich auch ausgeführt. Allerdings hab ich keinen Pfeil, der auf den nächsten Befehl hinweidt. In Der Main geht das schon.
Haderlump schrieb: > steckt also noch in den Kinderschuhen. Sie ist in einer Datei "lcd.h" > ausgelagert. Und da man so etwa nicht macht, kommt damit auch der Debugger nicht zurecht. Schreib die Funktion in eine lcd.c, füge die dem Projekt hinzu, dann klappts auch mit den Debugger. Oliver
sebastians schrieb: >
1 | > void delay_ms(ms_t ms) |
2 | > { |
3 | > _delay_ms(ms); |
4 | > } |
5 | >
|
> in eine extra Übersetzungseinheit und nur die mit Optimierung > compilieren, der Overhead für den Call ist vernachlässigbar im Vergleich > zu den 5ms Wartezeit? Nein, das geht gar nicht. > Warum ist _delay_ms eigentlich nicht von vornherein eine > Bibliotheksfunktion? Sie ist eine /inline/-Funktion, denn nur so kann der Compiler brauchbar auch kurze Verzögerungen implementieren (für lange Verzögerungen waren sie nie gedacht). Für lange Verzögerungen würde noch helfen:
1 | void delay_ms(uint16_t ms) |
2 | {
|
3 | while (ms-- != 0) |
4 | _delay_ms(1); |
5 | }
|
Für kurze Verzögerungen hilft es dann nur noch, sich die Zyklenzahl zu Fuß auszurechnen und _delay_loop1()/_delay_loop2() explizit aufzurufen. Die sind unabhängig von der Optimierung, da sie direkt in eine inline-asm-Implementierung münden. Eine einzelne Datei separat mit anderer Optimierung zu compilieren ist aber nicht gerade das, was mit AVR Studio Spaß machen wird.
Danke, Oliver das wars. ich hab die LCD-Funktionen in eine C-Datei geschrieben und jetzt geht es. Ich dachte halt, die LCD-Routinen braucht man immer wieder und deshalb wollte ich sie in der Bibliothek ablegen. Ich wusste ja nicht, dass der Debugger damit nicht zurecht kommt. Aber schön, dass es dieses Forum gibt, alleine wäre ich da wohl nie drauf gekommen. Die Delay ist eine Bibliotheksfunktion. Das hab ich im Tutorial gefunden. Ich will noch timergesteuerte Delays machen. Da bei einer Heizungssteuerung lange Wartezeiten im Minutenbereich erforderlich sind, wäre das Programm sonst ja völlig blockiert (Anzeigen, Displayabfragen, Temperaturmessungen etc.). Vielen Dank nochmals an alle. Again what learned
Haderlump schrieb: > Ich dachte halt, die LCD-Routinen braucht man immer wieder und deshalb > wollte ich sie in der Bibliothek ablegen. Und somit, meintest Du, in ein .h-File ablegen. Mitnichten. Du schreibst jetzt hundert mal: „.h-Dateien sind keine Bibliotheken, sie beschreiben höchstens gelegentlich welche."
.h-Dateien sind keine Bibliotheken, sie beschreiben höchstens gelegentlich welche. .h-Dateien sind keine Bibliotheken, sie beschreiben höchstens gelegentlich welche. .h-Dateien sind keine Bibliotheken, sie beschreiben höchstens gelegentlich welche. .h-Dateien sind keine Bibliotheken, sie beschreiben höchstens gelegentlich welche. .h-Dateien sind keine Bibliotheken, sie beschreiben höchstens gelegentlich welche. .......... Den Rest hab ich woandes hingeschrieben In Demut und Reue bekenne ich meine Sünden. Sorry, bin noch Anfänger Nothing for ungood
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.