µC Raspberry Kombo

parallel ist da schon am effektivsten denke ich. Begründung warum sich 
das noch nicht richtig anfühlt, sind die etwaigen Ungenauigkeiten. Ich 
habs noch nicht ausreichend getestet. Kann mir aber vorstellen das beim 
abarbeiten von Nebentasks die Daten nicht immer schnell genug gesendet 
werden. Deswegen hab ich an einem FIFO gedacht, den ich wahrscheinlich 
intern mit dem Controller lösen muss.

Ein bisschen mehr Information zum Drumherum wären interessant.
Wie liegen die Muster Informationen vor, die der Raspberry 
schlussendlich erhalten soll?
Sind es einfach nur binäre Signale?

Es gibt zielgerichtete ICs für alle möglichen aufgaben, die man dann per 
i2c direkt an den Raspi anschließen kann.


Ansonsten wenn du selbst den Mikrocontroler programmieren musst, dann 
wirst du dir wohl oder übel ein kleiens protokoll ausdenken müssen das 
die Anforderungen wie Datenreihenfolge usw. erfüllt.
Kommt alles darauf an, welche Bestandteile der Information gebraucht 
werden.

Nur zum Zwecke der Reihenfolge packst du am besten die Daten auf dem 
Mikrocontroelr in Blöcke und verschickst immer wenn ein Block voll ist.
Also ein klassischer Puffer.
Zu nen gewissen Grad ist das schon FiFo, aber du brauchst im Endefekt 
nur einen inkrementierenden pointer.

Der durchsatzstärkste Bus des Raspi ist übrigens das SPI (abgesehen von 
dem Camera Interface), aber I2C ist meist einfacher zu verwenden.

Du könntest einen Beaglebone Black verwenden und für die Echtzeittasks 
die beiden PRUs des Prozessors benutzen. Genau dafür sind die gemacht.

Der Pi ist dafür nicht besonders gut geeignet. Der Prozessor war 
ursprünglich für digitale Bilderrahmen gedacht, und das merkt man immer 
noch.

fchk

Was es für Übertragungsmöglichkeiten gibt, ist mir an sich bewusst. Der 
Inhalt der Matrix auf dem Raspberry besteht immer aus einem byte. Und 
die schnellste Art der Datenübertragung auf kurzen wegen ist die Daten 
einfach parallel an einem Port des µC zu senden. Ich benötige die Daten 
etwa alle 10µs. Bis jetzt habe ich es so gemacht, das erst die Adresse 
gesendet wird anschließend die Daten. Ich habe jedoch die Befürchtung, 
dass der Raspberry mit Nebentasks zu tun hat, so dass ich gern, den 
Raspberry timingunabhängig seine Daten in einen Speicher schreiben 
lassen möchte und der Controller dann das timing übernimmt. Da die 
Matrix sehr groß ist, hab ich gedacht, dass es vlt sinnvoll wäre die 
Daten in richtiger Reihenfolge nacheinander in einen FIFO zu legen und 
den Controller die Asugabe übernehmen zu lassen. Hatte dies bis jetzt 
direkt gelöst, was bedeutet der Raspberry Daten sendet - der Controller 
empfängt diese und gibt sie auf den Bus direkt aus.
Bei dem Weg mit dem Zwischenspeicher (noch nicht ausprobiert) hat der 
Controller jedoch die extra Aufgabe zu welchem Zeitpunkt er was 
raussenden muss. Ich suche nun eine Lösung die am sinnvollsten ist. Ich 
könnte ja auch die Matrix komplett in einem externen RAM speichern und 
den Controller alles machen lassen, da hab ich das Problem das die 
Matrix zu groß werden könnte im extrem Fall und ich immer an ein maximum 
des Speichers gebunden bin.

Patrick S. schrieb:
> Leider ist der Raspberry für meine
> timinggenaue Ausgabe nicht geeignet. Auch nicht mit RT Betriebssystem,

Wie kommts? Was genau brauchst du denn?

