IO Timing synchron zu Encoder (Verschleppung)

Andreas T. schrieb:

Eher ist IIOT in Hochsprachen auf dem Pi

Das soll jetzt nicht irgendwie abwertend sein: so hört sich auch dein Vokabular an. Du verwendest Worte (Event, Queue, Statuswechsel, PinID...), die einem Hardwareentwickler nichts Verbindliches oder Realisierbares sagen. Denn für den hat ein Eingang natürlich keine "Eingangsevents", sondern ein Eingang ist ständig da und hat ständig Information.

digitale Signale von einem IOT2000 mit einem Drehgeber synchron einzulesen, zu verschleppen und wieder auszugeben.

?? Häh? Du willst mit einem Drehgeber digitale Signale einlesen? Oder hast du da Quelle und Zeil vertauscht? Hast du einfach mal eine Skizze, was da wo wie mit wem verbunden ist und wo du dein Gerät siehst?

Was ich bräuchte: Drehgebereingang A/B: ~50-60 kHz mindestens 16 IN mindestens 16 OUT

Und was soll damit wie lange "verschleppt" werden? Kannst du da mal ein Timing-Diagramm oder irgendsowas malen?

Andreas T. schrieb:

Was ich mir auf vorstelle ist ein Arduino-Shield mit ...

Kann es sein, dass du damit ein nicht echtzeitfähiges IOT-Gerät auf Echtzeit "ertüchtigen" willst, indem du für die Eingänge eine Art Logicanalyzer baust und für die Ausgänge eine "Todo"-Liste, wo eingetragen wird, zu welchem Zeitpunkt was ausgegeben werden soll?

Das wird im echten Leben nicht brauchbar funktionieren, weil ja die "Nichtechtzeit" des IOT-Geräts eine Reaktion der Ausgänge auf eine Eingangsbedingung beliebig verzögert. Also: sogar wenn du herausfindest, dass der Stop-Taster zum Zeitpunkt 100ms gedrückt wurde, du das dann aber erst zum Zeitpunkt 1700ms einliest und berechnest, dass zum Zeitpunkt 101ms der Motor abgeschaltet werden müsste, wird der Motor frühestens bei 1701ms anfangen zu bremsen.

Lothar M. schrieb:

Kann es sein, dass du damit ein nicht echtzeitfähiges IOT-Gerät auf Echtzeit "ertüchtigen" willst, indem du für die Eingänge eine Art Logicanalyzer baust und für die Ausgänge eine "Todo"-Liste, wo eingetragen wird, zu welchem Zeitpunkt was ausgegeben werden soll?

Ja genau dass, aber ohne sicherheitsrelevante Themen und direkte Steuerung von Analagen ... Es geht konkret darum Laufmeter (Encoderpulse) in einem Produktionsprozess von ca. 1000 m/min zu verfolgen. Dabei will ich verschiedene Sensoren (Digitale Eingänge) den Laufmetern des Materials zuordnen können, um diese später wieder aufzufinden. Am Ende des Prozesses gibt es eine Schleuse, die im richtigen Moment ausgelöst werden soll. Also die Gesamtanwendung hat tatsächlich eine Echtzeit- und eine IIOT-Ebene, die miteinander kommunizieren.

Auf dem IOT-Gerät hätte ich ausreichend Zeit (einige Sekunden) die Daten zu verarbeiten, und auch hier steht mir "Echtzeit" zur Verfügung (PREEMPT_RT). Aber bei 60 kHz Pulsgenau? Das sollte Hardware übernehmen. Daher meine Frage welche Hardware (für den Echtzeitteil) dass leisten könnte. Bei 50-60kHz Encoderfrequenz bräuchte ich für die gesamte IO-Loop eine Zykluszeit von < 20 µs. Komme ich da mit einem aktuellen Microcontroller aus oder brauche ich einen FPGA/CPLD für das harte Timing?

https://www.golem.de/news/bastelrechner-arduino-board-hat-fpga-integriert-1909-144114.html

Naja, da Overkill und mit Kanonen auf Spatzen schießen heute Volkssport ist, kann man auch einen fetten 32 Bit Controller mit 100MHz++ CPU Takt nehmen und die Kernroutine in einem sehr schnellen Interrupt abhandeln, ggf. sogar in Assembler. Das mache ich in einem Projekt in der Firma, dort läuft eine 100kHz ISR in einem PICCOLO, die handhabt den ADC und bis zu 5 digitale Regler.

Hallo,

das messen selbst ist nicht das Problem. 60kHz sind 16,7µs. Ich frage mit einem 20MHz getakteten AVR128DB64 3 Encoder innerhalb von 9,6µs ab und aktualisiere die Zählerstände. Eine Abfrage eines Encoders würde 6,3µs dauern. Dabei werden die I/Os nur gepollt. Die Frage lautet eher wie kommt der Zählerstand von diesem dafür abgestellten µC in deinen Pi? Spielt die "langsame" Übertragungszeit eine Rolle? Per USART, I2C, SPI? Du müsstest die Encoderabfrage dann sicherlich in einen Timer-Interrupt legen. Sonst wärest du während der Übertragung blind. Wenn du dafür einen schnelleren µC verwendest, sehe ich keine Probleme. Das Abfrageintervall sollte ja bei dir unter 8µs bleiben inkl. ggf. weiterer Verarbeitungszeiten vor der Übertragung.

