Brick Daemon für openwrt

huhu liebe leute,

wollte fragen, ob jemand weis, ob der daemon auch ohne weiteres mit openwrt läuft. es gibt dort python-twisted und libusb, aber kein python-gudev.

hat es schonmal jemand versucht?

viele grüße

die wurst

python-gudev wird nur für hotplug benötigt. D.h. wenn brickd gestartet wird nachdem die Bricks angeschlossen wurden funktionieren diese auch ohne python-gudev.

Hier hat jemand brickd auf einem Router zum laufen gebracht (NSLU): http://www.tinkerunity.org/forum/index.php?topic=52.0

huhu,

ich hab das ganze mal auf einem mr3020 mit openwrt r31288 getestet.

problem ist hierbei, dass libusb nicht gefunden wird:

root@OpenWrt:~/Tinkerforge-brickd-3313060/src/brickd# python brickd_linux.py 
Traceback (most recent call last):
  File "brickd_linux.py", line 30, in <module>
    from usb_notifier import USBNotifier
  File "/root/Tinkerforge-brickd-3313060/src/brickd/usb_notifier.py", line 25, in <module>
    from libusb import usb1
  File "/root/Tinkerforge-brickd-3313060/src/brickd/libusb/usb1.py", line 52, in <module>
    import libusb1
  File "/root/Tinkerforge-brickd-3313060/src/brickd/libusb/libusb1.py", line 118, in <module>
    libusb = _loadLibrary()
  File "/root/Tinkerforge-brickd-3313060/src/brickd/libusb/libusb1.py", line 111, in _loadLibrary
    raise Exception('Can\'t locate usb-1.0 library')
Exception: Can't locate usb-1.0 library

libusb ist aber installiert:

root@OpenWrt:/# find -name libusb*
./usr/lib/libusbpp-0.1.so.4
./usr/lib/libusbip.so.0
./usr/lib/libusbpp.so
./usr/lib/libusb-1.0.so.0.0.0
./usr/lib/libusb-1.0.so
./usr/lib/libusb-0.1.so.4.4.4
./usr/lib/libusbip.so.0.0.1
./usr/lib/libusb-0.1.so.4
./usr/lib/libusb-1.0.so.0
./usr/lib/libusbpp-0.1.so.4.4.4
./usr/lib/libusb.so

wenn man also in der libusb1.py zeile 94 aus

libusb_path = find_library('usb-1.0')

ein

libusb_path = '/usr/lib/libusb-1.0.so'

macht, startet brickd.

ich hab leider keine ahnung von python, aber vllt hilft euch das beim fixen.

platform.system() gibt hier ein 'Linux' aus.

grüße

die wurst

Eigentlich sollte die Library so gefunden werden - ohne das der Path mit angegeben wird. Kann es sein das ldconfig nicht gelaufen ist ?

Auf meiner NSLU sieht das so aus:

ldconfig -p | grep -i usb

libusb-1.0.so.0 (libc6) => /lib/libusb-1.0.so.0

libusb-1.0.so.0 (libc6) => /usr/lib/libusb-1.0.so.0

libusb-0.1.so.4 (libc6) => /lib/libusb-0.1.so.4

libusb-0.1.so.4 (libc6) => /usr/lib/libusb-0.1.so.4

Das Programm zieht sich dann die

lsof | grep -i libusb

python    13649        root  mem      REG        8,2    43460    645679 /lib/libusb-1.0.so.0.0.0

Ich habe allerdings mit dem openwrt keine Erfahrung.

Gruß

Nifty

öhm, wie lasse ich denn ldconfig "laufen" ?

nachdem ich ldconfig gerade installiert hab gibt er mir folgendes aus:

root@OpenWrt:~# ldconfig -p | grep usb
        libusbpp.so (libc0) => /usr/lib/libusbpp.so
        libusbpp-0.1.so.4 (libc0) => /usr/lib/libusbpp-0.1.so.4
        libusbip.so.0 (libc0) => /usr/lib/libusbip.so.0
        libusb.so (libc0) => /usr/lib/libusb.so
        libusb-1.0.so.0 (libc0) => /usr/lib/libusb-1.0.so.0
        libusb-1.0.so (libc0) => /usr/lib/libusb-1.0.so
        libusb-0.1.so.4 (libc0) => /usr/lib/libusb-0.1.so.4

lsof | grep -i libusb sagt nichts.

grüße

die wurst

einfach ldconfig ohne parameter aufrufen.

libusb ist bei Dir aber schon bekannt - das zeigt deine ldconfig Ausgabe an. Soweit also eigentlich ok.

Laut der Python Dokumentation ist der find_library Aufruf in den ursprünglichen Sourcen richtig, die Lib sollte automatisch mithilfe von ldconfig  gefunden werden.

http://docs.python.org/release/2.5.2/lib/ctypes-finding-shared-libraries.html

Vielleicht schaust Du mal bei Openwrt ob es da noch Infos über Bugs/Workarounds hierzu gibt.

scheint ein fehler in ctypes.util.find_library() zu sein. hab das ganze jetzt so gelöst:

