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.
:
Bearbeitet durch User
> 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.
> Das SD-Schrotten beim Raspberry ist ja bekannt
Nur bei Fehlkonfiguration oder wenn man Software nutzt, die für SD
Karten ungeeignet ist.
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.