Sensoren und andere Geräte parametrieren
Sensoren und andere Geräte parametrieren
Hallo Freunde,
jetzt melde ich mich auch mal...
Ich stelle zuerst die wesentlichen Eigenschaften der angestrebten Parametrierung vor:
Es werden Datenstrukturen definiert mit dem Ziel zu beschreiben was für Parameter der Sensor hat und wie sie darzustellen und zu verändern sind. Ebenso soll ein Protokoll festgelegt werden für ein einheitliches Auslesen der Parameter-Werte und -Beschreibungen und zum Zurückschreiben der veränderten Parameterwerte.
Es soll mehrere Implementierungen geben für die erforderlichen Geräte und Software:
- Absolut genial ist die Verwendung des robbe-Schlüsselanhängers Nr. 8642, der hardwaremäßig ziemlich genau alles mitbringt was man für diese Aufgabe braucht. Ingo hat da schon vorzeigbares geschaffen.
- Selbstverständlich muss es auch eine echte PC-Lösung geben; Teil meiner Arbeiten ist es, eine sehr einfache PC-Implementierung (Konsolprogramm) zu machen, die z.B. über den Multiplex-USB-Adapter (85149) Parametrierungen vorzunehmen.
- Darüber hinaus soll es erweiterte Implemenierungen geben, z.B. eine schicke GUI für das PC-Konsolprogramm oder für andere Hardware (z.B. eine Bluetooth-Anbindung ans Handy und ein Java-MIDP-Programm o.ä.). Hier sind wir beide jedoch nicht aktiv, es macht genug Arbeit eine grundlegende Implementierung auf die Beine zu stellen. Hier gibt's reichlich Möglichkeiten für weitere Entwickler...
Es ist klar, dass ein Sensor, der mit diesem System parametriert werden soll, gewisse Anforderungen mitbringen muss: Die Datenstrukturen und das Protokoll. Man muss also Funktionen einbauen, die vorgegeben sind, und man muss sich mit der Speicherung und Verarbeitung der Parameter an Vorgaben halten, die vielleicht nicht 100%ig genau so aussehen, wie man sich das schon immer gewünscht hat...
"Unser" Verfahren kann sicherlich nicht so komfortabel wie das von Multiplex sein. Eines wollen wir jedoch "besser" machen: Ein neuer Sensor, der die Vorgaben korrekt einhält, soll "sofort" und ohne Updates mit den vorhandenen Parametrierern (robbe-Schlüsselanhänger und PC) eingestellt werden können. Dies ist erforderlich wenn ein unstrukturierter Haufen von MSB-Sensor-Entwicklern (smile) dieses Verfahren gemeinsam nutzen möchte. Bei Multiplex sieht dies anders aus: Alle Entwickler sind in der gleichen Firma (und haben den gleichen Chef und gemeinsame Vorgaben und Ziele) und diese Firma hat eine eingespielte Infrastruktur um ihre Kunden mit Updates und Parameter-Infos zu versorgen - dort läuft das also sinnvollerweise anders und insbesondere sicherlich bequemer für den Kunden ab als "wir" das je können.
Man wird nicht nur Sensoren mit dieser Methode parametrieren wollen sondern möglichst viele ähnliche Geräte; dazu gehören z.B. auch spezielle Aktoren wie Drehzahlsteller (wie viele "Programmer-Cards" gibt's eigentlich schon für die vielen Drehzahlsteller?) oder auch die Haptik-Render-Engine, die ich letztes Jahr in meinen Sender eingebaut habe.
Es ist nicht einfach, sicher genug in die Zukunft zu schauen um zu sehen, was für Parameter denn in ein paar Jahren in den Sensoren etc. sein werden, die mit dieser Methode dann eingestellt werden können sollen - das wird sicherlich jeder glauben. Eine Liste von Parametertypen aufzustellen, die "alles abdeckt", ist ein langwieriger Job.
Eine weitere Anforderung an dieses Verfahren, wenn es sich durchsetzen sollte, ist die Überprüfung der Einhaltung der Standards oder, besser, Hilfsmittel zur einfachen Einhaltung der Standards. Je mehr DIY-MSB-Junkies es geben wird (kann süchtig machen!) umso dankbarer wird man für Hilfsmittel sein, die Fehler vermeiden helfen.
Also: Ein gewisses Maß an Komplexität und Fehlerfreiheit - das muss unter ein Dach. Und das alles muss in eine Hardware rein, die g'rad mal ein paar KBytes Code zulässt. Es macht richtig Spaß.
Ingo hat schon was auf die Beine gestellt. Wir haben leider viel zu spät korrespondiert um jetzt schon eine gemeinsame Lösung zu haben. Ich habe inzwischen ein Tool entwickelt, das das Problem der Unterstützung zur Fehlerfreiheit angeht - es ist selbst noch nicht ganz fehlerfrei (lautes Gelächter). Sobald mein Zeugs, das in der kommenden Flugsaison was tun soll, das auch tut, mach' ich an dem Tool weiter.
Dieses Verfahren ist dort, wo Code im Flash-Speicher steht, dem von Ingo sehr (sehr!) ähnlich und es besteht selbstverständlich nach wie vor das feste Ziel, beide Verfahren zusammen zu führen, die Unterschiede liegen nur in den Datenstrukturen (und dem Tool). Hierfür gibt es eine allererste Beschreibung, der Ingo meint, sie sei
viel zu lang... na gut, richtig leichte Kost ist's nicht, da hat er schon recht - aber wenn's was werden soll muss man irgendwann hingehen und sorgfältig aufschreiben was man will und wie's gehen soll. Wer sich ernsthaft dafür interessiert möge mich bitte anschreiben, der kriegt dann 31 Seiten pdf. Bitte etwas Geduld mitbringen, ich lese zur Zeit nicht allzu oft hier im Forum.
Ich würde mich freuen, wenn sich mehr Leute, die MSB-Sensoren entwickeln wollen, auch an diesem Thema beteiligen. Es gibt vielleicht immer noch Lücken in unser beider Überlegungen, Tricks, die wir übersehen haben und es gibt durchaus noch Gelegenheit, Code beizutragen (z.B. Bluetooth & Handy-Java, Muster-Implementierungen der Update-Funktionen für verschiedene uController-Plattformen).
Ich will noch ganz kurz auf die Frage nach den verwendeten Controllern eingehen:
Der robbe-Schlüsselanhänger ist, ganz klar, ein ATMEL-Gerät.
Ich selbst programmiere zur Zeit mit den kleinsten Freescale-Controllern; falls da jemand mitmachen will (ernsthaft): Ich kann einen SpYder-Debugger den ich auf der electronica gekriegt habe, abgeben - damit ist ein sehr kostengünstiger Eintieg möglich. Ich habe auch noch die Absicht, TI-Controller einzusetzten. Bei beiden Lieferanten schätze ich sehr, dass sie
billige Debugger zur Verfügung stellen.
Genug für heute.
Schöne Grüße aus Olching,
Helmut
) eingeschaltet . Alternativ könnte ich mir einfache Pegelschalter vorstellen die so eingebaut werden das sie schalten wenn die kritische Menge erreicht / unterschritten wird
