Echtzeit Linux, zeitliche Auflösung etc.

Hallo,

ich hatte heute eine Diskussion mit einem Kollegen wo es um den Einsatz von Microcontrollern und PCs ging.

Dabei kam die Frage auf, inwieweit man zeitkritische Sachen mit einem sogenannten Echtzeit-Linux machen kann, was es da gibt, und wo da die Grenzen sind.

Konkret geht es darum, auf digitale Eingangssignale in weniger als 100us zu reagieren. Mit einem Microcontroller kein Problem, aber geht sowas auch mit PC Hardware?

Wir setzen da aktuell AVR Prozessoren ein. Die werten Signale von digitalen Drehgebern und eine Lichtschranke aus. Die Lichtschranke

Drehgeber macht alle 200us einen Takt, entsprechend 5000 Impulse pro Sekunde).

Mit einem Compare Int werden dann nach einer vorgegebenen Anzahl Drehgebertakte kurze Impulse ausgegeben. Die Impulsdauer soll mit einer Genauigkeit von +-3 us eingestellt werden, der Startzeitpunkt auf besser als +-100us.

Unsere Anlage funktioniert soweit einwandfrei. Die Frage ist, ob man

Wie funktioniert das Echtzeig-Linux? In welchem Zeitraster kann ich da reagieren, sind das Millisekunden oder einige zig Mikrosekungen?

Wie lese ich da digitale Signale ein? Gibt es Hardware Interrupts die ich nutzen kann?

Stefan

Reply to
Stefan
Loading thread data ...

"Echtzeit" bedeutet, dass eine Reaktion innerhalb eines bestimmten

Millisekunden sein.

Klar, Barebone auf jeden Fall. Aber bei den Produktzyklen ist es nicht so klug, sich auf eine PC-Hardware festzulegen.

verwenden. Dann habe ich die relevante Hardware unter voller Kontrolle

nicht mehr, was da heute aktuell ist) oder eine Standardschnittstelle

Reply to
Edzard Egberts

Am 04.10.2017 um 15:13 schrieb Stefan:

schon sehr anspruchsvoll.

Karten geben.

DoDi

Reply to
Hans-Peter Diettrich

Hier findest du von einigen Rechnerkonfigurationen die erreichbaren Latenzzeiten von linuxcnc:

formatting link

Gernot

>
Reply to
Gernot Fink

Am 04.10.2017 um 16:38 schrieb Hans-Peter Diettrich:

Ich seh das genauso, nur da ich keine Ahnung von Echtzeit-Linux habe,

Stefan

Reply to
Stefan

Am Mittwoch, 4. Oktober 2017 17:39:18 UTC+2 schrieb Stefan:

re...

.

Modulen).

Bei Linux ist die Verteilung der Rechenzeit recht komplex und daher ist ein e

Es gibt einige Echt-Zeit-Linuxe: RTLinux, LibeRTOS, PREEMPT_RT Patch

100us Reaktionszeit sollten mit Kernel-Modulen schon machbar sein, solange in der Interrupt-Routine nicht so viel passiert (Linux-Dokumentation enth

dazu evtl. Angaben [kernel-doc]).

.
Reply to
Stefan Engler

Ich will dich nicht von Linux abbringen, nachdem ich es selbst im

Industriesteuerungen unter DOS programmiert. Den Scheduler hat er einfach selbst geschrieben. Das ist schon ein paar Jahre her, ich

hat halt wenig Overhead.

--

www.youtube.com/watch?v=ByzwOBeKD-c
Reply to
Werner Holtfreter

Da hast du mich wohl falsch verstanden. Ich bin auf der Schiene

die Verwaltung.

Na ja, es ist schon ein Unterschied, ob man mit Millisekunden oder Mikrosekunden rechnet.

Wie geschrieben, meine Frage bezog sich nicht auf Dos gegen Linux sondern Microcontroller gegen Linux speziell bei zeitkritischen Sachen im Mikrosekundenbereich.

Reply to
Stefan

Am 04.10.2017 um 15:13 schrieb Stefan:

( Arduino Due wegen >80 MHz Taktfrequenz)

Hermann der c't make Arduino spezial wegen der interrupt Beschreibung interessant fand.

