Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.sci.electronics > #233033 > unrolled thread

Echtzeit Linux, zeitliche Auflösung etc.

Back to article view | Back to de.sci.electronics

Contents

  Echtzeit Linux, zeitliche Auflösung etc. Stefan <df9bi@arcor.de> - 2017-10-04 15:13 +0200
    Re: Echtzeit Linux, zeitliche Auflösung etc. Edzard Egberts <news@edzeg.net> - 2017-10-04 16:03 +0200
      Re: Re: Echtzeit Linux, zeitliche Auflösung etc. Gernot Fink <g.fink@gmx.net> - 2017-10-04 17:00 +0200
      Re: Echtzeit Linux, zeitliche Auflösung etc. Edzard Egberts <news@edzeg.net> - 2017-10-05 08:06 +0200
        Re: Echtzeit Linux, zeitliche Auflösung etc. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-05 12:59 +0200
          Re: Echtzeit Linux, zeitliche Auflösung etc. Edzard Egberts <news@edzeg.net> - 2017-10-05 14:18 +0200
        Re: Echtzeit Linux, zeitliche Auflösung etc. Rolf Bombach <rolfnospambombach@invalid.invalid> - 2017-10-07 19:26 +0200
    Re: Echtzeit Linux, zeitliche Auflösung etc. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-04 16:38 +0200
      Re: Echtzeit Linux, zeitliche Auflösung etc. Stefan <df9bi@arcor.de> - 2017-10-04 17:39 +0200
        Re: Echtzeit Linux, zeitliche Auflösung etc. Stefan Engler <Lehrerfreund@web.de> - 2017-10-04 09:42 -0700
    Re: Echtzeit Linux, zeitliche Auflösung etc. Werner Holtfreter <holtfreter@gmx.de> - 2017-10-04 19:54 +0200
      Re: Echtzeit Linux, zeitliche Auflösung etc. Stefan <df9bi@arcor.de> - 2017-10-04 19:59 +0200
        Re: Echtzeit Linux, zeitliche Auflösung etc. Werner Holtfreter <holtfreter@gmx.de> - 2017-10-05 02:21 +0200
          Re: Echtzeit Linux, zeitliche Auflösung etc. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-10-05 06:20 +0200
          Re: Echtzeit Linux, zeitliche Auflösung etc. Hans-Peter Diettrich <DrDiettrich1@aol.com> - 2017-10-05 13:45 +0200
            Re: Echtzeit Linux, zeitliche Auflösung etc. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-10-05 15:31 +0200
    Re: Echtzeit Linux, zeitliche Auflösung etc. Hermann Riemann <nospam.ng@hermann-riemann.de> - 2017-10-04 20:44 +0200
      Re: Echtzeit Linux, zeitliche Auflösung etc. Stefan <df9bi@arcor.de> - 2017-10-05 13:57 +0200

#233033 — 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 
erkennt ein Objekt und löst einen Capture des Drehgeberzählers aus. Der 
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 
sowas auch mit einem Echtzeit-Linux hinbekommen würde.

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?

Gruß

Stefan

[toc] | [next] | [standalone]

#233034

> 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.

"Echtzeit" bedeutet, dass eine Reaktion innerhalb eines bestimmten
Zeitinvervalls garantiert wird, das können aber durchaus mehrere
Millisekunden sein.

> 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?

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

> Die Impulsdauer soll mit
> einer Genauigkeit von +-3 us eingestellt werden, der Startzeitpunkt
> auf besser als +-100us.

Bei solchen Anforderungen würde ich immer einen Mikrocontroller
spendieren und den PC nur für Datenaufnahme/Visualisierung/Bedienung
verwenden. Dann habe ich die relevante Hardware unter voller Kontrolle
und der fehleranfälligere PC ist ein Austauschprodukt von der Stange.

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

Du müsstest Dir eine Einsteckkarte für den Bus basteln (ich weiß gar
nicht mehr, was da heute aktuell ist) oder eine Standardschnittstelle
verwenden - das wäre dann also USB als Verbindung zum Controller...

[toc] | [prev] | [next] | [standalone]

#233040

In article <or2pnv$1kr$1@news4.open-news-network.org>,
	Edzard Egberts <news@edzeg.net> writes:
>> 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.

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

http://wiki.linuxcnc.org/cgi-bin/wiki.pl?Latency-Test

Gernot

> 

[toc] | [prev] | [next] | [standalone]

#233088

