Das „Custom Programming Tool“ in Atmel Studio

Schon länger gibt es in Atmel Studio die Möglichkeit, ein eigenes Programming tool zu verwenden:

Hat mich bis jetzt nie wirklich interessiert, da ich entweder über einen in-circuit-Programmer (der direkt unterstützt wird) flashe oder FastBoot manuell startete.

Zu viele Klicks bzw. Tastaturakrobatik. Also doch mal mit dem bereits Vorhandenem spielen.

echo „foo“ macht was es soll:

Prima, also kann ich einfach die burn.bat im Projektverzeichnis einfügen und los geht’s!

Nope. Da passt wohl das Arbeitsverzeichnis nicht. Aber wie kommt man ins aktuelle Projektverzeichnis? Zunächst versuchte ich mich an den Platzhalter der „External Tools“. Allerdings wurde „$(ProjectDir)“ zu leer ersetzt.

Hmpf. Für die Buildautomatisierung gibt es noch die Build Events – klickt man dort auf „Edit #-build …“ und dann auf Show Macros, bekommt man eine längere Liste an Platzhaltern:

echo „$(MSBuildProjectDirectory)“ zeigt das aktuelle Projektverzeichnis 🙂

also schnell „$(MSBuildProjectDirectory)\burn.bat“ eingegeben und ab dafür!

Jaa-eein. Die Batch-Datei wird zwar ausgeführt, aber im falschen Arbeitsverzeichnis. Mist.

Eine kurze Suche bei Stack Overflow lässt in das richtige Verzeichnis wechseln:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat

It verks!!1!

Jetzt steht in der dämlichen Batchdatei halt noch der feste Pfad zum Binary und es wird immer die Debug-Config über den UART geschoben. Ein bisschen mehr Makro-Magic und ein %1 an der richtigen Stelle (die zu flashende Datei) mit folgendem Command erledigt den Job:

cmd /k pushd $(MSBuildProjectDirectory) & burn.bat „$(Configuration)\$(OutputFileName).hex“

Da in der burn.bat in meinem Fall eh nicht mehr als ein Aufruf von fboot.exe ist, kann die Batch-Datei auch komplett weggelassen werden:

cmd /k pushd $(MSBuildProjectDirectory) & fboot /B57600 /C1 /P“$(Configuration)\$(OutputFileName).hex“

Jetzt müsste man nur noch die Ausgabe des Build und des Custom programming tool gleichzeitig anzeigen können, dann wäre ich richtig happy 😉

PS: Bitte beim Copy & Paste der Befehle die Anführungszeichen manuell ersetzen, WordPress macht sie typografisch korrekt aber funktional kaputt.

Ich fahre, also bin ich

Autonomes fahren ist in aller Munde, die meisten Hersteller sind aber eher zurückhaltend. Einzig Tesla ist innovativ, mutig oder dumm genug mit seinem „Autopilot“ vorauszupreschen und hat bereits einige Unfälle, viele beinahe-Unfälle und bereits  Todesopfer gefordert.

Im ersten Fall, weil das hauptsächlich kamerabasierte System unter schwierigen Lichtbedingungen einen querenden Lastwagen (was softwareseitig noch nicht unterstützt wurde) fälschlicherweise als Schild erkannt hat. Mobileye, der Hersteller der verwendeten Bildauswertungsplattform im Fahrzeug wies die Schuld von sich und beendete die Zusammenarbeit mit dem Automobilhersteller. Wohl aus Selbstschutz, denn auch andere Hersteller verwenden deren Systeme für Assistenzsysteme.

Die Bundesanstalt für Straßenwesen hat zumindest dem System im Model S als eine „erheblich Verkehrsgefährdung“ (keine Primärquelle gefunden) bezeichnet. Einfach mal die Zusammenfassung hinter dem Link lesen, das reicht. Man muss dazu sagen: der Verkehr in den USA ist sicherlich anders, Highways sind langsamer und zusätzlich sind die Geschwindigkeitsunterschiede zwischen den Fahrzeugen sicher niedriger. Bei fehlender Straßenmarkierung einfach dem Vordermann folgen (und bei dessen Einscheren nach dem Überholen das Fahrzeug nebenan abdrängen/rammen) ist allerdings mehr als stümperhaft.

