borg

http://www.tinkerforge.com/de/doc/Software/Bricks/Master_Brick_Java.html#konstanten OK, das ist natürlich als "Top to Bottom"-Ansatz einfach nachvollziehbar. Du darfst dabei aber nicht vergessen das wir ein komplexes System von Firmwares, Plugins, Schnitstellen, Hardware, USB/Ethernet/Wi-Fi, usw. haben. Die API für C# ist ja nur ein winziger Teil. Die APIs für unsere Produkte werden automatisch generiert aus Konfigurationsdateien. Die Config für das Voltage/Current Bricklet sieht z.B. so aus: https://github.com/Tinkerforge/generators/blob/master/configs/bricklet_voltage_current_config.py Die API des Voltage/Current Bricklet für die ganzen Sprachen muss also aus dieser Datei generiert werden. Viele der Informationen die für deinen Vorschlag benötigt werden sind dort einfach nicht vorhanden. Grundsätzlich sehen wir es so: Wir wollen einem Programm (welches Bricks/Bricklets nutzt) möglichst wenig Zeilen Code aufzwingen. D.h. ein durchschnittliches Programm nutzt wenige Zeilen Code um Objekte für die IPConnection und die Bricks/Bricklets zu erzeugen und ruft auf diesen Objekten dann eine Reihe von Gettern und Settern auf wenn notwendig. Mehr mischen wir uns nicht ein, alles andere ist dem Nutzer überlassen.

Du könntest den Counter bei 0 Anfangen lassen und dann das Setzen der Segmente so machen: counter = counter+1 segments = (DIGITS[(counter/1000) % 10], DIGITS[(counter/100) % 10], DIGITS[(counter/10) % 10], DIGITS[counter % 10]) Aber deine Lösung führt ja auch zum Ziel .

Die Hard- und Software ist Open Source, du kannst also Problemlos hergehen und dir ein Design machen welches mehrere Bricks und Bricklets beinhaltet und das produzieren lassen. Wenn du da bei einzelnen Bauteilen Beschaffungsprobleme hast kannst du dich bei uns melden, das kriegen wir dann schon irgendwie hin. So ein "Bausatz aus den Bauteilen" wäre ein riesiger Aufwand. Die ganzen Bauteile haben wir ja als "Tape and Reel" auf Lager, da kann man nicht so ohne weiteres einfach immer ein Bauteil rausnehmen. Wir haben sowas für Firmen übrigens schon gemacht: Ein Design das mehre Bricks/Bricklets auf eine große Leiterplatte und in ein Industrie-Hutschienengehäuse bringt. Das lohnt sich aber finanziell erst ab 250-500 Stück, sonst wird das exorbitant teuer auf Grund der Entwicklungs- sowie Einmalkosten (Bestückungsschablonen usw).

Darf ich fragen an welcher Stelle die API besser dokumentiert hätte sein können? Die Bricklet UIDs hättest du dir übrigens auch einfach über den Brick Viewer holen können . Und wo musste man zuviel mit Bits und Bytes arbeiten? Wahrscheinlich bei der IO16? Ist eigentlich das einzige Bricklet was du hast welches mit Bitmasken arbeitet. Beim setzen von einzelnen Pins machen Bitmasken einfach immernoch sehr viel Sinn.

Das VMWare Thema gab es hier schonmal im Forum: http://www.tinkerunity.org/forum/index.php?topic=1972.0

Cool! Was du machen könntest mit den digitalen LEDs ist eine Anzeige die so ähnlich funktioniert wie die im Brick Viewer. D.h. du nutzt die LEDs um ein Farbspektrum von grün auf rot darzustellen (unten grün, oben rot) und machst die Anzahl der LEDs die an sind (von unten nach oben) abhängig von der Lautstärke.

Die LEDs sind leider nicht bei jedem Hersteller gleich angeschlossen. Wir können das aber von außen nicht feststellen, daher kann es da zu einer beliebigen Vertauschung kommen . Also einfach einmal am Anfang durchprobieren was genau R, G und B ist und dann passend nutzen .

Je nachdem welcher Pin krumm war, wird das EEPROM evtl. zuviel Spannung abbekommen haben und dadurch wurden die Daten im ROM korrumpiert. Das könnte ich mir zumindest vorstellen .

Ist vielleicht eines der Beinchen im Bricklet Stecker krumm (beim Master oder bei einem der Bricklets)? So wie hier: http://www.tinkerforge.com/de/doc/FAQ.html#mein-brick-wird-heisz

1000 Nachrichten/Sekunde ist das Maximum was die USB Spezifikation zulässt für die USB Version und USB Class die wir nutzen. Bzgl der SPI Performance können wir erst eine Aussage treffen wenn wir da wirklich einen Treiber für fertig haben. Die SPI Schnittstelle wird auf jeden Fall nicht mit anderen Teilnehmern geteilt (Maus, Tastatur, USB Festplatte etc), dadurch sollte sie in dem Sinne schon zuverlässiger sein vom Durchsatz her.

