Gast Robin Geschrieben February 4, 2014 at 18:16 Geschrieben February 4, 2014 at 18:16 Auf die Idee mit den GPIO Ports bin ich noch gar nicht gekommen. Vielleicht hat da einfach noch keiner dran gedacht und da geht was. Da bräuchte man dann sowas wie einen Pi Brick für, damit man von den IO Ports auf den Stapel kommt. Zitieren
wehnerc Geschrieben February 5, 2014 at 10:11 Geschrieben February 5, 2014 at 10:11 Hab noch nicht abgestimmt aber dafür eine Frage: Kann ein Wlan-Stick hier als Access-Point konfiguriert werden? Ich würde das Teil gerne autark laufen lassen und z.B. mit einem Tablet (iPad) befüllen. Dazu müßte ich mich einloggen können oder eine Verbindung als Mininetzwerk aufbauen können um den Webserver zu sehen. Zitieren
borg Geschrieben February 5, 2014 at 13:02 Autor Geschrieben February 5, 2014 at 13:02 Hab noch nicht abgestimmt aber dafür eine Frage: Kann ein Wlan-Stick hier als Access-Point konfiguriert werden? Das kommt auf den USB Stick an. Der verwendete WLAN Treiber muss bei "AP" ein "yes" stehen haben in der Liste: http://wireless.kernel.org/en/users/Drivers Zitieren
Martin Geschrieben February 7, 2014 at 23:06 Geschrieben February 7, 2014 at 23:06 Hallo, Das RED Brick benötigt doch im Grunde eine TinkerForge Linux-Distribution, deren Wartung mit einigem Aufwand verbunden ist. Programme benötigen oft noch weitere externe Bibliotheken. Ich habe z.B. gerade angefangen die Python Wetterstation-Beispielapplikation mit SQLAlchemy (http://www.sqlalchemy.org/) zu erweitern, um die Daten in einer Datenbank zu speichern. Diese Bibliothek würde ich dann z.B. auch gerne in einem TF-Repository wiederfinden. Mit dem Raspberry Pi, den ich aktuell zur Ansteuerung verwende bin ich allerdings unzufrieden. Nach wenigen Tagen Datensammeln gab es bei mir schon Stabilitätsprobleme (unvollständig geschriebene Daten, SSD korrupt). Da sind vermutlich Software-Bugs im Spiel, aber ich überlege trotzdem evtl. auf eine Alternative, wie z.B. einen Wandboard Quad (http://www.wandboard.org/) oder eben einen RED Brick umzusteigen, die dann aber wohl teurer kommt. (Ein Arbeitskollege hat sich längere Zeit mit Serverraum-Monitoring Raspberries herumgeärgert und diese nun z.B. erfolgreich durch Cubietrucks (http://cubieboard.org/) ersetzt.) Auch die Grenzen der Leistungsfähigkeit scheint beim RaspPi schnell erreicht zu sein und so habe ich die Befürchtung, dass Boards der unteren Preisklasse wie z.B. das BeagleBoneBlack (http://beagleboard.org/products/beaglebone%20black) ebenfalls schnell überfordert sind. Es ist zwar besser, die eigene Software zu optimieren, aber auch bequem Leistungsreserven zu haben. Ein wichtiges Kriterium wäre für mich also auf jeden Fall die Stabilität und Leistungsfähigkeit der Hardware (inkl.Treiber)! Die Stückzahlen einer Speziallösung liegen aber sicherlich deutlich unter denen von Raspberry Pi & Co. und das wirkt sich vermutlich auf den Preis aus. Dennoch würde der RED Brick gut in das TinkerForge Sortiment passen, auch wenn sich das TF-Team hier meiner Meinung nach deutlich mehr Arbeit aufhalst als bei den übrigen Bricks. Und so ist es vielleicht dennoch klüger auf bestehende (möglichst "offene") Boards mit vorhandenen Linuxdistributionen aufzubauen und den Repositories TinkerForge-Pakete beizusteuern. P.S.: TinkerForge-deb-Pakete für Raspbian und anderen Linux-Distributionen (auch rpm) wären bequemer zu installieren und würden die Sichtbarkeit erhöhen. (http://www.raspberryconnect.com/raspbian-packages-list/item/62-raspbian-electronics zeigt z.B. (noch) keine TinkerForge Einträge.) Aber wie gesagt - ich bin mir nicht sicher, ob der Raspberry Pi wirklich das beste Board ist. Auch wenn das natürlich auf den Anwendungsfall ankommt... Zitieren
Nic Geschrieben February 20, 2014 at 09:30 Geschrieben February 20, 2014 at 09:30 Mal was ganz anderes, aber es gehört zum OnDevice Thema, und wir haben das doch etwas übersehen. Aus aktuellem Anlass (Die Threads zu Encoder etc.) zur Klarheit nochmals nachgefragt: Wir hatten vor Monaten darüber disskutiert wie zumindest nur Steuersignale direkt an Bricks/Bricklets übertragen und dort weiterverarbeitet werden könnten (http://www.tinkerunity.org/forum/index.php/topic,1219.msg7466.html#msg7466) und damit nicht den "langen" und zeitkritischen Umweg über USB an den Host PC zu gehen. In wieweit ließe sich das mit dem RED managen ? Beispielsweise Events von Endlagenschalter direkt ans Stepper-Brick, Encoder Signale direkt am Brick ausgewertet etc... Zitieren
batti Geschrieben February 21, 2014 at 07:34 Geschrieben February 21, 2014 at 07:34 Es ist geplant Brickd so zu erweitern, so dass dieser direkt per SPI mit den Bricks des Stapels kommunizieren kann. Hierdurch könnten Latenzen die durch USB entstehen reduziert werden. Die Software der Bricks bleibt aber die gleiche. Ein direkte Verarbeitung von Events ist somit nicht möglich. Zitieren
borg Geschrieben February 21, 2014 at 18:17 Autor Geschrieben February 21, 2014 at 18:17 Es gibt schon erste Fortschritte: http://www.tinkerforge.com/de/blog/2014/2/21/tinkerforge-goes-stand-alone-aka-red-brick Zitieren
Loetkolben Geschrieben February 21, 2014 at 19:21 Geschrieben February 21, 2014 at 19:21 Hallo zusammen, erstmal Glueckwunsch zum schicken Layout und vielen Dank fuer die Info. Was mir spontan einfaellt: Irgendwie mag ich bei den kleinen Rechnern Normal-Grosse-SD lieber als Micro-SD. Beim hantieren kommen die grossen nicht so schnell abhanden und sofern man genug Platz hat koennte man diese doch verbauen. Wie sehen das die anderen und waere das moeglich das zu aendern? 512MB Ram scheinen im Moment vielleicht genug zu sein, aber mein Bauchgefuehl sagt mir, dass mehr Ram nie schaden kann. Ggf. kann man dann auch mal ganz andere OS daraus installieren oder laufen lassen. Ist ein groesserer Ram Baustein noch eine Option ueber die man nachdenken kann? Kann man dem Micro HDMI Port noch eine machanische Entlastung durch verschieben in die Mitte spendieren? Vielen Dank auf jeden Fall. Der Loetkolben Zitieren
batti Geschrieben February 21, 2014 at 22:22 Geschrieben February 21, 2014 at 22:22 Hallo Loetkolben, Irgendwie mag ich bei den kleinen Rechnern Normal-Grosse-SD lieber als Micro-SD. Du wirst dich wundern wie groß auf einmal eine SD Karte ist. Wir sind sehr froh den Kram überhaupt dadrauf bekommen zu haben. Der Prozessor und RAM haben so viele Durchkontaktierungen, dass diese Bereiche für alle anderen Bauteile gesperrt sind. ein großer SD Karten Slot passt daher da nur schwer drauf. Auch die Abblockkondensatoren wollen ja schließlich irgendwo hin. Ist ein groesserer Ram Baustein noch eine Option ueber die man nachdenken kann? Definitv. Die Footprints sind da standardisiert. Wir werden mal gucken was das größte ist was man bekommt. Kann man dem Micro HDMI Port noch eine machanische Entlastung durch verschieben in die Mitte spendieren? Wo möchtest du dann mit dem USB Host hin? Danke für die Anregungen. Grüße, Bastian Zitieren
remotecontrol Geschrieben February 22, 2014 at 14:43 Geschrieben February 22, 2014 at 14:43 Bzgl. der SD-Karte: mein Raspi eine eine "normale", mein Cubieboard eine Micro-SD. Inzwischen ziehe ich die Micro-SD vor, da die am Cubieboard nicht übersteht und so oft wechsle ich die ja auch nicht. Zitieren
R99 Geschrieben February 24, 2014 at 15:00 Geschrieben February 24, 2014 at 15:00 Ich hätte dazu ein paar fragen: Könnte man nun einen USB Hub verwenden(für Maus, Tastatur, Webcam, Touchscreen controller ?) Ist PHP schon vorinstalliert? Ist ein Webserver für einge Seiten auch schon drauf? Libe grüße R99 alias Willowgfan P.S. Bin ein totaler Fan von der Idee. Weil mein Pi nicht immer funktioniert(Webcamserver)! Zitieren
batti Geschrieben February 24, 2014 at 15:07 Geschrieben February 24, 2014 at 15:07 Könnte man nun einen USB Hub verwenden(für Maus, Tastatur, Webcam, Touchscreen controller ?) Es ist ein normaler USB Host Anschluss. Es können USB Host Geräte wie USB Hubs, Tastaturen, Touchscreen Controller etc verwendet werden. Ist PHP schon vorinstalliert? Auf unserem Image sollen alle Sprachen vorinstalliert sein. Ist ein Webserver für einge Seiten auch schon drauf? Es spricht nichts dagegen. Zitieren
pluto Geschrieben February 24, 2014 at 17:13 Geschrieben February 24, 2014 at 17:13 Ich habe jetzt nicht alles durchgelesen. Was mir aufgefallen ist: Alle Varianten kosten einfach zu viel. Ein Raspberry PI ist einfach Günstiger. Deutlich. Selbst mit einige Erweiterungen. Gibt es keine Günstigere Möglichkeit? Die CPU braucht doch gar nicht so viel Leistung. Ein atMega gibt es schon Relativ günstig. Damit müsste man doch was machen können. Z.B. könnte man auf ein atMega ein Script Interpreten Hochladen. Klar hat euer System einige Vorteile, aber zu den Preis? Zitieren
developer Geschrieben February 24, 2014 at 21:42 Geschrieben February 24, 2014 at 21:42 Also ich zahle den Preis gerne wenn es mehr Leistung bringt. Was bringt ein schwachbrüstiger Prozessor wenn es mich einfach in den Anwendungsmöglichkeiten eingrenzt und ich auf ein anderes System ausweichen müsste ? Ausserdem, da wir ja bereits Stapelbauweise haben, könnte man über Multiprozessor -Betrieb nachdenken : man klickt sich soviele Prozessoren zusammen wie man braucht... Teuer, zugegeben, aber Entwicklung und Forschung war nie billig, hauptsache es tut das was ws soll. Grüsse, Dim Zitieren
Loetkolben Geschrieben February 25, 2014 at 01:27 Geschrieben February 25, 2014 at 01:27 Ich habe mal auf die Seiten des A10s Prozessors geschaut und anscheinend kann der auch CVBS (FBAS). Display: •Multi-channel HD display •Integrated HDMI 1.4 •YPbPr, CVBS, VGA •Multiple LCD interfaces, including CPU, RGB, LVDS up to Full HD Koenntet ihr das bitte verfuegbar machen. Zwei (Ein) Loetpunkte reicht. So kann man wenigstens die ganzen kleinen TFTs anschliessen oder aber auch einen Fernseher. Siehe Seite 9 (Schema) und Seite 82 : A10s Manual Wie sieht das eigentlich mich Audio aus? Wenn verfuegbar koennte man auch Hinweistoene ausgeben, evtl. auch MP3 Samples? Der Loetkolben Zitieren
TomF Geschrieben February 25, 2014 at 12:45 Geschrieben February 25, 2014 at 12:45 Also ich würde es super finden, wenn man auch die Wifi-Extension mit der 1. Variante nutzen könnte. Mit einem USB-Wifi-Stick kann man leider nicht so einfach einen Access Point aufbauen. Vielleicht lässt sich die Wifi-Extension ja doch mit wenig Aufwand umsetzten. Danke und Gruß Tom Zitieren
jan Geschrieben February 25, 2014 at 12:57 Geschrieben February 25, 2014 at 12:57 Ausserdem, da wir ja bereits Stapelbauweise haben, könnte man über Multiprozessor -Betrieb nachdenken : man klickt sich soviele Prozessoren zusammen wie man braucht... Das wäre Cool Zitieren
raphael_vogel Geschrieben February 25, 2014 at 13:03 Geschrieben February 25, 2014 at 13:03 Also ich zahle den Preis gerne wenn es mehr Leistung bringt. Was bringt ein schwachbrüstiger Prozessor wenn es mich einfach in den Anwendungsmöglichkeiten eingrenzt und ich auf ein anderes System ausweichen müsste ? Es geht ja hier nicht nur um den Raspi, sondern generell um Einplatinencomputer. Das Cubieboard kostet mit dem A10 Chip knapp 50€. Der Cubietruck mit dem A20 (Dual Core !) kostet knapp 90€. Beide sind billiger als der anvisierte Preis des RED (99€), und der Cubietruck ist zudem DEUTLICH schneller als der RED sein wird. Da kann man schonmal die Frage stellen was der RED Brick an Mehrwert bringt? Meiner Meinung nach sind es: 1) Passt zum Rest des Stacks (4x4cm) 2) TF hat das Ziel Leute anzusprechen, die wenig Ahnung von Elektronik haben und auch keine Linux Experten sind/sein wollen. (-> "High-level" Ansatz). Es kommt also darauf an, ob es TF schafft das RED so einfach und intuitiv zu machen, das man dafür auch breit ist etwas mehr zu bezahlen. Genauso ist es mit den Sensoren/Aktoren. Es ist sicherlich jedem klar, dass wenn man z.B. einen Servo steuern will mit dem Raspi und etwas Bastelei sicherlich eine Lösung hinbekommt, die DEUTLICH unter dem liegt wenn man das ganze mit TF realisiert (Master Brick + Servobrick sind schon 80€ + eventuell Step Down um Servos mit genügend Strom zu versorgen) Also TF spielt seine Stärken sicherlich nicht über den Preis aus, sondern über die einfache Bedienbarkeit, die gute Doku, das Bauskasten Prinzip.....) Zitieren
jan Geschrieben February 25, 2014 at 13:09 Geschrieben February 25, 2014 at 13:09 Also TF spielt seine Stärken sicherlich nicht über den Preis aus, sondern über die einfache Bedienbarkeit, die gute Doku, das Bauskasten Prinzip.....) Das sehe ich genau so. Lieber "nen Euro" mehr, damit es sofort funktioniert und passt... Zitieren
Equinox Geschrieben February 25, 2014 at 13:29 Geschrieben February 25, 2014 at 13:29 Hallo, Also TF spielt seine Stärken sicherlich nicht über den Preis aus, sondern über die einfache Bedienbarkeit, die gute Doku, das Bauskasten Prinzip.....) Genau. Und außerdem ist das Hauptanliegen des RED Bricks, dass man einen Stack "stand alone" betreiben kann. Zitieren
raphael_vogel Geschrieben February 25, 2014 at 13:58 Geschrieben February 25, 2014 at 13:58 Früher hatte ich Zeit aber kein Geld. Damals hätte ich eher zum Raspi + Lötkolben + Breadboard + Transistor usw. gegriffen. Heute habe ich (eher) Geld aber keine Zeit mehr, daher mache ich TF ;D Zitieren
developer Geschrieben February 25, 2014 at 14:27 Geschrieben February 25, 2014 at 14:27 Das wichtigste ist sowieso Programmierung und nicht Hardware. Wenn einer noch die Sony AIBO Roboterhunde kennt - die armen Biester hatten nur Prozessoren mit 192, 384 und 586 Mhz mit 16-64 Mb RAM - und die haben Dinge getan die den meisten noch als Traum erscheinen. Neuronale netze, Lernfähigkeit, simultane Steuerung von bis zu 36 Gelenke, Gesichtserkennung, autonomes Aufladen und Erkunden der Umgebung, und, und, und... Grüsse, Dim Zitieren
remotecontrol Geschrieben February 25, 2014 at 16:43 Geschrieben February 25, 2014 at 16:43 Der RED Brick ist etwas teurer, aber die Größe ist einfach super kompakt (darum hatte ich auch für diese kleine Version gestimmt) und etwas mehr Leistung als beim Raspi hat man auch, plus vorkonfigurierte Software ... das kostet dann ein paar EUR mehr. Das finde ich OK, zumal das TF-Team ja auch von was leben muss . Stapelbare REDs wären aber nett: mit dem Cubieboard und Apache Hadoop haben die Cubie-Entwickler mal in einen "Cluster" aufgebaut ... Zitieren
batti Geschrieben February 25, 2014 at 21:47 Geschrieben February 25, 2014 at 21:47 Ich versuche mal auf die verschiedenen Dinge zu antworten: Gibt es keine Günstigere Möglichkeit? Die CPU braucht doch gar nicht so viel Leistung. Ein atMega gibt es schon Relativ günstig. Damit müsste man doch was machen können. Andere haben hier ja auch schon etwas geschrieben. Ich fasse mal unsere Ideen dazu zusammen: Beschränkt man sich auf eine Sprache, dann gibt es günstigere Möglichkeiten. Naheliegend wäre es zum Beispiel C oder C++ direkt auf den Prozessoren der Bricks zu programmieren. Dazu wollen wir unsere Kunden aber nicht zwingen. Wer das möchte kann es jetzt auch schon tun. Für diejenigen, die aber gerne "high-level" Sprachen und insbesondere untypische Embedded Programmiersprachen wie Java, PHP o.ä. programmieren möchten ist das wohl keine Alternative. Dazu sehe ich persönlich einfach den Vorteil von Hochsprachen, wie zum Beispiel Python. Ich bin damit einfach viel schneller als wenn ich etwas in C Programmieren muss. Insbesondere wenn dies direkt auf einem Mikrocontroller ausgeführt wird! Die Programmierung da ist ja schon etwas anders. Alternativ hatten wir schon darüber nachgedacht einen eigenen Interpreter für eine, noch zu bestimmende, Sprache auf den Bricks zu implementieren. Das klingt in der Theorie toll, da jedes Brick praktisch standalone sein könnte. Offensichtlicher Nachteil ist dann aber, dass wieder genau eine Sprache unterstützt wird. Was ist mit den anderen? Wir würden Nutzer wieder Zwingen. Mindestens genauso schlimm sind aber die Beschränkungen die dann wieder existieren. So ist zum Beispiel der RAM sehr begrenzt. Würde man Sprachen wie Python nutzen, so könnte nur ein gewisser Funktionsumfang implementiert werden etc. etc. Ein Programmierer der Python gewohnt ist würde über X Dinge stolpern. Die Idee, dass der Anwender dies einfach nutzt ist damit aus unserer Sicht gestorben. (Beispiel: PyMite, scheint schon länger tot zu sein) Daher jetzt der Weg mit dem RED Brick. Im optimalen Fall bekommen wir es hin, dass der Anwender sein Programm einfach auf das RED Brick hochläd, es zu den Bricks steckt und schon ist die Anwendung standalone. Da es sich bei dem RED Brick defakto um einen PC handelt, existieren ähnliche Einschränkungen wie auf dem PC an dem die Anwendung entwickelt wurde. Aus unserer Sicht ein riesen Vorteil gegenüber dem C oder Interpreter Ansatz. Bezüglich des Preises haben ja andere hier auch ihre Meinung geäußert. Danke dafür! Es wird so sein, dass das RED Brick teurer sein wird wie ein Raspberry. Wir sind nun mal aber keine Stiftung die ein Board zu den Herstellkosten vertreibt. Dazu kommt, dass wir vermutlich nicht so schnell an die Stückzahlen eines Raspberrys herankommen werden (hätte aber nichts dagegen ). Ich habe mal auf die Seiten des A10s Prozessors geschaut und anscheinend kann der auch CVBS (FBAS). Koenntet ihr das bitte verfuegbar machen. Zwei (Ein) Loetpunkte reicht. Ich weiß ehrlich gesagt nicht wie ich das Signal aus dem Ding noch rausbekommen soll. Werden bald noch einen Blogeintrag mit weiteren Bildern machen, da sieht man dann besser wie eng es doch beim Prozessor zu geht. Wie sieht das eigentlich mich Audio aus? Wenn verfuegbar koennte man auch Hinweistoene ausgeben, evtl. auch MP3 Samples? Finde ich auch toll. Insbesondere weil es fast nichts kostet. Mussten dieses aber sehr früh von der Liste streichen weil dafür einfach kein Platz ist. Die Buchsen müssten auf die Oberseite und da ist einfach nichts mehr frei. Stapelbare REDs wären aber nett: mit dem Cubieboard und Apache Hadoop haben die Cubie-Entwickler mal in einen "Cluster" aufgebaut ... Die Hardware kann prinzipiell zwischen mehreren RED Bricks in einem Stack unterscheiden, so dass sich einer als "Master" des Stacks verhalten kann. Lasst uns abwarten was man damit vll. tun kann. Aktuell geplant ist da noch nichts. Zitieren
Loetkolben Geschrieben February 25, 2014 at 22:27 Geschrieben February 25, 2014 at 22:27 Hallo batti. Vielen Dank fuer die Info. Mussten dieses aber sehr früh von der Liste streichen weil dafür einfach kein Platz ist. Platz ist in der kleisten Huette. Mal ernsthaft: Ist wirklich keine Mini/Micro/Pico-Stiftleiste fuer Audio/Video Signale mehr moeglich? Was haelst Du von der Idee die MicroHDMI Buchse wegzulassen, denn die braucht man wahrscheinlich eh nur zum testen bis alles laeuft, und dafuer eine Stiftleiste mit HDMI/Audio/CVBS zu machen an der man dann per Adapter die Signale abgreifen kann. Im Prinzip wie der GPIO Anschluss. Andere Idee: Kann man Audio noch mit auf die MicroHDMO Buchse legen und dann per "Spezial-Y-kabel" dort abgreifen? Der Loetkolben Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.