Ist die Programmierung mit Lazarus Free-Pascal zeitgemäß??

[mschnell]

Ein PI ist kein Controller. Den Dual Core dspic ist nicht dual core für doppelter allgemeine Rechenperformance wie RPI2 oder 3, aber um auf ein Core eine enge Motorkontrolle schleife aus zu führen, und den andere Core für Kommunikation mit den Außenwelt und die mehr langfristige Reglungsschleifen und Monitoring.

Wenn Du was schnelles und relativ einfach zu handhabendes mit Koprozessor willst, nimmst Du einen BeagleBone: ziemlich schneller ARM-Prozessor mit Linux (ähnlich RasPi), mindestens 2 sehr schnelle Hardware-nahe Koprozessoren, die auf alle Ressourcen des Chips zugreifen können und eigene sehr schnelle "nahe" (eigener Bus) Peripherie (z.B. Ethernet und Bit I/O) haben. (Ein Freund von mir hat in mehreren Projekten sehr gute Erfahrungen damit gemacht. )
-Michael

[mschnell]

Auch Kontroller mit integrierter Ethernet können eine Lösung sein, aber die sind seltsam, und kombinieren oft nicht mit Quadratur/Motorkontrol, was ich unbedingt benötige.

Meiner Ansicht ist der TI-Controller (Beagle-Bone) ideal genau dafür.
-Michael

[pluto]

Wenn Du was schnelles und relativ einfach zu handhabendes mit Koprozessor willst, nimmst Du einen Beaglebone:

Was ich mich immer Frage: Wo braucht man so viel Leistung?
- Um eine oder mehrer LED'S Blinken zu lassen?
- Um Sensoren Auslesen wie etwa dem BME280 oder so?
- Um ein WebServer zu betreiben?

[mschnell]

Wo braucht man so viel Leistung?

Ein "ordentliches" Embedded Ding (das nicht nur als ganz dumme Peripherie im Einsatz ist), sollte heutzutage einen Webserver haben, damit man es leicht konfigurieren und kontrollieren kann. Das ist nur mit vertretbarem Aufwand realisierbar, wenn es unter Linux läuft. Und dazu braucht es jede Menge Leistung.
Und wenn die angeschlossene Peripherie schnellen oder "realtime" Datenaustausch braucht, geht das sehr oft nicht unter Linux. Deshalb ist ein Koprozessor nötig.
-Michael

[pluto]

Ein "ordentliches" Embedded Ding (das nicht nur als ganz dumme Peripherie im Einsatz ist), sollte heutzutage einen Webserver haben, damit man es leicht konfigurieren und kontrollieren kann.

OK, dafür würde sich aber ein ESP8266 oder ein EPS32 sehr gut für eignen... Wir wollen doch nicht mit Kanonen auf Spatzen schießen oder?
Gut Grafana würde ich jetzt nicht unbedingt auf ein ESP laufen lassen, nicht mal auf einem PI, aber dafür wird es denke ich auch eine Alternative geben.
Ich finde, wenn man es "richtig" anstellt, kann man mit Arduino und CO schon sehr viel machen.

Und dazu braucht es jede Menge Leistung.

Kommt auf den WebServer an und wie viele Nutzte es geben wird.

Und wenn die angeschlossene Peripherie schnellen oder "realtime" Datenaustausch braucht, geht das sehr oft nicht unter Linux. D

Auch für Linux gibt es Realtime Kernels.
Wie oft ist das wirklich notwendig?

[mschnell]

Wie oft ist das wirklich notwendig?

Sehr oft, wenn man exakte Zeiten benötigt. Mit Linux ist das kritisch und falls es möglich ist u.-U. sehr aufwändig. Mit einem Koppropzessor ist es sehr einfach.
-Michael

[pluto]

Sehr oft, wenn man exakte Zeiten benötigt.

Kannst du ein Beispiel nennen, wo man wirklich exakte Zeiten benötigt?

[six1]

Wenn ich einen uC einsetze, dann habe ich volle Kontrolle in Echtzeit, die man vielleicht auch für Steuerungsaufgaben braucht.
Ich zumindest setze Atmels in solchen Steuerungen ein, wo ich genaue Zeiten abbilden muss.
Mit einem Arm und Linux hat das ja mal gar nichts zu tun.

[mschnell]

Kannst du ein Beispiel nennen, wo man wirklich exakte Zeiten benötigt?

-> https://de.wikipedia.org/wiki/Echtzeitsystem
-Michael

[pluto]

-> https://de.wikipedia.org/wiki/Echtzeitsystem

Die in den Artikel genannten Beispiele, sind aber für den Normalen Anwender etwas weit hergeholt, behaupte ich jetzt einfach mal.
Ich denke, in der Regel ist realtime nicht unbedingt erforderlich...
Es gibt ja noch FPGAS.

[six1]