Zumindest hat Tesla den Namen für sein System relativ gut gewählt: „Autopilot“, nicht „Auto(nomous)drive“. Ein Autopilot in der Avionik sorgt in aller Regel für eine stabile, gerichtete Fluglage und Kurs, nimmt dabei aber keine Rücksicht auf andere Verkehrsteilnehmer. Er nimmt den Piloten zwar Arbeit ab, ersetzt sie aber nicht. Obwohl die Systeme mittlerweile auch das Landen übernehmen können, müssen die Piloten aufmerksam bleiben, überwachen und wenn es sein muss eingreifen. Wie würden Passagiere reagieren, wenn sich so etwas im Cockpit abspielen würde?

Wie Piloten dürfen auch Benutzer des stark ausgebauten Fahrerassistenzsystems nicht die Aufmerksamkeit auf das Verkehrsgeschehen verlieren.

Das ist schwierig und verlangt umdenken. Ich war zwar noch nicht in einem so stark automatisierten Fahrzeug unterwegs, allerdings in welchen, die bei denen man auf der Autobahn schon fast loslassen könnte: Abstandsgeregelter Tempomat, Spurhalte- &  Seitenassistent, Schildererkennung und den ganzen anderen Schnickschnack.

Solange man sich auf der Standardautobahn in halbwegs absehbaren Situationen befindet, super entspannt und man fühlt sich sicher. Die einzige Frage, die ich mir mittlerweile stelle: wie gut ist die Illusion?

Der Abstandsregelautomat bremste mich aus, als in einer langgezogenen Linkskurve das vorausfahrende Fahrzeug links abbog (und deutlich langsamer wurd). Für die hinter mir  muss ich wohl wie der dümmste Fahrer aller Zeiten gewirkt haben. Die Straße frei, und der Vollpfosten in der dicken Karre bremst. Für das Radar war das aber plausibel, weil der Verkehrsteilnehmer noch vor mir war.

Die nächste, schon öfter erlebte Situation: Spurhalteassistenz in Baustellenbereichen mit gelben und weißen Markierungen und nicht optimale Sicht. Das Auto wollte den weißen Spuren folgen. Mein Lenkeingriff war noch nicht grenzwertig aber doch unangenehm. Mittlerweile mach ich das System in solchen Situationen aus – nur wenn es wirklich frei ist, mach ich etwas „thrillseeking“ – wird die richtige Spur diesmal erkannt? Nein. Ratsch. Auch spontanem Ausweichen (habe ich zum Glück noch nicht testen „dürfen“/müssen) wäre damit sicher ein „Spaß“: „oh, du verlässt deine Spur – moment, ich mach mal“. Blech oder im Zweifel Leben.

Von der Schildererkennung wurde ich immer wieder enttäuscht. Immer wieder wurden Aufhebungsszeichen nicht erkannt, Ortsschilder schon gleich gar nicht und das Display sagte 80 innerorts. Mit Verstand im Standby würde das immerhin 120 Euro und einen Punkt kosten.

Da ist mir der Seitenassistent noch am liebsten. Zumindest bei einer Marke. Ist ein anderes Auto im „Anmarsch“ und man setzt den Blinker, holt sich der Außenspiegel Aufmerksamkeit. Beim ersten Mal habe ich mich gewundert, wo denn der Blitzer stand. Ohne Blinker und Gefahr beim Ausscheren glimmen die LEDs nur. Sehr komfortabel, aber auch zuverlässig? Ich bin mir sicher, viele kommen irgendwann an den Punkt, an dem sie dem System sprichsprichuwörtlich blind vertrauen und keinen zweiten Blick wagen. Was, wenn in solchem Fall die Anzeige durch einen schlechten Kontakt ausfällt? Die Folgen können fatal sein.

Das waren jetzt nur drei ADAS-Systeme und auch nur eingeschränkt gültige Erfahrungen. Aber sie zeigen dass sie Aufmerksamkeit noch nicht ersetzen können.

