amiga-news DEUTSCHE VERSION
.
Links| Forums| Comments| Report news
.
Chat| Polls| Newsticker| Archive
.

amiga-news.de Forum > Programmierung > Betriebssystem vs. kein Betriebssystem [ - Search - New posts - Register - Login - ]

-1- [ - Post reply - ]

2006-03-31, 15:05 h

DrNOP
Posts: 4118
User
Mahlzeit.

Ich schon wieder ... ;)

Wir haben hier beie Arbeit eine Baugruppe, die nur dazu da ist andere Baugruppen zu überwachen. Dazu rechnen die anderen Baugruppen ihre nächsten Sollzustände aus und schicken sie seriell und über CAN an die angeschlossenen Aktoren und die Überwachung.
Die Überwachungsbaugruppe liest die Telegramme und vergleicht ihren Inhalt mit den gespeicherten Konfigurationsdaten der Anlage, um verbotene Zustände zu finden. Findet sie einen nicht erlaubten Zustand in einem Telegramm, so soll sie innerhalb von 300 ms eine Fehlermeldung an die anderen Baugruppen schicken und die Anlage abschalten.

Das funktioniert zwar seit Jahren, aber inzwischen eben so lange, daß der Prozessor abgekündigt ist und ein neuer her soll. Das nahm ein Kollege hier zum Anlaß, für die Neuimplementierung eine Variante mit Betriebssystem vorzuschlagen. Das halte ich bei dem Arbeitsumfang, den die Baugruppe hat, für etwas übertrieben. Bisher ist es ein einfacher Zustandsautomat, der eben nacheinander alle geforderten Arbeiten erledigt. Nebenbei bemerkt ist die Implementierung nicht gerade die beste ...

Was ich von seiner Argumentation behalten habe ist, daß mit einem Betriebssystem
- die Reaktionszeiten auf Interrupts besser werden
- die Telegramme schneller gelesen werden, falls viel Last auf dem Bus ist
- die Bearbeitung der Telegramme schneller erfolgt weil nicht erst der komplette Zustandsautomat abgeklappert werden muß, bis man an der passenden Stelle angekommen ist wo die Telegrammbearbeitung gemacht wird.

Ich denke, kein einziger dieser Punkte läßt sich allein durch den Einsatz eines Betriebssystems verbessern, weil die Menge der Programmschritte pro Umlauf die gleiche bleibt: Ich kriege eine bestimmte Menge Telegramme 'rein, muß sie untersuchen und ggf. reagieren. Wenn ich ohne Betriebssystem dazu nicht schnell genug bin, dann werd' ich das mit Betriebssystem sicher auch nicht sein, oder seh' ich da was falsch?

Auch die Reaktionszeiten auf Interrupts halte ich für kein geeignetes Argument, weil da im Endeffekt das gleiche gilt: Wenn nur genügend Interrupts kommen, dann halten sie mich auf jeden Fall von der Arbeit ab, ob mit oder ohne Betriebssystem. In beiden Fällen bleiben Telegramme unbearbeitet liegen.

Außerdem finde ich, daß er seine eigene Argumentation mit einem einzigen Satz ad absurdum geführt hat, als ein dritter Kollege fragte "Ja ist das denn echtzeitfähig?", nachdem er erfahren hat daß embedded Linux im Gespräch ist. Die Antwort jenes welchen war: "Da machen wir einen Task mit hoher Priorität, dann geht das schon."
Hm .... was unterscheidet diese Lösung dann noch von der ohne Betriebssystem?

Das hier ist keine Grundlage für eine tatsächliche Entscheidung für oder gegen ein Betriebssystem, ich wollte nur Außenstehende fragen ob ich mit meiner Ansicht wirklich völlig auf dem Holzweg bin oder ob mein Kollege versucht, mit Kanonen auf Spatzen zu schießen.
--
Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln.

[ - Answer - Quote - Direct link - ]

2006-04-03, 13:04 h

Solar
Posts: 3680
User
Dein Kollege will sich wichtig machen, hat aber keine Ahnung, was seine Aussage zum Thema "Echtzeitfähigkeit durch Task hoher Priorität" deutlich zeigt.

"Innerhalb von 300 ms" ist eine Echtzeitanforderung. Je nachdem, wie "wichtig" die Abschaltung in eben dieser Zeit ist, spricht man von einer "weichen" Echtzeitforderung (kann unter wirklich fiesen Umständen auch mal schiefgehen) und einer "harten" Forderung (es muß ausgeschlossen werden können, das es jemals schiefgeht).

