Hallo, ich versuche derzeit die LED auf dem µC blinken zu lassen. Allerdings verstehe ich nicht ganz wie man die Bits setzen muss. Die LED ist über EXT1-11, also PE4 verbunden. Mein Code sieht derzeit so aus: int main(void) { DDRE = 0b00010000; PORTE = 0b00010000; while (1) { PORTE &= ~ (1<<PE4); _delay_ms(500); PORTE |= (1<<PE4); _delay_ms(500); } } Ich spreche den Port und das Register an , und in der Endlosschleife soll die LED an und nach einem Verzug von einer halben Sekunde wieder angeschaltet werden. Was mache ich hier falsch ? Die LED leuchtet zu beginn, geht dann kurz aus und leuchtet wieder.Das ist aber auf den Reset zurückzuführen.
Maximilian S. schrieb: > Die LED ist über EXT1-11, also PE4 verbunden. Der 90CAN128 hat kein EXT1-11, was für eine Platine ist das und wie ist die Beschaltung? Dein Programm-Fragment ist zumindest unvollständig, ergänze bitte noch den Rest den Du hast und mit dem das ohne Fehler oder Warnungen compiliert. Das kann man zwar raten, ist aber nicht ungedingt das gleiche. In dem Fragment sehe ich erstmal keinen Fehler. Auf was für einem Takt soll der Controller laufen und ist F_CPU entsprechend definiert, damit die _delay() Funktion auch richtig arbeiten kann? Sind die Fuse-Bits entsprechend gesetzt? Hast Du mal länger gewartet, ob das nicht doch blinkt? Wenn der Controller eigentlich auf 16 MHz laufen sollte, aber noch auf 1 MHz läuft, dann sind das ja 8 Sekunden statt 0,5. Ist das Programm überhaupt im Controller? Wie sieht die .lss Datei zu dem Programm aus? Maximilian S. schrieb: > Die LED leuchtet zu beginn, geht dann kurz aus und leuchtet wieder.Das > ist aber auf den Reset zurückzuführen. Hmm, klingt seltsam.
Hallo Rudolph, danke für deine Rückmeldung. Aber ich hab das Problem gelöst und es funktioniert jetzt alles :) Es ist ein AT -90Can128, da gibts Ext1-11. Es kommen keine Fehler , es funktioniert nur nicht, was an den falsch gelegten Bits lag. Ansonsten sind nur Bibilotheken eingefügt. An die Taktfrequenz hab ich gar nicht gedacht. Es wird bei 16 MHZ gearbeitet, allerdings konnte ich jetzt keine Verzögerung festellen. Trotzdem guter Einwurf! Ich arbeite mit Atmel, da kann man die AVR programmieren und den Reset auch an-/ ausschalten. Die Lösung war: DDRE = 0b11111111; PORTE = 0b00000000; while(1){ PORTE |= (1<<PE4); _delay_ms(500); PORTE &= ~(1<<PE4); _delay_ms(500); } Trotzdem Danke für deine Einwürfe :)
Solltest Du künftig mehr mir Mikrocontrollern machen, dann gewöhne Dir bitte einen neuen "Stil" an. Wartefunktionen sind in der Steuerungstechnik ein absolutes NoGo! Man baut eine Schleife, die regelmäßig (z.B. alle 10ms) aufgerufen wird (Timer oder so) und baut sich darin zusätzliche Zähler, aus deren Zählstand Du ableitest, ob die LED nun leuchten soll oder nicht. Nur so kann das System auf alle Signale von außen immer und immer mit etwa der gleichen Reaktionszeit reagieren und irgendetwas steuern. D.h. jeder Durchlauf muss immer völlig "durchlaufen" und darf niemals auf irgendein Ereignis warten. Wenn dies notwendig sein sollte, dann wird ein Bit gesetzt, das bei jedem weiteren Durchlauf zusammen mit der "mach weiter" Bedingung abgefragt wird...
Maximilian S. schrieb: > Es ist ein AT -90Can128, da gibts Ext1-11. Wenn das eine Platine sein soll, dann vielleicht, die sollte dann aber nicht genau so wie der Controller heissen. Die Suche im Datenblatt vom AT90CAN128 nach "Ext1" hat Null Treffer. > Ich arbeite mit Atmel, da kann man die AVR programmieren und den Reset > auch an-/ ausschalten. Ich auch, an denen wackelt nichts rum durch den Reset. Ja, die Portpins werden hochohmig, dadurch ginge ein LED im Reset aus. Aber an-aus-an durch den Reset - eher nicht so. > Die Lösung war: > > DDRE = 0b11111111; > PORTE = 0b00000000; > > while(1){ > PORTE |= (1<<PE4); > _delay_ms(500); > PORTE &= ~(1<<PE4); > _delay_ms(500); > } Sorry, aber das passt nicht zusammen. Das Fragment unterscheidet sich in dem vorherigen nur dadurch, dass sinnlos gleich der komplette Port auf Ausgang gestellt wird. Das zum Anfang PE4 auf Null gesetzt und dann gesetzt und wieder gelöscht wird ändert im Grunde gar nichts an dem Programm. Das hier macht übrigens das gleiche: [c] DDRE = (1<<PE4); while(1) { PINE = (1<<PE4); _delay_ms(500); } [/code] Nur auch nicht, wenn drum herum was nicht stimmt.
Servus Zusammen, Kurz zum Hintergrund: Max Arbeitet sich grad in das Thema MC ein. Ich betreu ihn und hab ihn erstmal machen lassen. Unter anderem auch damit er sich den Umgang mit dem Forum hier angewöhnt ;-). Da das Projekt am Ende seinen Schaltzustand eh nur ändern wird wenn eine Botschaft auf dem Can eintrifft und das LED Blinken nur ein Hardwaretest ist hab ich noch nichts gesagt. Natürlich wirds später keine solchen Konstrukte mehr geben. @Rudolph: Du hast komplett Recht. Er hat ein Olimex AT90-CAN Entwicklungsboard und auf dessen Platine ist der MC Port als Ext 1-11 rausgeführt. Der MC läuft tatsächlich mit 16MhZ, Fuses stimmen auch. @Rudolph und Fire Heart: Auch von mir nochmal Danke für die konstruktive Hilfestellung/Kritik.
ErdBaer schrieb: > Er hat ein Olimex AT90-CAN Entwicklungsboard Okay, das erklärt die Verschaltung der LED, Null ist an, Eins ist aus. Und schön, dass es jetzt funktioniert wenn auch noch nicht geklärt ist, warum es denn nicht funktioniert hat. :-) Wenn die LED zwischen zwei Portpins hängen würde, dann wäre es jetzt geklärt, warum es hilft den kompletten Port auf Ausgang zu schalten. Da die LED aber nur zwischen Plus und einem Pin geschaltet ist würde ich auch einen Azubi oder Praktikanten nicht mit der Antwort bisher vom Haken lassen. :-)
Der Fehler lag wie immer ganz woanders. Max hat die ganze Zeit in einer Datei im Editor rumgewurschtelt die gar nicht mit kompiliert wurde ;-) und den Geänderten Code dann in die richtige Datei kopiert. Was lernen wir daraus? Immer nur eine Änderung und dann testen.
ErdBaer schrieb: > Der Fehler lag wie immer ganz woanders. > > Max hat die ganze Zeit in einer Datei im Editor rumgewurschtelt die gar > nicht mit kompiliert wurde ;-) und den Geänderten Code dann in die > richtige Datei kopiert. > > Was lernen wir daraus? Immer nur eine Änderung und dann testen. Sowas hatte ich auch mal bei einem großen PC Projekt. Ich hab den Fehler gesucht und gesucht und gesucht. Irgendwann ist es mir zu blöd geworden und ich hab ein paar Zeilen Müll in den Code geschrieben ... und siehe da, auch das ließ sich compilieren! Dann war's klar. Allerdings war die Sache noch etwas subtiler, weil ich's irgendwie geschafft hatte, das Datum der Source-Datei auf eine zukünftige Zeit zu stellen. Somit war für den Compiler nicht "veraltet" und er hat sie nicht mehr mitcompiliert.
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.