[Umfrage] Standalone/OnDevice Lösung

[developer]

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

[Martin]

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

 

[borg]

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 .

[batti]

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

 

[Nic]

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

[batti]

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.

[pluto]

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.

[photron]

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.

[Nic]

@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

[Loetkolben]

Hallo zusammen,

 

sollte man mal eine Liste der "gewuenschten" Pakete machen    oder wie wird der normales OS Tool-Krams unterstuetzt?

 

 

Viele Gruesse

 

Der Loetkolben

[pluto]

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?

[pluto]

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.

[benatweb]

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.

[Loetkolben]

 

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

[pluto]

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.

[benatweb]

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?

[pluto]

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.

[borg]

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

 

[pluto]

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.

[benatweb]

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.

[Equinox]

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.

[borg]

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

[SierraX]

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.

[pluto]

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.

[derAngler]

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