developer Geschrieben February 25, 2014 at 23:01 Geschrieben February 25, 2014 at 23:01 Hallo batti, Es ist auch in dem Blogeintrag von "General purpose connector" für Flachbandkabel die Rede. Was für Signale werden denn da ausgegeben ? Grüsse, Dim Zitieren
Martin Geschrieben February 27, 2014 at 00:51 Geschrieben February 27, 2014 at 00:51 Bestehenden Einplatinencomputer können teilweise auch erweitert werden... Beim BeagleBone Black (http://beagleboard.org/Products/BeagleBone%20Black) werden Erweiterungsplatinen z.B. als "Capes" bezeichnet (http://elinux.org/Beagleboard:BeagleBone_Capes, http://elinux.org/Beagleboard:BeagleBone_Black_Capes) Für die Cubieboards (http://cubieboard.org/) sind anscheinend ebenfalls Erweitungsplatinen (http://docs.cubieboard.org/expander_boards) angedacht und die Wandboards (http://wandboard.org/) bieten wohl einen "EDM standard connector" (EDM=Embedded Design Module, s. z.B. http://www.edm-standard.org/) Der Raspberry Pi hat da sicher auch Möglichkeiten. Und es gibt da natürlich noch viele viele weitere Einplatinencomputer... (s. z.B. http://en.wikipedia.org/wiki/List_of_single_board_computers http://en.wikipedia.org/wiki/Comparison_of_single-board_computers) Für ein geeignetes Board hätte man doch vermutlich auch eine TinkerForge-Erweiterung entwickeln können, oder? Doch welches Board wäre hier ein möglicher Kandidat gewesen? Die Schnittstelle muss ausreichende Möglichkeiten besitzen und wenn man so eine Erweiterung auch mit der jeweils nächsten Generation eines Boards weiterverwenden oder zumindest einfach anpassen kann, wäre das sicher von Vorteil. Das Beagleboard Black (BBB) und die Cubieboards haben z.B. bereits flash storage on-board auf dem man z.B. Teile des Betriebssystems ablegen kann. Im Gegensatz zum Raspberry Pi liefern manche Boards eine batteriegepufferte Uhr, so dass z.B. auch ohne Netzwerkanbindung und NTP-Client eine Speicherung von Sensordaten mit Uhrzeitstempel möglich ist. Mit laut Wikipedia "mehr als 2 Millionen Geräte" wird der Raspberry Pi vermutlich die größten Stückzahlen aufweisen können und die 127450 boards des BBB (http://elinux.org/Beagleboard:BeagleBoneBlack#Board_Shipments) sind da vergleichsweise recht bescheiden. Welche Stückzahlen werden für das RED erwartet? All diese Boards sind aber immerhin schon am Markt. Es sind hier mehrere Preisklassen auszumachen, wobei der Raspberry Pi und der BBB bei den oben erwähnten das untere Ende ausmachen, aber sicher auch weniger Leistung bieten. (Aber immer noch deutlich mehr als z.B. ein "klassischer" Arduino.) Interessant finde ich auch die Frage, welche Boards und Features denn bisher mit TinkerForge verwendet wurden bzw. werden. Mir scheint es wird recht oft der Raspberry Pi genannt und demnach auch eingesetzt. (s. z.B. http://www.tinkerforge.com/en/doc/index.html#embedded-boards) Warum gerade dieses Board so erfolgreich ist? Evtl. die relativ frühe Verfügbarkeit und der relativ niedrige Preis, was zu größeren Stückzahlen und einer großen "Community" geführt hat. Ich selbst habe mir auch einen gekauft und dann später noch einen geschenkt bekommen, bin aber nicht so 100%ig zufrieden und kann somit nicht so recht nachvollziehen warum sich ausgerechnet dieses Board so großer Beliebtheit erfreut. All diese Boards sind nicht speziell für TinkerForge entwickelt und so sind manche Features evtl. nicht nötig. Die GPIO Möglichkeiten des Raspberry Pi habe ich z.B. für TinkerForge Projekte noch nicht eingesetzt, wobei das eigentlich noch ganz gut in diesen Anwendungsbereich passt. Und so wird es bei vielen Features doch den einen oder anderen geben, der das dann doch braucht. Je nach Bedarf kann man aber ja das zum Projekt passende Board einsetzen und das wird sicher auch mit der Verfügbarkeit des RED noch möglich sein... Denn selbst für TinkerForge Projekte sind die Anforderungen doch sicher teilweise recht unterschiedlich. Der Stromverbrauch ist z.B. immer wichtig, wird aber für eine fest an die Wand montierte Wetterstation mit direktem Stromanschluß sicher nicht ganz so kritisch sein wie bei einem Fluggerät, welches keine allzu schweren Akkus befördern kann und auf eine ausreichend lange Flugdauer kommen möchte. Die nötige CPU-Leistung ist im Fall eines Fahrroboters, der eine schwarze Linie verfolgt sicher geringer als bei einem fußballspielenden Roboter, der sich per Bilderkennung selbst orientiert und auch einen Doppelpass mit einem Mitspieler ausführen soll. Welchen Bereich kann hier der RED abdecken? Auch die Größe der Boards kann ein Entscheidungskriterium sein und hier ist der RED sicher im Vorteil, denn die o.g. Boards sind alle etwas größer. Für all die oben erwähnten Boards sind noch Weiterentwicklung zu erwarten. Welche Update-Zyklen sind für das RED vorgesehen? Das RED Brick passt wirklich 100% zum TinkerForge Konzept und das ist sein Stärke! Der Aufwand könnte allerdings recht hoch werden und sich nicht auf die Entwicklung beschränkt. Ein Repository z.B. für Raspbian ist mir bisher nicht bekannt. Das wäre einfacher, als die TinkerForge Bibliotheken per Hand oder den Boardmitteln der Programmiersprachen zu installieren. Beim RED soll ja aber alles anscheinend recht einfach werden. Gibt es da dann einen Paket-Mechanismus wie bei Linux üblich? Die meisten Programmiersprachen können z.B. durch zusätzliche Bibliotheken im Funktionsumfang erweitert werden und diese zusätzlichen Bibliotheken müssen ja installiert werden. Ein WWW-Server und NTP-Client wird vermutlich schon vorinstalliert sein. Wie sieht es aber z.B. mit einem NFS-Client aus? usw. Wie lange wird die "Distribution" gewartet? (Long Term Support?) Wie geht man mit Sicherheitsupdates um? Die Geräte sind ja schließlich teilweise am Netz und gerade das allseits beliebte WLAN kann schlecht über andere Geräte abgesichert werden. Bei den Einplatinencomputer wird das von der entsprechenden "Community" übernommen, beim RED Brick sollte das dann ja TinkerForge übernehmen... Gute Nacht, Martin Zitieren
borg Geschrieben February 27, 2014 at 08:40 Autor Geschrieben February 27, 2014 at 08:40 Gibt es da dann einen Paket-Mechanismus wie bei Linux üblich? Die meisten Programmiersprachen können z.B. durch zusätzliche Bibliotheken im Funktionsumfang erweitert werden und diese zusätzlichen Bibliotheken müssen ja installiert werden. Ein WWW-Server und NTP-Client wird vermutlich schon vorinstalliert sein. Wie sieht es aber z.B. mit einem NFS-Client aus? usw. Wie lange wird die "Distribution" gewartet? (Long Term Support?) Wie geht man mit Sicherheitsupdates um? Die Geräte sind ja schließlich teilweise am Netz und gerade das allseits beliebte WLAN kann schlecht über andere Geräte abgesichert werden. Bei den Einplatinencomputer wird das von der entsprechenden "Community" übernommen, beim RED Brick sollte das dann ja TinkerForge übernehmen... Das ist alles weniger schwierig als du es dir vorstellst. Wir werden da einfach ein Debian verwenden und zusätzliche Pakete hinzufügen (für brickd, brickv, Bindings, Interface zum hochladen von Programmen, usw). Updates und Sicherheits-Updates kommen weiterhin ganz normal über Debian. Das dürfte auch einen Großteil deiner anderen Fragen klären: Das RED Brick ist ein kleiner Linux PC mit 1GHz, 512MB RAM, Debian und kann wie ein ganz normaler Linux PC genutzt werden. Man kann den RED Brick aber auch als "Blackbox" betrachten auf die man über den Brick Viewer oder ein Webinterface sein vorher am PC entwickeltes Programm hochläd welches dann Standalone im Stack ausgeführt wird. So werden wir es bewerben . Zitieren
batti Geschrieben February 27, 2014 at 17:54 Geschrieben February 27, 2014 at 17:54 Mal ernsthaft: Ist wirklich keine Mini/Micro/Pico-Stiftleiste fuer Audio/Video Signale mehr moeglich? Nicht wirklich. Sie muss ja auch anschließbar sein und ich muss irgendwie das Signal auch noch dahin bekommen. Auf meinen Signallagen habe ich keinen Platz mehr. Ich könnte da jetzt etwas reinhacken, dies würde aber zur Lasten der anderen Signale gehen. Was haelst Du von der Idee die MicroHDMI Buchse wegzulassen Ehrlich gesagt nicht viel. Ich sehe durchaus Anwendungen in denen man ein Touchpad Edit: Display + Touchscreen anschließen möchte. Und das ist HDMI sehr einfach. Kann man Audio noch mit auf die MicroHDMO Buchse legen und dann per "Spezial-Y-kabel" dort abgreifen? Auf HDMI liegt kein analoges Audio. Ich kann da also nichts "drauflegen". Es könnte aber sein, dass man einen Audiostream digital per HDMI übertragen kann mit dem Board. HDMI unterstützt das zumindest. Ich habe von Leuten gelesen, die das mit ähnlichen Boards versucht haben. Eine eindeutige Aussage konnte ich aber auf die schnelle nicht finden. Also Kurzfassung: Es kann sein, dass digitales Audio Out doch nach draußen gelegt wird. Analoges Out oder In wird dieses Design aber nicht haben. Im Zweifelsfall müsste dann eine USB Soundkarte genutzt werden. Es ist auch in dem Blogeintrag von "General purpose connector" für Flachbandkabel die Rede. Was für Signale werden denn da ausgegeben ? Da liegen Signale für den Anschluss von Kamera-Sensor-ICs drauf (ähnlich wie die Cam beim Raspberry). Das ist im wesentlichen 5V, 3.3V, I2C, UART, und SPI. Wie gesagt, geplant ist da noch nichts mit. Es ist erstmal nur "da". Für ein geeignetes Board hätte man doch vermutlich auch eine TinkerForge-Erweiterung entwickeln können, oder? Das hätte man tun können. Vorteil wäre gewesen, dass das Entwicklungs-Risiko minimiert würde. Nachteilig wäre die Abhängigkeit von diesem Board gewesen (was wenn der Hersteller dieses einstellt?) und das es nicht wirklich im Baukastensystem integriert wäre. Doch welches Board wäre hier ein möglicher Kandidat gewesen? Prinzipiell könnte man jedes Board nutzen welches eine SPI Schnittstelle und 8 GPIOs besitzt. Rasyberry Pi, Beagle Bone etc. wären alles Kandidaten. Den vorläufigen Schaltplan könnt ihr übrigens hier im PDF-Format finden: link Zitieren
Nic Geschrieben February 28, 2014 at 09:37 Geschrieben February 28, 2014 at 09:37 ...Ich sehe durchaus Anwendungen in denen man ein Touchpad anschließen möchte. Und das ist HDMI sehr einfach. Was ist damit gemeint ? Touchpad ? Soll das ein TFT-Display mit Touchscreen http://www.reichelt.de/Touchdisplays/FAYTECH-T7-SW/3/index.html?&ACTION=3&LA=2&ARTICLE=87444&GROUPID=6219&artnr=FAYTECH+T7+SW sein, der per HDMI am RED angeschlossen werden könnte, allerdings werden die Touch-Signale i.d.R. via USB oder Seriell an den PC übertragen. ...Mit einem USB-Wifi-Stick kann man leider nicht so einfach einen Access Point aufbauen. Diesbezgl. bin ich nicht der Experte, aber wie sieht es in der Praxis aus ? Wenn erstmal die WIFI-Ext. aus SPI-Treiber Gründen erstmal nicht ansteht, wie sicher ist die WIFI Komptabilität der Sticks, die es auf dem Markt gibt. Es muss zumindest eine Möglichkeit der Kommunikation zw. dezentralen Stacks geben. Zitieren
batti Geschrieben February 28, 2014 at 10:47 Geschrieben February 28, 2014 at 10:47 Was ist damit gemeint ? Touchpad ? Soll das ein TFT-Display mit Touchscreen Mein Fehler, korrekt. Ich meinte ein Display mit Touchscreen. Beim Raspberry Pi machen es die Leute z.B. so, dass sie das Display per HDMI und den Touchscreen per USB anschließen. Diesbezgl. bin ich nicht der Experte, aber wie sieht es in der Praxis aus ? Wenn erstmal die WIFI-Ext. aus SPI-Treiber Gründen erstmal nicht ansteht, wie sicher ist die WIFI Komptabilität der Sticks, die es auf dem Markt gibt. Es muss zumindest eine Möglichkeit der Kommunikation zw. dezentralen Stacks geben. Das ist noch eine der Hausaufgaben. Zitieren
pluto Geschrieben February 28, 2014 at 13:31 Geschrieben February 28, 2014 at 13:31 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. Nun, beim TCP habt ihr es ja auch geschafft, ein Interface zu Entwickeln. Richtig? Also ihr habt ein Server und jetzt mehrere Clients die von verschiedenen Sprachen aus genutzt werden können. So ähnlich könntet ihr es auch in diesen Fall machen: 1. Ihr habt ein Brick wo ein Binärer Code ausgeführt wird. Der ist immer gleich. 2. Nun müsstet ihr "nur" noch für verschiedene Sprachen ein Übersetzter haben. Wisst ihr wie ich meine? Angenommen. ich möchte in Pascal schreiben, dann muss der pascal Soruce-Code in das Binäre Format übersetzt werden. Angenommen ich möchte in C Schreiben, genau das gleiche Spiel. Das habe ich mit Arduino vor. Ich finde die Sprache Grauenvoll. Also dachte ich mir: Versuche ich doch mal bei Gelegenheit ein Umwandler zuschreiben. Ihr habt doch schon mit den Code-Generatoren eine gute Grundlage. Der Vorteil ist einfach, der Preis ist deutlich Geringer als bei euer Vorgenschlagenden Variante. Selbst wenn ihr ein paar EEProms verbaut. Die kosten bei Reichelt z.b. gar nicht viel. Da ihr bestimmt in Größeren Mengen einkauft als ich, dürftet ihr sogar noch einen Mengen Rabat bekommen. Ich weiß jetzt nicht wie das mit dem RAM aussieht. Aber ich würde trotzdem behaupten, dass wäre die Sinnvollste Möglichkeit. Zitieren
photron Geschrieben February 28, 2014 at 13:51 Geschrieben February 28, 2014 at 13:51 pluto, das ist viel schwerer als du dir das vorstellst und von der Komplexität nicht vergleichbar mit den Bindings-Generatoren. Du schlägst im Prinzip vor C/C++, C#, Delphi, Java, Perl, PHP, Python, Ruby, Shell und VB.NET Compiler zu schreiben die Code erzeugen, der auf dem Brick direkt ausgeführt werden kann. Die technischen Details der exakten Ausführung diese Unterfangens sollen hier mal unter den Tisch fallen. Für C gibt es das schon, so schreiben wir ja die Firmwares, aber für alle anderen Sprachen ist das sehr sehr viel Aufwand, wenn es überhaupt sinnvoll möglich ist. Da ist es viel einfacher und überschaubarer ein RED Brick nach jetzigem Plan zu machen, auf dem man dann all die existierende Infrastruktur für alle unterstützten Sprachen einfach weiter nutzen kann. Zitieren
Nic Geschrieben February 28, 2014 at 15:19 Geschrieben February 28, 2014 at 15:19 @TF: Habt ihr schon einen Favouriten für die Linux-Distro ? Ev. kann man sich mal eine VM anlegen und damit warm werden . Manjaro soll z.B. besonders benutzerfreundlich sein und die Netbook edition ideal für kleine Display: http://www.heise.de/open/artikel/Anwenderfreundliches-Arch-Linux-Manjaro-Linux-0-8-9-2122579.html Zitieren
Loetkolben Geschrieben February 28, 2014 at 16:02 Geschrieben February 28, 2014 at 16:02 Hallo zusammen, sollte man mal eine Liste der "gewuenschten" Pakete machen oder wie wird der normales OS Tool-Krams unterstuetzt? Viele Gruesse Der Loetkolben Zitieren
pluto Geschrieben February 28, 2014 at 17:07 Geschrieben February 28, 2014 at 17:07 Mir geht es eben um den Hohen Preis von ca 100€. Für kleine Projekt ist das einfach viel zu Hoch. Eine andere Frage wäre da noch: Welche Anwendungen Stellt ihr euch für diese Platine vor? Zitieren
pluto Geschrieben February 28, 2014 at 17:11 Geschrieben February 28, 2014 at 17:11 Ach ja: Und ein eigene Interpreter müsst ihr auch nicht schreiben. Im Prinzip müsst ihr ja nur die Syntax übersetzten. Z.B. Statt begin ein { draus machen. Wir reden hier von ganz einfachem Code, wie der vom Arduino. Also bräuchtet ihr "nur" entsprechende Tabellen. Zitieren
benatweb Geschrieben February 28, 2014 at 17:38 Geschrieben February 28, 2014 at 17:38 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. Zitieren
Loetkolben Geschrieben February 28, 2014 at 17:50 Geschrieben February 28, 2014 at 17:50 Um mal hier den Graben, der zwar nicht gross ist aber doch vorhanden ist, zuzuschuetten moechte ich mal folgendes anregen: Der RED ist nunmal "teuer". :'( Fuer die "Zielgruppe" und die Moeglichkeiten die er bietet passt der Preis wohl. Wie ich das hier aber sehe, sind viele Hobbyisten doch ein wenig enttaeuscht. Gerade wenn man schon einen Raspberry Pi hat ist die Anschaffung eines RED doppelt "schmerzhaft". Egal wie schoen er auch ist. Deshalb moechte ich folgendes anregen: Tinkerforge moege doch bitte neben dem RED ein einfaches, aber intelligent gestaltetes, Aufsteckboard fuer den Raspberry Pi machen. Vielleicht nur ein mechanicher Adapter fuer den Stack der noch 5 Volt durchleitet. Vielleicht auch noch ein oder zwei Features und gut sollte es sein. Vielleicht kommt dann auch die Freude bei all denen zurueck die am Anschaffungswiderstand des RED scheitern. Der Loetkolben Zitieren
pluto Geschrieben February 28, 2014 at 18:10 Geschrieben February 28, 2014 at 18:10 Tinkerforge moege doch bitte neben dem RED ein einfaches, aber intelligent gestaltetes, Aufsteckboard fuer den Raspberry Pi machen. Vielleicht nur ein mechanicher Adapter fuer den Stack der noch 5 Volt durchleitet. Vielleicht auch noch ein oder zwei Features und gut sollte es sein. Das wäre doch mal eine Gute Idee. Adapter für den PI und für Arduino. Zitieren
benatweb Geschrieben February 28, 2014 at 21:53 Geschrieben February 28, 2014 at 21:53 Tinkerforge moege doch bitte neben dem RED ein einfaches, aber intelligent gestaltetes, Aufsteckboard fuer den Raspberry Pi machen. Vielleicht nur ein mechanicher Adapter fuer den Stack der noch 5 Volt durchleitet. Vielleicht auch noch ein oder zwei Features und gut sollte es sein. 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? Zitieren
pluto Geschrieben March 1, 2014 at 13:11 Geschrieben March 1, 2014 at 13:11 Ach ja: Nebenbei gesagt: Tinkerforge Projekte laufen trotzdem nicht eigenständig. Ein PC bleibt ein PC. Egal wie groß der auch sein mag. Zu Behaupten das die Projekte dann eigenständig sind, ist Falsch. Das Thema lautet ja: "Standalone/OnDevice". Eine Lösung ist das jedenfalls nicht. Zitieren
borg Geschrieben March 1, 2014 at 13:41 Autor Geschrieben March 1, 2014 at 13:41 @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? Der SPI Treiber ist noch nicht geschrieben, ist also schwer zu sagen wie portabel er ist . Die Vorteile eines RPi-Shields gegenüber einem USB Kabel sind marginal, das macht nicht viel Sinn. Da wäre schon eher eine Art Halteplatte Sinnvoll wo man das RPi sowie Bricks/Bricklets befestigen kann. Ach ja: Nebenbei gesagt: Tinkerforge Projekte laufen trotzdem nicht eigenständig. Ein PC bleibt ein PC. Egal wie groß der auch sein mag. Zu Behaupten das die Projekte dann eigenständig sind, ist Falsch. Das Thema lautet ja: "Standalone/OnDevice". Eine Lösung ist das jedenfalls nicht. Naja, das ist jetzt Ansichtssache. Wir schaffen mit dem RED Brick das, was mit großem Abstand am meisten angefragt wird bei uns: Eine Möglichkeit das Java/C#/PHP/Python/etc Programm in den Stack zu bekommen. Warum ist es dann nicht eigenständig, nur weil ein Linux darauf läuft? Zitieren
pluto Geschrieben March 1, 2014 at 14:03 Geschrieben March 1, 2014 at 14:03 Ganz einfach: Die Leistung vom Brick ist einfach viel zu Viel. Ein atMega ist für mich eigenständig. Da die Leistung hier deutlich geringer ist. Bei den Geplanten RED Brick ist die Leistung aber mit dem eines PC vergleichbar. Zur Leistung zählt zum einen die CPU und zum anderen auch der Verbaute RAM. Wäre es nicht Sinnvoller auf was Fertiges zu setzten? Da die Stückzahlen einfach höher sind. Eine Ganz Wichtige Frage habe ich noch: Was für Anwendungen sind damit Umsetzbar, die NICHT mit einem PI, oder ähnlichem umgesetzt werden könnte? Klar ist es verlockend ein eigenen Mini-PC zu entwickeln. Aber ist es wirklich notwendig? Schaut euch mal das Cubiebord an, da bekomme ich sogar zwei CPU'S und habe noch ein VGA Ausgang. Den es beim PI leider nicht gibt. Wird es dann sowas beim RED brick geben? Ich halte VGA für extrem Wichtig. Gerade in Schulen. Wo viele Monitor noch aus der "Steinzeit" stammen. Zitieren
benatweb Geschrieben March 1, 2014 at 14:08 Geschrieben March 1, 2014 at 14:08 Der SPI Treiber ist noch nicht geschrieben, ist also schwer zu sagen wie portabel er ist . Die Vorteile eines RPi-Shields gegenüber einem USB Kabel sind marginal, das macht nicht viel Sinn. Da wäre schon eher eine Art Halteplatte Sinnvoll wo man das RPi sowie Bricks/Bricklets befestigen kann. 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. Zitieren
Equinox Geschrieben March 1, 2014 at 14:33 Geschrieben March 1, 2014 at 14:33 Warum ist es dann nicht eigenständig, nur weil ein Linux darauf läuft? Ganz einfach: Die Leistung vom Brick ist einfach viel zu Viel. Ein atMega ist für mich eigenständig. Da die Leistung hier deutlich geringer ist. Bei den Geplanten RED Brick ist die Leistung aber mit dem eines PC vergleichbar. Zur Leistung zählt zum einen die CPU und zum anderen auch der Verbaute RAM. Ich verstehe nur Bahnhof Was hat denn "Eigenständigkeit" mit der Leistung zu tun und vor allem, warum ist zuviel Leistung schlecht für die Eigenständigkeit? Abgesehen davon, dass mehr Leistung nie schadet, ist es gerade für die den standalone-Betrieb ein Vorteil. Also ich verstehe dein Problem nicht. Zitieren
borg Geschrieben March 1, 2014 at 14:47 Autor Geschrieben March 1, 2014 at 14:47 @pluto: Vielleicht einmal ganz vorn vorne: Wir haben ein System mit dem man einfach mit vielen Programmiersprachen ohne Erfahrung in der embedded-Programmierung oder von Hardwareentwicklung mit der Umwelt interagieren kann. Jetzt gibt es das verständliche Bedürfnis dieses System "Standalone" zu betreiben. Dieses System ist aber technisch nicht auf einem atmega und auch nicht auf den viel Leistungsstärkeren Cortex-M3 die wir verwenden implementierbar. Nun haben wir für Sandalone-Lösungen immer auf das RPi/BeagleBaord/CubieBoard/etc verwiesen und wir bekommen immer wieder gesagt dass dies zu kompliziert ist. Mit dem RED Brick werden wir nun eine Möglichkeit bieten ein auf dem PC programmiertes und getestetes Programm auf ein Modul zu bringen welches man in den Stack steckt. Dies wird in 90% der Fälle ohne jegliche Kenntnisse von Linux-Konfiguration oder ähnlichem möglich sein. Die Tatsache das ein Linux auf dem RED Brick läuft ist nahezu irrelevant. Ich hätte auch noch eine Metapher anzubieten : Ich kann hergehen und mir mit dem RPi eine Funksteckdose bauen die ich per Webbrowser bedienen kann: http://www.openhomeautomation.net/control-a-relay-from-anywhere-using-the-raspberry-pi/ Oder ich kann eine fertige Funksteckdose nehmen die genau das tut: http://www.amazon.de/Belkin-WeMo-Automation-Switch-Android-Ger%C3%A4te/dp/B008TPVZNY Technisch sind die beiden fast gleich. Sowohl auf der WeMo Funksteckdose als auch auf dem RPi läuft ein Linux mit Webserver und einem kleinen einfachem Steuerprogramm. Dadurch verliert die Steckdose aber nicht ihre Daseinsberechtigung . Das RED Brick ist eben nicht "yet another development board", auch wenn es technisch sehr ähnlich ist. Zitieren
SierraX Geschrieben March 3, 2014 at 09:44 Geschrieben March 3, 2014 at 09:44 Hab das jetzt nicht alle Antworten durchgelesen... Eine Idee die ich noch so hätte wäre an Stelle eins eigenen Devices, ein BeagleBone Black Shield zu bauen (wahrscheinlich schon von 1oo anderen Geeks gekommen)... Würde mir fast noch mehr zusagen, als die Variante 1. Zitieren
pluto Geschrieben March 3, 2014 at 14:15 Geschrieben March 3, 2014 at 14:15 Nun haben wir für Sandalone-Lösungen immer auf das RPi/BeagleBaord/CubieBoard/etc verwiesen und wir bekommen immer wieder gesagt dass dies zu kompliziert ist. Warum ist das zu Kompliziert? Einfacher geht es doch fast gar nicht mehr. Mit dem RED Brick werden wir nun eine Möglichkeit bieten ein auf dem PC programmiertes und getestetes Programm auf ein Modul zu bringen welches man in den Stack steckt. Dies wird in 90% der Fälle ohne jegliche Kenntnisse von Linux-Konfiguration oder ähnlichem möglich sein. Die Tatsache das ein Linux auf dem RED Brick läuft ist nahezu irrelevant. Finde ich nicht. Ein Linux mag auf viele System drauf sein, z.b. DVD Player, Fernseher und soweiter. Aber ich meine, Die Bricks sollen doch Eigenständig laufen. Eigenständig laufen sie aber nicht, wenn da ein Mini PC im Hintergrund die Fehden Zieht. Ich kann hergehen und mir mit dem RPi eine Funksteckdose bauen die ich per Webbrowser bedienen kann: Ja, ich kann auch mit Kanonen auf Spatzen schießen oder ein Schalter für den PI bauen, der ca 20 € kostet. Fast halb zu viel für den PI. Oder ich kann eine fertige Funksteckdose nehmen die genau das tut: Guter Vergleich. Kosten beide in etwa gleich viel... Das RED Brick ist eben nicht "yet another development board", auch wenn es technisch sehr ähnlich ist. Was mir auch noch unklar ist, ist zum einen die Zielgruppe und zum anderen die Anwendungen. Aber zum Glück hat man ja die Wahl. Ich würde jedenfalls den PI vorziehen. Einfach weil es Günstiger ist. Selbst als Bündel. Kostet der gerade mal halb zu viel wie das geplante RED Brick. Eine Idee die ich noch so hätte wäre an Stelle eins eigenen Devices, ein BeagleBone Black Shield zu bauen (wahrscheinlich schon von 1oo anderen Geeks gekommen).. Das wurde bereits von jemanden vorgeschlagen, jedoch für den PI. Ich denke aber auch, solche Adapter wären bestimmt Sinnvoll. Also, versteht mich nicht falsch. Ich schätze die Bricks. Gerade die Einfachheit. Ich befasse mich aber aus drei Gründen immer mehr mit Arduino. 1. Mit Tinkerforge kann man eben nicht alles machen. z .b. ein USB IR Adapter. Habe ich versucht, geht nicht. Weil die Bricks dafür nicht ausgelegt sind. Nur als Beispiel. 2. Weil die Bricks doch Eingeschränkt sind. Ändert sich das mit dem RED Brick? Z.B. wenn ich fünft Bricks an den Masterbrick anschließen möchte, muss ich gleich wieder 30€ hinlegen für ein masterBrick. Ein Arudino Uno kostet etwa genau so viel. 3. Kostenpunkt. Aber im allgemein, nutzte ich Tinkerforge schon gerne. Ich erwähne es auch öfter... Keine Frage. Aber ich denke, dass RED Brick ist einfach übertrieben. Aus meiner Sicht. Aber wie schon gesagt, man hat ja die Wahl. Man kann ja immer noch ein anderen Mini PC nutzen. Mit etwas mehr Aufwand. Auch für Schulen wird der Punkt gerade Wichtig sein. Für die ist das einfach zu Teuer, 100€ für ein Brick auszugeben. Sie brauchen ja nicht nur einen sondern schon ein paar mehr. Zitieren
derAngler Geschrieben March 3, 2014 at 14:42 Geschrieben March 3, 2014 at 14:42 @Pluto Ich kann dich nicht ganz verstehen, du meckerst die ganze Zeit über den geplanten RED und erzählst hier einen von wegen nicht eigenständig wegen Linux ... alles Quatsch meiner Meinung nach. Erstens zwingt dich ja keiner den RED zu kaufen, nimm stattdessen einen Raspi und gut ist - warum solche Aufregung? Zweitens ist deine Logik irgendwie seltsam, warum sollte ein RED nicht eigenständig sein nur weil ein Linux drauf läuft? Irgendeine Art OS muss(!) darauf laufen, sonst wirds nix mit Eigenständigkeit .... keine Software = dummer Chip. Insofern ist die Entscheidung für eine debian-Linux nur richtig und gut. Drittens war der Vergleich von TF bezüglich Steckdose mit Raspi/WeMo richtig gut, anscheinend hast du ihn aber nicht verstanden. Viertens die Zielgruppe. Natürlich gibt es eine, auch wenn ich selbst nicht dazu gehöre (zu teuer), so hat der RED alleine schon wegen seine Größe und dem Stromverbauch einen echten Vorteil gegenüber den anderen Lösungen. @allgemeine Shields Ich lese immer mal wieder davon das der ein oder andere sich ein Ardunio/BeagleBone Shield wünscht. Das würde ich nicht machen, ich gehe stark davon aus das 75% der mit TF genutzten PC's Raspberry Pi's sind. Der Preis ist unschlagbar und die Community ist riesig, dazu kann ich mit einem Raspberry Pi als Anfänger wesentlich schneller zu Ergebnissen kommen, als mit einem Ardunio. Deswegen würde ich zu aller erst, noch vor dem RED-Brick und Shields für Ardunio/BeagleBone, eine Erweiterung für den Pi anbieten - gerade im Hinblick auf Schulen. 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.