Für letzteres bedürfte es eines speziellen Betriebssystems (QNX, RTLinux, VxWorks o.ä.), sowie rundrum darauf abgestimmte Hardware. "Da machen wir einen Task mit hoher Priorität, dann geht das schon" ist in dem Zusammenhang fahrlässiger Schwachsinn.

Woher der Kollege seine Behauptung nimmt, das es mit einem Betriebssystem schneller gehen soll, ist mir ebenfalls unklar. Um "schneller" geht's ja auch gar nicht, sondern um "innerhalb 300 ms".

Fazit: Laßt das jemanden entscheiden, der Ahnung von Echtzeitsystemen hat. Besagter Kollege hat diese Ahnung jedenfalls nicht.

[ Dieser Beitrag wurde von Solar am 03.04.2006 um 13:05 Uhr geändert. ]

[ - Answer - Quote - Direct link - ]

2006-04-03, 13:45 h

DrNOP
Posts: 4118
User
:lach:
Du hast meine Meinung über diesen Kollegen recht gut adaptiert ... :D

Dummerweise wird er von unseren Vorgestzten für einen von denen gehalten, die Ahnung von Betriebssystemen haben. Wir setzen bisher ja auch VxWorks ein auf unseren anderen Baugruppen - nur diese hier ist eben noch komplett ohne. "Der Trend", wie man so schön sagt, zeigt bei uns aber langsam weg von VxWorks, eben weil es lizenzfreie (oder günstigere) Alternativen gibt.

Wenigstens bin ich nicht komplett neben der Spur. :)
--
Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln.

[ - Answer - Quote - Direct link - ]

2006-04-03, 16:02 h

Solar
Posts: 3680
User
Bei entsprechender Simplizität der verwendeten Hardware kann eine Lösung in Hardware (d.h. ohne Betriebssystem) durchaus schnell und zuverlässig laufen - und ist wahrscheinlich einfacher "beweisbar" als eine OS-Lösung. Wie gesagt, die Argumentation "pro Betriebssystem" kann ich an dieser Stelle nicht ganz nachvollziehen.

[ - Answer - Quote - Direct link - ]

2006-04-03, 19:21 h

Holger
Posts: 8116
User
Zitat:
Original von DrNOP:
Dummerweise wird er von unseren Vorgestzten für einen von denen gehalten, die Ahnung von Betriebssystemen haben.

Selbst wenn das stimmen würde, kommt das, was Du beschrieben hast, ja perfekt ohne Betriebssystem aus, liegt somit außerhalb seines Kompentenzbereiches (immer noch unter der Annahme, Betriebssystem wären tatsächlich sein Kompentenzbereich).
Wenn er es geschafft hat dein Eindruck eines Betriebssystemexperten zu erwecken, ist die Motivation, überall Betriebssysteme ins Spiel zu bringen, auch verständlich.
Das ist so wie mit dem Biologiestudenten, dem Elefanten und dem Regenwurm...

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2006-04-03, 21:03 h

Solar
Posts: 3680
User
Zitat:
Original von Holger:

Das ist so wie mit dem Biologiestudenten, dem Elefanten und dem Regenwurm...


Du machst mich neugierig, erzähl mal... (*keuleschwing*) I-)

[ - Answer - Quote - Direct link - ]

2006-04-03, 22:48 h

DrNOP
Posts: 4118
User
Zitat:
Original von Solar:
Du machst mich neugierig, erzähl mal... (*keuleschwing*) I-)

Ja, das interessiert mich jetzt auch! :O


Vielleicht sollte ich noch erwähne, daß ich selbst aus dem "Kein-Betriebssystem"-Background stamme, aber das habt ihr euch sicher eh' gedacht. ;)
Jedenfalls hab' ich mich inzwischen unter den Kollegen weiter umgehört und habe doch noch was erfahren, was ziemlich eindeutig für ein Betriebssystem spricht:
Man kann die Telegramme einfacher in Queues schreiben, ohne sich um deren Abwicklung selbst kümmern zu müssen, ebenso Semaphoren, die ich ohne OS mit einfachen Flags "emulieren" müßte und solche Sachen. Dinge, um die man sich eben nicht unbedingt selbst kümmern müssen sollte, die einem das Betriebssystem abnehmen kann. Es war eben nur seine Argumentation, die totaler Quark ist. :P

Er hat ürbigens auch noch dieses PDF aus dem Hut gezaubert, um seine "pro OS"-Ansicht zu untermauern. Aber Vosricht ;) : Das scheint selbst von einem OS-Freund verfaßt zu sein, ich jedenfalls hätte mindestens für die Hälfte von dem, was der da ohne OS zusammenstrickt, einen anderen Ansatz gewählt...
--
Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln.

