Hallo Folgendes ich bin derzeit am Uc lernen und lese immer das man Interrupts nach Möglichkeit vermeinden sollte, gerade bei Echtzeitbetriebssystemen.. Ich habe einen timer der alle 10ms einen Interrupt gibt und in der isr Frage ich einen taster ab, da ich gelesen habe das die effizienter ist.. Wäre es nun sinnvoll statt einen uart Interrupt die uart in der timer isr zu Pollen? Mfg
papaschlumpf schrieb: > Folgendes ich bin derzeit am Uc lernen Falls mit Uc ein Mikrokontroller gemeint ist, schlage ich vor auf einer deutschen Tastatur [Alt Gr] + [M] für µ zu drücken und danach ein großes C zu schreiben. Ist so die allgemeine Abkürzung µC für Mikrokontroller.
papaschlumpf schrieb: > Hallo > Folgendes ich bin derzeit am Uc lernen und lese immer das man Interrupts > nach Möglichkeit vermeinden sollte, gerade bei > Echtzeitbetriebssystemen.. Was du vermeiden sollst, sind exzessive Code-Arien in den Interrupt Routinen. Und das sind vor allen Dingen Warteschleifen. Ein bischen Daten hin und her schaufeln, ein wenig rechnen, ist normalerweise kein Problem. Du sollst in erster Linie wissen was du tust und bercksichtigten, dass Dogmen alle "Du darfst nicht" fast immer falsch sind. Mit Mass und Ziel an die Sache rangehen, Hausverstand einschalten, dann lösen sich die meisten Dinge von alleine in Luft auf.
ja danke für deinen beitrag.. vom handy ist das natürlich nicht so leicht zu schreiben..
papaschlumpf schrieb: > Wäre es nun sinnvoll statt einen uart Interrupt die uart in der timer > isr zu Pollen? Denk mal kurz nach, wie lange die UART für den Empfang eines Bytes bei einer Beispielbaudrate von (niedrigen) 9600 Baud braucht. Ich geh einfach mal davon aus, dass der verwendete Prozessor keinen größeren internen Empfangspuffer als 1 Byte hat (was ja bei den kleineren meist der Fall ist). Un nun überdenk mal was passiert wenn du nur alle 10 ms die UART pollst aber stetig Daten ankommen. Damit sollte die Frage vom Tisch sein.
papaschlumpf schrieb: > gerade bei > Echtzeitbetriebssystemen.. Ein Interrupt darf natürlich einen Controller nicht so lange für anderes sperren, dass die Echtzeit-Bedingungen nicht mehr erfüllt werden können. Wie Karl Heinz schon schrieb ist das aber selten ein Problem, wenn man in der ISR nur das allernötigste macht.
Wenn Du die UART nur alle 10ms pollst, kriegst Du maximal 100 Baud hin! => Ich empfehle unbedingt den UART RXD-Interrupt zu verwendenden. Wie schon gesagt wurde: Wichtig ist, dass die ISR kurz ist, bzw. ein Minimum an CPU-Zeit belegt. >Falls mit Uc ein Mikrokontroller gemeint ist, schlage ich vor auf einer >deutschen Tastatur [Alt Gr] + [M] für µ Ich schreibe immer uC, weil das mit dem [Alt Gr] + [M] meist nicht tut.
Ganz klar UART-Rx-Int. Beim senden kannst du dir ja Zeit lassen, aber beim Empfang solltest du nichts verpassen. Rx-Int ist der klassische Ansatz für einen Ringpuffer: Kurze, knappe Int-Routine die das empfangene Byte (bei kleinem µC, z.B. AVRs) oder die empfangenen Daten (bei größeren µC mit Empfangspuffer>1Byte, z.B. ARMs) in einen Puffer wegschreibt. Den Inhalt des Puffers wertest du dann außerhalb der ISRs aus. Für den Anfang wäre es schon eine gute Übung, wenn du ein UART-Echo so aufbaust: Empfangene Daten in Puffer schreiben. Puffer auf Inhalt prüfen und an der UART wieder absenden. Für den AVR gibt es dann schon fertige Libraries, welche den Rx/Tx-Int benutzen und dir auch den Ringpuffer abnehmen (pfleury UART lib).
Okee vielen dank schonmal für diese info. dann habe ich anscheined etwas falsch verstanden. aber wie realisiere ich z.b.: in bei einem echtzeitbetriebssystem alá ucos2 eine uart kommunikation? auch via interrupt? oder wäre hier ein pollen sinnvoller?? das taster abfragen, würde ich im systemtick reinpacken. Konkret geht es um einen Atmega1284p. neben den Uart Interrupt wäre noch einen frequenzmessung via capture compare pin enthalten. Zum einen frage ich mich ob es sinnvoll ist ein Echtzeitbetriebssystem zu verwenden wenn man "so viele" interrupts benötigt, andererseits muss es möglich sein, die frage die sich mir nur stellt ist, wie man diese Schnittstellen richtig anspricht und dabei aber trotzdem das Echtzeitverhalten behält, weil bei "zeitkritischen" Anwendungen verwendet man ja das define OS_ENTER_CRITICAL , was ja nur cli() oder bei EXIT das sei() ist, aber wenn man dies verwendet unterbindet man ja erst recht wieder die Interrupts. Sinnvoller wäre hier nur den Timer anzuhalten danach die Uart abzuarbeiten z.b befehl senden und empfangen oder die Frequenzmessung starten und dann wieder den Timer weiter laufen zu lassen.. allerdings wäre dann das Echtzeitverhalten weg. Mfg
papaschlumpf schrieb: > lese immer das man Interrupts > nach Möglichkeit vermeinden sollte Das Einfluß von Interrupts läßt sich mit ein wenig Aufwand vorher berechnen. Damit kann man den Worst-Case einplanen und das System entsprechend auslegen. "Echtzeit" bedeutet nicht, daß das System sofort reagiert, sondern innerhalb einer bestimmten, genau spezifizierten Zeit. Ein Timer-Interrupt, der alle 10ms max. z.B. 100µs Laufzeit benötigt, ist absolut deterministisch. Ein UART-Interrupt kann max. so oft kommen, wie es die Baudrate erlaubt (abgesehen von Spezialfällen, daß z.B. auch Fehlerzustände den Interrupt auslösen können), also auch deterministisch. Schwierig wird es bei PIN-Interrupts: ein floatender Pin kann das System komplett lahmlegen, wenn er schwingt. Hier helfen Hardware- oder Software-Tiefpaß-Filter (PIN-Interrupt nach Trigger für bestimmte Zeit sperren). Letztendlich legst Du das System so aus, daß Dein Timing noch sicher okay ist, wenn alle Interrupts mit maximaler Frequenz kommen.
papaschlumpf schrieb: > Konkret geht es um einen Atmega1284p. > neben den Uart Interrupt wäre noch einen frequenzmessung via capture > compare pin enthalten. Welche maximale Grenzfrequenz? Das ist dein Auslegekriterium. Wenn genug Zeit bleibt, dass die Auswertung des Capture Ereignisses nicht sofort passieren muss, sondern ein paar Taktzyklen warten kann, dann ist eine zwischenzeitlich laufender USART-ISR ja kein Problem.
> Sinnvoller wäre hier nur den Timer anzuhalten danach die > Uart abzuarbeiten z.b befehl senden und empfangen > oder die Frequenzmessung starten und dann wieder den Timer > weiter laufen zu lassen.. allerdings wäre dann das Echtzeitverhalten > weg. Ich hab da so ein Gefühl. Und zwar das Gefühl, welches ab und an hier im Forum aufkommt, wenn man mit µC-Neulingen spricht. Kann es sein, dass du die Leistungsfähigkeit deines µC ganz rigoros unterschätzt? Das ist nicht so, dass der eine halbe Stunde lang mit der Bearbeitung eines per UART empfangenen Zeichens, um es in einen Ringbuffer zu bugsieren, beschäftigt ist! Die notwendigen Aktionen bei einem Cpature Interrupt sind unaufwändig und brauchen 10, vielleicht 20 Taktzyklen! Bei 16Mhz sind das ein paar mykro-Sekunden!
#Die# allein selig machende Technik gibt es nicht. Als Faustregel kann man sagen: Für alles, wo der Benutzer involviert ist, reicht normalerweise Pollen völlig aus. Denn Benutzer sind von Natur aus langsam. Und in der Praxis hat man auch oft einen Hybridansatz. Gerade USART ist da ein gutes Beispiel. Mittels Interrupt räumt man die Hardware frei und speichert die Zeichen in einem Ringbuffer zwischen, von wo sich dann die Hauptschleife mittels Pollen die Zeichen gemütlich abholen kann, wenn Zeit ist.
papaschlumpf schrieb: > gerade bei > Echtzeitbetriebssystemen.. Ein Echtzeitbetriebssystem sollte schon entsprechende Treiber für die üblichen Ressourcen beinhalten. Dadurch, daß alle Tasks aus Programmierersicht voll parallel ablaufen, ist die Kontrolle von Ressourcen nen ganzen Zacken komplizierter und ein direkter Zugriff nicht mehr möglich. Es muß alles über Treiber erfolgen, auch sogar ein simples Pinwackeln. Und globale Variablen zur Parameterübergabe gibt es ja eh nicht, nur Mutexe und Semaphoren. Im Prinzip wie bei Windows, nur etwas schlanker. Falls ein Treiber nicht existiert, sollte in der Doku zu dem BS stehen, wie man einen Treiber erstellen muß. Peter
papaschlumpf schrieb: > allerdings > wäre dann das Echtzeitverhalten weg. Ein Echtzeitverhalten ist nicht an ein BS gebunden. Es ist sogar erheblich einfacher die Echtzeit zu bestimmen, wenn kein BS verwendet wird. Das ist einfach die worst case Summe aller Tasks in der Mainloop und aller Interrupts, d.h. der längst mögliche Durchlauf der Mainloop. Eine Mainloop funktioniert quasi so, wie eine SPS. Nimmt man ein BS, ist das komplizierter. Es können sich Prioritätsinversionen oder Blockierungen ergeben und damit bestimmte Tasks nie oder nur selten zum Zuge kommen. Ich würde sogar sagen, mit BS läßtt sich 100%-ige Echtzeit nicht mehr garantieren. Die Abhängigkeiten sind nicht mehr kontrollierbar. Und deshalb ruckelt eben machmal das Video unter Windows und der Ton stottert. Peter
Die Frage die man sich bei einem doch eher kleinen µC stellen sollte ist, ob man überhaupt ein Betriebssystem braucht, oder besser alles vom Programm an kontrolliert. Mit BS ist die Programmierung in einigen Fällen eventuell etwas einfacher und portabler. In einfachen Fällen ist es aber direkt von Hand einfacher, und sofern man es richtig macht kann man von Hand auch schneller sein.
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.