Eigentlich braucht man über dieses Thema wenig bis gar nicht diskutieren.
Linux ist kein Echtzeit Betriebssystem
R-Tos wäre eines...
Wenn ein kleiner Kontroller in Echtzeit die Arbeit verrichten kann, warum sich dagegen sträuben?
Wenn die Anforderungen zu hoch sind für einen kleinen Kontroller, kann man ihn ja noch immer an den "PC" hängen und die Steuerung so in Echtzeit durchführen, die Bedienung jedoch auf dem PC vollziehen...

[pluto]

Linux ist kein Echtzeit Betriebssystem

Wie schon erwähnt: Es gibt ein Realtime Kernel. Wie Aktuell der ist, weiß ich nicht, es gibt ihn aber.

Wenn ein kleiner Kontroller in Echtzeit die Arbeit verrichten kann, warum sich dagegen sträuben?

Ich finde es einfach nur übertrieben... Es gibt nur einige bis wenige wirkliche Anwendungenfälle.
Außerdem muss du, die beiden "Systeme", welche das auch immer sein mögen mit einander verbinden... das dürfte mehr Aufwand sein.

[marcov]

Wenn Du was schnelles und relativ einfach zu handhabendes mit Koprozessor willst, nimmst Du einen Beaglebone:

Was ich mich immer Frage: Wo braucht man so viel Leistung?
- Um eine oder mehrer LED'S Blinken zu lassen?
- Um Sensoren Auslesen wie etwa dem BME280 oder so?
- Um ein WebServer zu betreiben?

Motor auf eine Axe mit ein Quadraturencoder, paar foto-sensoren, Fotosensoren tüchtig debouncen. (motoren verursachen einfach Interferenz ), motor reglen an der Hand der Encoder um sie so sanft möglich laufen zu lassen. (nur fürs Messaparat, fester Schnelheit nicht fester Torque)Und dan pro Rundgang gibts auf mehrere Angeln was spezials zu tun (pneumatisch raus). Schnelheid Rundgang von einmal pro 10 Sekunden (Messapparat) biss zehn-fuefzeen mahl pro Sekunde (Produktion laufender band mit typisch Bierflaschen)

Aber alles sind Techniken die auch in typische Maker Anwendungen wie zb 3D Printer, speziell die des Messapparat. Das ist auch alles fein steuern von (stepper) Motoren. Den Hauptunterschied von Speziallösungen für die Industrie sind etwas mehr isolation (als optocoupler und driver Module, nie Prozessor pinnen direkt anschließen), ein und etwas mehr Validation von Signalen im Software (immer Interferenz) und ein eigenes Powersupply. Oft muss man auch 10 Jahre Ersatzteile garantieren

Das macht leider nutzen Makerkram schwierig , und man muss eigen Prints machen.

[marcov]

Auch Kontroller mit integrierter Ethernet können eine Lösung sein, aber die sind seltsam, und kombinieren oft nicht mit Quadratur/Motorkontrol, was ich unbedingt benötige.

Meiner Ansicht ist der TI-Controller (Beagle-Bone) ideal genau dafür.

Ich denke der kann das schon ja. Aber ist mehr etwas wie PIC32MZ, aber dan mit etwas Motorkontrol.

Aber schwere zu programmieren, schwerer zu Soldieren usw, und forcierter Teilung von Realtime und nicht.

Das ist nur eine erste Impression.

[Timm Thaler]

Ich finde es einfach nur übertrieben... Es gibt nur einige bis wenige wirkliche Anwendungenfälle.

Ähm sorry, nur weil Dir gerade keine einfallen heisst das nicht, dass es nicht zahlreiche Anwendungen für µC in Echtzeit gibt. Angefangen von stromsparenden Sensoren, Datenloggern bis zu Motorregelung, PWM. => 3D-Drucker, Quadrokopter, CNC-Maschine...

Jede Woche schlagen im Raspberry-Forum die Leute auf, die sich wundern warum ihre LED-Steuerung mit PWM auf dem Raspi flackert. Tja, ist halt kein Echtzeit-System, und wenn der Raspi gerade über was anderes nachdenkt, kann so eine Software-PWM schon mal nicht bedient oder der Dimmerwert für eine Hardware-PWM nicht stetig aktualisiert werden.

Meine Heizungssteuerung macht Phasenanschnitt- bzw. Schwingungspaketsteuerung für die Heizungs-, Solar-, Kessel-... pumpen, Mischer netzsynchron für 10 Ausgänge mit einem ATtiny. Steuerung über I2C. Die netzsynchrone Ansteuerung überlasse ich nicht dem Hauptcontroller - denn jeden Jitter um ein paar µsec in der Ansteuerung hörst Du in den Pumpen - und schon gar nicht einem Raspberry oder irgendwas super intelligentem, was dann erstmal mit sich selbst beschäftigt ist.

Meistens zeigen Aussagen wie "das braucht man nicht, das ist überholt, wozu ein 8-Bitter wenn es 32-Bitter gibt..." nur, dass da jemand nicht über den Tellerrand schauen kann und denkt, seine kleine Entwicklerwelt ist das ganze Universum.