benatweb

Ein Step-Up/Step-Down so in der Art hier wäre auch ganz praktisch: http://www.exp-tech.de/Sensoren/Strom-Spannung/Pololu-Voltage-Regulator-S18V20F5.html

Seh ich eig. genauso, aber wenn der Treiber laufen würde, wieso nicht Aber schreibt den natürlich erstmal Meine Idee wäre eine Platte die man auf die GPIO-Leiste vom Raspberry stecken kann und die analog zur Step-Down den unteren Stack-Abschluss darstellt. Die könnte dann entweder vom Pi aus den Stack mit 5V versorgen oder wieder eine Step-Down sein und dann Pi und Stack zusammen versorgen. Dann noch ein kurzes USB-Kabel vom Pi zum Stack und gut ist. Ich bastel da mal ein Mockup.

ACK. @TF, aus Interesse: Wie portabel ist denn euer Custom-SPI-Treiber? Würde der sich prinzipiell auch auf einen Raspberry Pi od. ähn. portieren lassen?

Nein, Syntax ist nicht alles, woraus so eine Programmiersprache besteht. Jede Sprache hat ihre ganz eigenen Strukturen und Abläufe und jede braucht deshalb einen eigenen (speziellen) Compiler/Interpreter um aus dem geschriebenen Programmcode etwas zu bauen, was der Prozessor ausführen kann. Wenn man für jede Sprache den selben Compiler verwenden könnte und nur die Syntax anpassen, das wäre ein sehr viel einfacheres Leben Hinzu kommt, dass so ein kleiner Microcontroller ganz andere (viel kleinere) Instruktionssets spricht als etwa ein x86 oder ARM-Prozessor. Für letztere gibt es Compiler für die meisten Sprachen (deshalb auch der Ansatz mit dem RED-Brick und Linux, der ist ja ein ARM), Microcontroller lassen sich meist nur in C programmieren (weil sonst keine Compiler zur Verfügung stehen, man müsste die schon selbst schreiben). Und billigere Linux-fähige Prozessoren sind dann meist einfach zu schwach, aka Preis/Leistung stimmt nicht mehr. Den Preisvorteil, den Raspberry Pi und Co. haben, der geht hier schlicht über größere Stückzahlen (und beim Raspberry kräftigem Rabatt von Broadcom), die TF mit dem RED nicht erreichen kann. Aber für ein 4x4cm großes Board auf dem ein komplettes Linux läuft sind die 100€ definitiv nicht zu viel verlangt.

Ich vermute die 5V werden als Referenz für die Datenleitungen verwendet, brauchst du also. Ich kenn mich jetzt mit der USB-Spezifikation nicht genau aus, aber ich vermute eine Diode von Master Richtung Pi wird evtl. nicht funktionieren, weil die 5V Referenz vom USB-Host kommen muss, aber wie gesagt, nur ne Vermutung. Was du machen könntest, wäre einen Transistor einzubauen, der von der 12V Leitung aus die 5V vom Step-Down zur PiUSV schaltet (12V weg -> keine Verbindung mehr vom Step-Down zur PiUSV). Wenn ich mich grad nicht vertue, sollte das so wie im Bild das machen, was du brauchst.

Guck mal hier: http://www.electronic-things.de/shop/RepRap-Shop/Elektronik/Motoren--Treiber-und-Zubehoer/NEMA17-Schrittmotor-42BYGHW811.html Und hier (0,9° Schrittwinkel): http://nodna.de/NEMA-17-Bipolar-48mm-Stepper-Motor Halt ohne Encoder.

Laufen per USB am Computer auch die Dual Relays (also mit Last)? Ich vermute nämlich, die ziehen einfach zu viel Strom für eine Versorgung des Stapels mit USB und du solltest mal versuchen, stattdessen den Stapel mit einer Step-Down-Power-Supply zu versorgen. Die andere Möglichkeit wäre, dass der Stapel was abkriegt wenn die Dual-Relays schalten: http://www.tinkerunity.org/forum/index.php/topic,1707.msg11434.html http://www.tinkerunity.org/forum/index.php/topic,241.msg4121.html

