borg

Ich sitze gerade an der Implementierung für die RS485 Extension und mir ist gerade aufgefallen das ich gelogen hab als ich gesagt hab die RS485 Extension spricht full duplex. Wir haben alle Pinne die für full duplex benötigt werden würden im Stack liegen, allerdings spricht der RS485 transceiver den wir benutzen nur half duplex (es gehen ja auch nur 3 Kabel raus). Da hatte ich damals nicht richtig drüber nachgedacht.

Das ist wirklich seltsam, wir haben den Brick Viewer eigentlich auf neuinstallierten Windowsen getestet. Mal schauen ob wir das Problem reproduzieren können, sollte aber einfach fixbar sein.

Den Fehler hatten wir noch nicht und ihn hat auch bisher noch keiner berichtet. Kannst du mal versuchen entweder dies (32 bit) oder dies (64 bit) zu installieren? Es wird ein Fehlerlog im Installationsverzeichnis angelegt. Allerdings sieht mir das so aus als würde es schon zu einem Fehler kommen bevor unser eigentliches Programm gestartet wird.

Wir werden dort das gleiche Protokoll sprechen was wir auch im SPI Bus und über Chibi sprechen. Dies ist aber ein einfaches Protokoll und kann auch direkt gesprochen werden, das müssten wir dann nur dokumentieren. Im großen und ganzen wird immer [stack ID, Funktions-Nummer, Länge, Nutzdaten, CRC] übertragen.

RS485 kommt direkt nach der Chibi Extension und dem IMU Brick. Der Bus ist full duplex. Da die Infrastruktur für die Extensions jetzt steht hab ich Hoffnung das ich da schneller voran komme.

Interesting. Can you try to install python-ctypes? opkg install python-ctypes