Mit Vanilla Linux aus dem Userland und DMA kommt man bspw. mit MOSI/MISO 
auf ca. 30 MBit Bitstream. Wenn der µC SPI auf der Hardware hat, bietet 
sich SPI als Übertragung an (btw: RPi kann nur SPI Master).

> da dieser zuviele neben Tasks machen müsste. (Ein erster Versuch lief,
> war aber zu langsam und ungenau).

Welches RTOS hast du denn genommen was nicht kann, was du über µC 
hinbekommst? Lt. Nutzerberichten wurden mit Ultibo schon 1 MHz 
Bussysteme simuliert.

Patrick S. schrieb:
> Ich benötige die Daten
> etwa alle 10µs. Bis jetzt habe ich es so gemacht, das erst die Adresse
> gesendet wird anschließend die Daten.

Also du "sendest" 8 Bit alle 10µs?! Wie stelltst du sicher dass die 
Daten am Pi exakt zu dem Zeitpunkt/dauer anliegen?

Prinzipiell kann man Bitstreams auf ein oder zwei Pins Taktgenau 
serialisieren: PWM (2x), PCM (1x), 2x SPI (1x). Um mehr zu machen, 
könnte sich der Secondary Memory Bus eignen, der allerdings nicht 
dokumentiert ist.

https://www.raspberrypi.org/app/uploads/2012/02/BCM2835-ARM-Peripherals.pdf

Da parallele Ausgabe ansonsten nicht getaktet möglich ist, müsstest du 
die Daten "wild" senden. Dann brauchst du eine oder zwei Steuerleitungen 
(Data Activ, ggf. Ack) für den Handshake; plus auf dem µC einen Buffer 
der groß genug ist, die Totzeiten des RPi auszugleichen. Das müsste der 
µC nebenbei machen!

Patrick S. schrieb:
> hab ich gedacht, dass es vlt sinnvoll wäre die
> Daten in richtiger Reihenfolge nacheinander in einen FIFO zu legen und
> den Controller die Asugabe übernehmen zu lassen.

Solch ein Baustein brauch dann zwei Busse und muss auch irgendwie 
angesteuert werden. Mit ist kein "Wald-und-Wiesen" external SRAM FIFO 
bekannt. Vielleicht kennt ja von den Profis hier einen.

Frank K. schrieb:
> Der Prozessor war
> ursprünglich für digitale Bilderrahmen gedacht

Quelle?

Also der Beaglebone hat mein Interesse geweckt. Versteh ich das richtig, 
dass ich auf dem Beaglebone Linux als Betriebssystem laufen lassen kann 
und die µController seperat programmieren kann bzw. den vom 
Betriebssystem unabhängig aufgaben geben kann. Das klingt ja wie 
geschaffen für meine Anwendung. Oder gibt es Kritikpunkte am Beaglebone?

Du könntest auch einen Raspberry Pi nehmen und dort AMP betreiben. Du 
lässt das Linux auf nur 3 Cores laufen. Dann lädst du die 
Echtzeitanwendung in einen freien (reservierten) Speicher und startest 
damit den 4. Core, der dann die Echtzeitanwendung laufen lässt.

Im Anhang ein Bericht wo soetwas auf einem i.MX6 gemacht wurde. Sollte 
auf dem Rpi eigentlich auch gehen.

Ich find die Lösung ziemlich gelungen (wenn nicht genial) wenn man keine 
Extra-CPUs für die Echtzeit hat.

900ss D. schrieb:
> Du könntest auch einen Raspberry Pi nehmen und dort AMP betreiben. Du
> lässt das Linux auf nur 3 Cores laufen. Dann lädst du die
> Echtzeitanwendung in einen freien (reservierten) Speicher und startest
> damit den 4. Core, der dann die Echtzeitanwendung laufen lässt.
>
> Im Anhang ein Bericht wo soetwas auf einem i.MX6 gemacht wurde. Sollte
> auf dem Rpi eigentlich auch gehen.