[ - Answer - Quote - Direct link - ]

2006-04-03, 23:26 h

ylf
Posts: 4112
User
Also wenn ich das richtig verstehe, dann ist die Lösung mit BS für den Programmierer einfacher, aber nicht wirklich besser.

Ich denke ein BS ist nur dann vom Vorteil, wenn die Aufgabenstellung komplexer ist. Oder komplexere Teilaufgaben implementiert werden müssen. Z.B. TCP/IP, Steuerung via http oder soetwas in der Richtung.

Hängt natürlich auch von der Performence des verwendeten Prozessors ab. Mir fällt in dem Zusammenhang die c't Artikelserie über den c't-Bot ein. Da muß man schon bei der Programmierung in C aufpassen und bestimmte programmtechnische Konstrukte vermeiden bzw. sparsam anwenden, um den "kleinen" 8Bit-Controller nicht zu überfordern.


bye, ylf

[ - Answer - Quote - Direct link - ]

2006-04-04, 08:12 h

DrNOP
Posts: 4118
User
Zitat:
Original von ylf:
Also wenn ich das richtig verstehe, dann ist die Lösung mit BS für den Programmierer einfacher, aber nicht wirklich besser.

Ich denke ein BS ist nur dann vom Vorteil, wenn die Aufgabenstellung komplexer ist. Oder komplexere Teilaufgaben implementiert werden müssen. Z.B. TCP/IP, Steuerung via http oder soetwas in der Richtung.

Ich denke, das siehst du richtig.

Zitat:
Da muß man schon bei der Programmierung in C aufpassen und bestimmte programmtechnische Konstrukte vermeiden bzw. sparsam anwenden, um den "kleinen" 8Bit-Controller nicht zu überfordern.
Es gibt eben grundsätzliche Unterschiede in der Herangehensweise:
Ohne Betriebssystem darfst du keine blockierenden Funktionen benutzen die erst dann weitermachen wenn sie ein Zeichen empfangen haben oder ähnliches, MIT Betriebssystem mußt du sie benutzen, sonst stiehlt ein Task den anderen Rechenzeit, obwohl er überhaupt nichts tut.
Auch For- und while-Schleifen sollte man möglichst durch if-Konstrukte ersetzen, die eben bei jedem Umlauf ein Stück weiterrechnen, ebenso Rekursionen. Einen Controller ohne Betriebssystem zu programmieren läuft im Endeffekt immer auf einen Zustandsautomaten 'raus. Hilfreich ist auch, wenn man weiß wie SPS programmiert werden... ;)
--
Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln.

[ - Answer - Quote - Direct link - ]

2006-04-04, 09:11 h

Holger
Posts: 8116
User
Zitat:
Original von Solar:
Du machst mich neugierig, erzähl mal... (*keuleschwing*) I-)

Eigentlich uralt. Es geht um einen Biologiestudenten, der nächtelang für seinen Prüfung gebüffelt hat und nun wirklich alles, jedes kleinste Detail über den Regenwurm inne hat.
Dann kommt die Prüfung und seine Aufgabe: eine Referat über den Elefanten.
Nach kurzem Stottern fängt er dann an: „Der Elefant hat einen langen Rüssel, der aussieht wie ein Regenwurm. Der Regenwurm ...‟

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2006-04-04, 09:21 h

Holger
Posts: 8116
User
Zitat:
Original von DrNOP:
Einen Controller ohne Betriebssystem zu programmieren läuft im Endeffekt immer auf einen Zustandsautomaten 'raus.

Ist das Betriebssystem nicht letztendlich auch nur ein Zustandsautomat?
Ich würde z.B. einen interruptgesteuerten Controller nicht automatisch als einen mit Betriebssystem bezeichnen.
Die Frage ist, wo man die Grenze zieht. Für mich gehört die Fähigkeit, beliebige Programme ausführen zu können, zu einem Betriebssystem. Ein Gerät mit nur einer Aufgabe, die auch einfach genug ist, um in einem einzigen Programm realisiert zu werden, braucht diese Fähigkeit imho nicht.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2006-04-04, 09:36 h

Holger
Posts: 8116
User
Zitat:
Original von DrNOP:
Jedenfalls hab' ich mich inzwischen unter den Kollegen weiter umgehört und habe doch noch was erfahren, was ziemlich eindeutig für ein Betriebssystem spricht:
Man kann die Telegramme einfacher in Queues schreiben, ohne sich um deren Abwicklung selbst kümmern zu müssen, ebenso Semaphoren, die ich ohne OS mit einfachen Flags "emulieren" müßte und solche Sachen.

