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.
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
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
