Auswahl uController

Moin,

So ganz spontan haett' ich da so'n STM32 Discovery Board genommen. Da 
gibts welche mit Display, und allen moeglichen Sensoren schon dabei. Zu 
dem Preis kriegt man's wahrscheinlich nicht selbergebaut.
Aber wenn du bei AVR daheim bist und nicht bei ARM, dann mach's halt mit 
nem AVR.

Gruss
WK

Andreas schrieb:
> Da das ganze mit nur einem uC gesteuert werden soll und insb. wegen
> Ansteuerung SD Karte habe ich mich für einen AVR32 Controller
> entschieden.

Kann man machen, ist aber eher übermotorisiert.

> Abgesehen von den Messwerten, welche alles max. 16bit Werte
> sind gehe ich davon aus dass ein 16bit Controller mit Datenverarbeitung
> und paralleler Ausgabe an Grafik Display an seine Grenzen gelangt.

;-)

[ ] Du hast Ahnung, was ein zeitgemäßer 8-Bit Controller leisten kann, 
wenn man weiß was man tun.

Deinen Drucksensor muss man sicher NICHT mit 33kHz auslesen, 1kHz ist 
wahrscheinlich mehr als genug. Der Rest ist Krümelkram, auch für einen 
8-Bit Controller (wenn's nicht gerade ein uralter PIC10 ist)

Andreas schrieb:
> Was meint ihr zu dieser uC Auswahl?

Ich meine, wann immer jemand so ein Projekt erstmal mit einer µC Auswahl 
beginnt, wird das nichts. Warum?
Weil er dann meist gar keine Erfahrung mit gar keinem Controller hat. 
Wer schon mit Controllern entwickelt hat, weiß was er nehmen kann und 
sollte.

Das ist so ein typischer Einstieg nach dem Motto "Kann nix, will Space 
Shuttle bauen. Welchen Wasserhahn soll ich da im Klo verbauen?".

Also nimm den Controller mit dem du dich auskennst. Wenn es da keinen 
gibt, ist das Projekt ne Nummer zu groß.

Au ja, das wollte ich auch immer mal machen...

Allerdings würde für ein einfaches Vario doch auch ein 8bitter reichen.

Andreas schrieb:
> - Drucksensor (Vario) >> 33khz 16bit A/D
Das halte ich für viel zu hoch. 1000 Datenpunkte pro Sekunde wären doch 
immer noch mehr als reichlich.

> - GPS Modul (x,y,z Position + Zeit) >> I2C <400kbps
OK
> - Grafik Display 128x64 (Ausgabe) >> SPI
OK
> - SD Karte (30s Logging GPS Pos + div. AVG/Peak Werte) >> I2C
Wenn Du nicht Deinen ganzen Flug für den XC-Contest aufzeichnen willst 
sondern nur ein einfaches Vario willst mit eventuell im Flug einer 
Grafik Deines letzten Steigens/Sinkens sowie Speicherung von max. 
Sinken, max. Steigen, Flugdauer, max. Höhe, kumul. Steigen... dann würde 
ich die SD-Karte weglassen. Das kann man auch bis zum Flugende im RAM 
behalten. Die meisten Werte brauchen ja sowieso nur 8bit zu sein. Wenn 
Du mal mehr als 25,5m/s Sinken oder Steigen hattest, wirst Du das Vario 
danach sowieso nicht mehr auslesen. ;-)
Für ein Flugtagebuch könnte man die dann in ein EEPROM schreiben. Viel 
einfacher als SD-Karte.

> - Bluetooth Modul optional (Übermittlung Datenlogging nach Aufzeichnung)
Wäre BT nicht eher interessant dafür, die Daten sofort weiter zu 
schieben, so dass auf dem Empfänger z.B. XCSoar gefüttert werden kann?

Andreas schrieb:
> Auf jeden Fall werde ich mein Projekt hier sharen.

Soso, "sharen". Früher (tm) hat man es geteilt oder vorgestellt, im 
proefssionellen Umfeld auch veröffentlicht.