Queues sind einfache Datenstrukturen, die man auch ohne Betriebssystem benutzen kann, aber auch nur dann braucht, wenn man Daten asynchron verarbeiten will. Und ohne Multitasking braucht man auch keine Semaphoren.
Die einzige parallelisierbare Aufgabe ist in Deiner Beschreibung das Empfangen und das Verarbeiten der Telegramme. Das kannst Du aber nicht über eine Queue realisieren "ohne sich um deren Abwicklung selber zu kümmern". Aus der Echtzeitanforderung "maximal 300ms bis zur Bearbeitung" ergibt sich eine maximale Queuelänge. Und die möglichen Schwankungen auf dem Bus dürfen nie die Queue überfordern.
Die sicherste Methode bleibt, das System so zu entwerfen, daß es immer genug Kapazitäten für eine synchrone Verarbeitung hat. Dann braucht es aber keine Queue.

mfg
--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2006-04-04, 13:03 h

DrNOP
Posts: 4118
User
Zitat:
Original von Holger:
Ist das Betriebssystem nicht letztendlich auch nur ein Zustandsautomat?

Finde ich nicht, aber das führt jetzt vielleicht auch zu weit.
Ein Zustandsautomat wie ich ihn kenne hat eine vordefinierte Anzahl von Zuständen, was bei einem Betriebssystem, das zur Laufzeit Tasks (mehrmals parallel) starten und beenden kann, so nicht der Fall ist.

Zitat:
Die sicherste Methode bleibt, das System so zu entwerfen, daß es immer genug Kapazitäten für eine synchrone Verarbeitung hat. Dann braucht es aber keine Queue.
Meine Rede. Und nachdem eh' ein neuer Prozessor her muß, sollte es ja kein Problem sein einen zu finden, der dafür leistungsfähig genug ist.
--
Es gibt keine Notbremse für all den technischen Humbug, mit dem wir unsere Zeit vertrödeln.

[ - Answer - Quote - Direct link - ]

2006-04-04, 13:28 h

Solar
Posts: 3680
User
Zitat:
Original von Holger:

Nach kurzem Stottern fängt er dann an: "Der Elefant hat einen langen Rüssel, der aussieht wie ein Regenwurm. Der Regenwurm ..."


:lach: :lach: :lach:

*keulewegsteck*

:D

[ - Answer - Quote - Direct link - ]

2006-04-04, 18:11 h

ylf
Posts: 4112
User
Zitat:
Original von DrNOP:
Zitat:
Original von Holger:
Ist das Betriebssystem nicht letztendlich auch nur ein Zustandsautomat?

Finde ich nicht, aber das führt jetzt vielleicht auch zu weit.
Ein Zustandsautomat wie ich ihn kenne hat eine vordefinierte Anzahl von Zuständen, was bei einem Betriebssystem, das zur Laufzeit Tasks (mehrmals parallel) starten und beenden kann, so nicht der Fall ist.


Oder mal anders betrachtet:
ein Zustandsautomat ist berechenbar,
ein Betriebssystem nicht ... :D

bye, ylf

[ - Answer - Quote - Direct link - ]

2006-04-05, 12:20 h

Holger
Posts: 8116
User
Zitat:
Original von DrNOP:
Finde ich nicht, aber das führt jetzt vielleicht auch zu weit.
Ein Zustandsautomat wie ich ihn kenne hat eine vordefinierte Anzahl von Zuständen, was bei einem Betriebssystem, das zur Laufzeit Tasks (mehrmals parallel) starten und beenden kann, so nicht der Fall ist.

Theoretisch.
Wenn das Betriebssystem aber wie für den hier beschriebenen Fall immer exakt dieselben tasks ausführt, stellt es eben jenen Zustandsautomaten dar, den man mit der single-task Lösung implementieren würde.
Plus den overhead für die theoretischen Möglichkeiten, weitere taks zu starten oder gar Programme aus externen Quellen nachzuladen, die man hier aber gar nicht nutzt.

mfg

--
Good coders do not comment. What was hard to write should be hard to read too.

[ - Answer - Quote - Direct link - ]

2006-04-05, 12:35 h

Solar
Posts: 3680
User
...plus die Unberechenbarkeit, bzw. die höhere Komplexität bei der Berechnung der Zeitbedarfe...

[ - Answer - Quote - Direct link - ]


-1- [ - Post reply - ]


amiga-news.de Forum > Programmierung > Betriebssystem vs. kein Betriebssystem [ - Search - New posts - Register - Login - ]


.
Masthead | Privacy policy | Netiquette | Advertising | Contact
Copyright © 1998-2024 by amiga-news.de - all rights reserved.
.