Sehr interessanter Ansatz!
Heir hatd as jemand tatsächlich auf dem Raspberry hinbekommen!
http://telmomoya.blogspot.de/2016/10/

Ob der Aufwand gegenüber einem separaten Microcontroler lohnt, ist die 
andere Frage...
Das einzige was man spart ist die Kommunikation.

Patrick S. schrieb:
> Also der Beaglebone hat mein Interesse geweckt. Versteh ich das richtig,
> dass ich auf dem Beaglebone Linux als Betriebssystem laufen lassen kann
> und die µController seperat programmieren kann bzw. den vom
> Betriebssystem unabhängig aufgaben geben kann. Das klingt ja wie
> geschaffen für meine Anwendung. Oder gibt es Kritikpunkte am Beaglebone?

Ja, die beiden PRUs laufen unabhängig vom Linux-ARM. TI hat Compiler und 
Bibliotheken und Linux-Treiber dafür. Der Support für die TI Sitara ARMs 
sollte längst im Mainland-Kernel von kernel.org angekommen sein. Du 
brauchst also keine spezielle Distribution mehr. Beim Beaglebone wird 
defaultmäßig ein normales Debian benutzt, Du darfst aber auch gerne 
Anstrøm oder was anderes nehmen.

Der Beaglebone Black hat alles, was dem Pi fehlt: vernünftige 
Peripherie. Beispielsweise echtes Gigabit Ethernet ohne Umweg über USB. 
Der Chip selber kann auch noch ein zweites Gigabit Ethernet ansteuern, 
aber auf dem originalen Beaglebone Black ist das nicht implementiert. 
Oder 2* CAN-Bus im Prozessor und nicht extern via SPI angeflanscht. Da 
gehen Dir dann auch bei hoher Buslast keine Pakete verloren.

fchk

Vielen Dank Frank. Ich werd mir einen zu Testzwecken besetellen. Ich 
stürz mich damit ja nicht in Unkosten. Aber das was ich gelesen hab, 
klingt sehr interessant und ich freu mich auf den beaglebone.

Ich hab noch eine Frage bezüglich des shared memory. Wie groß ist der 
Speicher den man gemeinsam nutzen kann mit dem embedded Linux und den 
PRU Controllern oder kann man direkt auf den internen RAM über die PRUs 
zugreifen?

Das hat mir nicht geholfen, wenn dus weißt dann sags einfach. Aber nen 
Link von der Hauptseite reinstellen kann jeder. Bin anders weitig fündig 
geworden. Anscheinend gibt es 12kB shared Ram, was mir jedoch zu wenig 
ist. Die Möglichkeit scheint zu bestehen direkt auf den Arbeitsspeicher 
zuzugreifen über die PRUs. Sorge bereiten mir da eventuelle 
Zugriffskonflikte falls Linux und einer der PRUs gleichzeitig zugreifen 
wollen.

Willkommen in der Welt des Multithreadings. Nichts anderes ist das im 
Grunde. Es kann eine grausame aber dafür leistungsstarke Welt sein :)
Dabei hast du es noch einfach wenn diese 12Kb in Hardware geschützt sind 
(also du darauf sowas wie semaphores oder einfach atomare Operationen 
nutzen kannst). Benutz die einfach um (atomar) Flags zu setzen, wann die 
PRU schreibt und wann nicht und nimm 2 Buffer im Hauptspeicher die 
ausgetauscht werden. Also aus dem einen wird dann grad gelesen und 
verarbeitet während in dass andere gleichzeitig in Echtzeit die nächsten 
Daten geschrieben werden.

Hat denn hier jemand schon einen der Beagles mit seinen PRUs 
programmiert und kann seine Erfahrungen mitteilen?

Edit: Die hohe Latency und die nicht-deterministische Antwortzeit bei 
Zugriffen auf den (Haupt-)Speicher ist zwar nicht wirklich überraschend, 
ist aber etwas was man bei der Programmierung wohl im Auge behalten 
muss.