|
Anzeige
|
ISR() wird dauernd aufgerufen?
Gast
#3174829
hi, ich lasse im Hauptprogramm nur LEDs blinken. Wenn ich mit einem Terminalprogramm ein Zeichen über RS232 schicke wird auch die ISR(USART_RXC_vect) aufgerufen.Nur,jetzt ist es so das die ISR() dauerhaft aufgerufen wird. Freue mich über jeden Beitrag
Gast
#3174842
Hole das Zeichen direkt im interrupt aus dem UDR-Register. Lies mal im Datenblatt nach, was genau passiert, wenn der Interrupt auftritt und warum der Interrupt auftritt. Und mache auch keine delays im interrupt.
Gast
#3174860
tim schrieb: > Nur,jetzt ist es so das die ISR() dauerhaft aufgerufen wird. Ist doch auch logisch. Die ISR wird aufgerufen, weil ein Zeichen zur Abholung bereitsteht. Nach Ablauf deiner ISR hat sich daran nichts geändert. Hallo, noch eine weitere Anmerkung; lass doch den Compiler / Präprozessor die Uartwert für UBRR ausrechnen. Zumindest das ist falsch :
Passender wäre so etwas:
Du solltes auch die Fehler der Baudrate bzgl. der gewählten Quarzfrequenz beachten ! Für einen 8MHz Quarz ist 19200 optimal:
Gast
#3174871
Danke RXC ist solange 1 bis UDR ausgelesen wurde.
Gast
#3174879
Uwe S. schrieb: > const uint16_t BAUDRATE = 19200; > const uint16_t UBRR = (uint16_t)(1.0 * F_CPU 16 BAUDRATE -0.5); Warum Variablen? Die belegen dann nur unnötig RAM. Mit einem Makro geht das doch genaus gut. Hallo, das ist ein Beispiel und der Compiler legt hier keine Variablen an, da sie vom type "const" sind - also unveränderlich ! Der Vorteil ist, man(n) sieht sofort die Datentypen und der Compiler ist in der Lage einen Typeüberprüfung durch zu führen. Ich denke, diese Umstände waren Dir nicht bekannt. ISR Flag wird gelöscht sobald du UDR ausliest also unsigned char newChar; newChar = UDR; //löscht das Flag Gruß Jonas Uwe S. schrieb: > Hallo, > > das ist ein Beispiel und der Compiler legt hier keine Variablen an, da > sie vom type "const" sind - also unveränderlich ! Doch. Das sind Variablen. Das const bedeutet nur, dass der Compiler überwacht, dass du nicht den Wert änderst (was man aber auch umgehen kann) und das er den Wert auch direkt verwenden kann, wenn er das will. Aber erst mal sind das Variablen, wie alle anderen auch. Unter anderem auch daran erkennbar, dass man auf sie einen Adressoperator anwenden kann und sich aus anderen Files mittels extern auf sie beziehen kann. Ob der Compiler in weiterer Folge in der Lage ist, diese Variablen wegzuoptimieren, steht auf einem anderen Blatt. Im gegenständlichen Fall muss das nicht unbedingt so sein. Wären die Dinger static, würden die Chancen steigen, dass der Compiler/Linker die Variablen tatsächlich eliminiert. > Der Vorteil ist, man(n) sieht sofort die Datentypen und der Compiler ist > in der Lage einen Typeüberprüfung durch zu führen. Das zweifellos.
Gast
#3175545
Uwe S. schrieb: > Hallo, > > das ist ein Beispiel und der Compiler legt hier keine Variablen an, da > sie vom type "const" sind - also unveränderlich ! Mit dem const versprichst du dem Compiler, daß du sie nicht änderst, aber Variablen sind es trotzdem. In C gibt es keine echten Konstanten. Das ist ja auch der Grund, warum man meistens Makros benutzt und eben nicht const. > Der Vorteil ist, man(n) sieht sofort die Datentypen und der Compiler ist > in der Lage einen Typeüberprüfung durch zu führen. Auch bei einem #define hat der Wert einen Typ, also kann der Compiler den auch prüfen, genauso, als ob es eine Variable wäre. Man sieht der Makro-Definition den Typ vielleicht nicht unbedingt so leicht an, was man aber mit einem Cast beheben könnte. Den hat dein Beispiel eh schon. Das könnte mit einem #define so aussehen:
Da erkennt man den Typ genauso schnell wie bei deinem
> Ich denke, diese Umstände waren Dir nicht bekannt.
Mir sind die Umstände schon bekannt, dir aber anscheinend nicht so ganz.
Antwort schreibenBitte melde dich an, um einen Beitrag zu schreiben. |
Anzeige
|