http://kamelopedia.net/wiki/Denglisch

"Again what learnt"

Andreas schrieb:
> Abgesehen von den Messwerten, welche alles max. 16bit Werte
> sind gehe ich davon aus dass ein 16bit Controller mit Datenverarbeitung
> und paralleler Ausgabe an Grafik Display an seine Grenzen gelangt.

Nur gut, daß die Compiler nichts von Deiner Beschränkung auf die Breite 
des Datenbusses wissen und auch auf nem 8-Bitter fleißig mit float und 
32Bit Integer rechnen.

Andreas schrieb:
> Kann sein...das letzte Mal habe ich mich mit 32biter im Studium vor bald
> 10 Jahren versucht und seither nix mehr programmiert.

Jo, dann nimm einfach mal einen STM32 samt Toolchain und Debugger in 
Betrieb und lasse ein LED blinken.

Wenn du dann noch Bock hast, kannst du anfangen deine Liste da oben 
abzuarbeiten.
Allein bis du auf einem kleinen Grafik LCD einen Text ausgegeben hast 
(wenn du es selbst machst) wird ein wenig Wasser den Bach runtergehne. 
Dito bei der SD Karte, dito beim parsen von NMEA Daten vom GPS.
Drucksensor auslesen ist dagegen popelig.

Natürlich gibts für das meiste auch fertigen Code und Libs. Die muss man 
aber auch erst mal einbinden und nutzen.

D.h. deine "µC Auswahl" ist wirklich dein kleinstes Problem.

Hallo Andreas,

wenn Du selber fliegst, weisst Du ja, gegen welche "Mitbewerber" Du 
antrittst (Skytraxx,Syride,XC Soar Anpassungen,Flymaster, Oudie etc pp). 
Momentan ist eine reine Drucksensor Auswertung komplett out; fast alle 
Varios auf dem Markt haben neben dem Drucksensor auch Gyroskope, 
Thermometer und G-Sensoren, die die Steig- und Sinkwerte recht komplex 
aus all diesen Faktoren ermitteln. Du solltest deine Peripherieansprüche 
also schon etwas anpassen. Es gibt zwar Fluganwendungen auf Handies mit 
Druckdosen, aber normalerweise reichen die nicht aus für die 
Anforderungen eines Varios. Auch die grafischen Aufbereitsungsoptionen 
der Geräte auf dem Markt sind ja z.T. schon sehr ansprechend und 
komplex, das wird sehr viel Arbeit erfordern, Höhenprofile etc 
aufzubereiten.

Ausserdem gibt es vier Faktoren, an die oft nicht gedacht wird, die aber 
gerade beim Tütenfliegen enorm wichtig sind:

1. Energiesparen, um auch bei mehrtägigen Ausfahrten lange Flüge loggen 
zu können, ohne dass der Akku schlapp macht;
2. Robustheit - unsanfte Landungen sind ja nicht immer ganz 
unvermeidbar, und so ein Gerät muss schon mal etwas aushalten können. 
Das schliesst schon mal mechanisch anfällige Komponenten aus.
3. industrieller Temperaturbereich - ich bin eine Zeitlang mal mit einem 
Kobo Mini mit XC Soar drauf geflogen, habe es u.A. deswegen aufgegeben, 
weil das Gerät im Frühjahr bei grösseren Höhen schon Mal im wahrsten 
Sinne des Wortes eingefroren ist.
4. Einfachheit der Bedienerführung - Touch kannst Du in der Regel 
vergessen. Fast Alle Geräte auf dem Markt haben 4-Knopf Tastaturen, die 
auch mit Handschuhen bedienbar sein müssen und wo sehr viel Hirnschmalz 
da rein gesteckt wurde, die Bedienerführung so zu gestalten, dass man 
auch dann, wenn es "zur Sache geht," mit dem Gerät noch umgehen kann.

