Hallo! Ich habe mit Eurer Hilfe ja erfolgreich mein Bordcomputer-Projekt für die alte Vespa realisiert. Derzeit messe ich die Abgastemperatur mit Thermoelement und Max6675, die Geschwindigkeit mit reed-relais, die Drehzahl mit einem Hallsensor und logge alle Daten auf SD-Karte. Einen Bootloader habe ich ebenfalls integriert. Ausgegeben wird alles auf einem 2*16 Zeichen LCD. Etliche Menufunktionen, Anzeigemodi und Warnfunktionen (zB bei zu hoher Temp) gibts auch. Nun stehen noch ein paar Dinge auf dem Wunschzettel für die zweite Version welche mir Kopfschmerzen machen da es sich zum Teil um zeitkritische Steueraufgaben (Auslasssteuerung, vielleicht Zündverstellung) handelt und zum Teil um zeitraubenden Kram. Ich würde gerne ein S65 Grafikdisplay betreiben. Ebenfalls ist angedacht ein GPS-Modul zu integrieren und die Daten mitzuloggen. Beide Aufgaben sind aufgrund der Datenraten der Geräte wohl sehr zeitraubend. So habe ich irgendwo gelesen das es 0,8 sekunden dauert um den sekündlichen refresh vom GPS Modul auszuwerten. Auch das Display ist nicht das schnellste. Ich habe mich nun gefragt ob es die beste Lösung ist einfach zwei Controller aufs Board zu packen. Der eine erfasst die steuerrelevanten Daten (das wär für den Moment eigentlich nur das Signal vom Hallsensor) und steuert, der andere macht den ganzen Schnickschnack inklusive der Ausgabe auf dem Display und lässt sich dafür so viel Zeit wies halt braucht. Vielleicht würde ich bei der Lösung sogar dazu übergehen einfach zwei Boards zu entwickeln. Eins für die Steuerung und ein für den Rest. Meine Frage ist eigentlich nur: schätze ich das alles vielleicht völlig falsch ein und das ist eigentlich ohne Probleme von einem Controller zu leisten oder lieg ich richtig mit dem Ansatz zu teilen? Grüße!
Also das läßt sich sicherlich mit einem COntroler machen. ABER Ich bin dazu übergegangen das zu trennen, ein µC kostet nicht so arg viel, habe das bei mir so gemacht das ich einen "größeren" Controller (Mega16) habe welcher die Meßdaten aufnimmt und verarbeitet un ein Tiny2313 kümmert sich nur um die Anzeige in diesem Fall das Multiplexing eines etwas größeren LED Moduls. Das hat den Vorteil, das wenn man die Anzeige erweitert oder sosntiges man nur ein board redesignen muß außerdem müllt man sich den Code des Steuer uC nicht unötig mit Ausgabe funktionen zumüllt. Das muß man aber son bischen selbst entscheiden. Wo haßt du den die 0,8 Sek her? Ich brauche z.Z. zum auswerten der GPS Daten vieleicht im ms bereich, kommt halt drauf an was man da noch groß rechnet, aber die Postion läßt sich z.B. sehr gut als Festkommazahl verarbeiten das geht recht fix.
In meinen Projekten, die zugegebenermassen nicht so komplex sind, mach ich folgendes: A) Die Applikation hat 3 Prioritätsstufen 0) Normale Applikation ab main() 1) Unterbrechbare Interrupts 2) Nichtunterbrechbare Interrupts für kurze, echtzeitkritische Aufgaben ad 1) zu Anfang wir die betreffende IRQ disabled, um sie gegen Iteration zu sichern. Am Ende wird gefragt, ob das IRQ-Flag gesetzt ist. Falls ja, spring ich wieder an den Anfang der ISR. Das spart einen ISR-Prolog und -Epilog. Wenn das Flag nicht gesetzt ist, wird die IRQ erlaubt und die ISR ist fertig. B) Interne Datenpufferung, um Resourcenengpässe zu nivellieren C) Das Hauptprogramm arbeitet komplett ohne Warteschleifen etc. Es gibt ein Countdown-Modul, über das alle benötigten (Warte-) Zeiten der Applikation blockierungsfrei realisiert werden können.
Läubi Mail@laeubi.de wrote:
> Wo haßt du den die 0,8 Sek her?
BASCOM?
#wegduck#
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.