Ich habe mir inzwischen noch gedacht, dass PC-Hardware natürlich ein
ganzer Haufen Rechenleistung auf kleinem Raum ist und es sicher auch
Anwendungen gibt, bei denen diese Rechenleistung gebraucht wird - wenn
nämlich die Signale nicht nur schnell sind, sondern auch in "Echtzeit"
ausgewertet werden müssen, z.B. FFT.

Da bleibt allerdings das Problem der Geometrie: Sachen im
Mikrosekundenbereich kann man nicht "einfach so" mit Kabel anschließen,
da stellt sich dann das Problem, wie man die gesteuerte Hardware in oder
an den PC bringt. Hier haben Controller den großen Vorteil, dass sie
direkt in die Steuerelektronik integriert sind und die schnelle
Verarbeitung vor Ort in eine langsamere Datenübertragung umwandeln können.

[toc] | [prev] | [next] | [standalone]

#233093

Am 05.10.2017 um 08:06 schrieb Edzard Egberts:
> Ich habe mir inzwischen noch gedacht, dass PC-Hardware natürlich ein
> ganzer Haufen Rechenleistung auf kleinem Raum ist und es sicher auch
> Anwendungen gibt, bei denen diese Rechenleistung gebraucht wird - wenn
> nämlich die Signale nicht nur schnell sind, sondern auch in "Echtzeit"
> ausgewertet werden müssen, z.B. FFT.

FFT erfordert einen schnellen ADC, oder die Auswertung darf so langsam 
arbeiten wie die Daten eintröpfeln. Ein Controller, wie er in (Video) 
Kameras oder digitalen Scopes benutzt wird, sollte auch für FFT o.ä. 
genügend Rechenleistung haben. Nicht umsonst werden Supercomputer oft 
mit Grafikprozessoren ausfgebaut, die Numbercrunching und schnelle 
Datenübertragung auf mehreren Kanälen beherrschen.

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 
er schnell mit den benötigten Daten gefüllt werden kann. Das bedeutet, 
daß insbesonder die Tasks eines Echtzeit-Systems so konstruiert werden 
sollten, daß sie sich nicht gegenseitig ausbremsen können - sofern das 
überhaupt möglich (vorgesehen) ist. Mikrocontroller mit RAM auf dem Chip 
haben da wendiger Probleme mit dem Datendurchsatz als eine CPU mit 
externem Speicher. Auf solchen Controllern läßt sich auch ein 
Echtzeitsystem installieren, das vielen Ansprüchen besser genügt als auf 
einer PC Hardware (IMO).

> Da bleibt allerdings das Problem der Geometrie: Sachen im
> Mikrosekundenbereich kann man nicht "einfach so" mit Kabel anschließen,
> da stellt sich dann das Problem, wie man die gesteuerte Hardware in oder
> an den PC bringt. Hier haben Controller den großen Vorteil, dass sie
> direkt in die Steuerelektronik integriert sind und die schnelle
> Verarbeitung vor Ort in eine langsamere Datenübertragung umwandeln können.

Bei verteilten Datenquellen sind Netze besser zu realisieren und weniger 
störanfällig als ein Kabelverhau zu einem Zentralrechner. Ein Netz ist 
auch besser skalierbar, wenn sich die Anforderungen ändern oder wachsen. 
Ob dann Knoten mit (industrietauglicher) PC Hardware noch vorteilhaft 
sind (Platz, Preis, Netzteil, Leistungsbedarf/Kühlung...), kommt auf den 
Einzelfall an.

DoDi

[toc] | [prev] | [next] | [standalone]

#233096

Hans-Peter Diettrich wrote:

> Ob dann Knoten mit (industrietauglicher) PC Hardware
> noch vorteilhaft sind (Platz, Preis, Netzteil,
> Leistungsbedarf/Kühlung...), kommt auf den Einzelfall an.