Genau das gibts ja sogar schon, für Ethernet würde bei Variante 1 wie bisher die Ethernet-Extension zuständig sein. Wäre dann zwar leicht teurer als Variante 2, dafür wird aber der Formfaktor gewahrt + man kann Stromversorgung via PoE machen falls man das will. IDE kannste dir ja auch nach Wunsch (muss ja nicht jeder die selbe bevorzugen) noch nachinstallieren, auf dem RED-Brick läuft ja ein stinknormales Linux. Editor direkt im TF-Webinterface integriert wäre natürlich auch praktisch, aber muss imo nicht zwingend sein, kann man ja wie gesagt auch nachrüsten.

Cool

Erstmal alle Achtung, ein Linux auf 4x4cm (ein Viertel von einem Raspberry Pi!) ist schon nicht von schlechten Eltern Zwei Fragen: 1. Stellt der RED-Brick auf seinem Mini-USB Anschluss für den Host-Computer eine serielle Konsole bereit? Also ich schließe ihn an meinen Computer an und kann dann via picocom o.ä. ein Terminal auf dem RED-Linux öffnen? 2. Ist es theoretisch möglich eine Platine zu basteln, die ich auf die Board-to-Board Connectoren des RED-Bricks stecke und auf der GPIOs, SPI und Co. des A10 (halt eben die, die im Connector verbunden sind) auf Stiftleisten verfügbar gemacht werden? Und wäre das dann auch von Programmen auf dem RED-Linux so direkt ansprechbar oder müsste man da noch Entwicklungsarbeit reinstecken, bis das funktionieren würde? Edit: Nicht vom Stack genutzte zusätzliche GPIOs des A10 irgendwo auf dem RED auf irgendeinem Mini-Frickel-Connector verfügbar zu machen, würde bei Variante 1 sicher nicht noch funktionieren, korrekt?

Das Voltage Bricklet gibts nicht mehr, das war der Vorgänger vom Analog In. Offenbar gibts mitterweile auch die Current Bricklets nicht mehr, dann brauchst du dafür wohl ein Voltage/Current Bricklet. Hinweis in die Doku, welche Bricklets nicht mehr verkauft werden, wäre wirklich eine gute Idee.

Das Problem sollte vmtl. weniger der USB-OTG Modus sein - sondern eher, ob du die nötigen Dependencies für den brickd (Host-Programm für die USB-Verbindung zum Brick) irgendwie auf dem Smartphone installieren kannst: http://www.tinkerforge.com/de/doc/Software/Brickd_Install_Linux.html#brickd-install-linux Schätze, das zu versuchen (es sei denn, du kennst dich mit Android-Interna gründlich genug aus) wird den Aufwand nicht wirklich lohnen... Ein Raspberry Pi oder die Ethernet-Extension dürften die einfachere Alternative sein falls es wirklich nicht am Rechner hängen kann.

Na ja, wie in jedem anderen Computer auch halt, um rein während der Laufzeit Daten kurzzeitig ablegen zu können (z.B. Daten vom Bricklet, die gepuffert werden, bevor sie an den Host gehen). RAM ist im Gegensatz zu Flash-Speicher auch flüchtig, d.h. Strom weg -> alles im RAM weg. Wenn ich mich richtig erinnere steht der Bootloader in einem gesonderten Bereich, dort ist er aber auch glaube ich reingebrannt, d.h. kann nach der Produktion vom Brick nicht mehr geändert werden.

Ich hab zwar kein US Bricklet zusammen mit meinem Remote Switch angeschlossen (Temperature, PTC, Ambient Light, Strom via Ethernet-Extension mit PoE), bei mir tritt allerdings das selbe Problem auf, dass das Remote Switch Bricklet im Brickviewer die Buttons zum Senden dauerhaft sperrt und die Steckdose auch nicht reagiert. Selbst ein Master-Reset hilft nicht (nächster Versuch dann genau das selbe), erst nach Strom weg gings dann wieder problemlos. Ist bis jetzt schon paar Mal passiert. Scheint also wohl nicht nur an der Kombi Distance US + Remote Switch zu liegen...

Grade eine Ladung NeoPixels gekauft, da würde ich mich auch über Tinkerforge-Unterstützung der WS2812er freuen