Also der TXT, wie das BeagleBoneBlack stammen zwar aus der selben Ti-Familie (am335x), aber leider hat der TXT
die Variante AM3352 (also keine PRU's), die eigentlich die "Krone" dieser SoC's sind.
Der Key dabei ist, das zusätzlich 2x200 MHz Risc - CPU's on board sind, die linux prinzipiell erst einmal nicht kennt.
Diese laufen mit 5 ns / Befehl (ca. 30 Assembler Befehle sind vorhanden, es gibt mittlerweile auch einen C-Compiler ...)
mit eigenem Speicher für Daten / Programm. Darüber hinaus ex. sog. Shared Speicher, in dem sowohl die PRU's, als auch
die ARM - CPU lesen/schreiben können...
Das ganze sieht dann so aus, das die PRU's, die diverse CPU-Pins im 5 ns Raster lesen/schreiben können, sich um die gesamte
low Level I/O (in der Regel via kaskadierter Schieberegister) kümmern, und hierbei die Output - Daten aus dem Speicher holen
(ARM schreibt), und die aktuellen Input Daten (ARM liest) im Speicher ablegt + Interrupt um den ARM zu "wecken".
=> Um einen Ausgang zu setzen, muss z.B nur ein Bit im Shared Speicher gesetzt werden, aber auch high Level Funktionen wie
Motor-Rampen, Motor - Zielfahrten wären prinzipiell dort einzubauen.
Da die PRU's den I/O Zyklus < 100 usec abwickeln können, sind quasi jitterfreie ARM I/O Zyklen von 1 msec problemlos
unter rt-linux möglich (habe Board(s) entwickelt, die in der realen Welt (+24 V, CAN, ....) genau das tun...)
Es müsste einfach nur der FT-Kern daran angepasst werden, die I/O's via Shared RAM zu setzen und zu lesen, und voila der
extrem schnelle und super sichere I/O Zyklus ist fertig, weil die PRU's nichts sonst tun, und auf nichts warten (das war die kurz Version ..)
=> Der ARM - Core (Linux, und damit auch das FT-Interface) bekäme dann quasi umsonst ein extrem zuverlässiges und schnelles I/O Interface,
wo nichts < 2 msec (Abtasttheorem) auf allen Kanälen übersehen wird ...