"Starter Kit: Server Room Monitoring" jetzt mit pulverbeschichteter Aluminium-Frontblende: Blogeintrag

"Starter Kit: Server Room Monitoring" now with powder coated aluminum front panel: Blog entry

Doch, werden sie. Es wird über eine Schablone Lötpaste aufgetragen, dann werden die Bauteile mit einem Bestückungsautomat bestückt und dann wird das Panel durch einen Ofen geschoben. Danach wird die Leiterplatte umgedreht und das ganze passiert nochmal von vorne. Das kann man auch daran erkennen das die unteren Board-to-Board Stecker ein bisschen dunkler sind als die oberen (sind 2x durch den Ofen gegangen). Dabei wird beim zweiten Durchgang das Zinn natürlich wieder flüssig, allerdings ist die Oberflächenspannung von der Lötpaste bei den ganzen kleinen Bauteilen groß genug das trotzdem nichts herunterfällt. Einzige Ausnahme sind bei uns glaube ich die großen Kondensatoren beim Servo Brick. Da kann man auch manchmal an der Seite so rote Flecken sehen neben den Kondensatoren, da wurde dann vorher Kleber auf der Leiterplatte aufgetragen.

Plugins: Dual Button Bricklet 2.0.2 Fix links/rechts Vertauschung Download: Dual Button Bricklet

Plugins: Dual Button Bricklet 2.0.2 Fix left/right button permutation Download: Dual Button Bricklet

IoT mit JavaFX / iOS Apps im App Store Blogeintrag

IoT with JavaFX / iOS Apps in App Store Blog entry

Plugins: Dual Button Bricklet 2.0.1 Fix selected_led_state Bug Download: Dual Button Bricklet

Plugins: Dual Button Bricklet 2.0.1 Fix selected_led_state bug Download: Dual Button Bricklet

Das kann ich nachvollziehen, aber wir wollen ja gerade Leute ansprechend die nicht unbedingt low-level C schreiben können und auch nicht lernen wollen. Wir haben eine C API ja in betracht gezogen, allerdings haben wir uns auf Grund der überwältigenden Anzahl von Anfragen Java/Python/C# etc. im Stack auszuführen dagegen entschieden. Wir haben hier eine kleine Anleitung: http://www.tinkerforge.com/de/doc/Embedded/Raspberry_Pi.html Das RPi ist ein Linux Board mit dem man Bricks/Bricklets ansprechen kann, das RED Brick ist ein Brick mit dem man Hochsprachen einfach im Stack ausführen kann. So muss man den vergleich vielleicht betrachten. Je nach Anwendung und Wissensstand mag das RPi genauso gut geeignet und günstiger sein. Aber das ist ja auch nicht schlimm .

@derAngler: Du kannst ja das RPi nutzen, auch wenn wir ein RED Brick haben . Da spricht ja nichts gegen. Der Grund für das RED Brick ist denke ich schlicht und ergreifend die Nachfrage. Wir haben hunderte Emails (und auch Forenbeiträge) wo Leute nach einer Möglichkeit fragen ihren Code auf einem Brick auszuführen (Stichwort Standalone/OnDevice). Bisher war unsere Aussage ja auch immer das man dafür das RPi nehmen kann, das ist für viele aber einfach nichts. Zum Preis: Ihr dürft auch nicht vergessen dass das RPi von einer "not-for-profit organization" ist. Der Verkaufspreis entspricht da mehr oder weniger dem Herstellungspreis.

Der A23 hat kein integriertes HDMI (evtl. nicht so schlimm) und Allwinner hat bisher keinerlei Source Code für den A23 veröffentlicht. Es gibt auch keine Entwicklungsboards o.ä. auf die wir aufsetzen könnten. Wenn wir jetzt ein fertiges Board mit dem Prozessor hier hätten, hätten wir keine Chance darauf ein Linux zu booten. http://linux-sunxi.org/A23: Edit: Wenn er HDMI hätte und Allwinner die Sourcen veröffentlicht hätte, wäre der A23 eine sehr gute Alternative!

Wir haben da viel Zeit mit verbracht nach Prozessoren zu suchen und haben einen guten Überblick. So einfach ist das aber alles nicht. Wir hätten z.B. gerne eine CPU von TI mit Package on Package genommen. Da hat die CPU dann oben drauf nochmal Pads auf die man direkt den RAM löten kann. Das hätte uns natürlich viel Platz gespart. Leider hat TI kein Interesse daran uns sowas zu verkaufen... Man hat da bei den "kleinen" vierstelligen Stückzahlen die wir anstreben leider keine riesige Auswahl.

Versteh ich jetzt nicht: An RED kann ich doch in Variante 1 keine Bricklets anschließen. Daher kann doch RED kein Ersatz für den Master sein. Er hat keine Bricklet Ports in Variante 1+2, aber er arbeitet als Master eines Stacks . Öh, vielleicht könnte man 1€ sparen indem man den kleineren Microcontroller nimmt, das lohnt sich aber schon auf Grund der Fixkosten nicht befürchte ich.

Dafür haben wir leider nicht genug Platz.