Ich sehe mich schon irgendwann mal eine Äpp programmieren, denn für die
reine Bedienung/Visualisierung sind die neuen (ja, ja, jetzt kommt mir
nicht mit #Neuland! ;o) Geräteklassen Smartphone und Tablet schon
richtig interessant.

[toc] | [prev] | [next] | [standalone]

#233214

Edzard Egberts schrieb:
> Ich habe mir inzwischen noch gedacht, dass PC-Hardware natürlich ein
> ganzer Haufen Rechenleistung auf kleinem Raum ist und es sicher auch
> Anwendungen gibt, bei denen diese Rechenleistung gebraucht wird - wenn
> nämlich die Signale nicht nur schnell sind, sondern auch in "Echtzeit"
> ausgewertet werden müssen, z.B. FFT.
>
> Da bleibt allerdings das Problem der Geometrie: Sachen im
> Mikrosekundenbereich kann man nicht "einfach so" mit Kabel anschließen,
> da stellt sich dann das Problem, wie man die gesteuerte Hardware in oder
> an den PC bringt. Hier haben Controller den großen Vorteil, dass sie
> direkt in die Steuerelektronik integriert sind und die schnelle
> Verarbeitung vor Ort in eine langsamere Datenübertragung umwandeln können.

Wirklich schnell wird es IMHO erst mit programmierbarer (FPGA) oder
programmierter (ASIC) Hardware. Ein Controller dazu hat üblicherweise
noch logischen oder physikalischen Platz auf dem Chip. Allerdings
muss man sich dann vom Wunschdenken schell-flexibel-billig verabschieden.

-- 
mfg Rolf Bombach

[toc] | [prev] | [next] | [standalone]

#233037

Am 04.10.2017 um 15:13 schrieb Stefan:

> 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 
> sowas auch mit einem Echtzeit-Linux hinbekommen würde.

Erfahrungen habe ich damit nicht, aber 3µs Genauigkeit erscheinen mir da 
schon sehr anspruchsvoll.


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

Hardware Interrupts gibt es schon, allerdings muß dafür auch die 
passende Hardware existieren, welche die Interrupts auslöst, und ein 
passender Treiber. Ob man dafür einen Printer-Port o.ä. mißbrauchen 
kann, wäre auszuprobieren. Ansonsten sieht es mit freien 
interruptfähigen Anschlüssen auf einem Mainboard nicht gut aus, es 
dürfte aber Karten (und hoffentlich auch Treiber) für spezielle I/O 
Karten geben.

Ich persönlich würde mir Echtzeit auf einer PC Hardware nicht antun, 
egal ob mit Linux oder RTOS, der Aufwand erscheint mir eher höher als 
mit Arduinos oder anderen µC. Sowohl was die Software (Treiber...) 
betrifft, als auch die Hardware (Anpassung an existierende I/O Kanäle).

DoDi

[toc] | [prev] | [next] | [standalone]

#233042

Am 04.10.2017 um 16:38 schrieb Hans-Peter Diettrich:
> Am 04.10.2017 um 15:13 schrieb Stefan:
> 

> Ich persönlich würde mir Echtzeit auf einer PC Hardware nicht antun, 
> egal ob mit Linux oder RTOS, der Aufwand erscheint mir eher höher als 
> mit Arduinos oder anderen µC. Sowohl was die Software (Treiber...) 
> betrifft, als auch die Hardware (Anpassung an existierende I/O Kanäle).
> 
> DoDi

Ich seh das genauso, nur da ich keine Ahnung von Echtzeit-Linux habe, 
wollte ich einfach mal fragen. Könnte ja auch sein, dass ich mich irre...

Im Prinzip bestätigen die bisherigen Antworten aber meine Vorurteile.

Gruß

Stefan

[toc] | [prev] | [next] | [standalone]

#233047

Am Mittwoch, 4. Oktober 2017 17:39:18 UTC+2 schrieb Stefan:
> Ich seh das genauso, nur da ich keine Ahnung von Echtzeit-Linux habe, 
> wollte ich einfach mal fragen. Könnte ja auch sein, dass ich mich irre...
> Im Prinzip bestätigen die bisherigen Antworten aber meine Vorurteile.

Es gibt ein paar gute Bücher zum Linux Kernel (zum Schreiben von Linux Modulen).

Bei Linux ist die Verteilung der Rechenzeit recht komplex und daher ist eine
genau geplante Reaktion in einer bestimmten Zeit nicht möglich.

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ält 
dazu evtl. Angaben [kernel-doc]).
Der Raspi soll auf mittlere 12 und 13 µs und maximal 83 µs kommen.

[toc] | [prev] | [next] | [standalone]

#233055

Stefan wrote:

> 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.