Andreas T. schrieb:

Drehgebereingang A/B: ~50-60 kHz mindestens 16 IN mindestens 16 OUT

Es gibt uC mit dedizierter Encoder Hardware. Bei TI Piccolo heißt das glaube ich QEI (Quadrature Encoder Interface). Bei ST können das glaube ich bestimmte Timerzellen. Damit könnte man den Encoder schonmal in die Hardware auslagern. Was schon einiges an unnötiger Last von der CPU nimmt.

Wenn man richtig Latenzarm sein will würde man vermutlich ein Controller mit ausreichend Pins suchen um die Daten nicht erst noch über SPI lesen/schreiben zu müssen. Also großes Package. 16xIN einlesen wäre dann in einer zyklischen Task? Entprellen wirst du trotzdem müssen um deine Input Queue nicht vollzurotzen.

Das setzen der Outputs sehe ich da schon kritischer. Gerade wenn es zu einem bestimmten Zählerstand (exakt zur Flanke des Encoders?) sein sollte. Hast du nicht gesagt, merke ich nur an.

Außerdem brauchst du noch eine Logik dass dir niemand Dinge in deine Output Queue schreibt die sich gegenseitig blockieren. Ich denke da an zu spät ankommende Aufträge (Zählerstand ist schon beim Eintreffen der Queue über/unterschritten) oder sich gegenseitig blockierende Jobs (Auftrag 2 in Queue ist eigentlich vor Auftrag 1 dran).

Dann noch ein schlankes Protokoll mit wenigen Bytes. Feste Länge. DMA kopiert die Daten vom Peripheral und löst nach X Byte den Empfangs-ISR aus.

Andreas T. schrieb:

Ich weiß, dass einige Framegrabber für Zeilenkameras genau diese Funktionalität über FPGA bieten, aber ich brauche einfach nur die IOs.

Klar mit FPGA bekommst du das richtig Echzeitfähig hin. Die Frage ist ob du das wirklich brauchst und du dir das wirklich antun willst. Gerade wenn uC schon eine Hürde ist wird es mit FPGA nicht besser werden, oder?

Andreas T. schrieb:

Gibt es einen entsprechenden FPGA/CPLD-Shield, den ich so nutzen könnte.

Eva Boards gibt's wie Sand am Meer. Max1000 oder DE0Nano wären so zwei was mir sofort einfallen. Da würde auch noch ein kleiner Softcore reinpassen falls man ihm braucht. Aber wenn die Echtzeitforderungen nicht zu hoch sind sollte das auch mit einem uC machbar sein.

Danke für die vielen Infos. Vor allem der "Spartan Edge Accelerator" sieht spannend aus. Habe noch zwei Arduino-Shields gefunden, die auch Hilfreich sein könnten:

• https://earthpeopletechnology.com/?wpsc-product=ept-570-ap-u2-usbpld-development-system-for-the-arduino-uno
• https://oe7twj.at/index.php?title=Arduino/Amani/64 - (da fehlt mir aber leider eine Bezugsquelle)

Mein Pi ist ein Siemens IOT-2040 und der hat einen Arduino-Shield kompatiblen Sockel. Aber spätestens wenn es an FPGA/CPLD Programmierung, geht werde ich mir wohl noch ext. Unterstützung suchen.

Andreas T. schrieb:

Danke für die vielen Infos. Vor allem der "Spartan Edge Accelerator" sieht spannend aus. Habe noch zwei Arduino-Shields gefunden, die auch Hilfreich sein könnten:

https://earthpeopletechnology.com/?wpsc-product=ept-570-ap-u2-usbpld-development-system-for-the-arduino-uno

Naja, ein CPLD mit 440 Macrozellen ist heute nicht mehr so dolle. Kann sein, daß man den Kram reinkriegt, kann aber auch eng werden. Ich würde damit nicht ins Rennen gehen. Selbst der kleinste FPGA kostet keinen Cent mehr als so ein CPLD und hat locker Faktor 10 und mehr Logikresourcen incl. RAM! Den brauchst du für deine Queues.

• https://oe7twj.at/index.php?title=Arduino/Amani/64 - (da fehlt mir aber leider eine Bezugsquelle)

64 Macrozellen ist erst recht Spielzeug! Finger weg!

Mein Pi ist ein Siemens IOT-2040 und der hat einen Arduino-Shield kompatiblen Sockel.

Vergiss den Sockel, nimm normale Schnittstellen wie UART, SPI oder I2C. Wenn die Zusatzlogik gescheit gebaut ist, kann man das recht locker von außen steuern. Ohne Zeitstress.