Display+Touch Anwenung - Schubst in die richtige Richtung

[Sascha S. (excess)]

Hallo allerseits,

ich möchte zum Monitoren und Schalten bestimmter Stromkreise in einer 
12V Umgebung (Boot) eine Touchdisplay + µC/CPU einsetzen. Neben dem 
Überwachen von Spannungen, Strömen und dem Ein- und Ausschalter diverser 
Kreise, soll noch eine CAN-Schnittstelle (NMEA 2000) und ein GSM Modul 
angeschlossen werden. Jetzt tendiere ich prinzipiell zwischen diesen 
beiden Ansätze:

1. Touchpanel mit integriertem Grafikcontroller (z.B. von Riverdi) an 
einem großen µC anschließen (ATmega etc).

2. ARM MCU/Prozessor nehmen, Android oder Linux als Betriebssystem und 
dann eine Standalone-App basteln. Als Vorteile würde ich sehen, dass die 
GUI Programmierung einfacher ist, APIs zur Verfügung stehen, man eine 
SD-Karte ein Softwareupdate durchführen kann, generell eher "PC-like" 
programmiert. Als Nachteil den Stromverbrauch und die Kosten.

Wie ist in solchen Fällen der übliche Weg? Ist es überhaupt sinnvoll bei 
einer derart dedizierten Anwendung ein Betriebssystem zu nutzen, wenn ja 
doch nur eine Anwendung läuft? Ab welcher Komplexität entscheidet man 
sich eher für einen ARM, anstelle eines einfachen µC? Oder bin ich 
einfach zu blind um das Offensichtliche zu sehen? ;-) Mit welchem OS 
arbeiten bspw. einfache Navigationsgeräte?

Danke für eure Tipps,
Sascha

[Frank K. (fchk)]

Sascha S. schrieb:

> 1. Touchpanel mit integriertem Grafikcontroller (z.B. von Riverdi) an
> einem großen µC anschließen (ATmega etc).

Üblicherweise ist ein Atmega plus extra Grafikcontroller teuer als ein 
kleiner ARM oder MIPS mit eingebautem Grafikcontroller. Also wird der 
ARM genommen.

> 2. ARM MCU/Prozessor nehmen, Android oder Linux als Betriebssystem und
> dann eine Standalone-App basteln. Als Vorteile würde ich sehen, dass die
> GUI Programmierung einfacher ist, APIs zur Verfügung stehen, man eine
> SD-Karte ein Softwareupdate durchführen kann, generell eher "PC-like"
> programmiert. Als Nachteil den Stromverbrauch und die Kosten.

Stromverbrauch? Nö. Ein Atmega läuft mit 5V, wenn Du die volle 
Geschwindigkeit haben willst. Ein ARM oder MIPS läuft intern oft nur mit 
1.8V. Und da die Leistung quadratisch mit der Spannung geht...

Kosten: Nö. Gemessen an der Rechenleistung ist ein AVR teuer. Ein ARM 
oder MIPS ist nicht teurer.

Schau:
http://de.farnell.com/stmicroelectronics/stm32l100rbt6/mcu-32bit-cortex-m3-32mhz-lqfp/dp/2333383
http://de.farnell.com/atmel/atmega64a-au/mcu-8bit-avr-64k-flash-64tqfp/dp/1972124

Verstanden?

> Wie ist in solchen Fällen der übliche Weg? Ist es überhaupt sinnvoll bei
> einer derart dedizierten Anwendung ein Betriebssystem zu nutzen, wenn ja
> doch nur eine Anwendung läuft? Ab welcher Komplexität entscheidet man
> sich eher für einen ARM, anstelle eines einfachen µC? Oder bin ich
> einfach zu blind um das Offensichtliche zu sehen? ;-) Mit welchem OS
> arbeiten bspw. einfache Navigationsgeräte?

Navis arbeiten entweder mit Windows CE, Linux oder Android und haben 
MIPS oder ARMs.

Außerdem gibt es außer Linux und Android noch eine Klasse von 
Betriebssystemen darunter. Kleine Echtzeitkerne wie FreeRTOS oder RTEMS 
zB. Die laufen auch auf kleineren Prozessoren.

fchk

PS:
http://www.st.com/web/catalog/tools/FM116/SC959/SS1532/PF259090

[Sascha S. (excess)]

Hallo Frank,

herzlichen Dank für deine Antwort. Das war schon ein sehr deutlich 
Schubs in die offensichtlich richtige Richtung. Auch die Links waren 
sehr hilfreich und ich bin überrascht, wie günstig das 
"32F429IDISCOVERY" Board ist. Ich hatte vorwiegend mit Android 
geliebäugelt, da ich auch noch eine passende App fürs Handy (Android) 
bauen will und dann könnte man bestimmte Dinge evtl. wiederverwenden. 
RTOS hat ich auch schon mal überflogen, aber eine echte "Real-Time" 
Anwendung wird es nicht. Die kritischen Sachen werden eh über einen 
eigenen µC direkt am Ort des Geschehens gemacht (und über CAN an der 
Display-Einheit angekoppelt).

Anyway, vielen Dank! Ich suche mir dann erst mal ein Development-Board 
mit Touch raus und werde mal paar Gehversuche mit RTOS, Android und 
evtl. noch Linux machen.

Viele Grüße,
Sascha