Wie im ersten Threat im PS angedacht hier die Frage als eingener Threat: Was macht Ihr den eigentlich so mit dem Grasshopper? Es scheinen sich ja ein paar Leute mit dem Grasshopper zu beschäftigen aber was genau macht Ihr für Projekte? Meine Projekt soll meine PC basierte Lösung zur Messung der Energie-Effizienz meines Hauses ablösen (Laptop mit ATMega8 Karte über RS232). Ich messe damit die Temperaturen meines Heizkessels, meines Speichers, meiner WW-Solaranlage und meiner Komfort-Lüftung. Erweitert werden soll das ganze noch um die Daten von Pumpenlaufzeiten, Stromaufnahme aller EL.-Verbraucher und vielleicht noch um den Volumenstrom der in den Systemen umgewälzt wird. Im Moment speichere ich die Daten ganz stumpf alle paar Minuten in einem grossen Textfile und merke mir die SensorID und das Datum/Uhrzeit. Ausgewertet und visualisiert wird noch nichts. Endziel ist eine Webbasierte Lösung evtl. mit Eingriff in die Steuerung (Lüftung An/Aus, Heizung An/Aus). Also was macht Ihr? Gruss, Axel
Wenn Du den Grasshopper gerade mal eben so rumliegen hast und viel Zeit, Dich darin einzuarbeiten, könnte man ihn für sowas nehmen. Notwendig ist er allerdings nicht. Jeder 8-Bitter wird sich bei dieser Aufgabe schon mächtig langweilen. Interessieren würde mich daher auch, mit welcher Aufgabe andere einen 32-Bitter auchmal wirklich fordern. Ich würde dann aber lieber einen ARM-Cortex nehmen, da scheint ja richtig viel los zu sein (neue Hersteller, neue Chips). Peter
Hoi Peter naja, der Grund warum ich auf den Grasshopper gekommen bin, ist, dass ich ganz passabel im Linux Umfeld zurechtkomme und meine PC Lösung weniger Stromfressend ablösen will. Das der AP7000 Langeweile schiebt kann schon sein. Naja hoffentlich kommt keiner auf die Idee, dass ich den Grasshopper nicht Artgerecht halte ;-) Ein 2.6er Kernel bei so wenig Stromaufnahme und zu dem Preis klang super. Gruss, Axel
Ich häng mich mal dran. Mir gehts ähnlich, der Grasshopper ist als Linuxplattform mit voller gcc und g++ Unterstützung und Multitasking nebst grosser Auswahl an Filesystemen einfach eine Versuchung. Ich bin beruflich Linux-Entwickler, und habe 8051 Erfahrungen von vor 10 Jahren, also durchaus ein paar Oszi-Stunden hinter mir. Mein Plan ist es seit langer Zeit, einmal einen Tripmaster bzw. Motorradcomputer selber zu bauen. Das gibts zwar auch zu kaufen, aber ich würde gerne selber mal was machen. Dafür wäre ein ATMegaXYZ wahrscheinlich dicke ausreichend, aber als ich den Preis für einen Grasshopper geshen habe, bin ich doch ins Grübeln gekommen: was soll ich mit minimalistischer Hardware herumschlagen, wenn ich es dick und fett mit Linux und allem PiPaPo für nen Appel und ein Ei viel bequemer haben kann? Ich hab nur ein bischen Schiss, dass so ein 32Bitter doch eine andere Kampfklasse ist, als das was ich aus meinen ehemaligen 8051 und AVR-Aktivitäten so kenne. Aber die Visualiserung der Fahrdaten ist grafisch natürlich am schönsten. Und da ist kommt die TFT Unterstützung natürlich gerade recht. Ich bin nun nur nicht sicher, ob ich hinsichtlich Echtzeitanforderungen damit glücklich werden würde. Dass so ein Grasshopper als Tripmaster hoffnungslos oversized ist ist mir klar, aber bei dem Stromverbrauch und dem Anschaffungspreis kann ich Anbetrachts meines Linux-Hintergrundes eigentlich kaum anders. Was meinen denn die Grasshopper-Kenner zur Echtzeit-Signalverarbeitung (z.B Drehzahlmesser-Impulse), ist sowas mit einem Grasshopper zu machen? Oder -um beim Threadtjema zu bleiben- hat schon mal etwas in dieser Art damit gemacht ?
> Ich bin beruflich Linux-Entwickler
Dann weißt du doch wie es mit Echtzeitverarbeitung unter Linux bestellt
ist...
Nuja wenn es mit dem Timing nicht geht, wäre es doch auch sicher kein großes Problem, einen kleinen Atmega daneben zu setzen, der über RS232 die Messwerte mundgerecht rüberschiebt...
> Dann weißt du doch wie es mit Echtzeitverarbeitung unter Linux bestellt
ist...
Na eben nicht, jedenfalls nicht auf embedded Plattformen: ich kenne
Linux nur von x84 Rechnern. Sonst würde ich doch nicht fragen.
Linux ist also, wenn ich das richtig interpretiere, per se nicht
Echtzeitfähig?
Sicher kannst Du da ein bisschen präziser werden.
emax schrieb: > Dafür wäre ein ATMegaXYZ wahrscheinlich dicke ausreichend, aber als ich > den Preis für einen Grasshopper geshen habe, bin ich doch ins Grübeln > gekommen: was soll ich mit minimalistischer Hardware herumschlagen, wenn > ich es dick und fett mit Linux und allem PiPaPo für nen Appel und ein Ei > viel bequemer haben kann? Da unterscheiden sich unsere Ansichten wohl etwas. Ich finde 85,-€ nicht gerade preiswert, wenn ich die Aufgabe auch mit nem ATmega für 2,-€ wuppen kann. Ich finde es auch einfacher, sich mit der Hardware direkt "rumzuschlagen" als über den Umweg über das OS. Wenn ich alles über API-Calls mache, statt über IO-Zugriffe, muß ich trotzdem die Hardware kennen, also das Datenbatt lesen bleibt nicht erspart. Ich muß aber noch zusätzlich das API lernen. > Ich hab nur ein bischen Schiss, dass so ein > 32Bitter doch eine andere Kampfklasse ist, als das was ich aus meinen > ehemaligen 8051 und AVR-Aktivitäten so kenne. Ohne ein OS geht 32Bit genauso gut, wie 8Bit. Und wenn man oft 32Bit rechnen muß oder großen Speicher ansprechen, geht 32Bit sogar etwas besser. Ich weiß jetzt nicht, ob der AVR32 auch die schönen und mächtigen Bitbefehle hat, wie der 8051 und der ARM-Cortex. Du mußt daher wohl erstmal die Frage klären, willst Du das OS nutzen mit all seinen Vor- und Nachteilen oder nicht. Peter
Ich arbeite seit einiger Zeit an einem (privaten) Projekt, in dem ich ein kleines Fahrzeug baue, welches durch meine Wohnung fährt. Der AP7000 soll hierbei eine schnellere Funkübertragung (möglichst WLAN) übernehmen. Über sie möchte ich dann die Fahrsteuerung und Kamerabilder übertragen. In etwas fernerer Zukunft wäre dann noch ein wenig Eigenintelligenz für das Fahrzeug geplant. DA im Gegensatz zu meinen Vorgängern hier ein Liunux-Neuling bin, ist der Start leider eher schleppend.
Hoi Peter, Hoi Emax 2€ versus 85€ ist auf der einen Seite richtig und auf der anderen Seite nicht vergleichbar. Mit 2€ hat man weder die Schaltung um den ATMega zu versorgen noch die Support Schaltung zusammen, die ein Drehzahlmesser braucht. Die Frage ist doch, ob man für den Tripmaster wirklich "harte Echtzeitanforderungen" braucht. Für mich mit meiner Heizung war die Visualisierung und die Möglichkeiten, die mir das OS liefern der Grund nicht alles auf Basis eines ATMega zu machen. Es gibt ja zig Boards und Vorschläge wie man das lösen kann. Ich kann meine Sachen einfach auf einem Notebook vorbereiten und das ganze dann auf den Grasshopper rüberspielen, wenn das läuft. Im Moment sind das einfache Bash-Scripte und Perl Progrämchen, die die Daten auslesen. Aber nach und nach werde ich das auf eine X11 like Oberfläche bringen, die auf einem kleinen Screen die Informationen darstellt. Naklar kann man dass auch ohne OS - aber bei mir ist es schlicht ein Zeitproblem. Dirket und Linux habe ich das schon ein paar Mal gemacht - embedded starte ich wieder bei "0" und muss mich erstmal in die Grundlage einarbeiten. Mit meinem ATmega8 Board habe ich das auch schon mal gemacht und mir so einen Logger für One-Wire Sensoren gebaut. Aber vollkommen verstanden habe ich das nicht - Linux benutze ich täglich und es ist mir - völlig subjektiv lieber als direkt auf der Hardware zu arbeiten. Allein bis ich so halb begriffen habe, wie man ein Schieberegister baut - ich bin fast verrückt geworden. Also alles in allem haben wir bisher: - Ein Bord-Compi für Töff (= Motorad auf Schweizerdeutsch) - Ein mobiles autonomes System (@Hans Wurst - schau mal bei der ETH Zürich vorbei - autonumus systems lab - sehr interessant die Jungs ;-) ) Was macht Ihr den sonnst noch so? Peter wofür hast DU den Grasshopper den im Einsatz/Verplant? Gruss, Axel
Eins vorweg: Ich habe keinen Grashopper. Der Grund ist eben die 2€ gegenüber 85€. Ansonsten ist das Teil recht interessant. Für kleinere Projekte verwende ich aber immer noch AVRs (mega/tiny; früher mal 8051). Eine Perepherieanbindung brauche ich beim ATmega/tiny, wie auch bei einem Grashopper; diese Kosten kann ich also nicht rechnen. Ich war auch vor kurzen dabei, eine witterungsgeführte Heizungssteuerung mit AVR(s) zu bauen. Dann hatte ich eine Alternative entdeckt - einen 32bit-Linux-Einplatinenrechner. Nein, keinen Grashopper, sondern einen Router (Kostenpunkt < 15€). Der ist natürlich technisch gesehen auch overkill; vom Preis aber ungeschlagen. Besonders bequem daran ist, dass ich den Kernel nur einmal flaschen musste. Das System selber liegt auf einer SD-Karte vor und kann schnell verändert werden. Die Programme kann ich auch auf meinem PC schreiben und testen. Skripte sogar direkt auf dem Router. Den Stromverbrauch habe ich noch nicht gemessen (muß ich aber mal tun). Was braucht der Grashopper im Normalbetrieb (also wenn er sich fast schon langweilt) und unter Vollast? Christian
> Linux ist also, wenn ich das richtig interpretiere, per se nicht > Echtzeitfähig? echtzeitunterstützung siehe hier: http://rt.wiki.kernel.org/index.php/Main_Page geht ganz gut, aber mit einem avr nicht zu vergleichen.
@Christian Harf: Kannst Du mal nähere Infos/ Links über dein Projekt geben? Welchen Router, Toolchain usw. benutzt du?
Hallo Christian schliesse mich an. Kannst Du mal mehr über Deine Heizungssteuerung verraten? Was misst und regelst Du den so alles? Ach ja - und wie heisst der Router - verwendest Du einen Linksys? Den habe ich noch nie für 15€ gesehen. GRuss, Axel
Bei 15€ für nen Router würd ich mal auf einen Fonera tippen, die gibts für den Kurs und haben auch GPIOs
Das Teil ist noch nicht ganz fertig, läuft aber schon rudimentär. Ich sollte über das Projekt sowieso noch eine Webseite basteln. Zur Zeit fehlt mir aber die Zeit. Hier mal einige Eckdaten: Router: Edimax BR6104K (USB erweitert). Toolchain: Openwrt (Kamikaze) Temperaturmessung über 1-Wire (DS1820) Außensensor ist zur Zeit noch Drahtgebunden, wird aber noch durch Funk ersetzt. Pumpenansteuerung über 1-Wire-IO (DS2408) und Solid-State-Relais (SSR). Drehzahlsteuerung der Solarpumpe über ATtiny25 (per 1-Wire DS2450 angebunden) und S202S12. Da der DS2450 eigentlich ein ADC ist, hängt hier auch noch ein NTC für die Kollektortemperatur dran. Sensorinterface: 1-Wire (DS2490 am USB) und owfs. Programm: komplett in Perl ;-) Also jederzeit mittels integriertem Editor über RS232 oder Netzwerk (SSH) änderbar. Messen tue ich alle Temperaturen (Vor- und Rückläufe; Kollektoren; Speicher; ...). Die Pumpen/Ventile werden entweder digital (also ein/aus) per SSR oder mittels langsamer PWM in der Drehzahl gesteuert. Dazu kommt noch ein 3-Wege-Mischer per SSR. Das ganze 1-Wire mit owfs ist zwar recht träge, was aber aufgrund der nicht zeitkritischen Anwendung (gemessen wir 1x in der Minute) überhaupt kein Problem ist.
@Peter Ich gebe Dir für kleine Applikationen durchaus Recht, die kann man billiger mit einem AVR oder 8051 lösen. Aber ATHobaben hat schon Recht: ein Prozessor für 2 Euro ist keine Applikation mit Layout und geätztem oder sonstwie hergestelltem Board, Speicher, ggf. Display und anderem Zubehör: bei einer grösseren Serie lohnt sich eine minimallösung durchaus, weil die Hardwarekosten mehrfach eingespart werden. Für eine einmalige Sache muss sich der der Aufwand Boardlayout/Ätzen/Testen/Patchen etc. aber den Kosten eines Grasshoppers stellen. Und diesen gibts m.W. bereits ab 69 Euro. Zur Echtzeitfähigkeit: ich hatte deshalb nachgehakt, weil ich die pauschale Aussage weiter oben ("Dann weißt du doch wie es mit Echtzeitverarbeitung unter Linux bestellt ist..") do wenig durchdacht fand. Klar weiss ich das für Standard-Kernel, aber genau das war eigentlich meine Frage: sind die Grasshopper-Kernel so gebaut, dass Echtzeitverarbeitung mit gewissen mindest-Garantien möglich ist? Das ist vorwiegend eine Frage der Kernelkonfiguration, RT-Linux ist ein Beispiel dafür. Und für das, was mir vorschwebt, würde eine z.B. eine 1ms Zeitgarantie völlig reichen. Noch speziell zu einem Tripmaster: einen Tacho kann man locker mit einem 8-Bitter bauen, das wäre nicht das Thema. Aber GPS-Daten aus einer GPS-Maus auswerten, eine DCF-77 Uhr, mehrere parallel laufende Stoppuhren, Durchschnittsgeschwindigkeiten und andere Statistiken für Stunden/Tage/Wochen/Monate, Höhenmessung, Luft-, Öl- und Wasaertemperatur etc. etc. (es gibt unendlich viel überflüssige Informationen, die sich verarbeiten liessen :-) ), und das ganze mit grafischer Darstellung von gleichzeitig mehreren Grössen, also da kann einem 8-Bitter schon die Luif ausgehen. Ganz zu schweigen von USB- und Massenspeicher-Anbindung oder einer Netzwerkbasierten Konfiguration - wie schön ist in so einem Fall doch ein Multitasking System ... Es geht mir nicht um's Sinnvolle, sondern um's Machbare. :-) Ich träum ja nur vom Embedded-Luxustripmaster mit allen Schikanen, und das für 70-90 Euro ...
Hallo EMX Ich bin zwar kein Profi aber soweit ich weiss, verwenden die Automobilisten den CAN Bus. Vielleicht ja auch die Motoradbauer. Dann kannst du vielleicht schon die wichtigsten Daten direkt auslesen? http://www.mikrocontroller.net/articles/Linksammlung#CAN Das NMEA Format liefert doch Speed und die anderen Sachen mit http://www.kh-gps.de/nmea-faq.htm reicht da nicht sekündliches Auslesen, Speichern und rechnen? Ich meine bei den Quadkoptern auch mal was gelesen zu haben. Gruss, Axel
emax schrieb: > durchaus, weil die Hardwarekosten mehrfach eingespart werden. Für eine > einmalige Sache muss sich der der Aufwand > Boardlayout/Ätzen/Testen/Patchen etc. aber den Kosten eines Grasshoppers > stellen. Und diesen gibts m.W. bereits ab 69 Euro. Ich benutze Eval-Boards wirklich nur zum Reinriechen in was neues. Projekte mache ich dann immer mit dem MC und genau der Peripherie, die ich brauche. Ein Eval-Board, wo ich 90% nicht brauche, ist mir zu teuer. Ich brauche ja eh ne Platine, die die nötigen EMV-Schutzbeschaltungen, Signalanpassungen, Leistungstreiber usw. macht und dann kostet es fast nichts, wenn ich den MC gleich mit draufpappe. Im Gegenteil, ich spare sogar noch nen Haufen Steckverbinder zum Eval-Board. Außerdem passen Eval-Boards in der Regel nicht in das gewünschte Gehäuse (Abmaße, Befestigungsbohrungen, Steckverbinder). > Aber GPS-Daten aus einer GPS-Maus auswerten, eine DCF-77 Uhr, mehrere > parallel laufende Stoppuhren, Durchschnittsgeschwindigkeiten und andere > Statistiken für Stunden/Tage/Wochen/Monate, Höhenmessung, Luft-, Öl- und > Wasaertemperatur etc. etc. (es gibt unendlich viel überflüssige > Informationen, die sich verarbeiten liessen :-) ), und das ganze mit > grafischer Darstellung von gleichzeitig mehreren Grössen, also da kann > einem 8-Bitter schon die Luif ausgehen. Ganz zu schweigen von USB- und > Massenspeicher-Anbindung oder einer Netzwerkbasierten Konfiguration - > wie schön ist in so einem Fall doch ein Multitasking System ... Es nützt nichts, wenn Du nen Haufen Aufgaben aufzählst, wo der Mensch mit seinem begrenzten Aufnahmevermögen das einzige Limit darstellt. Die Daten (GPS, DCF-77, ...) liegen doch alle schon digital vor, da ist überhaupt keine Rechenleistung notwendig, der 8-Bitter gähnt nur vor langer Weile. Statistiken über Stunden sind auch nichts Forderndes. Wenn Du gesagt hättest, Statistiken über Millisekunden, das würde den 32-Bitter freuen. Es kann natürlich sein, daß ein RTOS die Entwicklung erleichtert, für jemanden, der darin geübt ist. Aber RTOSse gibts auch für 8Bit. Ich bin nicht darin geübt (Null Ahnung von Linux) und komme daher besser mit der klassischen Mainloop+Interrupt Methode zurecht. Grenzen dieser Methode konnte ich bei meinen Projekten bisher noch nicht feststellen. Wenn man sich in der Projektanalyse geirrt hat, d.h. ein Task doch mehr CPU-Zeit benötigt, dann muß man ihn in kleine Schritte aufteilen oder Teile in Interrupts verlagern. Oder unwichtigere Tasks verlangsamen. Ich denke aber, daß auch Multitasking nicht auf Anhieb funktioniert und kleinere Korrekturen im Programmablaufplan nötig werden. Ich stelle es mir allerdings schwieriger vor, unter einem RTOS eine zuverlässige Worst-Case Analyse zu machen. > Es geht mir nicht um's Sinnvolle, sondern um's Machbare. :-) Wenn Du wirklich nur ein Gerät bauen willst, ist der Entwicklungsaufwand eh nicht sinnvoll. Und der Machbarkeit setzt auch ein 8-Bitter keinerlei Grenzen. > Ich träum ja nur vom Embedded-Luxustripmaster mit allen Schikanen, und > das für 70-90 Euro ... Wie gesagt, Du brauchst eh noch Zusatzhardware und sei es nur, um das Ganze EMV-fest zu machen. Und das Display ist doch in den 90,-€ noch nicht drin oder? Peter
> Und das Display ist doch in den 90,-€ noch > nicht drin oder? Zum einen gibts das Ding bereits für unter 70 Euro. Und selbstredend wäre das Display bei Deiner 2-Euro Variante... > wenn ich die Aufgabe auch mit nem ATmega für 2,-€ > wuppen kann. sicher mit drin, gelle? Inklusiver aller erwähnten EMV-Massnahmen etc, ja nee, is klar. Wenn Du schon tönst, dass Du das mit einer vieeel billigere Lösung "wuppst", dann bleib wenigstens seriös, und lass bei Deiner eigenen Kalkulation nicht weg, was Du bei der anderen Lösung als Zusatzkosten aufführst. Das ist nicht nur unprofessionell, das ist auch höchst unredlich.
emax schrieb: >> Und das Display ist doch in den 90,-€ noch >> nicht drin oder? > > Zum einen gibts das Ding bereits für unter 70 Euro. Und selbstredend > wäre das Display bei Deiner 2-Euro Variante... Du schreibst doch, dass Du einen Tripmaster für 70-90 Euro möchtest. Um das zu schaffen, müssen in dem Preis enthalten sein: a) Grasshopper b) Zusatzplatine c) Display d) Gehäuse Ich denke nicht, dass das zu schaffen ist. Mit einem AVR geht das dagegen schon. >> wenn ich die Aufgabe auch mit nem ATmega für 2,-€ >> wuppen kann. > > sicher mit drin, gelle? Inklusiver aller erwähnten EMV-Massnahmen etc, > ja nee, is klar. Dann kostet es eben 5 Euro. Immernoch sehr viel günstiger als ein Grasshopper. Levelshifter und dergleichen brauchst Du ja schließlich auch beim Grasshopper. Markus
Also wenn das 5 Euro kostet, wären das nach Deiner Argumentation für die genannten Zusatzkomponenten 3 Euro Aufpreis. Ok. Dann kostet die Grasshopperlösung statt 70 Euro eben 73 Euro. Mal ganz egal, was die Grasshopperlösung kostet: für 2 Euro lässt sich das jedenfalls nicht "wuppen": Bei uns nennt man sowas "bleed Gebabbel". Und Du schreibst ganz genauso daher: auf der einen Seite zählst Du zur Grasshopperplatine noch Zusatzplatine, Display und Gehäuse auf (was völlig korrekt ist), und drei Zeilen später veranschlagst Du alle diese Massnahmen mit summa 3 Euro Aufpreis. Ja wie blöd ist das denn? Kurzum: ich bestreite keine Sekunde, dass zu den Kosten natürlich noch Display et.al. dazukommen, aber das ist bei jeder Lösung der Fall, egal ob Grasshopper oder "2 Euro gewupptes". Ich finde nur die Argumentation "ich mach's für 2 Euro aber Du musst ja noch Display und EMV-Massnahmen bezahlen" für ausgeprochen dämlich. Ansonsten klinke ich mich aus solchen Albernheiten hier aus. Es geht um den Grasshopper, und was man damit machen kann. Und dazu beteilige ich mich gerne weiter.
Angehängte Dateien:
-
Scannen0002.jpg
250 KB
Hallo Leser,Peter Dannegger, wo ist denn DCF77 mit dem Grashopper schon implementiert. Hast du da einen Link. Ich möchte gerne den Grashopper als NTP nutzen.
Cronos schrieb: > Hallo Leser,Peter Dannegger, Nana, ein Thread-Hijacker. Du hast doch schon nen eigenen Thread aufgemacht. > wo ist denn DCF77 mit dem Grashopper schon implementiert. Woher soll ich das denn wissen? Ich hab von Linux und AVR32 genau null Ahnung (sollte eigentlich aus meinen Postings ersichtlich sein). Peter
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.