BeagleBone Blue robotics controller

Für Microcontroller und sonstige "echte" Technik-Themen, die sonst nichts mit ft zu tun haben
Everything technical that has nothing to do with ft
Forumsregeln
Bitte beachte die Forumsregeln!
Antworten
Benutzeravatar
Defiant
Beiträge: 354
Registriert: 31 Okt 2010, 21:42
Wohnort: Narn Homeworld
Kontaktdaten:

BeagleBone Blue robotics controller

Beitrag von Defiant » 12 Jan 2016, 20:40

Die BeagleBoard-Macher haben ein neues Mitglied der Familie angekündigt: Das BeagleBone Blue.

Das Board enthält unter anderem:
- WLan, Bluetooth
- 4 Motor Controller
- 4 Quadratur decoder
- 8 Servo Ausgänge
- 9dof IMU mit Barometer
- natürlich div. Interfaces wie I2C, SPI

Mehr:
http://hackaday.com/2016/01/11/introduc ... bone-blue/
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer

Benutzeravatar
H.A.R.R.Y.
Beiträge: 1083
Registriert: 01 Okt 2012, 08:38
Wohnort: Westpfalz

Re: BeagleBone Blue robotics controller

Beitrag von H.A.R.R.Y. » 13 Jan 2016, 09:03

Bei hackaday steht auch nicht viel. Kann das Ding die Motorströme messen? Bis wieviel Ampère Dauerlast sind die Motortreiber spezifiziert? Das wäre mal interessant, denn ft-Powermotoren sind hier ein Muß.

Und so wie es sich liest, ist Dank PRU-Programmierung in Assembler vielen Fans hier die Leistungsfähigkeit des Boards verschlossen.
[42] SURVIVE - or die trying

Benutzeravatar
Defiant
Beiträge: 354
Registriert: 31 Okt 2010, 21:42
Wohnort: Narn Homeworld
Kontaktdaten:

Re: BeagleBone Blue robotics controller

Beitrag von Defiant » 13 Jan 2016, 18:56

Ist auch erst die Ankündigung, das Board ist erst in ein paar Monaten zu kaufen. Geh mal davon aus, dass es nicht die schwächsten Motortreiber werden, ansonsten: Eigene Hardware lässt sich natürlich immer noch nachrüsten.

Man muss die PRU nicht verwenden, aber man kann, im übrigen dürfte der TXT auch eine PRU enthalten.
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer

bo911
Beiträge: 10
Registriert: 22 Feb 2016, 20:07

Re: BeagleBone Blue robotics controller

Beitrag von bo911 » 22 Feb 2016, 20:40

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 ... ;)

Benutzeravatar
H.A.R.R.Y.
Beiträge: 1083
Registriert: 01 Okt 2012, 08:38
Wohnort: Westpfalz

Re: BeagleBone Blue robotics controller

Beitrag von H.A.R.R.Y. » 23 Feb 2016, 10:41

Wie ist der Befehlsspeicher (Code) der PRUs angelegt? FLASH? Kann so ein PRU zur Laufzeit das Programm getauscht bekommen oder ist das fix?

Hättest Du mal die Typnummer vom BeagleBone-Blue ARM? Ich würde mir das bei Gelegeheit auch gerne mal in dessen TRM anschauen.

Grüße
H.A.R.R.Y.
[42] SURVIVE - or die trying

bo911
Beiträge: 10
Registriert: 22 Feb 2016, 20:07

Re: BeagleBone Blue robotics controller

Beitrag von bo911 » 23 Feb 2016, 14:08

Der Instruktions / Datenbereich (8k/8k), sowie der Shared Seicher (16k) befindet sich innerhalb der AM335x - SoC's
und wird via Kernel Modul (pruss_uio, ..) + Ti - Library (z.B pruss_lib) normalen Linux Programme zugänglich gemacht..
=> 1.) Man erzeugt PRU - bin - Code mittels pasm - Assembler, oder Ti-sdk C-Compiler und legt das Programm im Filesystem ab
2.) Typischerweise erzeugt man ein Linux Programm (z.B C/C++) welches im Startup via Library Calls ebene ein Programm
von 1.) in den PRU - Speicher lädt und ausführt.
3.) Das Programm wartet z.B auf einen PRU - Interrupt, sobald z.B neue I/O Daten PRU - seitig heran geholt wurden ...
4.) Das Programm wertet I/O Daten aus (Ptr, oder aber memcpy), und setzt die gewünschten Ausgänge (z.B SharedMemory Struktur)
5.) loop über 3 - 4 until Programm stop ...

Der eigentliche Austausch der I/O Daten reduziert sich z.b auf einen memcpy aus dem SharedMemory, so dass über die Komplexität
dieses Austauschbereiches eben auch höhere Funktionen realisierbar. In der realen Welt sind z.b die Hardware Quadratur-Encoder (3 - Stück)
extrem interessant, weil die SoC - Komponente als fertiger Hardware 32 - Bit Counter mit automatischer Richtungsdetektion auch von
den PRU's ausgewertet werden können, um z.B den Motorpositionswert zum Zeitpunkt einer steigenden/ fallender Flanke einer Lichtschranke zu
ermitteln (Basis für Positionskorrekturen) , also nicht nur das I/O Signal, sondern auch die Korrelation mit Bewegungsdaten ...
Die 32 Bit Counter werden hierbei in Hardware, also ohne polling oder CPU - Zyklen ermittelt ....(die SoC's können wirklich viel ...)

Grüße Bernd

Benutzeravatar
Defiant
Beiträge: 354
Registriert: 31 Okt 2010, 21:42
Wohnort: Narn Homeworld
Kontaktdaten:

Re: BeagleBone Blue robotics controller

Beitrag von Defiant » 23 Feb 2016, 19:21

Deswegen wäre der ft Erkundungsroboter (oder ähnliches) als Modell ohne TXT mit BBBlue (Odometrie/Geschwindigkeitsregelung über PRU) schon ein schönes Ziel. Oben drauf sitzt dann natürlich ein ROS.
bo911 hat geschrieben: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.
ok schade, noch ein Grund weniger den TXT zu kaufen.
H.A.R.R.Y. hat geschrieben: Hättest Du mal die Typnummer vom BeagleBone-Blue ARM? Ich würde mir das bei Gelegeheit auch gerne mal in dessen TRM anschauen.
Vom Blue existiert bisher nur ein Prototyp, die Schaltpläne sind noch nicht fertig (Stand: heute), aber aktueller Stand ist ein AM3358 wie im Black. (Produktion im Mai)
"Propaganda does not deceive people; it merely helps them to deceive themselves."
E Hoffer

Antworten