Ich will dich nicht von Linux abbringen, nachdem ich es selbst im
Büro nutze, aber ein guter Bekannter hat zeitkritische
Industriesteuerungen unter DOS programmiert. Den Scheduler hat er
einfach selbst geschrieben. Das ist schon ein paar Jahre her, ich
weiß nicht, was er heute nutzt. DOS Derivate bekommt man wohl auch
noch ganz offiziell für kleines Geld. Allerdings nicht von MS. DOS
hat halt wenig Overhead.
-- 
Gruß Werner
www.youtube.com/watch?v=ByzwOBeKD-c

[toc] | [prev] | [next] | [standalone]

#233057

Am 04.10.2017 um 19:54 schrieb Werner Holtfreter:
> Stefan wrote:
> 
>> 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.
> 
> Ich will dich nicht von Linux abbringen, nachdem ich es selbst im

Da hast du mich wohl falsch verstanden. Ich bin auf der Schiene 
Microcontroller für zeitkritische Sachen und PC-Technik oder Linux für 
die Verwaltung.

> Büro nutze, aber ein guter Bekannter hat zeitkritische
> Industriesteuerungen unter DOS programmiert.

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

> Den Scheduler hat er
> einfach selbst geschrieben. Das ist schon ein paar Jahre her, ich
> weiß nicht, was er heute nutzt. DOS Derivate bekommt man wohl auch
> noch ganz offiziell für kleines Geld. Allerdings nicht von MS. DOS
> hat halt wenig Overhead.

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

[toc] | [prev] | [next] | [standalone]

#233085

Stefan wrote:

> Am 04.10.2017 um 19:54 schrieb Werner Holtfreter:
>> Stefan wrote:
>> 
>>> 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.
>> 
>> Ich will dich nicht von Linux abbringen, nachdem ich es selbst im
> 
> Da hast du mich wohl falsch verstanden. Ich bin auf der Schiene
> Microcontroller für zeitkritische Sachen und PC-Technik oder Linux
> für die Verwaltung.
> 
>> Büro nutze, aber ein guter Bekannter hat zeitkritische
>> Industriesteuerungen unter DOS programmiert.
> 
> Na ja, es ist schon ein Unterschied, ob man mit Millisekunden oder
> Mikrosekunden rechnet.
> 
>> Den Scheduler hat er
>> einfach selbst geschrieben. Das ist schon ein paar Jahre her, ich
>> weiß nicht, was er heute nutzt. DOS Derivate bekommt man wohl
>> auch noch ganz offiziell für kleines Geld. Allerdings nicht von
>> MS. DOS hat halt wenig Overhead.
> 
> Wie geschrieben, meine Frage bezog sich nicht auf Dos gegen Linux
> sondern Microcontroller gegen Linux speziell bei zeitkritischen
> Sachen im Mikrosekundenbereich.

Du willst demnach wissen, ob PC-Hardware bestimmte Zeitanforderungen
erfüllt. Schön, aber das hängt doch davon ab, welches
Betriebssystem darauf läuft, bzw. ob überhaupt ein Betriebssystem
läuft, denn DOS ist im engeren Sinne ja kein Betriebssystem, weil
sich da ein Programm nach Belieben die Hardware krallen kann, ohne
dass man es zwingen kann, sie wieder freizugeben. Ideale
Voraussetzung für schnelle Reaktion.
-- 
Gruß Werner
www.youtube.com/watch?v=ByzwOBeKD-c

[toc] | [prev] | [next] | [standalone]

#233086

Am 05.10.2017 um 02:21 schrieb Werner Holtfreter:

> Du willst demnach wissen, ob PC-Hardware bestimmte Zeitanforderungen
> erfüllt. Schön, aber das hängt doch davon ab, welches
> Betriebssystem darauf läuft, bzw. ob überhaupt ein Betriebssystem
> läuft, denn DOS ist im engeren Sinne ja kein Betriebssystem, weil
> sich da ein Programm nach Belieben die Hardware krallen kann, ohne
> dass man es zwingen kann, sie wieder freizugeben.

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

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

Baue mal im System im Teil mit der höchsten Priorität:
while (true){}
ein.

Hermann
    der meint, auf Arduino läuft teilweise
    ein eigenes Betriebssystem wie z.B. setup()

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#233094

Am 05.10.2017 um 02:21 schrieb Werner Holtfreter:
> Stefan wrote:

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

Linux kann auch auf einem µC laufen, wenn man nicht gerade auf 
schmalbrüstige Arduinos festgelegt ist. Da hat ein Echtzeit-Linux 
vielleicht den Vorteil, daß sich mehr Programmierer damit auskennen als 
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.

