Ich habe eine Prozessteuerung, in der bisher ein AVR ATmega32 werkelt. Die Aufgaben sind nicht sehr komplex: Ankommende Daten (RS232) auswerten und an einen Datenbus (RS485) für verschiedene Aktoren zu Verfügung stellen. Ein bißchen Statusabfrage und Displayausgabe. Die Evaluierung der Daten erfolgt über eine Look-Up-Table im Flash des AVR. Die Tabelle nimmt dabei etwa 50% des Flash ein, der Rest nochmal 20%. Auslagern gänge also allenfalls in einen externen EEprom. Es müssen allerdings mitunter Anpassungen der Tabelle "im Feld" vorgenommen werden, also beim Kunden. Jetzt habe ich die Option, den AVR durch einen BeagleBone zu ersetzen. 4 serielle Schnittstellen, viele GPIOs, Display möglich. Vorteil wäre, ich könnte auf dem BeagleBone direkt die Look-Up-Table bearbeiten - würde dann in einer Datei stehen. Ich könnte direkt Änderungen im Programm vornehmen, und ich könnte sogar eine Programmierumgebung für die Aktoren auf dem BeagleBone erstellen. Damit ließen sich Anpassungen direkt beim Kunden nur mit einer Tastatur und einem Monitor erledigen - die dort meistens irgendwo rumstehen -, während für den AVR immer der Laptop mit Programmierumgebung mit muss. Ich könnte sogar via Lan per Remotezugriff Änderungen vornehmen. Sicherheitskritisch ist die Anwendung nicht. Aber zuverlässig laufen sollte sie. Und hier kommen meine Bedenken: Wie zuverlässig läuft das System auf so einem Minirechner. Beim AVR eigentlich keine Frage: Solange der Flash in Ordnung ist, rödelt der einfach das Programm durch. Auf dem Minirechner gibt es aber viel mehr Komponenten, die Ärger machen könnten: Die SD-Karte, das Betriebssystem, irgendwelche Treiber (serielle Schnittstelle), Überhitzung. Die Raspies sollen gerade bei höheren Temperaturen Probleme haben. Erkaufe ich mir hier (deutlich) höheren Komfort mit erhöhter Ausfallwahrscheinlichkeit?
Timm Thaler schrieb: > Die Evaluierung > der Daten erfolgt über eine Look-Up-Table im Flash des AVR. Die Tabelle > nimmt dabei etwa 50% des Flash ein, der Rest nochmal 20%. Auslagern > gänge also allenfalls in einen externen EEprom. Das mußt du erklären. 50+20=70. Bleiben also 30% bis der Flash voll ist. Wieso muß man da irgendwas auslagern, wenn doch noch reichlich freier Platz vorhanden ist? Abgesehen davon kann man vom Mega32 noch zweimal kompatibel aufrüsten (100% pinkompatibel und weitestgehend Software-kompatibel) und somit den Flash nötigenfalls auf das doppelte oder gar vierfache aufblasen. > Es müssen allerdings > mitunter Anpassungen der Tabelle "im Feld" vorgenommen werden, also beim > Kunden. Und? Der Mega32 hat, wie fast die ganze AVR-Palette, "self-programming"-Fähigkeiten. Solange sich Größe und Struktur der Tabelle nicht ändert, sondern nur irgendwelche Tabellenwerte, ist das sowieso absoluter Kinderkram. Und auch ansonsten keine wirkliche Herausforderung. > Vorteil wäre, ich könnte auf dem BeagleBone direkt die Look-Up-Table > bearbeiten Kannst du auch mit dem AVR. Wie schon gesagt: Der kann "self-programming". > Ich könnte sogar via Lan per Remotezugriff Änderungen vornehmen. Auch das geht mit dem AVR. Er braucht dafür natürlich (genau wie das BeagleBone) einen Netzwerkstack und einen Netzwerkadapter. > Auf dem Minirechner gibt es aber viel mehr Komponenten, die Ärger machen > könnten Natürlich, das Komplexitätstheorem sagt das sogar geradezu zwingend voraus.
Für Zuverlässigkeit gelten zwei Prinzipien: Redundanz und "keep it simple". Schau, was du verbessern kannst, wenn die Zuverlässigkeit nicht hoch genug ist. Wenn du zur besseren Wartbarkeit sowohl Tabelle als auch Code per Bootloader o.ä. änderbar machst, sieh zu, daß dadurch nichts verschlimmbessert wird. Ob du jetzt auf ARM umschwenkst (Risiko oder Chance der neuentwicklung) oder beim AVR bleibst, hängt von zu vielen Parametern ab und wird wohl letzlich eine reine Bauchentscheidung deinerseits werden.
c-hater schrieb: > Wieso muß man da irgendwas auslagern, wenn doch noch reichlich freier > Platz vorhanden ist? Ich meine damit, die Tabelle ist so groß, dass der interne EEprom keine Option ist. Bei der Manipulation der Tabelle im Flash besteht halt immer die Gefahr, dass ich mir das Programm und vielleicht noch einen Bootloader zerschieße, und dann ist ganz Essig. Ok, andersherum: Wie sieht es denn mit der Langzeitstabilität von Systemen wie Raspberry Pi, Beagle Bone usw. aus? Könnten die auch problemlos längere Zeit, sprich Monate oder Jahre durchlaufen? Oder möchte das Linux - welches auch immer dann drauf läuft - immer mal neu gestartet werden?
Timm Thaler schrieb: > Ok, andersherum: Wie sieht es denn mit der Langzeitstabilität von > Systemen wie Raspberry Pi, Beagle Bone usw. aus? Könnten die auch > problemlos längere Zeit, sprich Monate oder Jahre durchlaufen? Oder > möchte das Linux - welches auch immer dann drauf läuft - immer mal neu > gestartet werden? Es gibt viele Unix-Systeme, die Uptimes von mehreren Jahren haben. Das kritische bei Linux sind Binary-only Module, die häufig für den Grafikprozessor oder WLAN benötigt werden. Da kannst Du nicht hineinsehen, und bei zukünftigen Updates kannst Du ganz schön alt aussehen. Die Boards selber sind natürlich von höchst unterschiedlicher Qualität. Der populärere PI ist alleine auf billig gebaut, und das wirst Du merken. Für eine industrielle Applikation lass die Finger davon. BeagleBone ist deutlich besser, das Wandboard nochmals. Es gibt viele verschiedene Systeme für den industriellen Einsatz zB als Hutschienen-Modul. Auch Firmen wie WAGO (die mit den Klemmen) haben nette Boxen. Linux ist allerdings kein Echtzeitsystem, d.h. das Zeitverhalten ist nicht immer deterministisch. Es gibt zwar Echtzeiterweiterungen, aber die kommen keinesfalls an die richtigen RTOSse wie vxWorks (auf dem Mars im Einsatz) oder QNX heran. Die gibts natürlich auch noch. fchk
Timm Thaler schrieb: > Könnten die auch > problemlos längere Zeit, sprich Monate oder Jahre durchlaufen? Oder > möchte das Linux - welches auch immer dann drauf läuft - immer mal neu > gestartet werden? Es gibt Distributionen, die sehr auf Stabilität bedacht sind. Debian ist so eine, und das läuft auch ewig ohne Reboot. Von dem her würde ich mir auf der Software-Seite an sich weniger Sorgen machen. Aber was problematisch sein kann sind z.B. Stromausfälle. Zumindest hatte ich (und man liest es auch oft) auch beim Raspberry Pi Probleme (Dateisystem auf der SD-Karte geschossen). Und wenn du die SD-Karte auf read-only stellst hast du im Endeffekt das selbe Problem wie beim AVR (Na gut, du könntest das System herunterfahren, Schreibzugriff aktivieren (Schieber bei SD-Karten) und dann deine Änderungen machen)
Frank K. schrieb: > Linux ist allerdings kein Echtzeitsystem, d.h. das Zeitverhalten ist > nicht immer deterministisch. Es gibt zwar Echtzeiterweiterungen, aber > die kommen keinesfalls an die richtigen RTOSse wie vxWorks (auf dem Mars > im Einsatz) oder QNX heran. RISCOS ist klein, schnell, echtzeitfähig, langzeitstabil ... http://www.raspberrypi.org/downloads
c-hater schrieb: > Auch das geht mit dem AVR. Er braucht dafür natürlich (genau wie das > BeagleBone) einen Netzwerkstack und einen Netzwerkadapter. Beaglebone hat bereits einen Netzwerkadapter und man wird kaum ein Betriebssystem für den Beaglebone ohne Netzwerkstack finden. Was der Beaglebone (classic) nicht hat ist ein Monitorausgang, den hat erst der Beaglebone Black. Übers Netzwerk einloggen und auf dem Gerät das Programm debuggen, ändern, neu kompilieren ist natürlich sehr komfortabel. Dinge die man evtl beachten muss sind zum Beispiel dass Flash speicher nur begrenzt oft beschrieben werden können und so eine gängige Linuxdistribution logfiles anlegt die auf das Flashmedium geschrieben werden. Das sollte man, wenn man kein gesteigertes interesse an den logs hat in eine ramdisk verlagern.
Erkaufe ich mir hier (deutlich) höheren Komfort mit erhöhter Ausfallwahrscheinlichkeit? Ja sicher - aber zudem zahlst du mit Kontrollverlust. - Na ja eigentlich könnte man das auch Überschaubarkeit nennen. Keep it simple.
Simon S. schrieb: > Aber was problematisch sein kann sind z.B. Stromausfälle. Autsch. Also bisher wird die Steuerung einfach ausgeschalten. Was dem AVR natürlich nicht schadet - es sei denn er würde gerade in den Flash schreiben, was er bisher nicht tut. Das heisst, auch bei Raspberry und BeagleBone gilt wie bei "großen" Rechnern: Immer erst runterfahren? Das könnte dem Anwender etwas schwer vermittelbar sein.
Gedanke: Du könntest doch auch den Look-Up-Table deines AVRs in einer einfachen Text-Datei in einem FAT-Dateisystem auf einer SD-Karte speichern. Dann kannst du die in einen x-beliebigen Computer stecken und bearbeiten, ohne dass du einen Programmer oder die AVR-Toolchain brauchst (Wenn du ein Smartphone mit OTG oder µSD-Einschub hast tuts sogar das - hast du ja eh immer in der Tasche) [EDIT] Timm Thaler schrieb: > Was dem > AVR natürlich nicht schadet - es sei denn er würde gerade in den Flash > schreiben, was er bisher nicht tut. Aber ein Linux macht das eben ständig, Logfiles zum Beispiel. Und dann kann das Dateisystem hops gehen.. > Das heisst, auch bei Raspberry und BeagleBone gilt wie bei "großen" > Rechnern: Immer erst runterfahren? Das könnte dem Anwender etwas schwer > vermittelbar sein. Oder das Linux so einrichten, dass es nichts verändern kann. Das musst du dann aber natürlich bevor du den Look-Up-Table ändern möchtest aufheben und danach wieder aktivieren
oder statt der SD-Karte so etwas z.B. auf die Platine setzen: http://www.tme.eu/de/details/m25p16-vmn6p/serielle-flash-speicher/micron/# Und dann mit einem einfachen PC-Programm eine neue Tabelle über RS232 an den µC senden, der sie im Flash abspeichert. Da ist auch genug Platz, um alles doppelt - oder noch öfter ;) - abzuspeichern. Damit kann man bei Stromausfall während des Schreibens die alten Daten wiederherstellen.
kopfkratz Ich verstehe das Problem irgendwie nicht ? Ist der SPI nicht verfügbar ? Denke ich nicht ergo bestehendes erprobtes System um eine SD-Karte erweitern wo die abzugleichenden Daten hinterlegt sind. Im übrigen muß man auch kein OS einsetzen wenn man das nicht benötigt. Un*x läuft ohne Probleme jahrelang außer man muß irgedeine Sicherheitslücke stopfen und ich denke kaum das Deine embedded Systeme im Internet sind. Und der Vorteil der SD-Karte liegt auf der Hand man kann eine neue zuhause beschicken und die aktuelle beim Kunden ohne neues flashen austauschen. Oder habe ich etwas übersehen ?
Simon S. schrieb: > Oder das Linux so einrichten, dass es nichts verändern kann. Dann könnte ich auch mit 2 Karten arbeiten: Eine für das BS, schreibgeschützt, und eine für die Daten. Simon S. schrieb: > Du könntest doch auch den Look-Up-Table deines AVRs in einer einfachen > Text-Datei in einem FAT-Dateisystem auf einer SD-Karte speichern. Ja, diese Option ist mit auf dem Plan.
Timm Thaler schrieb: >> Oder das Linux so einrichten, dass es nichts verändern kann. > > Dann könnte ich auch mit 2 Karten arbeiten: Eine für das BS, > schreibgeschützt, und eine für die Daten. Das nützt nichts, wenn auf der Datenkarte ein Dateisystem ist, das wird genauso beschädigt. Der Benutzer merkt den Unterschied nicht -- die Maschine geht nicht mehr. Du brauchst zwingend eine USV. Wenn du die schon erwähnten SPI-NOR-Flash Speicher nimmst und die Daten geschickt organisierst, reicht allerdings der Elko im Netzteil als USV. Diese Speicher schreiben 256-Byte Blöcke in max. 5ms, nicht in 5 Sekunden wie SD-Karten. Wenn es unbedingt eine SD-Karte sein muss, lass das Dateisystem weg. Wenn du rein sequentiell auf eine fabrikneue Karte schreibst, kannst du wenigstens hoffen, dass nur der eine Block geschrieben wird und es entsprechend schnell geht.
gnd3 schrieb: > Das nützt nichts, wenn auf der Datenkarte ein Dateisystem ist, das wird > genauso beschädigt. Hast du da irgendwo weitere Informationen dazu? Er kann die Karte ja mit der Option "noatime" mounten, dann wird auch nicht geschrieben wann die Datei zuletzt gelesen wurde. Warum sollte dann noch eine Beschädigung des Dateisystems auftreten?
Wenn nicht geschrieben wird, wird auch nichts kaputt, aber dann kann ich ja auch read-only mounten. Interessant ist doch nur der Fall, wenn die Daten geändert werden. Und dabei ist das Dateisystem in einem inkonsistenten Zustand, und zwar ziemlich lange: - die reine Zeit, die eigentlichen Daten zu schreiben + 30 Sekunden Wartezeit auf mehr Daten + die Zeit, die Metadaten zu schreiben + ggf. ein paar wenige Sekunden für's Wear Leveling Während der ganzen Zeit darf der Strom nicht ausfallen -- nicht mehr, und nicht weniger. Na gut, etwas weniger geht, man kann die 30 Sekunden kürzer einstellen. Die noatime Option sollte natürlich immer angegeben werden.
Gibt es eigentlich Datensysteme unter linux mit wear leveling? Weitere Vorteile so eines embedded Linux systems: Email im Fehlerfall oder bei merkwürdigen Werten versenden. Wlan-Stick rein und schon muss man nichtmal mehr ein Kabel hinverlegen. Web-Server drauf und Graphen erzeugen oder eine Steuerungswebsite.
2 SD Karten? Wirklich? Wie wärs mit mehreren Partitionen? Die normalen Systempartitionen werden alls read-only gemountet und dann gibt es eine Partition, auf der liegt nur die LUT + Prüfsumme. Diese Partition wird R/W (noatime) gemountet. So kannst du die LUT updaten, wenn beim Update was schief geht macht es auch nichts, dann muss das Update eben nach einem Reboot neu gestartet werden, dank der Prüfsumme ist der Fehler dann ja erkennbar. Dadurch verlierst du natürlich die Möglichkeit das Programm selbst zu updaten, im Zweifel kannst du das ja auch auf die R/W Partition hauen, dann musst du wenn beim Update was schief geht eben manuell remote das Programm neu einspielen.
Über die Zuverlässigkeit lässt sich zwar streiten, aber da ein ARM x mal mehr Speicher, y mal mehr RAM und z mal mehr Transistoren als ein AVR besitzt, kommt man zumindest theoretisch zu einer x*a+y*b+z*c höheren Ausfallwahrscheinlichkeit, falls man annimmt, das die Ausfallswahrscheinlichkeit der Komponenten beider Chips gleich sind und die Koeffizienten a,b,c die Wahrscheinlichkeit eines Ausfalls sind. Die Probleme mit Betriebssystem, höherer Frequenz und kleinerer, empfindlicherer Bauteile kommt noch dazu. Tatsache ist, das alte, einfache Systeme viel einfacher zu warten und reparieren sind, als neue. Ganz früher (6502/i8080/8051) hatte man externes RAM und ROM. ROM konnte man einfach mit einem Programmer auslesen und kopieren, RAM und Prozessor konnte man zur Fehlersuche einfach wechseln. Auf dem Address/Datenbus konnte man scih mit dem LA anschauen, was der CPU macht. Dann kam der PIC/AVR/uC mit internem Flash und RAM, falls da ein Problem mit dem Chip gibt, muss man als erstes hoffen, das kein Arsch das Lockbit gesetzt hat und das man den passenden Programmer hat, um den Chip auszulesen. Falls beides zutrifft, hat besteht Hoffnung, das man das Gerät wieder hinkommt. Heute wo überall ein Custom BGA-ARM mit OS drin ist, hat man meist keine Chance mehr, irgendwas zu reparieren.
gnd3 schrieb: > Wenn nicht geschrieben wird, wird auch nichts kaputt, aber dann > kann ich > ja auch read-only mounten. Interessant ist doch nur der Fall, wenn die > Daten geändert werden. Und dabei ist das Dateisystem in einem > inkonsistenten Zustand, und zwar ziemlich lange: > - die reine Zeit, die eigentlichen Daten zu schreiben > + 30 Sekunden Wartezeit auf mehr Daten > + die Zeit, die Metadaten zu schreiben > + ggf. ein paar wenige Sekunden für's Wear Leveling Das letzte Jahrtausend ist schon 14 Jahre vorbei. Und ja, es gibt spezielle Filesysteme für Flashchips.
wenn SD-karten dann kommst du um 2 nicht wirklich herum die dinger haben nämlich ein internes wear-leveling das gelegentlich anspringt wenn man auf sie schreibt selbst wenn du 2 partitionen drauf hast und nur auf eine schreibend zugreifst kann dir die karte intern in beiden umrühren (da bist du voll und ganz dem hersteller ausgeliefert)
Ein AVR ist ein Prozessor, ein BeagleBeone ein komplettes Board. Der ARM auf dem BeagleBone ist genauso zuverlässig wie ein AVR, die Zuverlässigkeit des Boards ist eine ganz andere Baustelle. Dazu sollte sich aber ausreichend Infos im Netz finden lassen. Oliver
Timm Thaler schrieb: > Bei der Manipulation der Tabelle im Flash besteht halt immer die Gefahr, > dass ich mir das Programm und vielleicht noch einen Bootloader > zerschieße, und dann ist ganz Essig. Den Bootloader kannst Du locken. Und wenn er nur den Datenflash ändern soll, prüft er einfach vor jedem Schreiben, ob die Adressse nicht in die Applikation zeigt. Oder Du pappst nen externen Flash/EEPROM ran (24C512). Wir benutzen auch einen Bootloader für Firmware-Updates auf dem AVR. Daß sich die Applikation ungewollt zerstört, haben wir bisher nie gehabt.
Opa erzählt vom Kreig schrieb:
> Und ja, es gibt spezielle Filesysteme für Flashchips.
Es gibt auch Gemüsecremesuppe, hier ging's aber um SD-Karten. Mach' den
Leuten hier keine falschen Hoffnungen.
Außerdem braucht man für eine einzelne Tabelle nun wirklich kein Dateisystem.
Timm Thaler schrieb: > Vorteil wäre, ich könnte auf dem BeagleBone direkt die Look-Up-Table > bearbeiten - würde dann in einer Datei stehen. Ich könnte direkt > Änderungen im Programm vornehmen, und ich könnte sogar eine > Programmierumgebung für die Aktoren auf dem BeagleBone erstellen. Damit > ließen sich Anpassungen direkt beim Kunden nur mit einer Tastatur und > einem Monitor erledigen - die dort meistens irgendwo rumstehen - Also darauf würde ich mich nicht verlassen. Außerdem sollte der Kundenservice doch wohl immer ein Laptop dabei haben. Dann kann man diese Software genausogut da drauf tun und den AVR damit neu (teil)flashen. > während für den AVR immer der Laptop mit Programmierumgebung mit muss. > Ich könnte sogar via Lan per Remotezugriff Änderungen vornehmen. Sofern es der Kunde erlaubt. Was er hoffentlich nicht tut. Das Scada- Desaster oder auch die Sicherheitsprobleme bei Vaillant-Heizungen sind hoffentlich noch präsent in den Köpfen der Chefs (oder zumindest: denen der Techniker) Timm Thaler schrieb: > Bei der Manipulation der Tabelle im Flash besteht halt immer die Gefahr, > dass ich mir das Programm und vielleicht noch einen Bootloader > zerschieße, und dann ist ganz Essig. Unwahrscheinlich. Der Bootloader kommt einfach in eine gelockte Sektion. Und dann kannst du immer noch entscheiden, ob du immer gleich Applikation + Tabelle flashst (per Bootloader + Standardtools) oder ob du eine eigene "update die Tabelle zur Laufzeit" Lösung baust, die dann natürlich eine Hardware-Schnittstelle und Software-Unterstützung braucht. Ein ausgewachsenes Linux-Minisystem hat IMHO die folgenden Probleme: * es ist deutlich komplexer - mehr Möglichkeiten Fehler zu machen. Ob sich das mit der tendenziell leichteren Analyse bei Fehlern rauskürzt, muß man sehen. * Flash-Speicher, zumal in Form von SD-Karten, ist nicht die Krone der Zuverlässigkeit. Ich habe jetzt schon mehrere SD-Karten entsorgen dürfen, weil sie ab und zu mal hängen oder Müll lesen. Auf Hardwareseite ist das auf jeden Fall die kritischste Komponente (ok, vielleicht noch das Netzteil) * ein Linux-System bietet auch mehr Angriffsmöglichkeiten. Konsolenzugang, Netzwerk und am einfachsten die SD-Karte. Fazit: ich würde mich an das KISS-Prinzip halten. Keep it simple, stupid. Die einfachste Lösung ist oft auch die zuverlässigste. XL
>Oder Du pappst nen externen Flash/EEPROM ran (24C512).
oder einen 23LCV1024 (bzw. einen seiner kleineren Brüder)
Timm Thaler schrieb: > Simon S. schrieb: >> Aber was problematisch sein kann sind z.B. Stromausfälle. > > Autsch. Also bisher wird die Steuerung einfach ausgeschalten. Was dem > AVR natürlich nicht schadet - es sei denn er würde gerade in den Flash > schreiben, was er bisher nicht tut. > > Das heisst, auch bei Raspberry und BeagleBone gilt wie bei "großen" > Rechnern: Immer erst runterfahren? Das könnte dem Anwender etwas schwer > vermittelbar sein. Ein richtiges Echtzeitsystem wie OS9 (nein, nicht das von Apple, sondern das von http://www.microware.com/) mit dem dazu passenden Dateisystem kannst Du einfach ausschalten. Das Betriebssystem garantiert, dass das Dateisystem zu jedem Zeitpunkt konsistent ist. Eine Datei ist entweder da - dann ist sie in Ordnung - oder nicht da. fchk
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.