Jump to content

borg

Administrators
  • Gesamte Inhalte

    3.592
  • Benutzer seit

  • Letzter Besuch

  • Tagessiege

    58

Alle erstellten Inhalte von borg

  1. Firmwares: Master Brick 1.2.4 Send empty message if slave has timeout, to allow slave to process buffer Download Firmwares: Master Brick
  2. Firmwares: Master Brick 1.2.4 Sende leere Nachricht falls RS485 Slave einen timeout hat, dadurch kann ein voller Buffer beim Slave abgearbeitet werden Download Firmwares: Master Brick
  3. Das IMU Plugin vom Brick Viewer benutzt OpenGL, das ist der einzige Unterschied der mir zu anderen Bricks/Bricklets einfällt.
  4. Ui, es gibt schon den ersten Pull Request mit Übersetzungen: https://github.com/Tinkerforge/generators/pull/16 . Was meint ihr wie wir unterschiedliche Sprachen in der Dokumentation behandeln sollen? Ich hab im Pull Request etwas dazu geschrieben.
  5. borg

    News zu TF

    @ArcaneDraconum: Da geben wir dir absolut recht! Ein gutes Gehäuse würde vermutlich auch einige der ESD Probleme lösen die hier ein paar Leute haben. Auf Dauer müssen Gehäuse her. Die Frage ist was so ein Gehäuse kosten darf und auch ob der Formfaktor den wir gewählt haben da überhaupt für geeignet ist... Wir haben gerade ein Projekt für einen Industriekunden fertiggestellt, welches in einem hübschen Hutschienengehäuse verbaut wird. Leider scheinen mir die Stackbarkeit und die Bricklet Ports nur schwer mit den Standard Hutschienengehäusen vereinbar zu sein .
  6. @chariowalda: Der OMAP3730 Ist ja erstmal nur ein Prozessor. Das von mir verlinkte Breakout Board hat aber schon die ganze externe Beschaltung usw drauf. Ein kleiner Fehler bei der Beschaltung und so eine CPU im Ghz Bereich strahlt wie ein Weltmeister . Die externe Beschaltung für den OMAP3730 könnten wir uns zwar vom Beagleboard-xM abgucken, aber leider hat TI da kein Interesse dran. Wir haben schonmal mit TI darüber gesprochen (bzgl des OMAP3530). Für die ist eine Abnahmemenge von 1000 Stück uninteressant. Für uns wäre das aber schon das absolute Maximum... So ein Breakoutboard was zwischen unsere Board-to-Board Stecker passt und von einer Drittfirma kommt die davon wiederum große Stückzahlen macht wäre für uns absolut perfekt!
  7. Eine kurze Googlesuche hat mir das hier rausgeworfen: http://www.co2meter.com/products/k-30-co2-sensor-module Das sollte man an ein Analog In Bricklet anschließen können.
  8. Also du möchtest etwas haben über das du mit einem Arduino kommunizieren kannst? Oder möchtest du direkt I2C Sensoren ansteuern, z.B. über das Breakout Bricklet? Über ein Arduino mit einem I2C Sensor zu kommunizieren ist ein bisschen von hinten durch die Brust ins Auge . Die Bricks haben mehr Rechenleistung, mehr RAM, mehr Flash als die meisten Arduinos. Was fehlt ist das "On Device Programming Interface". Unser inoffizieller Schlachtplan dafür ist folgender: Warten bis das Arduino Due raus ist: http://www.heise.de/hardware-hacks/meldung/Neue-Arduino-Mikrocontroller-Boards-1346308.html Arduino API für den Cortex M3 für unsere Bricks kompatibel machen und unseren Code mit der API neuschreiben API (basierend auf der Arduino API) für die Funktionalität der Bricks/Brickelts bereitstellen Damit erfinden wir zum einen das Rad nicht neu (Die Arduino Jungs sind ja ganz offensichtlich sehr gut daran einfach zu bedienende API zu machen und sie sind gerade dabei es für unsere CPU zu machen). Und zum anderen können die ganzen Arduino Beispiele dann auch auf unseren Bricks ausgeführt werden. Falls es darum geht I2C Sensoren direkt vom PC aus anzusteuern: Für bestimmte Kategorien von I2C Sensoren ist das sicherlich möglich, so ganz Allgemein ist wäre das allerdings sehr schwierig. Dafür ist USB leider einfach nicht gut geeignet .
  9. Alle Versuche von uns den CGRAM anzusteuern sind bisher gescheitert . Da ist irgendwo der Wurm drin. Ich schreibe es aber nochmal auf die TODO Liste. Aber das sind nur 8 selber definierbare Buchstaben, kein ganzer Zeichensatz!
  10. @sump: Wenn du keine Servos dran hast stürzt das Display nicht ab?
  11. Das ist absolut komisch. Die Änderungen zwischen Master Brick Version 1.2.2 und 1.2.3 sollten vollkommen irrelevant sein für die Ansteuerung der Bricklets. Ich bin aber gerade dabei noch ein paar Änderungen an der Master Brick Firmware vorzunehmen um es robuster für RS485 zu machen. Mal schauen ob das vielleicht auch bei dieser Geschichte hier hilft .
  12. Ups, ich hab die letzter Version im Downloadbereich einfach einmal dreisterweise überschrieben. Es sollte jetzt 1.1.8 angezeigt werden .
  13. Mh, gucke ich mir an .
  14. Dann werden wir das erstmal so Dokumentieren denke ich und in Zukunft vermutlich die 80€/Jahr "Applesteuer" zahlen...
  15. Mhh, nicht wirklich. Ich bin ein wenig ratlos. Hat irgendwer eine Idee?
  16. Hab jetzt hier einen großen Aufbau: 3x RS485, 12 Bricklets, 3 Master, 3 weitere Bricks. Ich hab es einmal geschafft einen der Stacks zum absturz zu bringen, er konnte dann erst wieder nach einem neustart gefunden werden! Mal schauen ob ich es hinkriege ein Programm zu schreiben welches den Absturz triggern kann. Melde mich wieder wenn ich Neuigkeiten hab!
  17. Die IO4 ist dafür leider nicht geeignet, der Sensor zieht zuviel Strom. Desweiteren wäre die Auflösung nicht so pralle. Der Puls dauert maximal 18ms wenn ich das richtig sehe, d.h. es wäre nur eine Auflösung von 18 Schritten möglich.
  18. Das Thema haben wir hier schon: http://www.tinkerunity.org/forum/index.php/topic,736.0.html Es funktioniert wenn du dir das .dmg z.B. mit wget ziehst (nicht mit dem Browser). OS X scheint das irgendwie als nicht-auszuführen zu kennzeichnen, vermutlich weil es nicht aus dem Apple Store kommt... Für Sachdienliche hinweise wie man das am geschicktesten umgeht sind wir natürlich dankbar .
  19. Also ich denke das nichts vom WIFI Code ausgeführt wird, solange keine Extension mit Extension ID 3 auf einem Master sitzt: https://github.com/Tinkerforge/master-brick/commit/14047de5ff336550dbb607a43407bf20daab4bfa Die größte Änderung ist das hier (in der bricklib): https://github.com/Tinkerforge/bricklib/commit/5a106ec891fee1713ab44ed9a8d36be463010de7 Ich hab für das Auslesen aus dem EEPROM und schreiben ins Flash von den Bricklet Plugins die Buffer Größe vergrößert und locks umgesetzt, damit das schneller geht. Zusätzlich hab ich beim Master das blinken am Anfang um 1 erhöht und die Timeouts bei RS485 dynamisch an die Baudrate angepasst. Mit diesen Änderungen konnte ich bei keiner Baudrate mehr Probleme erzeugen (vorher konnte ich Probleme bei niedrigen Baudraten reproduzieren). Am Wochenende lasse ich mal ein RS485 Aufbau mit den ganzen Sensoren die salvo nutzt durchlaufen, mal schauen ob ich das dann reproduzieren kann.
  20. Die längere Enumeration ist erwartet, an der Stelle hab ich die Timeouts hochgesetzt (d.h. ich warte bei niedriger RS485 Frequenz länger auf eine Antwort von den Slaves). Desweiteren wird am Anfang einmal mehr geblinkt. An der LED würde ich, wenn die gleiche Frequenz verwendet wird, keine Unterschiede erwarten. Die größere Firmware kommt zustande weil in 1.2.3 schon ein Großteil der WIFI Extension Unterstützung mit drin ist . Ich stelle am Wochenende mal genau deinen Aufbau nach (mit den Bricklets). Mal schauen ob es bei mir durchrennt.
  21. Hmpf. Kann ich absolut nicht reproduzieren hier. Der eigentliche Pakettransfer ist nicht anders gestaltet, ich hab habe nur bei niedrigeren Frequenzen ein paar Timeouts erhöht. Wir haben schon einige RS485 Extensions verkauft und nur sehr wenig Problemschilderungen (eigentlich nur nur dieser Thread hier und der von wurststulle). Daher gehe ich davon aus, dass es ein Problem ist, welches nur in einer bestimmten Konstellation auftritt. Welche Bricks/Bricklets hast du eigentlich an den Stacks? Mir ist nicht klar was da stecken bleiben soll, ich werde mal einen Langzeittest mit sehr langem Kabel ausprobieren!
  22. Mh, verstehe ich nicht. Wir blocken ja an der Stelle mit einer Semaphore und sobald wir blocken sollte die JVM schedulen. Oder nicht?
  23. Ah, ich hab gefixt das er losdreht wenn max_velocity auf 0 gesetzt war. Dieses Problem hatte ich gar nicht auf dem Schirm. Hab dafür schnell noch eine neue Version gebacken, sollte jetzt auch gehen. Die CALLBACK_NEW_STATE Sache ist aufwändiger, da muss ich ja neue API hinzufügen, also alle Bindings neu versionieren. Mache ich wenn es das nächste mal irgendwo eine API Änderung gibt!
  24. Firmwares: Stepper Brick 1.1.8 Stop completely if max velocity is set to 0 while in drive mode Download Firmwares: Stepper Brick
  25. Firmwares: Stepper Brick 1.1.8 Stoppe komplett falls max velocity auf 0 gesetzt wird im drive mode Download Firmwares: Stepper Brick
×
×
  • Neu erstellen...