Das Skytraxx hat m.W. nach einen ARM Cortex an Bord. Das ist wegen der 
Middleware, die deinen Anforderungen genügt, auch sinnvoll (ich weiss 
nicht, ob es viele SD Karten Bibliotheken oder Grafikbibliotheken für 
AVR32 gibt).

Wenn ich so ein Projekt angehen wollte, würde ich glaube ich eher beim 
Vario und/oder GPS auf eine bestehende Lösung zurückgreifen (BlueFly, xc 
Tracer o.ä.) und mich dann auf die Weiterverarbeitung der Daten 
fokussieren. Besser als diese Geräte kann man es ohne Vollzeitarbeit 
über mehrere Jahre nicht hinkriegen, auf jeden Fall nicht zu dem Preis.

Falk B. schrieb:
> Soso, "sharen". Früher (tm) hat man es geteilt oder vorgestellt, im
> proefssionellen Umfeld auch veröffentlicht.

Falk, Du erinnerst mich mit Deinen ständigen
"Soso, "...". Früher hat man..."
irgendwie an Sam, den Adler aus der Muppet-Show, stets auf kulturelles 
Niveau bedacht und dann Wayne und Wanda ansagend...

;D

Und Du, Mister-Minus-Man, bist Waldorf und/oder Statler.   :)

Happy Weekend!

(Soso, .... früher, ....)


PS: Ah, und!   :D

Andreas schrieb:

> Abgesehen von den Messwerten, welche alles max. 16bit Werte
> sind gehe ich davon aus dass ein 16bit Controller mit Datenverarbeitung
> und paralleler Ausgabe an Grafik Display an seine Grenzen gelangt.

Das was Du da vor hast haben wir vor 15 Jahren auf x51 kompatiblen 
Atmels bzw. 166ern gemacht. Die letzteren haben sich dabei auch noch arg 
gelangweilt. Wie heutzutage mit Kanonen auf Spatzen geschossen wird ist 
Zeugnis davon, dass fast keiner mehr versteht, was sein Compiler macht 
und wie man effektiv Programmiert.

Ruediger A. schrieb:
> gegen welche "Mitbewerber" Du
> antrittst
Ich glaube nicht, dass er sich da als "Mitbewerber" sieht. So wie ich's 
verstanden habe, soll es ein Hobby-Projekt werden mit Schwerpunkt auf 
dem Lern-Effekt.

Ruediger A. schrieb:
> Momentan ist eine reine Drucksensor Auswertung komplett out;
Ja, inzwischen ist das so. Aber davor hat sich gefühlte Jahrhunderte 
lang gar nichts getan, da die Platzhirsche fest im Sattel gesessen 
haben. Erst die Bastler-Szene und die "kleinen Krauter" wie Bluefly, 
Stodeus, SkyBean usw. haben da endlich wieder Bewegung rein gebracht.

Da finde ich es schon ganz witzig zu sehen, mit welch geringem Aufwand 
man etwas basteln kann, wofür Bräuniger & Co. noch hunderte von Euro 
haben  wollten (und das mit veralteten Drucksensoren).

Die Frage ist halt: Was soll es wirklich werden?
Andreas schrieb ja, dass er nur 30s loggen will. Das hört sich nicht so 
an, als wolle er den ganzen Track loggen.
Wenn es aber nur ein "BipBip" werden soll, dann hast Du sicher insofern 
Recht, als man dann eher das GPS zugunsten eines Beschleunigungs-Sensors 
rausschmeißen kann.

Ruediger A. schrieb:
> würde ich glaube ich eher beim
> Vario und/oder GPS auf eine bestehende Lösung zurückgreifen (BlueFly, xc
> Tracer o.ä.) und mich dann auf die Weiterverarbeitung der Daten
> fokussieren.
Hm, bei mir wäre es umgekehrt. Ich würde mich mit dem Auslesen und 
Verarbeiten von Druck-, Gyro- und GPS-Daten wesentlich wohler fühlen als 
mit deren Weiterverarbeitung in einem von mir zu schreibenden 
Karten-Programm mit allen XC-Optionen.
Grüße aus Annecy