Hallo, Ich habe bisher viel Cortex M3 Avr & CO programmiert. Alles direkt, also mit eigenen oder erweiterten Treibern. Häufig läuft alles über sequentielles Multitasking (in Funktionen) oder Interrups (Also Fuktionen schauen ob sie was tun können (Händler) sonst gehts zur nächsten, Auf Interrups werden bei Schnittstellen Ringpuffer bedient u.s.w.) Grundlegend habe ich ja dann die totale Kontrolle und das ganze ist soweit Echtzeitfähig (Alle Programme werden zur rechten Zeit ausgeführt). Zum Beispiel kann ich mir sicher sein bei kommenden CAN Nachrichten alles in meinen Ringpuffer legen zu können bevor die internen Hardwarespeicher überlaufen. Soll heißen IRQ und gut. Die Programme sind schon recht umfangreich da auch Protokolle u.s.w. laufen die allerdings unterbrochen werden dürfen. Da in Zukunft mit höheren Prozessoren gearbeitet werden soll und Ethernet und USB sowie Wlan im Raum stehen, will ich Linux als Betriebssystem einsetzen. Ich habe ein paar grundlegende Fragen, sagenwirmal bei einen ARM9 oder neueren Cortex A?: 1: Hab ich jetzt immer noch Interrupts oder muss ich hoffen das Linux das ganze "rechtzeitig" abspeichert (Natürlich ist noch mehr zu tun). Kann man das sicherstellen? 2: werden Portpins unmittelbar gesetzt wie früher, sind sie also quasi als Frequenzzähler verwendbar, oder haut das Betriebssystem dazwischen? 3: Kann ich meinen Ringpuffer verwenden oder hat Linux dann automatisch einen Ringpuffer durch eigene Speicherverwaltung. 4: Wenn ich z.B. auf die Uart einen ganzen Satz Daten schreibe, würde er ohne BS schön konstant gesendet, würde das allgemein auch unter Linux so sein (DMA Transfer oder ähnliches)?? 5: Wenn ich ein Analogsignal mit AD Wandler abtaste muss das schon recht Echtzeitbasiert passieren, gibt es quasi für solche aufgaben eine Möglichkeit Linux zu unterbrechen (Nicht lachen, ist ernst gemeint) 6: Gibt es tutorials die sich speziell mit praktischen Dingen beschäftigen also Hardwareanforderungen, Möglichkeiten, Träume und Warheiten bei Hardwarenahen Applikationen? Es sieht so aus als wenn ich Linux gar nicht haben will, aber genau das gegenteil ist der fall aus genannten gründen, nur fehlt mir so ein bisschen der Zugang, vieles im Netz setzt keine wirkliche Echtzeit bei den Beispielen vorraus. Vieleicht habe ich auch nur Angst mir ein paar Dinge abnehmen zu lassen durch ein BS. Mir ist klar das es RTLINUX gibt aber ab wann welches nötig ist, ist die Preisfrage.
Du musst halt unterscheiden was du für deine Anwendungen brauchst.
(Soft- oder Hardrealtime) Realtime heißt ja nicht - wie du richtig
gesagt hast - möglichst schnell sondern es wird nur garantiert dass
jeder Prozess in einem bestimmten Intervall sicher drankommt. Wenn du
Frequenzen messen willst und es reicht, wenn der Prozess alle 100ms mal
10ms Rechenzeit bekommt, könnte sich vl. was machen lassen. Wenn du
allerdings eine kontinuierliche Frequenzmessung über längere Zeit machen
willst schauts bitter aus. Prinzipiell bestimmt halt dein
Betriebssystem, welcher Prozess wann wie viel Rechenzeit bekommt, und
zwar durch preemtives (=unterbrechendes) Multitasking.
Über Prozesspriority und Nice-Faktor kannst du noch einigermaßen
festlegen wie wichtig ein Prozess ist (gibt auch die Priority RT für
Realtime meistens, aber ist eine sehr softe Angelegenheit,...)
Auf Hardware-Interrupts direkt hast du keinen Zugriff.
Kann dir jetzt leider die Fragen nicht so ganz beantworten da ich selbst
bei ähnlichen Problemen hänge. Was bei mir Probleme gemacht hat sind die
UARTs und deren Pufferzeiten. Erschwerend kommt dann noch dazu wenn man
externe Umsetzer (UART-Bridges) an USB verwendet, aber das ist ein
anderes Thema.
Es ist die Frage wie weit du mit selbst geschriebenen Treibern
runterkommst. Aus dem Usermode heraus ("normaler Betriebsmodus") wirst
du solche direkten Hardwarezugriffen verboten bekommen. Führst du
Programme im Kernelmode aus könnte schon eher was gehen, bin mir aber
grad auch nicht wirklich sicher was da möglich ist und wo das OS sagt ne
is nich...
Hallo, das eigendliche Problem ist ja, das man ohne schon bald nicht mehr herum kommt wenn man die Leistung auch tatsächlich nutzen will die der neue Prozessor bietet. Will man aber nicht schlechter sein als ein AVR wenn es um "Standart" Schnittstellen geht muss man anscheinend ganz schön aufpassen. Ein Beispiel: Ich steuer mehrere 7Segment Anzeigen an welches einen blinkenden Punkt hat. Per Spi muss mann also entspechend das Byte im richtigen Moment aktualisieren. Jede asynchronität ist sichtbar ab 20ms. Mit OHNE BS kein Problem.
Hi Bernd, Mit dem Thema habe ich mich vor einer Weile beschäftigt, ist eine knifflige Sache, und unter Linux so eine kleine Gratwanderung. Ich habe auf dem Blackfin die Xenomai-Erweiterungen am laufen und teils spezielle Treiber dafür bauen müssen, damit der Prozess auch in garantierter Zeit (wenigen us) auf Datenpakete reagiert. Zu Deinen Fragen im Detail: > 1: Hab ich jetzt immer noch Interrupts oder muss ich hoffen das Linux > das ganze "rechtzeitig" abspeichert (Natürlich ist noch mehr zu tun). > Kann man das sicherstellen? > Linux alleine gibt Dir keine Garantie, sowas wie "rechtzeitig" kann von wenigen us bis mehreren ms dauern. Der Interrupt geht aber im allgemeinen nicht verloren (ausser, er feuert wie ein Verrückter bei mehreren kHz) > 2: werden Portpins unmittelbar gesetzt wie früher, sind sie also quasi > als Frequenzzähler verwendbar, oder haut das Betriebssystem dazwischen? > Nee, kannst Du knicken. Am besten nutzt Du für sowas auch unter "Echtzeitsystemen" die PWM-Funktionalität. Die meisten PWMs können auch zählen. > 3: Kann ich meinen Ringpuffer verwenden oder hat Linux dann automatisch > einen Ringpuffer durch eigene Speicherverwaltung. > Die Ringpuffer und das Management musst Du im Kerneltreiber entsprechend programmieren. Nur das Allozieren von non-cacheable Speicherbereichen usw. kann dir das Kernel bieten. > 4: Wenn ich z.B. auf die Uart einen ganzen Satz Daten schreibe, würde er > ohne BS schön konstant gesendet, würde das allgemein auch unter Linux so > sein (DMA Transfer oder ähnliches)?? > Nur wenn's der Prozessor kann (und der Treiber). Beim Blackfin ist das der Fall. > 5: Wenn ich ein Analogsignal mit AD Wandler abtaste muss das schon recht > Echtzeitbasiert passieren, gibt es quasi für solche aufgaben eine > Möglichkeit Linux zu unterbrechen (Nicht lachen, ist ernst gemeint) > Ja, ich lache nicht, denn genau das ist eigentlich, was ADEOS/Xenomai macht: Es greift vor dem Scheduler an, Linux läuft da quasi als Prozess mit niedrigerer Priorität. Deswegen musst Du aber für die Xenomai-Domäne alle Treiber neu entwickeln (was aber keine riesen Hexerei ist). Bei den Treibern, die weniger kritisch sind, kannst Du die Linux-Seite verwenden (wie z.B. das Networking). > 6: Gibt es tutorials die sich speziell mit praktischen Dingen > beschäftigen > also Hardwareanforderungen, Möglichkeiten, Träume und Warheiten bei > Hardwarenahen Applikationen? Nicht dass ich wüsste. Ich habe damals erschreckend wenig zu dem Thema gefunden, aber es gab einige akademisch gefärbte Analysen von Antwortzeiten unter Xenomai. Der Blackfin ist ansich für solche Sachen ideal und sehr zu empfehlen, da er die DSP- und uC-Welt gleichermassen gut bedient. Dank seines clevern DMA gehn auch unter Vollast des Systems keine Daten verloren (sofern man die Memory-Bandbreite nicht knackt). Bei andern Chips muss man teils den DMA im Interrupt neu anwerfen, was kritisch sein kann. Es gibt aber auch eine Kanne anderer OS wie RTEMS und eCos, usw. RTEMS-gepowerte HW kriegt man offensichtlich in manchen Anwendungen leichter zertifiziert.. Mein Fazit nach all den Jahren: Wenn Linux nicht unbedingt notwendig ist (wegen Networking), würde ich es u.U. "standalone" probieren und einen SPI->Ethernet-Chip in Betracht ziehen. Ansonsten kannst Du mit der Xenomai-Geschichte Glück haben, aber da würde ich mir sehr genau die Board-Supply-Packages für die entsprechenden ARM-Derivate anschauen. Wichtig ist auch ein gutes externes Messsystem, mit dem Du die Event-Timings überprüfen kannst (z.B. Zähler im FPGA oder Oszi). Grüsse, - Strubi
bernd schrieb: > 1: Hab ich jetzt immer noch Interrupts oder muss ich hoffen das Linux > das ganze "rechtzeitig" abspeichert (Natürlich ist noch mehr zu tun). > Kann man das sicherstellen? Der übliche Weg ist, dass ein Linux Treiber die Interrupts nutzt um die Daten rechtzeitig abzuholen. Ohne RT Erweiterung gibt es aber keine Garantie wie lange es dauert bis dein Interrupt Handler aufgerufen wird. Das kann auch bei einem System ohne Last irgendwo im mittleren zweistelligen Mikrosekundenbereich liegen. > 2: werden Portpins unmittelbar gesetzt wie früher, sind sie also quasi > als Frequenzzähler verwendbar, oder haut das Betriebssystem dazwischen? Prinzipiell kann dir sowohl im User, als auch im Kernel Context immer ein langer Interrupt Handler und ein Prozesswechsel das Timing kaputt machen. Im Kernel Context kann man aber IRQs für kurze Aufgaben ausschalten, wenn z.B. zwei GPIOs direkt hintereinander verändert werden müssen. GPIOs die über Busse wie I2C und SPI angesteuert werden (z.B. PCF8574), können nicht angesprochen werden, wenn Scheduling unterbunden ist. Von Hand könnte dann man einen SPI Transfer starten, aber nicht darauf warten, dass er beendet (das sind die Momente in denen man merkt, dass der MCP2515 vielleicht doch keine gute Wahl war). > 3: Kann ich meinen Ringpuffer verwenden oder hat Linux dann automatisch > einen Ringpuffer durch eigene Speicherverwaltung. Sowas wie kfifo? > 4: Wenn ich z.B. auf die Uart einen ganzen Satz Daten schreibe, würde er > ohne BS schön konstant gesendet, würde das allgemein auch unter Linux so > sein (DMA Transfer oder ähnliches)?? UARTs sind normalerweise so langsam, dass das nicht mit DMA gemacht wird. Da reicht der low-watermark-IRQ des FIFOs. UARTs ohne 8+ Bytes FIFO findet man heutzutage auf großen ARMs praktisch nicht mehr. Nur wenn es in den Mbit/s Bereich geht, sollte man über DMA nachdenken. > 5: Wenn ich ein Analogsignal mit AD Wandler abtaste muss das schon recht > Echtzeitbasiert passieren, gibt es quasi für solche aufgaben eine > Möglichkeit Linux zu unterbrechen (Nicht lachen, ist ernst gemeint) Wenn es nur um <2kHz geht und dir Jitter fast egal ist, probier es ruhig den AD Wandler mit nem periodischen Timer auszulesen. Alles andere sollte DMA benutzen oder einen FIFO haben. > 6: Gibt es tutorials die sich speziell mit praktischen Dingen > beschäftigen > also Hardwareanforderungen, Möglichkeiten, Träume und Warheiten bei > Hardwarenahen Applikationen? Es gibt da Firmen die einen bei sowas beraten,,, > Es sieht so aus als wenn ich Linux gar nicht haben will, aber genau das > gegenteil ist der fall aus genannten gründen, nur fehlt mir so ein > bisschen der Zugang, vieles im Netz setzt keine wirkliche Echtzeit bei > den Beispielen vorraus. Linux ist ja auch kein Echtzeitbetriebssystem. Selbst wenn du sagst, dass du eine harte Echtzeitanforderung von 1 Sekunde Latenz hast, würde ich nicht unterschreiben, dass Linux das in 100% der Fälle schafft. Ich habe meinen alten Phenom Bürorechner ein nanosleep schon um mehr als das verpennen sehen. War aber scheinbar ein Bug. Linux ist mittlerweile so groß, dass niemand weiß, ob nicht doch noch irgendwo eine Stelle ist, die die Latenz in einem Sonderfall in die Höhe treibt. Deshalb ändern RT Erweiterungen auch grundlegend die Art und Weise wie Linux mit Interrupts umgeht.
Gut RTLinux gibt es ja, allerdings noch weniger Doku dazu. Soviel ich weiß arbeitet die RWTH Achen damit intensiever. Hab mir zwei Bücher für Linux geholt die suuper sein sollen, Ist zwar schön geschrieben aber unser Thema ist da auch nicht wirklich behandelt. Gibt ja mittlerweile tausende Hersteller die angepasstes Linux an ihr CPU-Board anbieten, was aber dann wie funktioniert ist dann immer ausprobieren. Ganz billig sind die Dev Kits auch nicht mehr. Im wensendlichen sind die Treiber wohl von Freescale mit entsprechenden Änderungen für die Platine des Herstellers. Gedacht hatte ich an sowas z.B. oder eben viele andere. Sofern man ein BS nimmt hat man ja eigendlich auch nicht mehr so die Detailsorgen (dachte ich) aber wehe es läuft etwas nicht, dann ict es plötzlich nur noch der GrundKernel der kompatibel ist. http://www.tq-group.com/produkte/produktdetail/prod/embedded-modul-tqma53/extb/Main/productdetail/
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.