Hallo miteinander Beim druchstöbern einer Zusammenfassung von Batchelorarbeiten einer FH viel mir auf, dass überall wo ein uC eingesetzt wurde ebenfalls ein das FreeRTOS genutzt wird. Da für mich das absolutes Neuland ist wollte ich einmal fragen, ob und wann sich den soetwas lohnt: Meistens werden auf den uCs sehr viel mit Peripherie gerabeitet (Timer, USART, SPI, I2C, I2S, OneWire...). Da hier bei neueren Modellen der DMA eine grosse Hilfe ist, können die Programme schon sehr optimiert geschrieben werden. Momentan bin ich an einem Programm für ein Cortex-M0 welcher alle 1ms kommunizieren muss (und alle Daten müssen aktuell sein), da hier die übergeordnete Verbindung EtherCat ist. Das heisst, das alles andere zwischendruch passieren muss. Nun bin ich mit dem Protokoll und dem übrigen Code schon knapp unter 1ms angelangt bin. Da jetzt die sehr nützliche Lib von ST viele Get- und Set-Funktionen hat, welche einem das Arbeiten und Portieren erleichtern sollen. Nur wird dadurch die Laufzeit des Programms erheblich reduziert. Also, was kann ich mir unter einem RTOS vorstellen? Dass die Tasks wirklich genau dann ausgeführt werden, wann sie sollen? Interrupt-Handling ist ja dann wohl nicht mehr möglich oder? Gruss
:
Verschoben durch Moderator
> Also, was kann ich mir unter einem RTOS vorstellen? Dass die Tasks > wirklich genau dann ausgeführt werden, wann sie sollen? FreeRtos ist in der Tat ein Echtzeitbetriebssystem. > Interrupt-Handling ist ja dann wohl nicht mehr möglich oder? Das ist schon möglich. Ich bin jetzt aber nicht so 100% im Thema drinn. Schau mal auf der HP von FreeRtos. Da gibt es Infos. Es gibt auch Bücher über FreeRtos wo alles genau erklärt wird.
Taskswitches sind ja auch Interrupts. Die Interrupts generieren Events, und die Task warten auf Events. dh die Task werden zumindest angestossen durch interrupts geswitched. Bei kleineren Prozessoren laesst man ein RTOS weg, und macht's zu Fuss. Klein bedeutet hier mit weniger als 64k code.
Patrick B. schrieb: > Beim druchstöbern einer Zusammenfassung von Batchelorarbeiten einer FH > viel mir auf, dass überall wo ein uC eingesetzt wurde ebenfalls ein das > FreeRTOS genutzt wird. Im Hobby- und Unibereich wird FreeRTOS eingesetzt weil es kostenlos ist. Dagegen wird im industriellen Einsatz eher ein OS wie z.B. SEGGER embOS eingesetzt. Moderne Microcontroller werden immer leistungsfähiger und damit ist es möglich auch komplexere Aufgaben damit zu erledigen. D.h. dann aber auch das verschiedene Aufgaben gleichzeitig ausgeführt werden müssen, also z.B. TCP/IP Kommunikation im Hintergrund und Bedienung eines LCDs im Vordergrund. Und genau da hilft dir ein echtzeitfähiges RTOS. Du musst dir dann keinen Gedanken mehr machen ob das Timing deiner Softwareteile noch passt sondern teilst die einzelnen Aufgaben in einzelne Tasks auf. Eine gute Erklärung findest du auch z.B. auf den ersten Seiten des embOS Manuals: http://segger.com/admin/uploads/productDocs/UM01001_embOS_Generic.pdf > Also, was kann ich mir unter einem RTOS vorstellen? Dass die Tasks > wirklich genau dann ausgeführt werden, wann sie sollen? Im Prinzip ja, dabei haben die Tasks noch eine Priorität, die Regel lautet dann, die Task mit der höchsten Priorität, die ausführungsbereit ist, wird ausgeführt.
Taugenichts schrieb: > Taskswitches sind ja auch Interrupts. Die Interrupts generieren Events, > und die Task warten auf Events. dh die Task werden zumindest angestossen > durch interrupts geswitched. Nicht ganz richtig, ein preemptiver Taskwechsel wird durch einen Interrupt ausgelöst, ein kooperativer Taskwechsel aber einfach durch die Task selber, weil sie z.B. ein OS_Delay() aufruft. > Bei kleineren Prozessoren laesst man ein RTOS weg, und macht's zu Fuss. > Klein bedeutet hier mit weniger als 64k code. Kann man auch so nicht pauschal sagen, es kommt immer auf die Applikation an. Auch hier gibt es genug Beispiele wo ein OS auch bei wenig Speicher sind macht.
Ob IRQ handling möglich ist, kommt auf das RTOS an. Bei Keil RTX geht es. Wie es bei FreeRTOS aussieht weiss ich nicht. Ich würde bei umfangreicheren Projekten ein RTOS nicht mehr missen wollen.
IRQ Handling ist immer möglich sonst macht ein OS keinen Sinn. Die Frage ist eher gibt es noch ein IRQ Handling welches vom OS nicht beeinflußt wird. Das gibt es z.B. bei embOS, dort gibt es es Zero Latency Interrupts, was letztlich heißt das diese Interrupts nie vom OS gesperrt werden (üblicherweise über Interrupt Prioritäten gelöst).
Taugenichts schrieb: > > Bei kleineren Prozessoren laesst man ein RTOS weg, und macht's zu Fuss. > Klein bedeutet hier mit weniger als 64k code. Quark. Ob ein RTOS sinnvoll ist oder nicht hängt von der Anzahl parallel notwendiger Tasks ab, nicht von der Speichergröße.
Hugo schrieb: > Die Frage ist eher gibt es noch ein IRQ Handling welches vom OS nicht > beeinflußt wird. Die Cortexe können aufgrund ihrer Interrupt-Struktur beides bieten: (1) Interrupts, die RTOS-APIs nutzen dürfen und daher auch mal zweitweilig vom RTOS ausgesperrt werden. (2) Interrupts, die keine RTOS-APIs verwenden und vom RTOS nicht beeinflusst werden. Ich meine, dass FreeRTOS beide Varianten unterstützt.
Hugo schrieb: > IRQ Handling ist immer möglich sonst macht ein OS keinen Sinn. > Die Frage ist eher gibt es noch ein IRQ Handling welches vom OS nicht > beeinflußt wird. Das gibt es z.B. bei embOS, dort gibt es es Zero > Latency Interrupts, was letztlich heißt das diese Interrupts nie vom OS > gesperrt werden (üblicherweise über Interrupt Prioritäten gelöst). Stimmt nicht. Man kommt auch sehr gut ohne interrupts aus. Wir verwenden in unserem Flight-Control-System (bis auf den Timer für das OS) keine Interrupts. Diese haben die sehr unangenehme Eigentschaft, das Verhalten des Systems bezüglich Timing schwer vorhersagbar zu machen. Entsprechend teuer bis unmöglich wird die Analyse.
EFA schrieb: > Stimmt nicht. > Man kommt auch sehr gut ohne interrupts aus. Hatte ja auch keiner behauptet, das du welche benutzen musst, die Aussage war ja nur, das man es kann. > Wir verwenden in unserem Flight-Control-System (bis auf den Timer für > das OS) keine Interrupts. Diese haben die sehr unangenehme Eigentschaft, > das Verhalten des Systems bezüglich Timing schwer vorhersagbar zu > machen. Entsprechend teuer bis unmöglich wird die Analyse. Es kommt sicher auf die Applikation an, was mam machen möchte. Aber generell würde kein Interrupt bedeuten, das man pollen muss bis irgendein Ereignis auftritt und das macht keinen Sinn. Der übliche Weg ist tatsächlich das ein Interrupt eine Task aufweckt und diese dann irgendwas macht. D.h. die Task wird nur aktiv wenn sie auch etwas zu tun hat. Anders wäre z.B. ein TCP/IP Stack nicht handelbar oder möchtest du dauernd pollen, ob neue Daten da sind?
nicht ganz so hart, wie der Blogtitel klingt http://embeddedgurus.com/state-space/2010/04/i-hate-rtoses/
Tester schrieb: > EFA schrieb: >> Stimmt nicht. >> Man kommt auch sehr gut ohne interrupts aus. > Hatte ja auch keiner behauptet, das du welche benutzen musst, die > Aussage war ja nur, das man es kann. > >> Wir verwenden in unserem Flight-Control-System (bis auf den Timer für >> das OS) keine Interrupts. Diese haben die sehr unangenehme Eigentschaft, >> das Verhalten des Systems bezüglich Timing schwer vorhersagbar zu >> machen. Entsprechend teuer bis unmöglich wird die Analyse. > Es kommt sicher auf die Applikation an, was mam machen möchte. Aber > generell würde kein Interrupt bedeuten, das man pollen muss bis > irgendein Ereignis auftritt Vollkommen richtig erkannt :) > und das macht keinen Sinn. Warum nicht? Damit kann ich genauso meine funktionalen Anforderungen abdecken. > Der übliche Weg > ist tatsächlich das ein Interrupt eine Task aufweckt und diese dann > irgendwas macht. Tatsächlich ist das der Weg, wenn eine genaue Aussage und ein formaler Nachweis bzgl. Timing nicht gefordert wird. > D.h. die Task wird nur aktiv wenn sie auch etwas zu tun > hat. Anders wäre z.B. ein TCP/IP Stack nicht handelbar oder möchtest du > dauernd pollen, ob neue Daten da sind? Es geht hier ja generell nicht um besser oder schlechter, beide Verfahren haben Vor- und Nachteile.
Was macht ein System mit ausschliesslich Timerinterrupts denn sinnvolles ? Keine Interrupts bedeutet fuer mich keine Peripherie, keine Kommunikation.
Taugenichts schrieb: > Was macht ein System mit ausschliesslich Timerinterrupts denn sinnvolles > ? Keine Interrupts bedeutet fuer mich keine Peripherie, keine > Kommunikation. Wieso sollte weder Peripherie noch Kommunikation möglich sein? Mit Polling und dem entsprechenden Systemdesign ist das kein Problem. Und nochmal: Ich sage nicht, dass die eine oder andere Methode besser ist (Interrupt vs. Polling). Ich sage nur, dass man durchaus komplexe Systeme (unser Flugkontrollrechner besteht aus 200K Lines of C-Code) ohne Interrupts bauen kann.
Ich benutze ein sehr rudimentaeres RTOS: scmRTOS. Es ist richtig, dass ich beim Einsatz eines RTOS weniger Interrupts benutzte. Aber Kommunikation mit der Ausserwelt mit Polling kann ich mir jetzt irgendwie nicht vorstellen. Vielleicht wenn die Peripherie einen grossen Buffer hat und die Geschwindigkeit sehr gering ist?
OH, besten Dank für die vielen Antworten. Unter einem OS stelle ich mir sowas wie Linux oder Windows vor, einfach etwas abgespeckt. Und Windows ist kein RT, selbst bei Linux kann ich mir das schlecht vorstellen. Setzt ein OS den CPU in den sleep-mode wenn es nichts zu tun hat? Damit wäre noch der winzige Vorteil von etwas Stromsparen, aber da die Peripherie ja ständig laufen muss um das OS mit den entsprechenden Daten zu bedienen, ist dies ja winzig. Wie kann ich mir das Vorstellen beim Aufbau? Eine Init-Funktion die die nötige Peripherie einschaltet, und dann werden alle Interrupts angesprungen, die genutzt werden, oder ist da schon alles Ein? Denn bei letzterem kann nicht mehr die Rede von einem RTOS sein. Den einzigen wirklichen Grund für ein OS ist für mich nur die Portierbarkeit, da selbst grosse Programme bei entsprechendem Design sehr gut ohne OS aufgebaut und gewartet werden können. Und die Geschwindigkeit ist allemal höher, weil jeder Jump-Aufruf bedeutet wiederum Zeitverlust, was ein RTOS nicht haben darf. Beim Interruptereigniss will ich ja sofort reagieren können und nicht noch eine Funktion aufrufen, welche dann wieder etwas macht, bis dann am Schluss vieleicht einmal mein Event-Handler angesprochen wird. Unsere Regler auf dem Cortex-M4 laufen alle ohne RTOS und sind auch nicht gerade klein. Wenn ich jetzt einmal ein Bastelprojekt von mir ansehe auf dem SMT32F401, dann läuft dort die USB-Kommunikation, ein Touch-Display, SD-Karte, SPI und I2C Sensoren und noch die normalen GPIOs. All das ohne ein OS und es wird genau dann etwas gemacht, wenn ich es will. Und das USB muss ich halt nur Pollen auf ein Flag, ob meine Daten da sind. Aber ein OS macht das im Kernel ja nicht anders, da hier das ganze Error-Handling noch hinzukommt. Ich will ja die Nutzdaten und da interessiert es mich ja nicht, ob die Übertragung 2x durchgeführt werden musste. Oder liege ich hier mit meiner Meinung komplett falsch?
Patrick B. schrieb: > Also, was kann ich mir unter einem RTOS vorstellen? Als allererstes stelle dir bitte NICHT vor, daß all diese kleinen RTOS'se auch nur eine annähernde Ähnlichkeit mit einem richtigen Betriebssystem wie Windows o.ä. haben. Im Prinzip sind das alles nur Scheduler mit mehr oder weniger Semaphorenhandling. Zur benutzung stell dir einfach vor, du hast in deinem Programm eine Anzahl Funktionen so etwa in der Art void MyFunc1 (void) {...} void MyFunc2 (void) {...} void MyFunc3 (void) {...} usw. und nachdem du in main alle nötigen Initialisierungen gemacht hast, registrierst du im RTOS, was du als eine Anzahl von C-Quellen zu deinem Programm hinzulinkst, dann deine Funktionen, etwa so (ganz grob dargestellt): StarteThread(MyFunc1, Priority_1); StarteThread(MyFunc2, Priority_5); StarteThread(MyFunc3, Alle_5_Sekunden); usw. Ich sag's mal so: RTOS'se sind ein nettes akademisches Spielzeug, weswegen sie dort auch gern für jeden Schnullifax benutzt werden. Im normalen Leben sollte man hingegen sich erstmal gründlich überlegen, ob man im konkreten Falle so ein RTOS auch wirklich braucht - oder ob man bloß zu doof ist, nichtblockierend und ereignisgesteuert seine Firmware zu schreiben. Wenn hier jemand "in unserem Flight-Control-System" (was ist das eigentlich? der Autopilot im A310 etwa? oder sowas wie Microsoft's Flugsimulator?) sowas tatsächlich benötigt, dann nur zu! Allerdings muß man sich auch darüber im Klaren sein, daß ein RTOS einem keine Rechenzeit (auch nicht zur rechten Zeit) bescheren kann, sondern selbst für sich Rechenzeit verbraucht. Wenn du also alle Millisekunde irgendwas liefern mußt und für dessen Bereitstellung bereits fast eine Millisekunde brauchst, dann liegt hier schon was im Argen, das du nur durch eine bessere Strategie und besseren Code beseitigen kannst. W.S.
W.S. schrieb: > Wenn du also alle Millisekunde irgendwas > liefern mußt und für dessen Bereitstellung bereits fast eine > Millisekunde brauchst, dann liegt hier schon was im Argen, das du nur > durch eine bessere Strategie und besseren Code beseitigen kannst. > > W.S. Bei meinem Beispiel ist das fast nicht möglich da der Wunsch war, dass alles über C++ gelöst werdenn soll und ebenfalls die Klassen soweit abstrahiert sind, dass sie auf ein FPGA portiert werden können. Das spart entwicklungszeit, verschwendet aber viel rechenzeit welche mit einem 48MHz Kontroller nicht gerade üppig vorhanden ist. Die ganze Uart läuft schon über DMA was mi viel erspart, aber das Protokoll braucht auch seine Zeit zum validieren. Achja und in der 1ms muss alles empfangen und gesendet werden, wodurch die Baudrate auch wider zum Flaschenhals wird (~50us für die Übertragung, dann 300us für die Validierung, 200us für Befehl abarbeiten und neue Daten entgegennehmen, 100us für Daten verpacken).
Ihr habt es alle nicht gelesen stimmts, dort steht auch das Ergebnis des Vergleiches zwischen: Superloop RTOS event driven programming (als 3. Alternative) Und der Mann muss es wissen, Zitat: "Miro Samek is the author of the book Practical UML Statecharts in C and C++ and a regular speaker at the Embedded Systems Conferences." NeedWeAnRTOS schrieb: > nicht ganz so hart, wie der Blogtitel klingt > > http://embeddedgurus.com/state-space/2010/04/i-hate-rtoses/
Fragt mal Adam Dunkels, der findet Eventdriven nicht so doll. Und hat eine zumindest vergleichbare Reputation. Der eine malt halt UML(-Events) und will auch so programmieren, der andere hat das mal untersucht und für ihn besseres gefunden. Der Link zeigt übrigens auf "state-space", also den Platz, an dem jeder seinen Senf ablassen kann. I-hate-<whatever> scheint richtig schick zu sein. Ob C versus Pascal,Assembler,Basic,C++ oder Event versus Task, ... Immer der gleich Glaubenskrieg.
Patrick B. schrieb: > Setzt ein OS den CPU in den sleep-mode wenn es nichts zu tun hat? Damit > wäre noch der winzige Vorteil von etwas Stromsparen, aber da die > Peripherie ja ständig laufen muss um das OS mit den entsprechenden Daten > zu bedienen, ist dies ja winzig. Ja, das ist möglich und das ist eben kein winziger Vorteil. Bei einem gut designten System hält sich das OS die meiste Zeit in einer Funktion OS_Idle() und kann dort in einen Stromsparmodus wechseln. Durch einen Interrupt läuft das OS dann weiter. Gerade heutzutage für batteriebetriebene Geräte ist das sehr wichtig.
W.S. schrieb: > Ich sag's mal so: RTOS'se sind ein nettes akademisches Spielzeug, > weswegen sie dort auch gern für jeden Schnullifax benutzt werden. Im > normalen Leben sollte man hingegen sich erstmal gründlich überlegen, ob > man im konkreten Falle so ein RTOS auch wirklich braucht - oder ob man > bloß zu doof ist, nichtblockierend und ereignisgesteuert seine Firmware > zu schreiben. Ahhh, ja. Und deswegen gibt es Firmen wie Segger, Micrium und so weiter? Weil keinen ein RTOS einsetzt? Sicher gibt es auch Applikationen wo ich kein RTOS brauche, aber die Applikation werden heutztage immer komplexer und da macht ein RTOS einfach Sinn. Davon mal abgesehen, das auch die Mikrocontroller immer komplexer werden. Nicht jeder möchte z.B. beim ARM9, Cortex A8/9 sich mit MMU/Cache usw. beschäftigen.
300 us fürs Validieren und 100 us zum Verpacken? Ich glaube, dein Code macht da irgendwas falsch. Ich würde bei 48 MHz eher 1/10 davon erwarten, wenn man gut programmiert. Oder ist das Protokoll so komplex? Deine Implikation, wegen Klassen und C++ wäre es langsamer muss übrigens nicht stimmen. Du musst dem Optimizer nur eine Chance geben, z.B. mit Whole-Program-Optimization. Etwas Hintergrundwissen, was in C++ zu suboptimalem Code führt, ist natürlich auch nützlich, aber das führt vom Thema weg. Ein RTOS wird dein Problem jedenfalls nicht lösen, sondern verschlimmern. Die Garantie, dass bestimmte Aufgaben (Tasks/Threads) einen bestimmten Anteil der Rechenpower bekommen, kostet seinerseits wieder etwas Rechenleistung, und letzteres ist ja dein Problem, nicht das Timing an sich.
Sam P. schrieb: > Ein RTOS wird dein Problem jedenfalls nicht lösen, sondern > verschlimmern. Die Garantie, dass bestimmte Aufgaben (Tasks/Threads) > einen bestimmten Anteil der Rechenpower bekommen, kostet seinerseits > wieder etwas Rechenleistung, und letzteres ist ja dein Problem, nicht > das Timing an sich. Ist ist leider eine verbreitete Fehleinschätzung, die vielleicht für Windows stimmt aber nicht für ein RTOS. Wenn eine Task läuft, dann hat sie 100% der CPU und wird höchstens kurz vom Systemtick unterbrochen. Ansonsten verbraucht das OS nur CPU Power beim Taskwechsel, und das geschieht in wenigen Cycles. Sprich das OS braucht an der Gesamtauslastung vielleicht 1-2%. Dafür garantiert es aber ein definiertes Timing.
Tom schrieb: > Ist ist leider eine verbreitete Fehleinschätzung, Ähem, die Fehleinschätzung liegt bei dir. Ganz konkret: Wenn jemand mehr Zeit braucht als er tatsächlich hat, um seine Daten zu verarbeiten, hilft ihm keinerlei Betriebssystem weiter. Da hilft nur, sich die Verarbeitungsroutinen genauer anzuschauen. Also, lies erstmal was schon dasteht... Der TO hat ja nicht geschrieben, was für Daten er da und wie verarbeiten will. Bei Paketen im 1 ms Takt kommt mir isochronous USB in den Sinn, ergo Sounddaten, ergo irgendwelche Filteralgorithmen, ergo besser ein Cortex M4 als ein M0, ergo den eigentlichen Filterkern in Assembler. Oder eben ein lascheres Filter - falls das alles zutreffen sollte. Guest schrieb: > Ahhh, ja. > Und deswegen gibt es Firmen wie Segger, Micrium und so weiter? Weil > keinen ein RTOS einsetzt? Nö. Sondern: Weil es massenweise Leute gibt, die ohne Gehhilfe nicht laufen können. Frag dich mal, warum hier in diesem Forum die Debounce-Routinen von Peter Dannegger so beliebt sind? Weil es hier eben massenweise Leute gibt, die für so eine einfache Aufgabe zu doof oder zu faul sind. Soll ich hier mal nen ehemaligen Mitarbeiter zitieren? Ja? Also: "Das brauche ich nicht zu können, darauf bin ich nicht geschult worden" oder nen anderen Spruch: "Für sowas muß doch ein passender Treiber erhältlich sein!" Selberkönnen? Fehlanzeige! Vor dem Selbermachen steht Ordern. Von solchen IT-Spezialisten leben Segger und Co. W.S.
>> Und deswegen gibt es Firmen wie Segger, Micrium und so weiter? Weil >> keinen ein RTOS einsetzt? >Nö. Sondern: Weil es massenweise Leute gibt, die ohne Gehhilfe nicht >laufen können. @W.S. Was der Bauer nicht kennt das frisst er nicht;) So lautet deine Aussage. Du willst kein RTOS? Dann mach halt ohne RTOS. Zwingt dich ja keiner. Das alle ausser dir Dumpfbacken sind äusserst du hier schon oft genug.
Daß manchmal diese Firmen auch Zertifikate für ihre RTOSe mitliefern, die dafür sorgen, daß man einen Auftrag überhaupt bekommt, ist aber klar. Und PeDa's Routinen sind deshalb beliebt, weil sie was taugen. Manche, z.B. ich, verwenden sein Verfahren auch in C++ Template Klassen, weil wir alle zu doof/faul sind selbst zu programmieren. Oftmals darf man aber nichts selber machen, weil irgendwer ein Patent auf das Verfahren hat und man dann kaufen muß. Die von Dir genannten Personen gibt es natürlich auch, aber was sinnvolles nicht machen, weil es auch Vollpfosten tun? Schön blöd!
Also irgendwie beneide ich W.S. Waehrend ich, um ARM zu erlernen, mir jahrelang den Arsch aufgerissen habe, scheint er dies in NullKommaNichts erlernt zu haben. Ich erinnere mich an einem Satz, den er mir mit auf den Weg gegeben hatte: "Ist gar nicht so schwer. Musst halt nur die Datenblaetter lesen können". Oder so aehnlich. Und waehrend ich mir manche Lösungen ohne RTOS erst gar nicht vorstellen kann, scheint W.S. solche Faelle mit einem Laecheln und einer Nonchalance zu lösen. Die Welt, und insbesondere Gott, ist schon irgendwie ungerecht. Immer auf die Kleinen. Und immer auf den Kopf. Tut schon weh.
Sam P. schrieb: > 300 us fürs Validieren und 100 us zum Verpacken? Ich glaube, dein Code > macht da irgendwas falsch. Ich würde bei 48 MHz eher 1/10 davon > erwarten, wenn man gut programmiert. Oder ist das Protokoll so komplex? Naja, eigentlich ist das Protokoll nicht sonderlich kompliziert. Es handelt sich um Modbus RTU. Hier sind fixe Header forhanden, dann Funktionscode, CRC, Adressen, Datengrösse... Falls ok, werden die neuen Daten verarbeitet und eine Antwort gesendet, falls nicht ok eine Fehlermeldung. Da der verwendete Controller leider der einzige ist, der Modbus schon von Haus aus unterstützt, ist ein Wechsel nicht so ohne weiteres möglich. Klar, beim debuggen habe ich mich auch gewundert, dass das Protokoll so langsam ist, da ich auch mehr erwartet hätte. Da der Kontroller über RS485 mit 460k Baud betrieben wird (Unidirektional), sind alleine für die Übertragung schon ein paar us fällig. Ausserdem muss das System sehr robust sein da ein Einsatz in einer Industriemaschine (die normalerweise mittels EtherCat intern vernetzt ist) irgendwo auf der Welt das Ziel ist. Ich werde mir wohl nochmals das Protokoll ansehen und wenn möglich optimieren. Achja, der Compiler ist schon auf Geschwindigkeit eingestellt (IAR Workbench)
>Ich werde mir wohl nochmals das Protokoll ansehen und wenn möglich >optimieren. Tu das. >Achja, der Compiler ist schon auf Geschwindigkeit eingestellt (IAR <Workbench) Bei einem völlig vergurkten Programm hilft das nicht die Bohne;)
@ Patrick B. (p51d) >Da der Kontroller über RS485 mit 460k Baud betrieben wird Ganz schön flott! >(Unidirektional), sind alleine für die Übertragung schon ein paar us >fällig. Dafür gibt es FIFOs, auch im UART etc. GGf. sogar DMA.
Sorry, hatte die Zahlen falsch im Kopf: Die Standartpakete sind 12 Bytes (Senden und Empfangen und dass im EtherCat Zyklus: Der Slave erhält Daten, dann müssen die über RS485 gesendet, verarbeitet und beantwortet werden, damit der Slave die neuen Daten über das EtherCat bereitstellen kann). Bei 460800Baud und 1 Stoppbit und Parity macht das 286us für die Übertragung in eine Richtung (da hier das RS485 nur mit 2 Leitungen realisiert ist, kann man ja nicht beides gleichzeitig. Muss ich auch nicht). => 2 x 286us + 50us = 622us (die 50us sind für das Modbus-Protokoll, damit das Ende erkannt werden kann. Dann für das Protokoll inkl. prüfen, und die aktuellen Daten zum Senden bereitstellen und verpacken sind noch 56us fällig. Die Empfangen Daten können wahlweise vor oder nach der Antwort bearbeitet werden, was bei erster Variante < 100us ist, je nach dem, was gemacht werden muss. Das heisst unter dem Strich bin ich bei ~750us, wobei der grösste Teil alleine die Übertragung ist.
Sorry, hatte die Zahlen falsch im Kopf: Die Standartpakete sind 12 Bytes (Senden und Empfangen und dass im EtherCat Zyklus: Der Slave erhält Daten, dann müssen die über RS485 gesendet, verarbeitet und beantwortet werden, damit der Slave die neuen Daten über das EtherCat bereitstellen kann). Bei 460800Baud und 1 Stoppbit und Parity macht das 286us für die Übertragung in eine Richtung (da hier das RS485 nur mit 2 Leitungen realisiert ist, kann man ja nicht beides gleichzeitig. Muss ich auch nicht). => 2 x 286us + 50us = 622us (die 50us sind für das Modbus-Protokoll, damit das Ende erkannt werden kann. Dann für das Protokoll inkl. prüfen, und die aktuellen Daten zum Senden bereitstellen und verpacken sind noch 56us fällig. Die Empfangen Daten können wahlweise vor oder nach der Antwort bearbeitet werden, was bei erster Variante < 100us ist, je nach dem, was gemacht werden muss. Das heisst unter dem Strich bin ich bei ~750us, wobei der grösste Teil alleine die Übertragung ist. Falk Brunner schrieb: > @ Patrick B. (p51d) > >>Da der Kontroller über RS485 mit 460k Baud betrieben wird > > Ganz schön flott! > >>(Unidirektional), sind alleine für die Übertragung schon ein paar us >>fällig. > > Dafür gibt es FIFOs, auch im UART etc. GGf. sogar DMA. Die UART läuft bereits über DMA. Ich bekomme ein Interrupt, nachdem die Pausenzeit (50us) abgelaufen ist, und dann kopiere ich die Daten in ein FIFO, damit ich beim bearbeiten keine verlieren kann. Da das RS485 nur über 2-Draht gemacht ist, ist nur Unidirektional möglich, ohne dass der Bus von 2 gleichzeitg beschrieben wird.
@ Patrick B. (p51d) >Die Standartpakete sind 12 Bytes (Senden und Empfangen und dass im >EtherCat Zyklus: Der Slave erhält Daten, dann müssen die über RS485 >gesendet, verarbeitet und beantwortet werden, damit der Slave die neuen >Daten über das EtherCat bereitstellen kann). Hmm. >Bei 460800Baud und 1 Stoppbit und Parity macht das 286us für die >Übertragung in eine Richtung (da hier das RS485 nur mit 2 Leitungen >realisiert ist, kann man ja nicht beides gleichzeitig. Muss ich auch >nicht). Halbduplex. Was macht die CPU in der Zeit? Däumchen drehen? >=> 2 x 286us + 50us = 622us (die 50us sind für das Modbus-Protokoll, >damit das Ende erkannt werden kann. umso schlimmer. >Das heisst unter dem Strich bin ich bei ~750us, wobei der grösste Teil >alleine die Übertragung ist. Währenddessen nichts getan wird, ja? Sollte/Könnte man das nicht so machen, dass während des Sendens der nächsten Nachricht die vorherige Antwort bearbeitet wird. Damit sollte man eine deutlich besser CPU-Auslastung erreichen.
Der Unterschied zwischen einem RT-OS und z.B. Windoof liegt darin das bei einem RealTime-OS eine GARANTIERTE Zeit der Tasks gewährleistet wird, während bei Windoof der Mauszeiger schonmal Sekunden oder Minuten stehenbleiben kann. Das hat NICHTS mit Interrupts zu tun ! Der Vorteil eines OS liegt an der Standardisierung der Schnittstellen, d.h. man muß sich nicht um I/O u.ä. persönlich kümmern. Bei kleinen Projekten macht ein RTOS keinen Sinn, bei umfangreichen Systemen die auch mehrere Prozesse verteilt behandeln müssen schon. Das hängt immer von der Komplexität und ressourcen ab. Allerdings erweitert sich bei Verwendung eines OS die Fehlermöglichkeit, man ist ja eine Abstraktionsstufe weiter als direkt auf der Hardware zu arbeiten ... Nützt dann aber alles nix wenn die Sensoren falsch herum eingebaut werden :-P
windoof schrieb: > Der Vorteil eines OS liegt an der Standardisierung der Schnittstellen, > d.h. man muß sich nicht um I/O u.ä. persönlich kümmern. Das mag bei diversen grösseren OS's (Windows, Linuux, ..) der Fall sein, aber ein simples RTOS wie z.B. FreeRTOS standardisiert nur die Quasiparalellverarbeitung und die Kommunikation zwischen solchen Prozessen, wie auch Interrupts. Da ist eine Tasks überhaupt nicht abstrakter, kann genauso auf HW zugreifen usw.
Wird zwar langsam OT aber ja nu: Falk Brunner schrieb: > Halbduplex. Was macht die CPU in der Zeit? Däumchen drehen? > >>=> 2 x 286us + 50us = 622us (die 50us sind für das Modbus-Protokoll, >>damit das Ende erkannt werden kann. > > umso schlimmer. > >>Das heisst unter dem Strich bin ich bei ~750us, wobei der grösste Teil >>alleine die Übertragung ist. > > Währenddessen nichts getan wird, ja? Sollte/Könnte man das nicht so > machen, dass während des Sendens der nächsten Nachricht die vorherige > Antwort bearbeitet wird. Damit sollte man eine deutlich besser > CPU-Auslastung erreichen. Naja, däumchendrehen nicht gerade. Wie gesagt, es ist ein Protokoll für verschiedenste Anwendungen. Es kann sein, dass externe Sensoren über SPI eingelesen werden müssen, oder der ADC überwacht wird, oder auf IOs reagiert werden muss. Wie gesagt, ich habs so gelöst, dass man eine Funktion registrieren kann, die die empfangenen Daten bearbeitet und anhand diesen dann die Antwort zusammenstellt. Falls die neusten Daten nun einmal auch bei der nächsten Übertragung gesendet werden können, werden die empfangen Daten bearbeitet sobald das Protokoll abgelaufen wurde und die Sendedaten dem DMA übergeben wurden. (Funktionspointers und Flags)
Fritz schrieb: > windoof schrieb: >> Der Vorteil eines OS liegt an der Standardisierung der Schnittstellen, >> d.h. man muß sich nicht um I/O u.ä. persönlich kümmern. > > Das mag bei diversen grösseren OS's (Windows, Linuux, ..) der Fall sein, > aber ein simples RTOS wie z.B. FreeRTOS standardisiert nur die > Quasiparalellverarbeitung und die Kommunikation zwischen solchen > Prozessen, wie auch Interrupts. Da ist eine Tasks überhaupt nicht > abstrakter, kann genauso auf HW zugreifen usw. Und was sind I/Os nun anderes als Deine erwähnte Kommunikation ? Der Schwerpunkt liegt auf GARANTIERTE Zeitabschnitte, also weiß ich das mein höher priorisierter Task "Zählpinabfragen" immer jede 10te ms abgearbeitet wird während mein Task "LCDausgeben" nur alle 100te ms abgearbeitet wird. IRQs können aber durchaus laufende Tasks unterbrechen, was aber NICHT zu einer Verlängerung der garantierten Zeitscheiben führt, das ist ja gerade den Sinn eines RTOS ;-)
windoof schrieb: > Und was sind I/Os nun anderes als Deine erwähnte Kommunikation ? Mit I/Os sind die ganz normale Peripherie gemeint, also alles was du an Hardware in deinem Microcontroller benutzen möchtest. Mit Kommunikation ist die Kommunikation zwischen Tasks usw. gemeint. Und nochmal weil es manche einfach nicht glauben können: Der Code in deiner Task läuft bei OS wie embOS oder FreeRTOS genauso wie ohne OS, da gibt es erstmal keinen großen Unterschied, man greift genauso direkt auf die Hardware zu. Es ist etwas anders bei OS wo die Tasks in einem nicht priviligierten Modus laufen und nicht direkt auf die Hardware zugreifen können. Das trifft aber nicht auf die meinsten RTOS zu.
windoof schrieb: > IRQs können aber durchaus laufende Tasks unterbrechen, was aber NICHT zu > einer Verlängerung der garantierten Zeitscheiben führt, das ist ja > gerade den Sinn eines RTOS ;-) Würde bedeuten, dass manchmal der Task einfach unterbrochen wird, damit ein andere bearbeitet werden kann. Was ist jetzt aber, wenn kritische Funktionen vorhanden sind, die nicht unterbrochen werden dürfen? Eben desshalb weil man die Möglichkeit hat auf die Hardware zuzugreifen dürfen manchmal die OS nicht einfach machen was sie wollen. Früher nannte man das atomare Aktionen.
Patrick B. schrieb: > Würde bedeuten, dass manchmal der Task einfach unterbrochen wird, damit > ein andere bearbeitet werden kann. Was ist jetzt aber, wenn kritische > Funktionen vorhanden sind, die nicht unterbrochen werden dürfen? Das kommt nun darauf an, ob sie generell überhaupt nicht unterbrochen dürfen, durch reinweg garnichts, oder ob es eher um mögliche Konflikte zwischen einigen Tasks und/oder und den zugehörigen Interrupts geht. Konflikten mit bestimmten Interrupts kann man aus dem Weg gehen, indem man je nach Controller genau diese spezielle Interrupts deaktiviert oder den Interrupt-Level entsprechend setzt. Probleme mit Tasks vermeidet man mit Semaphoren, Queues etc.
A. K. schrieb: > Patrick B. schrieb: >> Würde bedeuten, dass manchmal der Task einfach unterbrochen wird, damit >> ein andere bearbeitet werden kann. Was ist jetzt aber, wenn kritische >> Funktionen vorhanden sind, die nicht unterbrochen werden dürfen? > > Das kommt nun darauf an, ob sie generell überhaupt nicht unterbrochen > dürfen, durch reinweg garnichts, oder ob es eher um mögliche Konflikte > zwischen einigen Tasks und/oder und den zugehörigen Interrupts geht. Typischerweise bietet ein RTOS die Möglichkeit kritische Programmteile exklusiv auszuführen. Meist werden alle Interrupts gesperrt. Beim Cortex M3/4 gibt kann man auch hoch priorisierte ISR immer zulassen, die sollten keine RTOS-Funtionen benutzen, ISRs mit niedrigerer Priorität können aber über RTOS-Funtionen für kritische Programmteile gesperrt werden. In diesen ISRs kann man aber gewisse RTOS-Funtionen verwenden um mit einer Task sicher zu kommunizieren (z. B. Queues).
Fritz schrieb: > Typischerweise bietet ein RTOS die Möglichkeit kritische Programmteile > exklusiv auszuführen. Meist werden alle Interrupts gesperrt. Jain, das ist natürlich das ganz harte Vorgehen, das alles erschlägt. Exklusiven Zugriff auf Hardware kann man aber auch erstmal über eine Semaphore erlangen. Ansonsten bietet embOS z.B. auch API Aufrufe um den Taskwechsel zu sperren. Das macht natürlich nur Sinn, wenn der Zugriff sehr kurz ist. Patrick B. schrieb: > Würde bedeuten, dass manchmal der Task einfach unterbrochen wird, damit > ein andere bearbeitet werden kann. Was ist jetzt aber, wenn kritische > Funktionen vorhanden sind, die nicht unterbrochen werden dürfen? > Eben desshalb weil man die Möglichkeit hat auf die Hardware zuzugreifen > dürfen manchmal die OS nicht einfach machen was sie wollen. Früher > nannte man das atomare Aktionen. Wie oben beschrieben ist das kein Problem und atomare Aktionen sind immer noch möglich.
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.