skippi

Siehe auch: 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.

Ich muss vor dem generate_makefile noch ein paar Pfade setzen: export CMAKE_C_COMPILER=/opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi-gcc export CMAKE_CXX_COMPILER=/opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/arm-none-eabi-g++ export PATH=/opt/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_EABI/bin/:${PATH} glaube aber nicht, das das HotPizzaBoxs Problem ist. Bei mir wird das bin beim ersten mal erzeugt und es gibt auch weder beim kompilieren noch nachträglich Fehlermeldungen. Vielleicht sind die Files beim download beschädigt worden. Hole doch das monierte pwmc nochmal. Sonst fällt mir nur noch eine neue Kompilerversion ein ? Meine ist: gcc version 4.6.1 (Sourcery CodeBench Lite 2011.09-69) Das Binary ist: 119996 2012-12-03 15:48 master-brick.bin

Äh ganz so ist es nicht. Ich steuere meine Verbraucher über Halbleiterrelais anstatt über das Dual-Relay Bricklet. Das hat den Vorteil, das man auch PWM's für Thermoantriebe oder Wellenpaketsteuerungen für Umwälzpumpen fahren kann. Da das IO4 leider etwas wenig Treiberleistung für viele der Optokoppler hat, habe ich ein IO16 eingesetzt und damit ein paar Reservekanäle. Damit könnte Mikrolinux vielleicht auch einen Autoreset erzeugen: Kostet aber noch einen Kanal: Ich glaube der Resetzustand ist ein Pullup (müsste zumindest Input sein damit es funktioniert). Man könnte eine IO-Line auf den Reset verdrahten und mittels Monoflop auslösen. Ein zweites Monoflop müsste vorher den Callback aufrufen, in dem man dann beide retriggert. Kommt der Callback nicht, löst das Monoflop den Reset aus. Allerdings: Da die Monoflops auch in Software realisiert sind würde ich für wirklich kritische Anwendungen lieber ein externes 2. Monoflop nehmen. Ich gebe NIC aber auch recht: ein 'Hartbeat'-Timer auf den Masterbricks würde für viele Anwendungsfälle ausreichen. Idealerweise würde man ihn aber gleich so bauen, dass er auch als Watchdog agieren kann und (zumindest) den lokalen Stack zurücksetzten kann.

Hm, bei mir hat es funktioniert. Hast Du Dir die bricklib und brickletlib auch aktuell aus dem git besorgt und entsprechend verlinkt und neu kompiliert ? Und auch die angeschlossenen Bricklets neu geflasht ?

Ich meinen Watchdog mit Hilfe eines Monoflops auf einem IO-Bricklet realisiert: Das Monoflop wird alle 2s ausgeführt. In dem Callback wird zum einen das Monoflop selbst und auf dem Host ein Alarm(10) nachgetriggert. Wenn der Callback nicht kommt schlägt das Alarmsignal zu und man kann den Stack resetten. Auf dem OpenWrt muss ich dann in der Regel noch den brickd abschiessen und vom init neustaerten lassen. Ich vermute mal das er den Reset durch das fehlende gudev nicht mitbekommt. In dieser Kombination läuft es bei mir aber inzwischen recht kontinuierlich. Codebeispiele könnte ich nur in C beisteuern, ich denke die Prinzipien sind aber bereits ausreichend beschrieben.

Ja, schau mal in den software/build Ordner. Dort findet sich das ...bin auch wenn es beim Kompiliervorgang nicht explizit erwähnt wird. (Zumindest bei mir)

Na da es kein configure gibt, musste ich die Umgebung für das Crosscompilieren mit einbauen. Auf dem Router kann ich nicht direkt kompilieren. Aber wenn die Firmware schon läuft versuche ich mal die Resevebrick zu flaschen und mit ihr zu 'sprechen'. Ich vermute das die letzte Mail so zu verstehen ist, das die Bindings noch kein 2.0 unterstützen ?! Update: Zumindest auf dem PC habe ich Brickd und Brickv laufen. Eine Masterbrick und 2 Temperatur Bricklets sind neu geflasht und ich kann sie mit 2.0 auslesen. Next step: Brickd aud den Router schieben ... Übrigens gehört mein feature-request eher in diesen thread: Könnte man die neuen Bindings so bauen, dass sie sich auch ohne den brickd über ein serielles RS485 Device - oder auch direkt über tcpip (wifi-, ethernet Extension) mit einem als entsprechender slave configuriertem Stack verbinden können ?

