Hallo Gibt es bei der Interrupt-Routine für UART1-Empfang irgendwelche Besonderheiten zu beachten? (z.B. Reihenfolge beim setzen der Register oder so was?) Habe die Routine derzeit so programmiert, daß sie angesprungen wird, wenn ein Byte über RS232 empfangen wird.(Funktioniert auch!) In der Routine wird eine LED an- u. ausgeschaltet. Zu Beginn der "main" wird LED ausgeschaltet, so daß sie mit dem ersten empfangen Byte immer eingeschaltet wird.Das kann man mit dem Oszi auch sehen. Problem ist daß die LED aber nach 5 us wieder ausgeht. Dieses ein- u. nach 5us wieder ausschalten geschieht bei jedem gesendetem Byte?!
Wofür ist folgende Zeile im Interrupt: Wait1ms(50); Eine Wartezeit im Interrupt sollte grundsätzlich vermieden werden. Wo ist Wait1ms definiert? Dein Problem sieht danach aus, dass der Controller entweder ständig einen Reset bekommt. Dies kann z.B. an fehlender Stack-Initialisierung liegen. Oder Aufruf von software_reset(). Oder in main() ist die while(1)-Schleife nicht aktiv. Wenn main beendet wird, dann wird es sofort wieder neu gestartet - und führt damit die Initialisierung wieder komplett neu aus, also auch LED-Pin -> low. Stefan
Hab jetzt in die while(1) eine for-Schleife eingebaut mit der die LED interupt-gesteuert im Sec-Takt ein-7ausgeschaltet wird. (Funktioniert!) Sobald ich ein Byte sende verharrt die LED in ihrem Zustand. D.h. doch zum einen, daß die while(1) aktiv ist und zum anderen kein Reset ausgelöst wird, weil dann die LED ja wieder toggeln müßte.
>Sobald ich ein Byte sende verharrt die LED in ihrem Zustand. Schaltet der IR die LED nochmal oder nicht? Viellecit ist es sinnvoll, 2 unterschiedliche LEDs für den Test zu benutzen, dann wird Dein Problem vielleicht klarer. Hast Du den Stack korrekt initialisiert? Benutzt Du den Debugger für den M32C? Stefan
LED bleibt direkt in dem Zustand stehen in dem sie sich befindet, sobald ich am Rechner auf den Senden-Button klicke, schaltet also nicht mehr um. 2. LED nicht möglich, da es sich um eine fertige Appl. handelt. Benutze den IAR Compiler und flashe das Program direkt in den Controller.Debugger wird nicht benutzt. Zum Stack kann ich im Moment noch nichts sagen, habe das Bsp "toggle-led" von der Glyn-Homepage runtergeladen und alle Einstellungens so gelassen und nach und nach meinen Source dazu gemacht.
Dann wird der Code der IR-Routine wohl garnicht ausgeführt? Schau mal, ob die IR-Vektoren korrekt sind. Ob der Stack funktioniert, kannst Du brute-force testen: in main() eine Funktion (die nicht tun muss) aufrufen. Wenn Du danach nicht wieder in main() landest, ist der Stack nicht gesetzt. Ich habe beim M16C nur den nc30 benutzt. Aber auch mit dem IAR-Compiler sollte Debuggen möglich sein. Stefan
Hab in der while(1) nach der for-Schleife (Schleife zählt bis 5) für toggle-LED eine Funktion aufgerufen in der nichts drin steht. Led toggelt aber ununterbrochen weiter, demnach müßte der Stack gesetzt sein. In obiger Datei sind die Interruptvektoren. Da Timer-Int ausgeführt wird, müßten die wohl stimmen
in der RX_ISR wird die LED eingeschaltet, <Zitat> inByte = U1RB; //Daten aus Buffer holen P4 = LED_ON; //Port-Toggle </Zitat> (wobei //PORT-TOGGLE ja so nicht stimmt... "p4=~P4" wäre port-toggle) die ISR wird ausgeführt, und danach wird die Main Schleife wieder durchfahren, die LED geht wieder aus(toggle), die LED sollte doch also bei jedem empfangenen Zeichen aufblitzen, was du ja am Oszi bestätigen konntest. Ich denke, hier liegt kein Fehler vor. die 5us sind einfach die Zeit, die vergeht, bis deine Main Schleife wieder durchlaufen wird.
an Axel Das da jetzt P4 = LED_ON steht, war nur ein Test zwischendurch. Vorher stand da p4=~P4. Ergebnis war das gleiche.
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.