Beim autonomen Fahren muss intensive Datenfusion stattfinden, sich einzig auf eine Informationsquelle zu verlassen wäre grob fahrlässig. Bliebe ein Blatt an einer Kamera kleben, wäre es plötzlich vorbei mit dem Selbstfahrer, genauso wie ein mitgenommener Vogel vor dem Radar. Auch können Sensoren ausfallen oder unbrauchbar Informationen liefern, wie GPS im Tunnel oder Kameras bei Nacht. Man darf aber au bei nicht außer Acht lassen, dass Daten bewusst oder unbewusst manipuliert werden können. Der übelste mir bekannte Fall ist, dass ein Sicherheitsforscher aus größerer Entfernung einem LIDAR ein Objekt in wenigen Metern Entfernung vorgaukeln konnte. Die Steinewerfer der nächsten Generation sind also mit Laptop und Laser bzw SDR unterwegs?

Zu den selbstgewonnenen Daten kommen noch (in aller Regel vorverarbeitete) Fremddaten: TMC, Karten (nicht umsonst haben sich die dt. Automobilhersteller zusammengetan und Here Maps gekauft) und X-to-Car-Kommunikation. Besonders letzteres dürfte meiner Meinung eine erhebliche Rolle spielen, um Verkehrs- und Streckendaten auszutauschen und dem Blechfahrer genügend Informationen für die Fahrt zu geben. Das Problem ist hier sicher das flächendeckende Vorhandensein entsprechender Kommunikationspartner, denn Weitblick und Urteilsvermögen ist etwas, das man Software nur nur sehr schwer beibringen kann.

Eine Firma, die sich in letzter Zeit intensiv mit Supercomputing beschäftigt, möchte autonomen Fahren auf Basis von künstlicher Intelligenz bzw. deep learning entwickeln. Das Problem ist hier sicherlich, dass das Verhalten nicht wie bei konventionellem Quellcode durchblickt werden kann. Zwar lässt sich das Verhalten durch Simulation bzw. Stimulation erfassen, man bekommt allerdings ein Beobachterproblem: alle möglichen Konstellationen können faktisch nicht abgedeckt werden. Zudem: was, wenn der KI (un-)absichtlich schlechtes Verhalten beigebracht wird? Oder was, wenn Visionen aus Hollywood Wirklichkeit werden und der „Ghost in the machine“ Menschen als Gefahr ihrer selbst erkennt? Nicht, dass ich neuronale Netze grundsätzlich für schlecht halte, es ist tatsächlich ein extrem interessantes Feld – nur habe ich ehrlich gesagt kein gutes Gefühl, mein Leben in die Hand eines künstlichen Gehirnes mit der Intelligenz eines 2-3-jährigen Kindes zu legen.

Auch bei den klassischeren entwickelten Systemen hätte ich als „fahrtüberwachender Passagier“ ein Problem: Man weiß nie so genau, was das Auto in seiner Umgebung erkannt hat, siehe meine ADAS-Erfahrungen von oben. Um ein besseres Gefühl zu haben, würde ich gerne wissen, was das Fahrzeug im „sieht“ und was es für die nächsten Sekunden plant. Die hierfür benötigten Daten sind vorhanden, eine entsprechende Visualisierung habe ich schon gesehen – aber nicht im Produkt für Kunden. Ich vermute, dass dies die Kontrollfunktion der Benutzer verbessert und eine bessere Akzeptanz bringen kann, da vermutlich viele um Kontrollverlust und ihre Sicherheit bangen.

