Hallo, nun ist der neue BeagleBone Black auf dem Markt und ich habe mir als Linux-Neueinsteiger ein solches Teil zur Einarbeitung in ARM/Linux und später mal zur Verwendung als seriell anzusteuerndes HDMI-Display Interface für meinen AVR-Fuhrpark zugelegt. Die Prozessorpins bzw. die Pins, die die Buchsenleisten P8 und P9 herausführen können mit mehreren Funktionen belegt werden. Von der mich interessierenden seriellen Schnittstelle ist per default (Angstrom-Distribution 2013-06-06) keine der nutzbaren vom Start weg aktiv. Um das zu erreichen ist bislang eine ganze Orgie von Instruktionen abzuarbeiten; mit dem neuen 3.8er Kernel und dem "Device Tree" Konzept hat sich auch einiges in Setup / Ansteuerung der nutzbaren Anschlusspins geändert. Da ich Sinn und Zweck dieser höchst umständlich und unnötig kompliziert erscheinenden Linux I/O Steuerung im Augenblick wenig durchschaue bleibt nur Googeln und das Zusammentragen vieler Informationshäppchen, um erstmal ein funktionierendes Prozedere zur Aktivierung zu erhalten (anbei in deutsch + die beiden Downloads dazu). Dreh-und Angelpunkt ist hier offensichtlich zum einen die Erstellung einer neuen (mit dem "Device Tree Compiler" dtc zu kompilierenden) am335x-boneblack.dtb in "/boot/" die der Kernel auswertet sowie dann ein Schnittstellenfile ttyO1 für UART1 in "/dev/" kreiert- und zum anderen ein ebenso zu erstellendes und in "/lib/firmware/" abzulegendes Pinmux-File welches schließlich zur Aktivierung des Pinmux-Setting in einem via Service gestartetem Skript dem Cape-Manager und seiner Slot-Verwaltung zugewiesen wird... :-( Möglicherweise und hoffentlich lässt sich dieses oder jenes noch verbessern, ich hoffe sehr auf kundige Rückmeldungen! Dem BBB-Einsteiger möchte ich für die Arbeit übers Netzwerk bzw. mit Windows unbedingt noch die beiden Tools PuTTY (Shell) und WinSCP (Dateiübertragung) ans Herz legen. Dennis
Gast
#3214902
> die erste (UART0=ttyO0) steht nicht frei zur Verfügung.
was tut die auf dem Beaglebonen denn standardmässig? Falls dort ein
login-prompt zu sehen ist, sollte man sie in /etc/inittab für andere
Zwecke freigeben können. Ansonsten kann man mit lsof herausfinden,
welcher Prozess sie verwendet.
ansel schrieb: >> die erste (UART0=ttyO0) steht nicht frei zur Verfügung. Ja tatsächlich, wenn auch nicht auf den beiden Cape-Erweiterungsheadern P8/9 so aber doch auf einem separaten Debug-Port ist UART0 nutzbar! ansel schrieb: > /etc/inittab ... findet sich nicht im Dateisystem.
Gast
#3228888
Dennis S. schrieb: > ein ebenso zu erstellendes und in "/lib/firmware/" abzulegendes > Pinmux-File welches schließlich zur Aktivierung des Pinmux-Setting in > einem via Service gestartetem Skript dem Cape-Manager und seiner > Slot-Verwaltung zugewiesen wird... :-( Ich sehe diese Herangehensweise als Versuch, den Erfolg der "denkfreien" Arduino-Libs und den dazugehörigen Shields auf eine höhere Ebene, - auf ARM/Linux(BBB) und den dazugehörigen Capes, zu portieren, ohne den Aufwand und somit die Kosten der Entwicklung ebendieser Lib's tragen zu wollen. Die "Strickweise" hast Du ja schon gut umrissen ... -- und nun macht mal!
Gast
#3230578
Im Prinzip langt doch eine einfache Textdatei, die Betriebsart bzw. Status jedes Pins für die Initialisierung festlegt. Aber das wär wohl zu einfach...
Gast
#3258570
Tja, für Linux-Freunde ist eben nur das eine elegante Lösung was auch hinreichend kompliziert ist :)
Gast
#3326773
War nun selbst in der Not, drei UARTs an meinem BBB verwenden zu müssen, und kann nun etwas qualifizierter auf die Ursprungsfrage antworten... Folgende Zeile in meiner /boot/uEnv.txt war hier die einzige notwendige Konfiguration, um angelötete rs232- und rs485-Transciever zum Leben zu erwecken, und dauerhaft via /dev/ttyOx zugänglich zu machen:
1 | |
(Das ganze geschah mit Debian wheezy, aber capemgr und u-boot sind ja auch bei Angström im Einsatz. Einziger Unterschied ist IIRC, dass die Partition mit der uEnv.txt bei letzterem irnkwo unter /media statt /boot gemountet ist.)
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.