Hallo, Ich möchte eine Kombination aus Raspberry und µC nutzen, für eine Musterbasierte Datenverarbeitung und Ausgabe. Im Raspberry hab ich die Möglichkeit große Muster zu speichern, vorzuverarbeiten und zu ändern und kann sogar noch eine Netzanbindung bewerkstelligen. Leider ist der Raspberry für meine timinggenaue Ausgabe nicht geeignet. Auch nicht mit RT Betriebssystem, da dieser zuviele neben Tasks machen müsste. (Ein erster Versuch lief, war aber zu langsam und ungenau). Ich hab die Ausgabe auf ein Bussystem mit eine µC realisiert und kleienre Muster die in den Speicher passten zum testen genutzt. Was ohne Probleme funktionierte. Nun meine Frage wie kann ich die Vorteile beider System in Kombination nutzen? Wie kann ich mit dem µC auf die Daten vom Raspberry zugreifen. Meine erste Idee war, dass der Raspberry Daten in einen FIFO schiebt und der µC zyklisch die benötigte Adresse und Daten ausliest. Ist das machbar? Zur Zeit schiebt der Raspberry die Daten über eine parallele Anbindung in den µC, welcher dann die Verteilung und das timing für die Ausgabe übernimmt. Die Lösung fühlt sich aber noch nicht richtig an. Gibt es alternativen um mir den Speicher des Raspberrys für den Controller zu nutzen zu machen?
> Wie kann ich mit dem µC auf die Daten vom Raspberry zugreifen. Indem du eine Kommunikationsschnittstelle nutzt. Zum Beispiel UART oder I²C. > dass der Raspberry Daten in einen FIFO schiebt und > der µC zyklisch die benötigte Adresse und Daten ausliest Der µC wird wohl kaum direkten Zugriff auf den Arbeitsspeicher des Raspberry Pi haben. Also muss er selbst den Pufferspeicher enthalten, welcher dann vom Raspberry Pi über die Kommunikationsschnittstelle befüllt wird (jedes Modem und jeder Drucker funktionieren so). > Die Lösung fühlt sich aber noch nicht richtig an. Begründung?
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.
> Begründung warum sich > das noch nicht richtig anfühlt, sind die etwaigen Ungenauigkeiten Du könntest eventuell jedes Kommando mit einem Zeitpunkt versehen, der in der Zukunft liegt. Ein Timer auf dem µC führt dann die Kommandos zu den vorher festgelegten Zeiten aus.
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.
>Zur Zeit schiebt der Raspberry die Daten über eine parallele Anbindung >in den µC, welcher dann die Verteilung und das timing für die Ausgabe >übernimmt. Die Lösung fühlt sich aber noch nicht richtig an. 8 Bit Parallel? Was für eine Anbindung ist das? Normalerweise schaufelt man die Daten mit der nötigen Frequenz an die große CPU z.B. UART, SPI, I2C, CAN, MemoryMapped I/O. Der uC muss wie schon erwähnt die Daten solange buffern.
Der durchsatzstärkste Bus des Raspi ist übrigens das SPI (abgesehen von dem Camera Interface), aber I2C ist meist einfacher zu verwenden.
Patrick S. schrieb: > Wie kann ich mit dem µC auf die Daten vom Raspberry zugreifen. > Meine erste Idee war, dass der Raspberry Daten in einen FIFO schiebt und > der µC zyklisch die benötigte Adresse und Daten ausliest. Ist das > machbar? Welche Datenmenge musst du mit welcher Datenrate zum µC und von da weiter befördern? Was heißt "timinggenaue Ausgabe"? Kommt es auf Sekunden, Millisekunden oder Mikrosekunden an, nur um mal die Größenordnung zu klären?
Ich habe einen Arduino einfach über USB an den Raspi angeschlossen. Das geht prima, allerdings muss das Netzteil ausreichend sein. Für einen NXP Arm M0 Prozessor habe ich auch einen USB-Client Code geschrieben. NXP liefert Libraries mit. Auch damit ist eine Verbindung zu Raspi oder alternativen PC möglich.
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.
Externe RAM Bausteine haben in der Regel aber nicht zwei Busse. Ob es Spezielle FIFO Bausteine mit zwei Bussen gibt, weiß ich nicht. Habe ich jedenfalls noch nie gesehen. Es gibt viele Mikrocontroller mit einigen zig bis hundert kB internem RAM, der praktischerweise über DMA befüllt werden kann. Ich würde in diese Richtung weiter nachforschen. Schau mal: http://www.st.com/content/ccc/resource/technical/document/application_note/47/41/32/e8/6f/42/43/bd/CD00160362.pdf/files/CD00160362.pdf/jcr:content/translations/en.CD00160362.pdf
Ich sag ja: BeagleBone und die beiden PRUs benutzen. Das sind zwei zusätzliche 200MHz Microcontroller, die unabhänging vom Linux-Hauptprozessor laufen, ihr eigenes On-Chip RAM haben, aber gleichzeitig auf den kompletten Hauptspeicher und die IO-Pins zugreifen können. Das ist alles in in dem AM3559 Prozessorchip enthalten, da braucht es nichts externes dazu - keine FIFOs, keine extra Prozessoren. Andere Leute steuern damit Schrittmotoren oder Servos in Echtzeit, wobei der ARM die Bahnberechnungen macht, und die PRUs die berechneten Vektoren dann abfahren. Vom technischen Aspekt her ist das das Optimum. Hier hast Du was zum Einstieg. http://processors.wiki.ti.com/index.php/PRU-ICSS fchk
Stefan U. schrieb: > Externe RAM Bausteine haben in der Regel aber nicht zwei Busse. Ob es > Spezielle FIFO Bausteine mit zwei Bussen gibt, weiß ich nicht. Habe ich > jedenfalls noch nie gesehen. Dann schau mal her: https://www.idt.com/products/memory-logic/fifo-products/asynchronous-fifos Sind aber schweineteuer und werden heutzutage nur noch selten verwendet, weil es meistens bessere Lösungen gibt. Siehe mein vorheriger Post. fchk
>Ich möchte eine Kombination aus Raspberry und µC nutzen, für eine >Musterbasierte Datenverarbeitung und Ausgabe >Ich benötige die Daten etwa alle 10µs Du schreibst immer Ausgabe, wohin soll die Ausgabe sein? GUI App? Der Vorschlag von fchk ist auch eins der gängigen Möglichkeiten, welche ich kenne.
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.
Ich kann Frank nur zustimmen. Die Sitara Prozessoren wurden Speziell für solche Anwendungen entwickelt. Die Pi's wurden für für "Education" konzipiert. Auch die OSD335x (System on a Modul) haben PRU-ICSS. Da wird es dann auch günstiger: https://www.digikey.de/product-detail/de/ghi-electronics-llc/POCKETBEAGLE-SC-569/POCKETBEAGLE-SC-569-ND/7603326
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?
Patrick S. schrieb: > Oder gibt es Kritikpunkte am Beaglebone? Alles was nicht Raspberry Pi ist: Schau Dir vorher genau an, wie die OSs gepflegt werden und wie die "Community" ist. Bringt Dir nix, wenn Du ein tolles Board hast, welches dann keine Updates mehr bekommt und wo Du bei Fragen im Regen stehst, weil es kein anderer verwendet.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.