borg

Mh, auf Durchsatz hatte ich jetzt nicht getestet, muss ich mal vergleichen.

@kuli: USB wird 1x pro ms gepollt vom Linux Kernel (oder auch von Windows, ist so im Standard definiert). Die Antwort auf ein getter ist immer direkt beim nächsten polling vom PC fertig. D.h. so eine Anfrage dauert minimal 1ms und maximal 2ms, je nachdem wo du dich gerade in diesem Abfragefenster befindest. Deswegen schreiben wir überall das unbedingt wenn möglich die Callbacks benutzt werden soll, da ist dann die absolut maximale Latenz nach auftreten eines Events 1ms, im Schnitt 500us.

Naja, wir müssen zwischen "Datenrate" und "Durchsatz" unterschieden. Die WIFI Extension hat eine höhere Datenrate als USB. Aber wenn du nun getter aufrufst, ist die Datenrate fast irrelevant. Interessant ist die Zeit die es dauert bis ein Paket vom PC beim Brick angekommen ist und wieder zurück (Round Trip Time). Hier ist WLAN natürlich langsamer als USB (aber immernoch viel schneller als Chibi).

Sind die 2-3 Sekunden von Programmstart bis Programmende? Im laufenden Programm sollte so eine Abfrage keine 2-3 Sekunden dauern, auch nicht mit Java.

Das wird nichts werden, dafür fehlt zum einen der Platz auf der Leiterplatte und zum anderen müssten wir dafür immer zwischen Command-Modus und Daten-Modus hin und her wechseln, dann schaffen wir noch weniger Durchsatz.

Wir haben schon ein Barometer/Altimeter-Bricklet Prototyp hier rumliegen. Es basiert auf dem MS5611-01BA01: www.meas-spec.com/downloads/ms5611-01ba01.pdf

Gibt jetzt eine Master Brick Firmware Version 1.2.4. Ich hab jetzt mit dem Aufbau im Anhang getestet, 5 Bricks und 10 Bricklets. Ich lasse den Aufbau mit JTAG Debugger und Logic Analyzer usw. erstmal hier für eine Woche oder so liegen, falls es noch irgendwelche Probleme gibt bitte einmal beschreiben wie ich meine Aufbau abändern muss um das Problem nachzustellen . Getestet hab ich mit 9600 Baud, 19200 Baud, 1 MBaud und 2 MBaud.

Gibt jetzt Master Brick Firmware Version 1.2.4, bitte einmal damit probieren .

Gibt jetzt Master Brick Version 1.2.4, bitte damit einmal probieren!

Firmwares: Master Brick 1.2.4 Send empty message if slave has timeout, to allow slave to process buffer Download Firmwares: Master Brick

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

Das IMU Plugin vom Brick Viewer benutzt OpenGL, das ist der einzige Unterschied der mir zu anderen Bricks/Bricklets einfällt.

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.

@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 .

@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!

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.

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 .

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!

@sump: Wenn du keine Servos dran hast stürzt das Display nicht ab?

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 .

Ups, ich hab die letzter Version im Downloadbereich einfach einmal dreisterweise überschrieben. Es sollte jetzt 1.1.8 angezeigt werden .

Mh, gucke ich mir an .

Dann werden wir das erstmal so Dokumentieren denke ich und in Zukunft vermutlich die 80€/Jahr "Applesteuer" zahlen...

Mhh, nicht wirklich. Ich bin ein wenig ratlos. Hat irgendwer eine Idee?

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!