> Du willst demnach wissen, ob PC-Hardware bestimmte Zeitanforderungen
> erfüllt. Schön, aber das hängt doch davon ab, welches
> Betriebssystem darauf läuft, bzw. ob überhaupt ein Betriebssystem
> läuft, denn DOS ist im engeren Sinne ja kein Betriebssystem, weil
> sich da ein Programm nach Belieben die Hardware krallen kann, ohne
> dass man es zwingen kann, sie wieder freizugeben. Ideale
> Voraussetzung für schnelle Reaktion.

Du meinst sowas wie TSR? Damit läßt sich herrlich zaubern :-)

Die seit dem 386 eigentlich ausgewachsene (sichere) Speicherverwaltung 
erlaubt sogar mehrere unabhängige DOS Boxen auf einem Rechner, mit 
vollständiger Kontrolle der Rechenzeit- und Speichervergabe durch ein 
OS. So narrensicher läßt sich ein µC System kaum aufbauen, das würde von 
virtuellem Speicher[1] nur ausgebremst. Ob man aber von dem zusätzlichen 
Aufwand der PC Hardware für Plattencontroller, Caches, Grafik- und 
Soundkarte profitieren kann, kommt sehr auf den Einzelfall an.

[1]Bei PC Hardware führt jeder Taskwechsel erst mal zum Umladen der 
Speichertabellen, und danach muß der Cache nachgeladen werden. Das 
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 
immer ein längerdauernder Vorgang, so daß es fraglich ist, ob ein 
Echtzeit-System sowas für die zeitkritischen Teile überhaupt 
unterstützt. Hoher Durchsatz läßt sich auf dieser Hardware nur erzielen, 
wenn keine Taskwechsel vorkommen, oder wenn so lange andere Kerne mit 
anderen Aufgaben einen hohen Gesamtdurchsatz vortäuschen. Wenn deshalb 
die Echtzeit-Tasks/Treiber in der Systemtask laufen, ist es auch vorbei 
mit der Abschottung gegeneinander. Das gilt für Linux, Windows und 
andere Systeme gleichermaßen.

DoDi

[toc] | [prev] | [next] | [standalone]

#233099

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

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

> Linux kann auch auf einem µC laufen, wenn man nicht gerade auf 
> schmalbrüstige Arduinos festgelegt ist.

Arduino Yun; mit Linux.

> Da hat ein Echtzeit-Linux  vielleicht den Vorteil,
> daß sich mehr Programmierer damit auskennen als 
> mit einem anderen RT-OS.

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

> [1]Bei PC Hardware führt jeder Taskwechsel erst mal zum Umladen der 
> Speichertabellen, und danach muß der Cache nachgeladen werden. Das 
> 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 
> immer ein längerdauernder Vorgang, so daß es fraglich ist, ob ein 
> Echtzeit-System sowas für die zeitkritischen Teile überhaupt 
> unterstützt.

Da frage ich, ob man nicht einer der  Multi-Core-Prozessoren
für Realzeitaufgaben abzweigen kann.

Hermann
    der da allerdings Probleme mit dem cache vermutet.

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#233061

Am 04.10.2017 um 15:13 schrieb Stefan:

> 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.

Rein intuitiv würde ich da an PCs über USB Arduinos dranhängen.
( Arduino Due wegen >80 MHz Taktfrequenz)
Eingriffe per Lötkolben auf eine motherboard ohne Schaltplan ..
Und eine Kernel update während der ..

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

-- 
http://www.hermann-riemann.de

[toc] | [prev] | [next] | [standalone]

#233095

Am 04.10.2017 um 20:44 schrieb Hermann Riemann:
> Am 04.10.2017 um 15:13 schrieb Stefan:
> 
>> 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.
> 
> Rein intuitiv würde ich da an PCs über USB Arduinos dranhängen.
> ( Arduino Due wegen >80 MHz Taktfrequenz)

Kommt drauf an, was man machen will.
Problem sehe ich schon mal bei USB, weil da das Timing völlig unbestimmt 
ist, d.h. man müsste erst einmal sehen, wann der USB Baustein denn 
gewillt ist, Daten zu versenden.

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

> Eingriffe per Lötkolben auf eine motherboard ohne Schaltplan ..
> Und eine Kernel update während der ..
> 
> Hermann
>     der c't make Arduino spezial wegen der interrupt Beschreibung
>     interessant fand.
> 

[toc] | [prev] | [standalone]

Back to top | Article view | de.sci.electronics

csiph-web