you need python-twisted for the Brick Daemon, this is independent from the programming language you want to use. You can install the Brick Daemon from source (here is a lik to the zip: https://github.com/Tinkerforge/brickd/zipball/master) Just unzip it somewhere on your beaglebone, go to brickd/src/brickd and start with "python brickd_linux.py nodaemon" as root. As i mentioned before, you can also enable debug output if you install it from source and give me more information this way.

So, ich hab mal einen kleinen Aufsatz im Wiki verfasst. Ich hoffe das ist nicht zu grob und du kannst damit was anfangen. Du wirst allerdings definitiv nicht drum rumkommen dich in die vorhandenen Bindings einzulesen um eine Idee darüber zu bekommen wie diese funktionieren. Ich würde erstmal die Autogenerierung außen vor lassen und überhaupt erstmal eine Socket Verbindung mit Delphi zum brickd aufbauen und versuchen ein Paar Nachrichten auszutauschen. edit: Hab den Link zum Wiki vergessen: http://www.tinkerunity.org/wiki/index.php/BindingsErstellen

Oh, hab deine Antwort übersehen, entschuldige. Ich setze heute Abend mal ein Tutorial darüber auf, melde mich dann.

With the hotplug functionality brickd can find newly plugged in Bricks. If you plug in your Bricks first and start brickd afterwards, it will work without gudev (at least it should).

Hi guys, just some general ideas i have on this topic: - In principle there is no problem to get our stuff running on arm based embedded devices, in the German forum someone got brickd running on his NSLU (http://en.wikipedia.org/wiki/NSLU2, 133Mhz, 8MB flash). So, all the Beagleboard derivatives and the RPi should definitely work. - Debian on Beaglebone: Coldwilson: Did you not manage to install Debian at all or could you install Debian and our stuff didn't work? Because if you can install Debian it really should work out of the box, since we don't use any platform dependent stuff and Debian has all dependencies (python-twisted, python-gudev and libusb). - Angstrom: I am no Angstrom expert, but i could find libusb, python-twisted and gudev in the repository. I could not find the python bindings for gudev, can you try to install them from source: https://github.com/nzjrs/python-gudev? As far as i can see, it consists of only one c file. - gudev: It is possible to use brickd without gudev! gudev is only needed for the hotplug functionallity. So, if you plug in the Bricks and start brickd afterwards it should work. - Coldwilson: If you have libusb and python-twisted installed on your Beaglebone, could you install the brickd source, change the logging level to logging.DEBUG in brickd/src/brickd/config.py then plug in a Brick, then start the daemon with "python brickd_linux.py nodaemon" as root and post the output of the daemon here? It should say something like "Could not import gudev. Disabling USB hotplug" but work fine otherwise afterwards (if you plugged in the USB devices before you started brickd). If it doesn't work that way i would be interested in the error messages, perhaps it is something i can fix. I have lots of open source arm devices laying around here (beagle boards, openmoko etc, i have no beaglebone, but i intend to buy RPis). But currently i don't have Angstrom on any of them, so unfortunately i can't test it myself right now.

Die Konfigurationen bleiben persistent.

In der Tat, hab ich vergessen anzupassen. Hab die firmwares im Download Bereich entsprechend upgedatet.

Die Bindings generieren wir mit einem Pythin Skript. Die ganzen Generatoren findest du im generators git: https://github.com/Tinkerforge/generators Der Generator für die Bindings sieht so aus: https://github.com/Tinkerforge/generators/blob/master/csharp/generate_csharp_bindings.py Der Generator für die Dokumentation sieht so aus: https://github.com/Tinkerforge/generators/blob/master/csharp/generate_csharp_doc.py Die sind beide für C#, nur so als Beispiel. D.h. wenn du eine Unterstützung für Delphi hinzufügen wolltest, müsstest du mindestens den Generator für die Bindings für Delphi schreiben. Gucks dir mal an, wenn du da Lust zu hast würde ich nochmal genau aufschreiben wie du da am Besten vorgehst und was genau zu tun ist etc.

Ist leider nicht möglich. Der Treiber IC den wir dafür verwenden ist der DRV8811. Wenn du ganz genau wissen möchtest was theoretisch möglich ist kannst du da ins Datenblatt gucken.

Die Board-to-Board Verbinder sind leider keine Standardteile, da haben wir nichts gefunden was gepasst hätte (Pinanzahl und Höhe etc). Wie oben schon geschrieben werden wir aber welche bei uns in den Shop stellen sobald die nächste Bestückung fertig ist. Wenn benötigt können wir auch ganze Reels verkaufen.

Currently you need a permanent PC connection, as Paul said. It is possible to write C code, but there is currently no documentation for this.

Hab das Gerät hier und jetzt mal kurz getestet. Ich kriege das Olidata ding auf Anhieb nicht zum laufen (so rein gar nicht, auch nicht mit anderen Geräten, weder unter Linux noch unter Windows). Hab gerade keine Zeit mich damit Stunden zu beschäftigen, ich gucke es mir nächstes Wochenende noch mal an.

That is right. I wouldn't preclude that we ever make a "Linux Brick", but that won't happen any time soon. All Bricks have a processor speed of 64Mhz and the master has 256kb flash, that is definitely enough to program a robot. However, there is currently no documentation from us to do this. You will need to read the datasheets of the ICs we use etc. If you never did embedded C programming, this might be quite a challange (but its fun! If you want to learn embedded stuff, do it). A Beagleboard or Raspberry Pi on your robot that has Bricks/Bricklets connected over USB seems to be the easiest solution currently. Of course that will also give you lots of processing power. An adapter between an embedded Linux board and Bricks, that allows to directly control Bricks/Bricklets without USB is planned, but the software effort necessary to implement this is not trivial. The complete stack communication of the Master Brick needs to be implemented in the Linux kernel for this.

Den Akkuladezustand kannst du denke ich am besten anhand der Spannung feststellen (die fällt ab wenn der Akku leer wird). Die Spannung die am schwarzen Stecker auf dem Stepper Brick eingespeist wird kannst du mit get_external_input_voltage abfragen (oder get_stack_input_voltage, falls du durch einen Stack einspeist). Du kannst auch mit set_minimum_voltage eine minimale Spannung für dein Akku hinterlegen und bekommst dann ein UnderVoltage Signal, sobald die Spannung zu weit abfällt.

Zu den Bricklet Steckern hatte ich auch im englischen Forum schon was geschrieben: http://www.tinkerunity.org/forum/index.php/topic,90.0.html Die Stecker sind kompatible zu JST SH: SM10B-SRSS-TB (Auf der Platine) SHR-10V-S-B (Zum reinstecken)

Da die Frage danach schon öfter gekommen ist, denke ich wir werden alle Bauteile die keine Standardbauteile sind auch bei uns in den Shop stellen. Das wird allerdings erst nach der neuen Produktion passieren, wenn wir die übriggebliebenen Bauteile wieder haben. Wir haben im Moment keine nicht verlöteten Board-to-Board Stecker hier :-).

Puh, das haben wir wie gesagt noch nie getestet. Ich kann da im Moment nichts zu sagen. Ich nehme an du hast sowas hier gekauft: http://www.amazon.de/Olidata-Wireless-USB-Set/dp/B002BX3LRI/ref=sr_1_1?ie=UTF8&qid=1326324313&sr=8-1 ? Ich bestell das mal und probier es mal selber aus. Da WUSB noch vergleichsweise neu ist könnte ich mir vorstellen das sie die USB Geräteklasse die wir verwenden noch nicht komplett unterstützten (Im Gegensatz zu Eingabegeräten, Massenspeicher etc).

Das stimmt natürlich, sollten wir vermutlich auf dauer machen. Du kannst dich aber auch jetzt schon im download Bereich durchnavigieren und gucken was die letzte Version ist: http://download.tinkerforge.com/firmwares/

Das ist möglich, wird es direkt von uns allerdings in den nächsten Monaten nicht geben. Eher würden wir versuchen ein vorhandenes Linux embedded Board (wie Raspberry Pi: http://www.raspberrypi.org/) direkt zu unterstützten. So dass man per Adapter den Raspberry Pi als Master nutzen kann und andere Bricks draufstecken kann.