Jump to content

borg

Administrators
  • Gesamte Inhalte

    3.525
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    43

Alle erstellten Inhalte von borg

  1. Öh, ihr müsst das "Minute" oben durch "Sekunde" ersetzen. 1000 Nachrichten/Minute wäre ein bisschen wenig .
  2. Wir haben eine einzelne PID zu der 16d0 VID gekauft (eine komplette VID war uns damals zu teuer). Ich nehme an das GrauTec das genauso gemacht hat und das sie die ersten waren die ihre PID zum Maintainer der usb.ids geschickt haben und deswegen als Hersteller da stehen. Edit: Nur einmal zu Erklärung: Von der USB IF ist es schon so gedacht das jeder Hersteller sich eine VID kaufen muss, allerdings gab es zu den Anfangszeiten im Lizenzvertrag keinerlei Anmerkungen dazu ob man PIDs seiner VID weiterverkaufen kann. D.h. wer eine alte VID hat darf einzelne PIDs verkaufen (z.B. hier: http://www.mcselec.com/index.php?page=shop.product_details&flypage=shop.flypage&product_id=92&option=com_phpshop&Itemid=1). Daher kommt das zustande. Soweit ich weiß sind wir aber kurz davor das die VIDs der USB IF aufgebraucht sind, dann müssen die sich eh was neues einfallen lassen und vermutlich selber einzelne PIDs verkaufen. Spätestens dann ist die Darstellung wie sie in der usb.ids gemacht wird hinfällig .
  3. Wenn du keinen Rechner laufen lassen willst musst du definitiv auf die WLAN Extension warten. Wir haben im Moment kein iOS Gerät hier, deswegen gibt es auch noch kein iOS Support . Soweit ich weiß sollte Objective-C abwärtskompatibel zu C99 sein, die C/C++ Bindings könnten also out of the box funktionieren. Ist aber ungetestet .
  4. Das ist die Spannung und der Strom, die durch den Stack gehen. D.h. die sollten immer 0 sein, es sein denn du nutzt die Step-Down Powersupply (d.h. du speist Spannung über den Stack ein). Damit ist es möglich festzustellen wieviel Strom ein ganzer Stack in Summe zieht oder wie voll eine Batterie ist (anhand des Spannungsabfalls), wenn die Step-Down Powerupply über eine Batterie gespeist wird.
  5. Ah, "Set" gefällt mir. Schreibe ich mir mal auf, ändere ich dann mal bei Gelegenheit.
  6. Oh, das "Save" an der Stelle bedeutet nichts permanentes. Was wäre da ein besserer Begriff? Grundsätzlich ist auf dem EEPROM noch genug Platz um solche Einstellungen zu speichern (wird z.B. beim Distance IR Bricklet mit den Stützpunkten gemacht oder beim Joystick Bricklet mit der Kalibrierung). Allerdings ist es tendenziell gefährlich bei so einem IO Bricklet mit einem anderen Zustand als Input oder Input Pullup zu starten. Ansonsten hat man schnell den alten Zustand von vor 2 Wochen vergessen und einen Kurzschluss gebaut!
  7. borg

    PWM mit IO16

    Das ist schwierig umzusetzen. Per USB kann ich mit maximal 1000 Nachrichten pro Sekunde rechnen und das System ist entsprechend darauf aufgebaut. Zum Beispiel ruft unser interner Scheduler pro Bricklet Plugin nur 1x pro ms eine Task auf, wir können also auch nur 1x pro ms eine Zustandsänderung haben. Auf den meisten Bricks sind für sowas auch keine PWM oder Timer Counter Hardware Einheiten mehr über. Du musst bedenken das so ein Master Brick ja auch noch mit x Stack Teilnehmern und x Extension Slave Teilnehmern gleichzeitig sprechen können muss. Und die Treiber Bricks (Servo/Stepper/DC). Müssen ihre jeweilige Motoren steuern und Beschleunigungen/Debeschleunigungen etc. Berechnen. Das tut brickd bereits.
  8. Neue Bindings würde ich jetzt auch einfach mal als neues "Produkt" bezeichnen. Hab das oben mal entsprechend geändert. Viel mehr Aufwand machen mehr Bricks/Bricklets allerdings nicht beim erstellen neuer Bindings, die werden ja soweit autogeneriert. Der Mehraufwand ist dann nur in den Beispielen, die kann man natürlich schlecht generieren.
  9. Der Name "GrauTec" stammt aus der usb.ids Datei vom Linux Kernel: http://www.linux-usb.org/usb.ids Das können wir so von außen erstmal nicht beeinflussen. Ich schreibe Stephen J. Gowdy diesbezüglich mal an, aber ich kann nichts versprechen.
  10. Die Prototypen werden von uns von Hand ausgeschnitten, von Hand mit Lötpaste versehen, in unserem kleinen Prototypen-Ofen gebacken und dann nachbearbeitet um Brücken zu entfernen. Der Prozess ist _viel_ zu Aufwendig um damit eine verkaufbare Stückzahl Prototypen herzustellen. Und eine kleine Anzahl Prototypen vom Bestücker fertig machen zu lassen wäre absurd teuer und auch sehr ärgerlich wenn dann noch ein Fehler auf der Schaltung ist.
  11. Das ist allerdings eine gute Idee, ich hab die maximalen Stimmen mal auf 3 gestellt. Aber ich befürchte wer schon abgestimmt hat darf nicht nochmal abstimmen .
  12. borg

    RS485 Modul

    Die ist definitiv schon längst überfällig, leider kommt immer wieder etwas anderes dazwischen. Die Software ist soweit fertig, es fehlt noch ein bisschen testen und ein bisschen Bugfixing. Es ist leider im Moment so das nach 30-120 Minuten laufen die Verbindung abbricht und ich konnte noch nicht herausfinden warum. Solche Fehler sind natürlich auch immer schwer ausfindig zu machen.
  13. VID_03EB und PID_6124 bedeutet er ist im Bootloader. Einmal ganz von vorne. Installiere sam-ba und entpacke die sam-ba files in den sam-ba ordner. Dann stecke den Brick an während du den Reset Taster drückst (damit stellen wir sich das er auch wirklich im Bootloader ist). Dann wählst du folgenden Treiber aus: SAM-BA-ORDNER\drv (nicht den Treiber der in brickd\drivers liegt!). Falls er nicht nach einem Treiber fragt einmal über die Treiber aktualisieren die Treiber per Hand auswählen. Dann sam-ba starten und die Prozedur so durchführen wie in der Doku beschrieben. Wenn der Brick sich wieder als Brick anmeldet, dann den Treiber in Tinkerforge\Brickd\drivers auswählen (wenn du das schon einmal getan hast macht er das automatisch)!
  14. So, hier mal eine Liste von möglichen neuen Produkten. Ich bin einmal diesen Thread durchgegangen: http://www.tinkerunity.org/forum/index.php/topic,24.0.html und hab noch alles dazu aufgeschrieben was von uns geplant ist. Die ersten 5 davon stehen schon ziemlich fest. Interessant für uns ist natürlich in welcher Reihenfolge wir diese nun machen sollen. Wir haben vor auf dauer alle 2 Wochen ein neues Feature/Produkt zu veröffentlichen (neues Brick/Bricklet, neue Extension, neue Bindings, On Device Programming Interface etc). Wobei wir bei Bricklets mit ca. 3 Monaten rechnen bis etwas vom Prototypen-Status in die Produktion gehen kann (1,5 Monate bis zum funktionierenden Prototyp und 1,5 Monate bis zur Produktion). D.h. wenn jetzt eine gute neue Idee kommt dauert es mindestens 3 Monate bis sie erwerblich ist. Um zu zeigen das nicht alles Vaporware ist bei uns, hier die bisherigen Prototypen die wir hier haben : http://i.imgur.com/xmSaQ.jpg V.l.n.r.: GPS Bricklet, Barometer/Altimeter Bricklet, Sonic Range Bricklet, neues Current Bricklet, Incremental Encoder Bricklet
  15. In das SAM-BA Verzeichnis müssen nicht die neuen Firmwares rein sondern die "SAM-BA Files": http://download.tinkerforge.com/tools/samba/samba_files_1_0_0.zip Dort drin ist ein Bootloader für die Bricks. Die Bricks haben einen unlöschbaren minimalen Bootloader drauf der lädt diesen Bootloader um dann die neue Firmware zu flashen . Also einfach die Dateien im SAM-BA Ordner entpacken und dann sollte eine passende Auswahl da sein.
  16. borg

    Chibi oder WLAN ?

    Auch eine Master Extension. Ja, ja und ja .
  17. Wir benutzen den KS0066U LCD Controller mit dem Standard English/Japanese Zeichensatz. Hier gibt es eine Tabelle mit dem Zeichensatz: http://www.display-elektronik.de/CHAR_KS0066-00(Engl-Japan).PDF 0b11011111 sieht aus wie ein °. Also in Python z.B. lcd.write_line(0, 0, chr(0b11011111)) (habs gerade getestet, es funktioniert so)
  18. borg

    Chibi oder WLAN ?

    Der Prototyp mit dem wir im Moment arbeiten basiert auf diesem Modul hier: http://www.rovingnetworks.com/products/RN_171 Also leider nur 2.4GHz.
  19. Das ist leider Protokollbedingt gar nicht so einfach umzusetzen. Wenn du ein Enumerate erzwingst wird eine broadcast Nachricht losgeschickt auf die alle Bricks/Bricklets antworten. D.h. der Master bekommt die Enumerate Nachricht, Antwortet darauf (mit seinem Namen, Version etc) und gibt die Nachricht dann weiter an alle seine Bricklets, Stack Teilnehmer und Extension Slaves. Die geben es entsprechend auch wieder weiter an alle Bricks/Brickelts die sie kennen. Das funktioniert so weit ganz gut und es ist auch garantiert das jedes Brick/Bricklet erreicht wird, allerdings weiß kein Teilnehmer des Systems wann die letzte Nachricht rausgeht! Der einzige der überhaupt weiß wieviele Teilnehmer es im System gibt ist brickd. Im hinblick auf die WLAN Extension füge ich dem allerdings nur ungerne mehr Intelligenz hinzu, weil das die Implementierung für die WLAN Extension später viel aufwendiger machen würde.
  20. borg

    DMX Control

    When the RS485 Extension is available you could write your own firmware (low-level C) that controls DMX devices. I don't know anything about the DMX protocol, but this would probably be quite a big task!
  21. Oh, das ist aber ein Bug in den Bindings. Wir müssen Strings an der Stelle in Python 3 einfach anders behandeln.
  22. Oh, mir war gar nicht aufgefallen dass das hier der gleiche Fehler ist wie der schon im englischen Forum aufgetreten war. Nach kurzem durchwühlen der GCC ARM inline Assembler Dokumentation bin ich mir nicht sicher ob der Fix von AreaScout funktioniert. Ich hab aber folgendes gefunden; Kann einer von euch ausprobieren ob der kram mit "=r" (result) funktioniert? Falls ja würde ich das einbauen, weil kaputt machen kann das an der Stelle definitiv nichts, höchstens langsamer.
  23. Ich bekomme den Fehler nicht, welche Compiler Version verwendet ihr denn?
  24. borg

    Stromaufnahme?

    Ich würde behaupten bis auf DC/Stepper/Servo Bricks kannst du alles in ein geschlossenes Gehäuse packen ohne das es zu heiß wird. Bei der CPU ist der Stromverbrauch extrem abhängig davon welche Hardwareeinheiten aktiviert sind, die Werte die wir angeben sind Durchschnittswerte.
×
×
  • Neu erstellen...