Guten Tag Ich beabsichtige ein Variometer fürs Gleitschirmen zu bauen. Folgende Module möchte ich einbauen: - Drucksensor (Vario) >> 33khz 16bit A/D - GPS Modul (x,y,z Position + Zeit) >> I2C <400kbps - Grafik Display 128x64 (Ausgabe) >> SPI - SD Karte (30s Logging GPS Pos + div. AVG/Peak Werte) >> I2C - Bluetooth Modul optional (Übermittlung Datenlogging nach Aufzeichnung) 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. 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. Was meint ihr zu dieser uC Auswahl? Ich bin dankbar für Feedback. Gruss
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?
Kennst Du AVR32? Schon was damit gemacht? Bei Microchip ist AVR32 quasi EOL (End Of Life). Ja, sie verkaufen noch welche, solange noch Nachfrage ist, aber diese Architektur ist bei denen quasi auf dem Abstellgleis, weil neben ARM und MIPS (PIC32) eine dritte Architektur für sie keinen Sinn macht. Das solltest Du wissen. Aus strategischer Sicht, ist es besser, PIC32 oder ARM zu nehmen. Deine Anforderungen sind eh sehr generisch, da wirst Du mit so gut wie jedem Hersteller glücklich. > - GPS Modul (x,y,z Position + Zeit) >> I2C <400kbps GPS läuft meist über einen UART und NMEA 0183 Protokoll. > - Grafik Display 128x64 (Ausgabe) >> SPI > - SD Karte (30s Logging GPS Pos + div. AVG/Peak Werte) >> I2C SD-Karten werden über MCI (MMC Comunication Interface) oder SPI angesteuert. > - Bluetooth Modul optional (Übermittlung Datenlogging nach Aufzeichnung) braucht auch einen UART fchk
Hallo allerseits, danke für eure Meinungen. Cyblord -. schrieb: > 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?". Kann sein...das letzte Mal habe ich mich mit 32biter im Studium vor bald 10 Jahren versucht und seither nix mehr programmiert. Np R. schrieb: > Au ja, das wollte ich auch immer mal machen... > > Allerdings würde für ein einfaches Vario doch auch ein 8bitter reichen. > > 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. ;-) Wenigstens wärs fehlerfrei aufgezeichnet ;-) Ich beginne somit klein, 8biter mit LCD und Drucksensor, erweitere dann und wenns stolpert steige ich in die Höhen der 32bit Controller. Auf jeden Fall werde ich mein Projekt hier sharen. Gruss Andreas
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"
:
Bearbeitet durch User
Die AVR32 Serie mag ich gerne. Ich nutze den AVR32UC3C0512 in einem neuen Projekt. Aber nur, weil es einem bestehenden Projekt sehr ähnelt. Ansonsten hätte ich mich auch eher für einen stm32 entschieden. Leider wird tatsächlich die Infrastruktur (ASF, Toolchain, ...) bei Microchip nicht mehr gepu. Wenn die Anforderungen nicht ganz so hoch sind empfehle ich die STM32L4 Serie. Mit einem 8 Bitter würde ich ein neues Projekt nicht mehr anfangen, wenn nicht der Chip Stückpreis extrem sensibel ist. Und schon gar nicht für ein Bastel Projekt
Blume schrieb: > Wenn die Anforderungen nicht ganz so hoch sind empfehle ich die STM32L4 > Serie. In Assembler grausam zu programmieren. > Mit einem 8 Bitter würde ich ein neues Projekt nicht mehr anfangen, wenn > nicht der Chip Stückpreis extrem sensibel ist. Und schon gar nicht für > ein Bastel Projekt Seh ich genau andersrum. Der unbedarfte lernende Bastler hat so am ehesten die Chance, frustarm eine Lösung für sein Problem zu erhalten für das 8Bitter ja allermeistens ausreichen. Für ein Bastelprojekt erst recht.
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.
> (wenn du es selbst machst)
Du verstehst es nicht. Selbstmachen ist heute das Synonym fuer aus dem
Internet kopieren.
Was meinst du was das fuer ein Spass wird wenn diese Typen eines Tages
in der Firma aufschlagen...
Olaf
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.
:
Bearbeitet durch User
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
:
Bearbeitet durch User
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 kommt sicher drauf an, ob du auf dem Display nebenbei noch lustige Filmchen zeigen willst oder es dir nur um deinen Navigationsstatus geht.
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.
Für einen ersten Einstieg in STM32 empfehle ich Dir diese Anleitung: http://stefanfrings.de/mikrocontroller_buch2/index.html
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
:
Bearbeitet durch User
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.