--
http://www.hermann-riemann.de
Reply to
Hermann Riemann

Du willst demnach wissen, ob PC-Hardware bestimmte Zeitanforderungen

sich da ein Programm nach Belieben die Hardware krallen kann, ohne dass man es zwingen kann, sie wieder freizugeben. Ideale

--

www.youtube.com/watch?v=ByzwOBeKD-c
Reply to
Werner Holtfreter

Am 05.10.2017 um 02:21 schrieb Werner Holtfreter:

DOS ist ein Betreibssystem, ohne das multitasking im System verankert ist.

Und in fast? jedem Betriebssystem kann sich software die hradware krallen.

while (true){} ein.

Hermann

ein eigenes Betriebssystem wie z.B. setup()

--
http://www.hermann-riemann.de
Reply to
Hermann Riemann

ganzer Haufen Rechenleistung auf kleinem Raum ist und es sicher auch Anwendungen gibt, bei denen diese Rechenleistung gebraucht wird - wenn

Da bleibt allerdings das Problem der Geometrie: Sachen im

da stellt sich dann das Problem, wie man die gesteuerte Hardware in oder

direkt in die Steuerelektronik integriert sind und die schnelle

Reply to
Edzard Egberts

Am 05.10.2017 um 08:06 schrieb Edzard Egberts:

FFT erfordert einen schnellen ADC, oder die Auswertung darf so langsam

mit Grafikprozessoren ausfgebaut, die Numbercrunching und schnelle

Der engste Flaschenhals ist bei schnellen Prozessoren der Speicher, der speziell bei DMA (Platten, Grafik...) und speicherintensiven Programmen die CPU ausbremsen kann. Da kann ein Cache nur dann weiterhelfen, wenn

haben da wendiger Probleme mit dem Datendurchsatz als eine CPU mit

einer PC Hardware (IMO).

Bei verteilten Datenquellen sind Netze besser zu realisieren und weniger

Ob dann Knoten mit (industrietauglicher) PC Hardware noch vorteilhaft

Einzelfall an.

DoDi

Reply to
Hans-Peter Diettrich

mit einem anderen RT-OS. Aber wenn Linux benutzt werden soll, weil noch andere Anwendungen (Browser...) darauf laufen sollen, dann stellt sich erst recht die Frage nach einer Aufteilung auf dedizierte Rechner.

Die seit dem 386 eigentlich ausgewachsene (sichere) Speicherverwaltung

Soundkarte profitieren kann, kommt sehr auf den Einzelfall an.

Umladen der Segmentregister hat im 16 Bit Windows mit segmentiertem Speicher viel zu lange gedauert, deshalb wurde bald auf memory-paging umgestellt. Trotzdem bleibt ein Taskwechsel bei virtuellem Speicher

wenn keine Taskwechsel vorkommen, oder wenn so lange andere Kerne mit

die Echtzeit-Tasks/Treiber in der Systemtask laufen, ist es auch vorbei

DoDi

Reply to
Hans-Peter Diettrich

Am 04.10.2017 um 20:44 schrieb Hermann Riemann:

Kommt drauf an, was man machen will.

gewillt ist, Daten zu versenden.

Zumindest wenn der PC dann das Timing bestimmen soll, sehe ich da schwarz.

Reply to
Stefan

reine Bedienung/Visualisierung sind die neuen (ja, ja, jetzt kommt mir

richtig interessant.

Reply to
Edzard Egberts

Am 05.10.2017 um 13:45 schrieb Hans-Peter Diettrich:

Arduino Yun; mit Linux.

Oder man bastelt anhand des Buches: Linux-Treiber entwickeln.

Da frage ich, ob man nicht einer der Multi-Core-Prozessoren

Hermann der da allerdings Probleme mit dem cache vermutet.

--
http://www.hermann-riemann.de
Reply to
Hermann Riemann

Edzard Egberts schrieb:

Wirklich schnell wird es IMHO erst mit programmierbarer (FPGA) oder

noch logischen oder physikalischen Platz auf dem Chip. Allerdings muss man sich dann vom Wunschdenken schell-flexibel-billig verabschieden.

--
mfg Rolf Bombach
Reply to
Rolf Bombach

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.