Zum Thema Sicherheit (im Sinne von Safety) gab und gibt es eine von vielen noch nicht beantwortete ethische Frage: Darf man per Software entscheiden, wer bei einem unvermeidlichen Unfall stirbt? Das Szenario geht immer in die Richtung: Ein Fahrzeug fährt autonom, ein Kind rennt auf die Straße. Links ist eine ältere Person, rechts eine Mauer. Geradeaus weiter und das Kind stirbt. Links ausweichen bedeutet den Tod der älteren Person. Ein Manöver nach rechts würde zwar die die beiden Passanten retten, aber die Insassen opfern. Die Robotergesetze funktionieren hier leider nicht. Es gibt verschiedene Vorschläge, von Statistik (wer hat die besten Überlebenschancen) über Philosophisch und ethisch bis zum Zufallsprinzip. Einzig Mercedes hat sich (meines Wissens) bis jetzt klar für den Insassenschutz ausgesprochen und opfert schwächere Verkehrsteilnehmer. Würde sich auch schlecht im Kleingedruckten einer Broschüre lesen: „In Ausnahmesituationen kann die Software unseres autonomous drive Ihren Tod herbeiführen, um das Leben anderer Verkehrsteilnehmer zu schützen“.

Der wahrscheinlich einzige Schritt, autonomes Fahren möglichst sicher und effizient zu machen, wäre den Menschen komplett aus dem Verkehrsgeschehen herauszunehmen. Würden Computer alle unsere Fahrzeuge lenken, könnten sie sich durch Vernetzung und Determinismus vermutlich zu einem perfekten Fortbewegungsmittel entwickeln. Vielleicht. Wenn wir es wollen.

Flashen für faule

Und gleich noch einer hinterher:

Hintergrund für das gerade eben gebloggte visacon ist meine akute Faulheit. Weil am aktuellen Mikrocontroller-Projekt die Pins vom ISP anderweitig verwendet werden sollen, musste ein Bootloader auf den AVR. Die Wahl fiel auf Peter Danneggers FastBoot, den ich mit einem anderen Initstring kompiliert habe. Zunächst wollte die 64-Bit-Version von fboot.exe nicht damit sprechen. Für AVRDUDE gibt es zwar einen Patch, der hat es in fast 5 Jahren aber nicht in in die offizielle Version geschafft. Ich habe es versucht, mit Cygwin und MinGW, aber ich bin offenbar zu blöd, diese Software zu kompilieren.

Also habe ich UpdateLoader von Luani verwendet. Das hat eine ansprechende GUI und funktioniert auch prächtig mit meinem abweichenden Passwort, nur hat das Teil einen Nachteil: Es nimmt als Argument nur eine HEX- oder INI-Datei an. Keine wirkliche Scriptingfähigkeit. Ok, Sourcen sind vorhanden, aber ehrlich gesagt wenig Zeit und Lust, mich in Pascal und dessen Entwicklungswerkzeuge einzuarbeiten.

Bleibt die Frage: was macht UpdateLoader anders als fboot? Der Logic Analyzer liefert Erkenntnisse: Leo-Andres war so clever und stellt dem Passwort das Steuerzeichen \r voran. In der Protokoll-Beschreibung vom Bootloader steht auch, dass für die Bestimmung der Baudrate ein high-bit und vier low-bits erwartet werden. im Standardpasswort „Peda“ macht das das „a“ (binär 01100001). Was passiert nun, wenn ich meinem Passwort ein „a“ voranstelle – also nur bei der Verwendung von fboot.exe?

>fboot /C7 /B115200 /IaXYZ /P"program.hex"
COM7 at 115200 Baud: Connected
Bootloader V2.1
Target: 1E9403 fbDEF
Buffer: 512 Byte
Size available: 15872 Byte
Program program.hex: 00000 - 00533 successful
CRC: o.k.
Elapsed time: 0.64 seconds

läuft.

Nur muss ich jedes Mal PuTTy beenden, das Netzteil ausschalten, fboot anwerfen, Netzteil einschalten, PuTTy wieder starten. Muss ich? Nein.

PuTTy kann Profile – und man kann ihm sagen, einen bestimmten Fenstertitel zu verwenden:

putty_fenstertitel

Das ganze als Profil abgespeichert, schon kann man das Programm nach seinen Wünschen per Kommandozeile lostreten:

start putty.exe -load "meinprofil"

Warum das alles? Natürlich um PuTTy ganz einfach beenden zu können:

taskkill /fi "IMAGENAME eq putty.exe" /fi "WindowTitle eq meintitel" /f

