Hallo zusammen
Ich bin zurzeit daran eines meiner nächsten Projekte zu planen oder
Ideen dafür zu sammeln. Dabei ist auch die Frage nach der Plattform
aufgekommen. Bisher habe ich bei meinen embedded-Projekten
ausschliesslich mit Atmel AVR (Atmega) gearbeitet, programmiert in C.
Bei meinem nächsten Projekt (eine Wetterstation mit Internet-Zugang,
Farbdisplay etc.) werde ich ein wenig mehr Features ((W)LAN, USB,
Farbdisplay, Touch) brauchen, darum stellt sich mir die Frage nach der
Zielplattform und habe mir folgende Gedanken dazu gemacht.
Folgende Annahmen oder Vorbedingunen gelten:
-keine Massenfertigung (also keine economy of scale) und Stückpreise
auch zu verbachlässigen
-Arbeitszeit ist gratis bzw. "Lernzeit"
Gedanken ARM:
-perfekte Anpassung an den Zweck möglich, einfache Anpassung an den
Zweck
-eingeschränkte Auswahl der Programmiersprache
-Nur diese Applikation läuft: Keine Update-Notifications welche ich ohne
Eingabegerät (bzw. Tastatur) nicht behandeln könnte
Gedanken rPI:
-Einfachere Entwicklung: Einfach ein Programm mit wenig Hardware-Bezug
-Freie Wahl der Programmiersprache: C, Java, C++, Websprachen (PHP,
JavaScript), Python
Ich denke der Hauptnachteil des raspberry pi ist das Handling der
Software: Das Programm ist eben wirklich nur eines von vielen das am
Laufen ist und wenn irgend ein anderes Programm gerade aus Freude einen
Dialog vor meinem Fenster platziert habe ich eben Pech bis ich eben Zeit
hatte eine Tastatur anzuschliessen (oder per SSH zuzugreifen). Auch
müsste ich um das Programm beim Start zu starten mit Startskripten o.Ä.
hantieren.
Der Nachteil des ARM ist aber halt eben, dass man sich um Sachen wie
Netzwerkkommunikation etc. noch selber kümmern muss und von irgendwo
eine Library defür braucht.
Dafür ist es kein Problem, einen Taster hinzuzufügen der das ganze Board
sauber neu startet etc (man ist halt sehr nah an der Hardware).
Noch zum ARM-Board: Ich kenne mich in der Welt noch nicht wirklich aus,
habe jetzt aber in Richtung eines Cortex M3 von NXP geschielt: Es gibt
auf ebay für 100$ fertige dev-Boards mit Touchscreen und allem und NXP
legt erst noch für jeden Käufer eine gratis Version von emWIN bei um das
GUI zu bauen (hat jemand Erfahrung damit?)
Über eure Meinungen würde ich mich sehr freuen
Lisa
Erstaunlicher Weise ist der RPi auch nicht mehr, als ein großer ARM mit
Hühnerfutter drum rum.
Lisa schrieb:> und wenn irgend ein anderes Programm gerade aus Freude einen> Dialog vor meinem Fenster platziert habe ich eben Pech bis ich eben Zeit> hatte eine Tastatur anzuschliessen
Es ist ein Multiuser+Multitaking System.
Also nein: Das Problem ist beherrschbar.
Lisa schrieb:> Ich denke der Hauptnachteil des raspberry pi ist das Handling der> Software: Das Programm ist eben wirklich nur eines von vielen das am> Laufen ist und wenn irgend ein anderes Programm gerade aus Freude einen> Dialog vor meinem Fenster platziert habe ich eben Pech bis ich eben Zeit> hatte eine Tastatur anzuschliessen (oder per SSH zuzugreifen). Auch> müsste ich um das Programm beim Start zu starten mit Startskripten o.Ä.> hantieren.
Naja auf dem PI läuft ja nur Linux Programme die du nicht brauchst
kannst du Deinstallieren oder einfach nicht starten, dann nerven sie
auch nicht für die Bedingung gibt es auch Möglichkeiten z.b.
Tastatur/Maus Emu per Handy/Tablett übers Netzwerk.
Hab sowas hier selber laufen allerdings ohne PI und ohne Grafisches
Frontend mache fast alles per Bash/PHP, das was du machen solltest ist
dir erstmal ne Anforderungsliste schreiben was du alles brauchst und
dann dementsprechend das Board aussuchen, auch die TFT/LCD göße ist da
wichtig beim PI z.b. gehen nur kleine Displays oder welche die mit HDMI
um können, ärgerlich ist es immer wen man ein Dev-Board hat wo hinterher
was nicht geht weil man sich nicht überlegt hat das man es braucht.
Lisa schrieb:> Gedanken ARM:> -perfekte Anpassung an den Zweck möglich, einfache Anpassung an den> Zweck
Einfach würde ich nicht sagen, denn für jede Hardware, die man nutzen
möchte, muss man sich selbst um einen Treiber kümmern. Wenn da USB und
WLAN ins Spiel kommt, wird kompliziert. Beim RPi sind die passenden
Treiber quasi einfach da.
> Ich denke der Hauptnachteil des raspberry pi ist das Handling der> Software: Das Programm ist eben wirklich nur eines von vielen das am> Laufen ist und wenn irgend ein anderes Programm gerade aus Freude einen> Dialog vor meinem Fenster platziert habe ich eben Pech bis ich eben Zeit> hatte eine Tastatur anzuschliessen (oder per SSH zuzugreifen).
Wenn du nicht willst, daß "irgend ein anderes Programm" was anzeigt,
dann starte dieses eben nicht. Du hast das auch auf dem RPi selbst in
der Hand.
> Auch müsste ich um das Programm beim Start zu starten mit Startskripten> o.Ä. hantieren.
Ja, und? Das ist nun nicht gerade Raketentechnik.
> Noch zum ARM-Board:
Der RPi ist übrigens auch nix anderes als ein ARM-Board.
Lisa schrieb:> Bei meinem nächsten Projekt (eine Wetterstation mit Internet-Zugang,> Farbdisplay etc.) werde ich ein wenig mehr Features ((W)LAN, USB,> Farbdisplay, Touch) brauchen, darum stellt sich mir die Frage nach der> Zielplattform und habe mir folgende Gedanken dazu gemacht.> Gedanken rPI:> -Einfachere Entwicklung: Einfach ein Programm mit wenig Hardware-Bezug> -Freie Wahl der Programmiersprache: C, Java, C++, Websprachen (PHP,> JavaScript), Python> Ich denke der Hauptnachteil des raspberry pi ist das Handling der> Software: Das Programm ist eben wirklich nur eines von vielen das am> Laufen ist
Wie von Ulrich F. beschrieben - kein Mensch zwingt Dich, da einen
XServer drauf zu starten. Du kannst auch einfach eine Anwendung gegen
DirectFB o.ä. schreiben und trotzdem Qt nutzen.
Meine persönliche Empfehlung: RPi nehmen. Die Hardware-Abstraktion des
Linux-Kernels wird Dir bei Deinen gewünschten Features (WLAN, USB,...)
viel Arbeit abnehmen. Und mit Python und PyQt unter X11 hast du Ruckzuck
einen Prototypen zusammen (PySerial, Sockets, XML, BeautifulSoup (SOAP))
- die Zeit zu opfern, alles from Scratch neu zu schreiben würde Dir zwar
sicher viel Lerneffekte geben, aber die Wahrscheinlichkeit, dass es nix
wird, sehr erhöhen.
Hallo,
für mich ist bei solchen Projekten immer der Endzweck das Problem...
Wetterstation: Temperatur, Luftdruck, rel. Feuchte, Regenmenge?
Windrichtung? Windstärke?
Die Fragezeichen kommen daher, daß ich keine praktische Verwendung dafür
hätte. Um rasuzufinden, ob es regnet und wie windig es ist, reicht mir
der Blick aus dem Fenster.
Ich habe vor Jahren ein paar Sensoren gebaut, die laufen heute noch.
http://www.avr.roehres-home.de/
Da schau ich auch mal rauf, wenn ich wissen will, wie kalt es draußen
ist.
Grund war, daß ich mit den damals neuen RFM-Modulen rumspielen wollte,
die FOST02 und HP03S kaman damals auch gerade billg auf den Markt.
Der AVR-Webserver wurde irgendwann durch einen RasPi ersetzt, Webserver
drauf und MySQL. Ein paar Scripte und die Daten waren in der Datenbank.
Eine php-Grafikbibliothek dazu und ich konnte (theoretisch) den
Temperaturverlauf des letzten Tages, Monats usw. darstellen.
Theoretisch, weil ich es nie gemacht habe, wozu auch?
Letztens war der RasPi nicht mehr erreichbar, nachgeschaut und
festgestellt, daß meine Testscripte in den 2 Jahren das Dateisystem der
SD-Card geschrottet hatten. Naja, war meine eigene Schuld.
Nun hängt im Moment wieder der AVR-Webserver dran...
Ich habe überlegt, ob ich alles mal umbaue, nur des Umbaus wegen.
Probleme dabei: eine wirkliche Alternative zu meinen Sensoren mit den
RFM-Modulen, Stabilität über die Jahre, Stromverbrauch usw. sind mit für
mich üblichen Mitteln nicht anders zu erreichen.
Ins Auge gefaßt habe ich da im Moment also eine 433MHz-WLAN-Bridge mit
dem ESP8266. Entweder mit einem AVR dazwischen oder direkt auf dem
ESP8266.
Der RasPi könnte dann im LAN das Datensammeln übernehmen, wozu auch
immer.
Da müßte ich noch eine 868MHz-WLAN-Bridge bauen (oder beide Empfänger an
den ESP hängen), da senden meine Energiemeß-Steckdosen und irgendjemand
hat das Protokoll doch wirklich auseinandergenommen.
Ein altes 7" Androind-Tablett liegt auch noch rum, also Dauerstrom ran,
das Ding elegant an die Wand gehängt und ich hätte das Anzeige- und
Bedienfeld.
Der RasPi macht auch unter Linux (nicht meie stärkste Seite...) nur, was
er soll. Die Anbindung zum "Display" wäre dann wieder nur eine reine
Web-Anbindung, die ich bei Freigabe nach außen natürlich auch überall
per Browser aufrufen könnte.
Wie am Anfang gesagt: ich habe für all das keine wirkliche Anwendung, es
ist und bleibt Hobby, damit ich auf meine "alten Tage" nicht ganz
einroste.
Gruß aus Berlin
Michael
Falk S. schrieb:> Wie von Ulrich F. beschrieben - kein Mensch zwingt Dich, da einen> XServer drauf zu starten. Du kannst auch einfach eine Anwendung gegen> DirectFB o.ä. schreiben und trotzdem Qt nutzen.
Auch mit X-Server ist es kein Problem. Der macht selber schließlich
keine Fenster auf. Man muß ja außer diesem und dem gewünschten Programm
nix anderes graphisches starten. Selbst den Windowmanager kann man
weglassen.
Rolf M. schrieb:> Auch mit X-Server ist es kein Problem. Der macht selber schließlich> keine Fenster auf. Man muß ja außer diesem und dem gewünschten Programm> nix anderes graphisches starten. Selbst den Windowmanager kann man> weglassen.
Ist aber deswegen nicht falsch, wollte nur skizzieren, dass der X-Server
keine Zwangsvoraussetzung zur Verwendung von GUI ist.
Lisa schrieb:> Bei meinem nächsten Projekt (eine Wetterstation mit Internet-Zugang,> Farbdisplay etc.) werde ich ein wenig mehr Features ((W)LAN, USB,> Farbdisplay, Touch) brauchen,
Denke nochmal nach, was das Ding eigentlich sein sollte und können
sollte. So wie du es schriebest, ist das also eine Kiste, die an der
Wand hängt, ein Farbgrafik-Display mit Touch auf der Vorderseite hat und
dort die Wetterdaten aus deinem Vorgarten anzeigt, die du per Draht oder
sonstwie dort hineinleitest. Obendrein soll es am Internet hängen, also
vermutlich dein privater Internet-Server sein, der dir deine Wetterdaten
auch dann liefert, wenn du grad in Honolulu bist und dein smartes Phone
zückst. Ist das so etwa das, was du dir vorstellst?
Nun, ein Raspberry hat erstmal so gut wie keine echte Peripherie zum
Einsammeln von Wetterdaten. Du müßtest dir also zuerst einen µC basteln,
der die eigentliche Arbeit macht und dann die vorgekäuten Daten per
seriell oder sonstwie in den Raspberry hineinlöffelt.
Als nächstes wäre da der Bildschirm: bei meinem Raspberry ist da nur
eine HDMI-Buchse dran und das war's erstmal. Dort kriegst du ohne
Verrenkung kein Display dran, es sei denn, du willst einen ganzen
Monitor an die Wand hängen.
Für mich wäre da die Alternative, von Toradex ein Colibri oder von F+S
ein ArmStone oder so zu kaufen (ne ältere Variante gibt's derzeit bei
Pollin für ca. 10 Euro) und damit die Freiheit zu haben, WinCE oder
Linux drauf zu fahren - und beides gibt's von den jeweiligen Herstellern
fertig und industrietauglich und mit direktem Anschluß für TFT-Display.
Das SD-Schrotten beim Raspberry ist ja bekannt, sowas würde ich gewiß
nicht als Server im Inet nehmen wollen.
W.S.
W.S. schrieb:> Als nächstes wäre da der Bildschirm: bei meinem Raspberry ist da nur> eine HDMI-Buchse dran und das war's erstmal.
Nein. Der Raspi hat neben HDMI und FBAS auch einen DSI-Port für ein
Display. Und das gibt es auch als Originalzubehör zu kaufen:
http://www.heise.de/newsticker/meldung/7-Zoll-Touch-Display-fuer-Raspberry-Pi-ab-sofort-erhaeltlich-2808183.html
Es gibt aber auch Displays, die schon direkt einen HDMI- oder
DVI-Anschluss haben. Die kann man ebenfalls ganz ohne Verrenkungen
anschließen.
> es sei denn, du willst einen ganzen Monitor an die Wand hängen.
Ich schlage ein Android Tablet mit Webbrowser vor.
Dann funktioniert die lokale Anzeige nach dem gleichen technischen
Prinzip, wie die Remote Anzeige auf dem Smartphone.
Man braucht dann auf dem Raspberry Pi einen Webserver - das kann er ja
auch prima.
W.S. schrieb:> Nun, ein Raspberry hat erstmal so gut wie keine echte Peripherie zum> Einsammeln von Wetterdaten. Du müßtest dir also zuerst einen µC basteln,> der die eigentliche Arbeit macht und dann die vorgekäuten Daten per> seriell oder sonstwie in den Raspberry hineinlöffelt.
XBee-Shield auf /dev/ttyAMA0?
https://www.cooking-hacks.com/documentation/tutorials/xbee-arduino-raspberry-pi-tutorial/> Als nächstes wäre da der Bildschirm: bei meinem Raspberry ist da nur> eine HDMI-Buchse dran und das war's erstmal. Dort kriegst du ohne> Verrenkung kein Display dran, es sei denn, du willst einen ganzen> Monitor an die Wand hängen.
Echt?
https://www.raspberrypi.org/blog/the-eagerly-awaited-raspberry-pi-display/> Für mich wäre da die Alternative, von Toradex ein Colibri oder von F+S> ein ArmStone oder so zu kaufen (ne ältere Variante gibt's derzeit bei> Pollin für ca. 10 Euro) und damit die Freiheit zu haben, WinCE oder> Linux drauf zu fahren - und beides gibt's von den jeweiligen Herstellern> fertig und industrietauglich und mit direktem Anschluß für TFT-Display.> Das SD-Schrotten beim Raspberry ist ja bekannt, sowas würde ich gewiß> nicht als Server im Inet nehmen wollen.
Da gibt's aber viele, die das anders sehen mittlerweile (Server-Housing
mit Raspberrys). Man kann die SD-Karte ReadOnly auch read-only mounten
und Schreibzugriffe auf ein externes Gerät zulassen.
Oder du lässt die ganze Software (Web Browser und den Web Server) auf
einem Android Tablet laufen, das an der Wand hängt. Der kann dann auch
dein weit entferntes Smartphone bedienen.
Die Sensoren bindest du mit Hilfe eines kleinen Atmega Mikrocontroller
an, der per USB, Bluetooth, WLAN oder Ethernet mit dem Android Tablet
kommuniziert. Da gibt es schon fertige Lösungen, die du mit Google
leicht finden kannst.
Stefan U. schrieb:> Oder du lässt die ganze Software (Web Browser und den Web Server) auf> einem Android Tablet laufen, das an der Wand hängt. Der kann dann auch> dein weit entferntes Smartphone bedienen.
Hmm, Präsentation von Geschäftslogik zu trennen ist ein alter Hut und
wird im IoT mit billiger Hardware halt wiederneuerfunden. Ob man
unbedingt sich ein Tablet an die Wand hängen muss mit dem ganzen
Android-Schnulli, der da noch mit dazu ist - mein Fall wär's nicht,
höchstens mit 'nem maßgeschneidertem EmbeddedAndroid. Geht aber imho
schon viel zu weit vom ursprünglichen Vorhaben weg - da ging es sogar um
BareMetal-Arm-Implementierungen für sowas.
> Die Sensoren bindest du mit Hilfe eines kleinen Atmega Mikrocontroller> an, der per USB, Bluetooth, WLAN oder Ethernet mit dem Android Tablet> kommuniziert. Da gibt es schon fertige Lösungen, die du mit Google> leicht finden kannst.
Verschiebt die Komplexität der Gesamtaufgabe nur wieder wo anders hin,
in einen kleinen uC. Kann man mit Bordmitteln am RPi imho genausogut
lösen.
W.S. schrieb:> Nun, ein Raspberry hat erstmal so gut wie keine echte Peripherie zum> Einsammeln von Wetterdaten.
Ein nackter ARM oder AVR hat auch keine Peripherie für Wetterdaten
drauf, ausser vielleicht einem Schätzeisen für die Chip-Temperatur.
Sowohl der ARM als auch der RPi besitzen aber ein paar typische
Schnittstellen zum Anschluss solcher Wetter-Peripherie, wie SPI, I2C und
1-Wire. Beim RPi sind die nötigen Treiber aber schon drin, beim µC noch
nicht.
> Als nächstes wäre da der Bildschirm: bei meinem Raspberry ist da nur> eine HDMI-Buchse dran und das war's erstmal. Dort kriegst du ohne> Verrenkung kein Display dran, es sei denn, du willst einen ganzen> Monitor an die Wand hängen.
Die meisten µCs haben auch kein Display auf dem Chip drauf. Auch da muss
man das erst aussen dranhängen. ;-)
Andererseits gibts einen Haufen an RPIs anschliessbare Displays auf dem
Markt. Mit und ohne Touch, passend zum Formfactor wenn klein genug. Die
werden üblicherweise über SPI angeschlossen, ebenso wie viele
Grafikdisplays von Microcontrollern.
W.S. schrieb:
> Für mich wäre da die Alternative, von Toradex ein Colibri oder von F+S> ein ArmStone oder so zu kaufen
oder ein Beaglebone Black oder...
> Das SD-Schrotten beim Raspberry ist ja bekannt, sowas würde ich gewiß> nicht als Server im Inet nehmen wollen.
Das Problem haben aber alle diese Rechner ganz genauso, letztlich ist
es ja ein Bedienungsfehler und natürlich kann man es bei allen auch
richtig machen.
Na, so langsam wird's abenteuerlich.
Ja, es gibt Leute, die ihren Spaß daran haben, das ganze Haus zu
verkabeln und im Keller einen eigenen Webserver zu betreiben.
Aber hier haben wir mal folgendes als Ausgangspunkt:
Lisa schrieb:> Bisher habe ich bei meinen embedded-Projekten> ausschliesslich mit Atmel AVR (Atmega) gearbeitet, programmiert in C.
W.S.
W.S. schrieb:> und im Keller einen eigenen Webserver zu betreiben.
Hab ich. Aber damals gab es leider keinen RPi. Der wäre dafür weit
besser gewesen als ein AVR mit uIP.
