Ich bin eher ein Hardware-Mensch und plane gerade eine Schaltung, bei der ein Raspberry Pi von die Daten von 8 18bit AD-Wandlern etwa 10mal/s ausließt und skalieren soll, danach werden sie mit Zeitstempel auf eine SD-Karte geschrieben. Dazu kommen nochmal 8 14bit-Wandler, die ebenfalls mit einer ähnlcihen Frequenz ausgelesen werden sollen. Zuguter letzt werden noch ein paar Ausgänge geschaltet und ggf. ein analoges Ausgangssignal ausgegeben. Nun kann ich absolut nicht einschätzen, wie viel Rechenleistung für diese Aufgaben benötigt wird. Klar, ein Raspberry mit 700Mhz sollte damit keinerlei Probleme haben, aber lässt sich das mit einem Basic-Interpreter realieren? Ich stehe nämlich vor der Entscheidung, ob ich auf Rasbian oder RISC OS setzte, wobei mich RISC OS mehr reizen würde... Aber im Endeffekt geht esdarum, dass alles läuft! Viele Grüße
RISCOS ist beim Hardware-Zugriff echtzeitfähig und deutlich schneller als Linux. RISCOS BASIC schafft GPIO Toggle mit > 20 MHz, noch schneller geht es mit dem integrierten Inline-Assembler. http://www.raspberrypi.org/forums/viewtopic.php?f=55&t=22250
20 Kanäle, 10mal/s ... Das geht auch unter Linux mit Script und Datenbank. Nur mit der Lebensdauer der SD-Karte musst du aufpassen. Wenn Dateisystem/Datenbank immer wieder die selben Verwaltungsinformationen updaten, ist die Karte nach ein paar Monaten defekt.
@ EGSler (Gast) >Nun kann ich absolut nicht einschätzen, wie viel Rechenleistung für >diese Aufgaben benötigt wird. Lächerlich wenig. Ein kleiner AVR reicht hier dicke aus. > Klar, ein Raspberry mit 700Mhz sollte >damit keinerlei Probleme haben, aber lässt sich das mit einem >Basic-Interpreter realieren? DAS könnte schon eher ein Problem werden, ist auch ein sehr schönes BEispiel, wei man Rechenleistung maximal sinnlos verballern kann ;-) >Ich stehe nämlich vor der Entscheidung, ob ich auf Rasbian oder RISC OS >setzte, wobei mich RISC OS mehr reizen würde... Aber im Endeffekt geht >esdarum, dass alles läuft! Für so ein bisschen KRam braucht es kein OS, bestenfall eine fertige Lib für die SD-Karte/FAT. http://elm-chan.org/fsw/ff/00index_e.html Funktioniert 1A! Kann man nur empfehlen! Den Rest programmiert man einfach so runter. Timer aufsetzen, fertig.
Werd ich mir mal angucken, danke! Aber der Punkt ist, dass da noch eine grafische Benutzeroberfläche für her muss, damit spätermal "jeder Depp" (in diesem Fall die Physiker bei uns :p) die passenden Kanäle anwählen und andere Einstellungen tätigen kann. Da würde ich mich wahrscheinlich sehr schwer tun, wenn ich eine GUI ohne OS realisieren darf, oder...? Wie gesagt, ich kann den Software-Aufwand bisher nicht einschätzen, meine Programmierkenntnisse beschränken sich bisher auf ein wenig Assembler auf einem PIC und ein wenig Arduino-C... Aber man wächst an seinen Aufgaben^^ @Noch einer Was meinst du mit Update der Verwaltungsinformationen? Ist das etwas, dass das Betriebsystem im Hintergrund erledigt? Viele Grüße
@ EGSler (Gast) >kann. Da würde ich mich wahrscheinlich sehr schwer tun, wenn ich eine >GUI ohne OS realisieren darf, oder...? Das ist wohl wahr, davon war aber bisher keine Rede. >Assembler auf einem PIC und ein wenig Arduino-C... Aber man wächst an >seinen Aufgaben^^ Dann nimm den Arduino, einen LCD-Schield + SD-Karte. Die AD-Wandler laufen höchstwahrscheinlich alle mit SPI, den hast du schon am Arduino. Sicher geht es auch auf dem Raspberry Pi, aber nicht in einem grottigen Interpreterbasic. Man sollte wenigstens solides C nehmen und das dort in einem Systemtimer stecken.
Du hast Recht, das hatte ich nicht erwähnt, da das erstmal nicht meine Priorität hatte. Da habe ich die wichtige Info vergessen ;/ Jep, die AD-Wandler haben SPI, aber der Raspberry ist eine Vorgabe. Es soll auch nicht nur ein LCD angeschlossen werden, sondern ein richtiger Monitor. Aber das ist erstmal noch Zukunftsmusik^^ Das Projekt soll nach und nach immer erweitert werden, z.B. soll später noch RS485 dazu und ggf. über Ethernet eine Vernetzung an den laborinternen Uhrzeitgeber, damit der Zeitstempel auch mit anderen Messungen übereinstimmt. Mir ging es jetzt erstmal um die Auswahl des Betriebssystems. (Über Bare-Metal hatte ich auch schon nachgedacht, da ich an Assembler auf dem PIC immer richtig Spaß hatte, aber in allen Foren steht, dass es an Wahnsinn grenzt, wenn man sich als Anfänger in Assembler auf einen ARMv6 stürzen will^^). Also muss ich entweder unter Risc OS einen gescheiten C Compiler finden, oder ich setzte auf Raspberry und wähle bspw. Code::Blocks. Hm, vielleicht probier ich einfach mal beides aus =)
> Also muss ich entweder unter Risc OS einen gescheiten C Compiler finden, > oder ich setzte auf Raspberry und wähle bspw. Code::Blocks. Ich meine gelesen zu haben das es auch fuer Risc OS einen C compiler gibt. Es wuerde mich auch sehr wundern wenn die da seit 20Jahren alle mit Basic rumeiern. Ich finde Risc OS auch sehr interessant und denke wenn ich eine Anwendung fuer einen Rechner haette der noch eine Grafikoberflaeche haben muesste dann wuerde ich da auch drauf zurueckgreifen. Wer sich Risc OS noch nie angeschaut hat sollte das unbedingt mal machen. Es hat zum einen den etwas herben, aber nicht schlechten CHarme wie man ihn ende der 80er vom Amiga oder ST kannte, auf der anderen Seite ist es rasend schnell. Auch aus der Sicht von jemanden der eigentlich Linux mag und schon sehr lange nutzt! Aber der Rhasberry ist mit einem aktuellen Linux schon grenzwertig ueberfordert. Risc OS fuehrt einem sehr deutlich vor Augen zu was fuer traegen Kloetzen unsere Betriebsysteme in den letzten 20Jahren geworden sind. Es gibt aber eine Sache die gegen Risc OS spricht. Niemand kennt es und niemand nutz es. Also wird es wesentlich weniger Doku geben. Ausserdem tut sich jemand der erstmals damit in Kontakt kommt sicher etwas schwer weil die Bedienung teilweise anderen Konzepten/Ideen folgt. Trotzdem waere es schon wenn sich RiscOS mehr verbreiten wuerde. :-) Es waere ziemlich toll wenn das System auf meinem Handy laufen wuerde und der Akku dann wieder zwei Wochen halten wuerde.... olaf
Arch Linux statt Raspbian, einfach weil man da erst mal nur ein naktes system hat, ohne alles, nicht mal n Desktop. Da muss man sich dann zwar den Desktop selber zusammen "basteln", hat aber insgesamt den vorteil das du selbst entscheidest, was installiert wird. Bei Raspbain und Co bekommst du einen fertigen Desktop vorgesetzt, fast wie Windows, mit allerhand sachen, die du vielleicht gar nicht brauchst, die aber im zweifel trotzdem leistung fressen. Ja, Arch ist n bisschen anstrengend (zu anfang), zahlt sich aber auch aus. Allerdings muss man bereit sein, sich mit Arch beschaeftigen zu wollen. Olaf schrieb: > Aber der Rhasberry ist > mit einem aktuellen Linux schon grenzwertig ueberfordert. Risc OS fuehrt > einem sehr deutlich vor Augen zu was fuer traegen Kloetzen unsere > Betriebsysteme in den letzten 20Jahren geworden sind. Ein Raspberry mit naktem Arch (also nur Konsole) ist alles andere als "grenzwertig Ueberfordet". :-)
EGSler schrieb: > Du hast Recht, das hatte ich nicht erwähnt, da das erstmal nicht meine > Priorität hatte. Da habe ich die wichtige Info vergessen ;/ > > Jep, die AD-Wandler haben SPI, aber der Raspberry ist eine Vorgabe. Dann nimm besser einen BeagleBone Black. Das ist die bessere Hardware mit mehr IO und Peripherie. > Es > soll auch nicht nur ein LCD angeschlossen werden, sondern ein richtiger > Monitor. Solange es HDMI ist, ist egal, was Du da anschließt. > Aber das ist erstmal noch Zukunftsmusik^^ > Das Projekt soll nach und nach immer erweitert werden, z.B. soll später > noch RS485 dazu und ggf. über Ethernet eine Vernetzung an den > laborinternen Uhrzeitgeber, damit der Zeitstempel auch mit anderen > Messungen übereinstimmt. apt-get install ntp-server Damit wäre dieser Punkt auch erledigt.
> Was meinst du mit Update der Verwaltungsinformationen?
Z.B. steht im Inhaltsverzeichniss die Länge der Datei. Trotz aller
Optimierungen schreibt Linux das Verzeichniss recht häufig auf die Karte
zurück -> ausgerechnet der Block mit dem Inhaltsverzeichniss geht zuerst
kaputt.
Bei Datenbanken ändern sich die Dateiverzeichnisse zwar nicht, intern
gibt aber ähnliches.
Habe unter Linux keine Tools gefunden, um herauszufinden, wie oft das
System diese Blöcke ändert.
Einen Logger/Webserver in ähnlicher Größe hatte ich mit Raspberry und
RrdDb gemacht. Genial einfache Sache. Lässt sich alles in ein paar Tagen
mit zusammenstellen. Nur leider waren die Karten nach ein paar Monaten
hinüber.
Falls du vielleicht doch nicht soooo sehr auf den Raspberry festgenagelt bist, koennte vielleicht der UDOO(http://www.udoo.org) interessant sein. Zum einen ein Cortex-M3, der die Messungen machen kann, zum anderen ein Dual/Quad Core fuer das OS und deine GUI. Und echtes Netzwerk, nicht wie beim Raspberry ueber USB angebunden...
Nimm Raspian. Da kannst man viele Teile schon verwenden, und muss nicht alles selber machen. Das Projekt soll ja auch in endlicher Zeit fertig werden. Bei Bare Metal verschwendet man viel Zeit mit irgendwelchen Details, die ein OS schon bietet. Und sei es nur das Filesystem auf der SD-Karte. Oder der TCP/IP Stack. Bei Raspian bekommt man ausserdem alle Entwicklungstools mit, und kann leicht mit apt-get jedes noch nicht vorhandene Tool nachladen. Mit Raspian kannst du dich auf das Samplen der Daten konzentrieren. Und die Zeit, die du früher fertig bist, mit Freundin oder anderen Projekten vertrödeln.
>Bei Bare Metal verschwendet man viel Zeit mit irgendwelchen Details, die ein OS
schon bietet.
Kann man nicht so pauschal sagen. Wenn der Logger jahrelang
unbeaufsichtigt laufen soll, sieht es ganz anders aus.
So 1-2 mal Jahr stürzt so ein Linux-Teil ab. Bis man die Gründe
herausgefunden hat, gibt es schon längst wieder ein neues BS mit anderen
Macken.
In Summe kann die Bitfummelei auf einem Minimalsystem schneller gehen.
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.