Okay, dass man fürs Starten und Beenden ggf. unterschiedliche Bezeichnungen braucht, ist nicht so edel, genauso könnte die Gegenstelle den Fenstertitel verändern. Aber es funktioniert. Debug-Anzeige geht auf und das Flashen kann gestartet werden. Nur muss für das Flashen ein Reset vom Mikrocontroller ausgeführt werden. UpdateLoader kann dazu die DTR-Leitung toggeln, fboot nicht. Aber wofür habe ich mein neuestes Tool geschrieben, wenn nicht für das?

Das Rigol-Netzteil kann außer laut sein auch über den PC gesteuert werden:

visacon.exe USB0::0x1AB1::0x0E11::<snr>::INSTR W "INST CH1; OUTP OFF"

Der Befehl wählt Kanal 1 aus und schaltet ihn sogleich ab. Mit ON statt OFF passiert (oh Wunder) genau das Gegenteil.

es gibt nun also eine kleine BAT-Datei auf meinem Rechner:

taskkill /fi "IMAGENAME eq putty.exe" /fi "WindowTitle eq meintitel" /f
visacon.exe USB0::0x1AB1::0x0E11::<snr>::INSTR W "INST CH1; OUTP OFF"
timeout 1
visacon.exe USB0::0x1AB1::0x0E11::<snr>::INSTR W "INST CH1" W "OUTP ON"
fboot /C7 /B115200 /IaXYZ /P"program.hex"
start putty.exe -load "meinprofil"

Der Timeout-Befehl gibt dem Elko auf der Leiterkarte Zeit sich zu entladen. Bis jetzt funktioniert das Ganze wie ’ne Eins.

Jetzt sollte nur noch Atmel Studio nach dem erfolgreichen Build… Moment:

AS7_Buildevents
Warum es dafür keinen Wiki-Artikel gibt? Steht doch oben, weil ich faul bin.

visacon

Messautomatisierung ist etwas tolles und – wenn man sich damit einmal grundlegend beschäftigt hat – vor allem sehr einfach. Nur leider braucht man in den meisten Fällen irgendeine Entwicklungsumgebung, um mit über VISA mit den Instrumenten zu sprechen. Es gibt zwar noch NI MAX oder Hewlentsight IO Libraries Suite, mit letzterem kann man zwar auch automatisieren aber für manche Anwendungen ist es einfach etwas unpraktisch.

Für manche Anwendungen würde eine einfache Batchfile absolut ausreichen, nur daraus VISA sprechen? Ich habe zumindest kein Programm gefunden. Mit VBS/JScript bzw. dem, was der Windows Scripting Host hergibt, geht es wohl auch nicht so einfach.

Man darf sich nicht über Dinge beschweren, die man selbst machen könnte. Also habe ich ein kleines Kommandozeilen-Programm geschrieben: visacon.

Es verwendet das, was National Instruments mit dem Bollwerk an Treibern mitbringt – die beiden Assemblies NationalInstruments.Common und NationalInstruments.VisaNS. An dieser Stelle sei noch darauf hingewiesen, dass ich nicht der Urheber dieser DLLs bin und auch keinerlei Rechte daran besitze. Der Compiler hat sie einfach gelinkt und im Release-Verzeichnis abgelegt.

Das Programm ist einfach gestrickt – es versucht die angegebene Ressource zu öffnen und führt dann Write- und Query-Befehle aus – die Syntax ist wie folgt:

visacon.exe <resourcename> ((W|R) „<cmd>“)+

Wer der Regulären Ausdrücke nicht mächtig ist: als ersten Parameter muss man den Resourcennamen (natürlich ohne spitze Klammern) angeben, danach W für einen Write-Befehl oder Q für einen Query-Befehl. Im Anschluss daran den jeweilig auszuführenden SCPI-Befehl. Die letzten beiden Argumente kann man beliebig oft wiederholen. Alle Ergebnisse der Queries werden in der Konsole ausgegeben. Tritt ein Fehler auf, wird die zugehörige Exception ausgespuckt.

Benötigt werden funktionierende VISA-Treiber, .NET 4.0 und die Kommandozeile.

Viel Spaß damit!