--- src/brickd/libusb/libusb1.py	2012-04-15 05:28:42.000000000 +0200
+++ src/brickd/libusb/libusb1.py	2012-04-18 11:00:42.660701791 +0200
@@ -98,6 +98,10 @@ def _loadLibrary():
             elif system == 'Darwin':
                 libusb_name = 'usb-1.0'
                 libusb_path = find_library(libusb_name)
+            if os.uname()[4] == 'mips':
+                libusb_path = '/usr/lib/libusb-1.0.so'
+                if not os.path.isfile(libusb_path):   
+                    libusb_path = None
             if libusb_path is None:
                 # macport standard library path
                 libusb_path = '/opt/local/lib/libusb-1.0.dylib'

alles in allem kann ich, nun da auch die hardware da ist, sagen, dass es mit openwrt super läuft!!

hier noch ein schönes bild dazu.

wenn das wiki steht, kann ich gerne ein tutorial schreiben.

Hm, gibts da noch einen Trick ?

bei mir (auch openwrt ml3020) :

brick_protocol.py, line 24, in <module>

  from twisted.internet.protocol import Factory, Protocol

File "/usr/lib/python2.7/site-packages/twisted/__init__.py", line 22, in \ <module>

  raise ImportError("you need zope.interface installed "

Das ist aber installiert.

poste mal dein "opkg list-installed"

sorry ist etwas länger:

root@OpenWrt:~# opkg list-installed

base-files - 104-r30919

base-files-network - 4

blkid - 1.42-1

block-mount - 0.2.0-8

busybox - 1.19.3-10

bzip2 - 1.0.6-1

coreutils - 8.8-1

coreutils-stty - 8.8-1

crda - 1.1.1-1

dnsmasq - 2.59-2

dropbear - 2011.54-2

e2fsprogs - 1.42-1

firewall - 2-47

hotplug2 - 1.0-beta-4

iptables - 1.4.10-4

iw - 3.3-1

kernel - 3.2.9-1-7ca3c65ac3709dabad42d460596851da

kmod-ath - 3.2.9+2012-02-27-1

kmod-ath9k - 3.2.9+2012-02-27-1

kmod-ath9k-common - 3.2.9+2012-02-27-1

kmod-cfg80211 - 3.2.9+2012-02-27-1

kmod-crypto-aes - 3.2.9-1

kmod-crypto-arc4 - 3.2.9-1

kmod-crypto-core - 3.2.9-1

kmod-crypto-des - 3.2.9-1

kmod-crypto-ecb - 3.2.9-1

kmod-crypto-hash - 3.2.9-1

kmod-crypto-hmac - 3.2.9-1

kmod-crypto-manager - 3.2.9-1

kmod-crypto-md4 - 3.2.9-1

kmod-crypto-md5 - 3.2.9-1

kmod-fs-autofs4 - 3.2.9-1

kmod-fs-cifs - 3.2.9-1

kmod-fs-ext4 - 3.2.9-1

kmod-gpio-button-hotplug - 3.2.9-1

kmod-ipt-conntrack - 3.2.9-1

kmod-ipt-core - 3.2.9-1

kmod-ipt-nat - 3.2.9-1

kmod-ipt-nathelper - 3.2.9-1

kmod-leds-gpio - 3.2.9-1

kmod-ledtrig-usbdev - 3.2.9-1

kmod-lib-crc-ccitt - 3.2.9-1

kmod-lib-crc16 - 3.2.9-1

kmod-mac80211 - 3.2.9+2012-02-27-1

kmod-nls-base - 3.2.9-1

kmod-ppp - 3.2.9-1

kmod-pppoe - 3.2.9-1

kmod-scsi-core - 3.2.9-1

kmod-usb-core - 3.2.9-1

kmod-usb-ohci - 3.2.9-1

kmod-usb-printer - 3.2.9-1

kmod-usb-serial - 3.2.9-1

kmod-usb-serial-cp210x - 3.2.9-1

kmod-usb-serial-ftdi - 3.2.9-1

kmod-usb-serial-pl2303 - 3.2.9-1

kmod-usb-storage - 3.2.9-1

kmod-usb2 - 3.2.9-1

kmod-wdt-ath79 - 3.2.9-1

ldconfig - 0.9.33-106

libblkid - 1.42-1

libbz2 - 1.0.6-1

libc - 0.9.33-104

libcom_err - 1.42-1

libext2fs - 1.42-1

libffi - 3.0.10-1

libgcc - 4.6-linaro-104

libip4tc - 1.4.10-4

libnl-tiny - 0.1-2

libpthread - 0.9.33-104

librt - 0.9.33-104

libuci - 2012-02-24.1-1

libusb - 0.1.12-2

libusb-1.0 - 1.0.8-1

libuuid - 1.42-1

libxtables - 1.4.10-4

mtd - 17

netcat - 0.7.1-2

opkg - 618-2

ppp - 2.4.5-4

ppp-mod-pppoe - 2.4.5-4

python - 2.7.3rc2-2

python-mini - 2.7.3rc2-2

setserial - 2.17-2

swap-utils - 2.13.0.1-4

swconfig - 10

twisted - 2.5.0-1

uboot-envtools - 2011.06-4

uci - 2012-02-24.1-1

unzip - 5.52-1

usbutils - 004-1

wireless-tools - 29-4

wpad-mini - 20111103-3

zlib - 1.2.5-1

zope-interface - 2.5.0-1

ich habe noch pyusb installiert. probier das mal

pyusb - 0.4.2-1

Leider war es das nicht.

Fehlermeldung wie vor.

Scheint am zope package zu liegen.

Ich habe mal ein aktuelles besorgt und das zope Verzeichnis im python site-packages ersetzt und siehe da :

Mem: 24800K used, 4576K free, 0K shrd, 1252K buff, 4460K cached

CPU:  0% usr  0% sys  0% nic  98% idle  0% io  0% irq  0% sirq

Load average: 0.07 0.06 0.07 2/47 1646

  PID  PPID USER    STAT  VSZ %VSZ %CPU COMMAND

1636  1588 root    S    9468  32%  2% python example_callback.py

1645  1640 root    R    1496  5%  0% top

1606    1 root    S    14200  48%  0% python brickd_linux.py

1588  1587 root    S    1508  5%  0% -ash

Der python Speicherverbrauch ist allerdings gefährlich hoch.

Mal sehen ob das für einen NMEA Compass mit der IMU-Brick noch reicht.

hast du dir den openwrt trunk selbst kompiliert oder einen fertigen snapshot genommen? mit dem selbstgebauten trunk sollte es auf anhieb funktionieren

Ja, dann geht es auch mit dem "mitgelieferten" zope-interface.

Allerdings gibt es weitere Merkwürdigkeiten:

Ich wollte die c-bindings nutzen um wenigstens den Speicherbedarf meines Programms zu verkleinern. Bad Message: Es funktioniert auf dem Router nicht.

Dasselbe C-Programm läuft problemlos auf einem anderen Host und kommuniziert auch artig mit dem 3020 (bzw. in diesem Fall 3420) aber wenn ich das für den Router compiliere und dort starte kommt zwar noch eine Verbindung mit dem brickd zustande, es bekommt aber keinerlei Bricks und Bricklets zu sehen.

Sprich cb_enumerate wird nicht getriggert und direkter add_device funzt auch nicht.

Bei einem python codiertem Job klappt alles.

Ich befürchte die C Bindings achten nicht auf Endianness und die WRT haben einen Prozessor mit MIPS Architektur (Big Endian). Die Mikrocontroller auf den Bricks erwarten Little Endian.

Das steht schon seit langer Zeit auf meiner TODO Liste, sollten wir wirklich fixen.

Hier C/C++ Bindings die jetzt Big Endian richtig behandeln sollten.

tinkerforge_c_bindings_1_0_16_endian.zip

Hm schnelle Reaktion, aber der Effekt bleibt leider aus. Sprich keine Veränderung im Verhalten. (PC läuft Router kein enumerate)

Müsste es in ip_connection.c Zeile 501 dann nicht:

void ipcon_enumerate(IPConnection *ipcon, enumerate_callback_func_t callback) {

ipcon->enumerate_callback = callback;

Enumerate e = {

BROADCAST_ADDRESS,

FUNCTION_ENUMERATE,

ipcon_leconvert_uint16_from(sizeof(Enumerate))

};

heissen ?

Jop, definitiv. Wir hatten keine Big Endian Maschine zur Hand und das entsprechend nicht getestet. Ich denke wir werden das auf einem MIPS Board o.ä. testen müssen. Wenn du es zum laufen kriegst würden wir uns natürlich über einen Patch freuen!

Das kommt davon wenn man's nicht testet

Ich hatte einige Stellen übersehen. Hier jetzt Version 2, da sollte ich jetzt alles erwischt haben.

tinkerforge_c_bindings_1_0_16_endian_2.zip

Supi jetzt läuft es und spart auch 4MB - was bei 28MB schon hilft.

Gut das Ihr schneller wart, ich hatte "from/to" ja erstmal falsch herum interpretiert.

So, die Änderungen sind jetzt auch in C/C++ Bindings 1.0.17.

Siehe auch:

Benützung der Bricks ohne Brickd

Ich führe die Erfahrungen mit dem brickd 2.0 auf OpenWrt mal hier weiter.

Habe ihn gerade kompiliert und gelinkt bekommen und siehe da er läuft auch.

brickv von einem anderen Rechner findet auch den Stack und kann die Temperaturbricklets auslesen.

Eines meiner Probleme hat sich bisher nicht verbessert, wenn der Stack einen Reset macht, muss der brickd gestoppt und neu gestartet werden um die Kommunikation wieder aufzubauen. (Muss ich wohl doch über ein hotplug2 Skript lösen)

Dafür belegt er aber nur noch 5% statt 50% des verfügbaren Speichers.

Na dann schaunen wir mal, ob wir die Bindings ans Spielen bekommen.