Also für den mips-basierten OpenWrt (TL-MR3420/3020) geht das kompilieren schon mal - mit etwas Modifikation des Makefiles. Beim Linker fehlt mir noch der Pfad zur libudev. Was würde denn schon funktionieren und welche Bricks/Bricklets können damit umgehen ?

Ich hätte noch einen 'Featurrequest' für den neuen brickd: Es wäre schön, wenn man alternativ zur USB-Kommunikation auch ein serielles Device (RS485) nutzen könnte. Also der brickd direkt als RS485 Master mit dem oder den Stacks kommuniziert.

Für ein Protokoll ohne speicherfressenden python Brickd gibts sofort meine volle Unterstützung. Ich hatte gerade angefangen den brickd gegen einen RS485 Konverter 'zu tauschen'. Schafft Ihr das bis Ende November? Dann lege ich die Alternative erstmal auf Eis.

Ok, ich muss ja nicht alle Gründe verstehen. Dann versuche ich mal eine Antwort zu einem anderen Punkt: Suche mal nach PC16550d, 16450 uä. Sind standard RS232 Buffer. Zum Pegelwandeln wirst Du ggf.noch einen MAX232 davor setzen müssen. Der 16550 hat einen 16 Byte FIFO, das müsste für Deine Anwendung mit dem IO16 ausreichen.

Da Du sowiso einen Steuerrechner mit USB benötigst, kannst Du doch einfach einen RS232-USB Adapter einsetzen. Gibt es <~ 10€. Wofür also ein Bricklet ?

Tja, ich hatte das Problem auch nicht gemeldet weil ich es nicht reproduzierbar Beschreiben konnte. Ich musste aber mindestens viermal eine Brick neu flashen. Es trifft auch nicht immer die Masterbrick. Ich habe noch eine Servobrick im Stack, die noch nicht ernsthaft im Einsatz ist, aber auch Bricklets bedient. Auch dort ist das Problem einmal aufgetreten. Man müsste mal durch die Resetroutine durchschauen. Gesucht ist ein Stück Code das ggf. auf ein Ereignis wartet das nicht Eintritt wenn ein Bricklet angeschlossen ist das im falschen Zustand ist. Dies muss vor dem "Blinkenlights" sein, denn das machen die Bricks beim Reset dann nicht mehr. Dieser Deadlock wird durch das 'flashen' anscheinend beseitigt. Mir fällt in diesem Zusammenhang gerade ein: Wird beim Reset nicht Code aus den Bricklets übernommen ? Gibt es da eine Umschaltung Code / Betrieb ? Allerdings mussten die Bricklets bei mit nicht beim Flashen angeschlossen sein. Der 'Schalter' muss auf der Brick selbst liegen. Falls ich noch etwas herausfinde lege ich es hier ab.

Hi, ich gebe hier auch mal meine Erfahrungen dazu. Aus meiner Sicht scheint es einen Zustand bei Fehlern in der Stackkommunikation zu geben, der zum gemeldeten Fehlerbild (Stack hängt bis zum Abklemmen eines bestimmen Bricklets) führt. Reparatur ist nur(?) durch Neuflaschen der Firmware der Brick möglich. Ich hatte das Problem bis vor kurzem massiv. Die Umgebung ist dabei ein Brickdaemon der auf einem OpenWrt Router läuft. Anscheinend verkraftet der Brickd schlecht Memoryprobleme. Es gibt zwar keine Fehlermeldungen, aber irgendwann hängt sich der Stack (oder Teile davon) einfach weg. Ich hatte zunächst versucht ihn dann via Reset-Kommando wiederzubeleben. Hat auch manchmal funktioniert. Nicht selten war der Stack aber nicht wiederzubeleben und hing mit o.a. Fehlerbild. Seit ich den Speicher häufig aufräume (OpenWrt schreibt halt Logfiles normalerweise ins RAM) läuft der Stack seit etwa einer Woche stabil durch. Zum Nachstellen des Fehlerbildes empfehle ich also mal Kommunikationsfehler zu provozieren (z.B. durch usb resets o.ä)

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.

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 ?

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.

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.

pyusb - 0.4.2-1 Leider war es das nicht. Fehlermeldung wie vor.

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

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.