Hüftknochen-Einschlagapparat

Eine Apparatur zum Erlernen des richtigen Hammerschlags bei Operationen an (künstlichen) Hüftgelenken. Eingebettet in einer AR-Anwendung, an deren Entwicklung ich nicht beteiligt war.

Doch dazu kam ich nur scheibchenweise, um schließlich doch alles machen zu müssen. Abgesehen von der Mechanik.

Linak-Servo

Irgendwas aus Dänemark mit Absolutwertgeber, was mir hier vorgesetzt wird.

Gegenstand

• Linearachse LA12 mit Hall-Potenziometer
• Steuerteil TR-EM-288-SAF, mit 24 V versorgt
• Bedienteil EM-236A via 6-pol. MicroMatch-Stecker

Das Bedienteil will irgendetwas standardisiertes sein, tatsächlich entpuppt sich die Parametrierungsschnittstelle als closed-source sowie (absichtlich?) falsch dokumentiert: Die im Datenblatt angegebene Baudrate stimmt nicht.

Bastelauftrag

Ziel ist es, das Bedienteil durch eine PC-Software zu ersetzen, um die Parametrierung durch Software erledigen zu können. Im Blick ist dabei LabVIEW.

Dazu muss das Protokoll erschnüffelt werden. In diesem Fall steht sigrok/PulseView sowie ein preisgünstiges CY7C68013A-Entwicklungsboard aus China zur Verfügung.

Gleich zu Anfang stellt sich heraus:

• 4800 Baud, 8 Datenbits, gerade Parität, 1 Stoppbit, nichtinvertiert, TTL (d.h. das Startbit ist Low)
• Das Bedienteil fragt an, das Steuerteil antwortet umgehend
• Interrupt wird nicht benutzt

Der „burst1“ erschließt sich durch scharfes Hingucken. Dabei ist [0A] die String-Länge. Das [0B] vermutlich die Paket-Länge; hier nur 1 Sub-Item. Die anderen Konstanten werden wohl nicht entzifferbar (= bedeutungslos) bleiben. Unklar ist noch, warum der burst1 mit einem unbeantworteten [01] endet. Könnte sein dass das bereits zum burst2 gehört.

Der „burst2“ ist ebenfalls entziffert. Darin ist vermerkt, wieviele Parameter und Werte es gibt, und welche 8 Bit und welche 16 Bit breit sind. Daraus ergibt sich die Einschränkung, dass 16-Bit-Parameter stets hinter allen 8-Bit-Parametern angeordnet sein müssen; das gleiche für die Werte. Und dass es maximal 79 (Parameter + Werte) geben kann, da Parameter 1 auf „Adresse“ 21 und Folgebytes von Mehrbyte-Werten auf „Adresse“ 100 (jeweils dezimal) abgefragt werden.

Da auf dem Zielrechner das LabVIEW streikt, wurde kurzerhand das Programm in C++ in Visual Studio 6 erstellt. Alle Werte werden korrekt angezeigt. Die Zeilentitel können vom Anwender geändert werden und werden persistent je nach angeschlossener Steuerung (Name als Referenz) in der Registrierung gespeichert. Die Parameter können vom Anwender zwar editiert werden, werden jedoch noch nicht zur Steuerung zurückgeschrieben. Ein Tastaturinterface zum Umbenennen der Zeile bzw. zur Wertänderung ist (seitens Windows) nicht vorhanden, wird wohl noch mit F2 bzw. F3 realisiert (Explorer-kompatibel).

Das gesamte Teilprojekt, den Linak-Servo zu „reverse-engineeren“ erwies sich nachfolgend als hinfällig, da die entscheidende Steuerungsgröße Kraft nicht verfügbar ist und die Alternative Weg nur per Analogwert vorgebbar ist.

Gesamtlösung

Nun kommt die Katze aus dem Sack: Der Linak-Servo dient dazu, eine Fahrradbremse anzuziehen. Da sich alles bloß nicht die Stellkraft und die Position des Servos digital einstellen lässt, müssen mechanisch federnde Elemente dazwischen (Hebel, Bowdenzug) die Proportionalität von Weg und Kraft herstellen und ein Analogwert legt die Position fest. Der FT232R-Adapter wird wieder frei und durch die Firmware des Arduino(?) ersetzt. Zum Einsatz kam schließlich ein Board mit STM32F103. Und eine Firmware mit WebUSB für die Funktionsdarstellung im Browser.

Hinfällig: Da dies nicht ohne Bauchschmerzen mit einem Arduino Uno geht, tendiere ich umgehend zu meinem Liebling Arduino Leonardo mit nativem USB-Interface. Das Computerprogramm soll in LabVIEW laufen und mit dem Versuchsaufbau über USB (genau 1 Kabel) kommunizieren.

Zusätzlich soll noch eine mit einem Hammer einwirkende Kraft gemessen werden. Im Vorversuch wurde eine Abtastrate von 20 kSa/s als geradeso ausreichend festgelegt, um den Kraftstoß zu erfassen. Eine geeignete Kraftmessdose mit Dehnmessstreifen wurde konstruiert, aufgebaut und eingebaut. Zur Erfassung des Kraftstoßes fallen die üblichen Wägezellenverstärker mit Sigma-Delta-Umsetzer aus; diese sind viel zu langsam.

Und ein Verschiebeweg wird mit einem digitalen Messschieber aufgenommen. Der misst nur langsam; die Position vor und nach dem Hammerschlag genügt. Die üblichen Messchieber haben 1/100 mm = 10 µm Auflösung. Siehe auch caliper2pc.

Schließlich soll die Festhaltekraft (Bremskraft) außer durch das Computerprogramm auch analog an einem Potenziometer eingestellt werden können.

Die Linak-Steuerung benötigt zudem ein Netzteil mit 24 V und 2,2 A. Dass diese ihrerseits 5 V liefern kann wird hier nur genutzt, um der Steuerung einen Analogwert vorzugeben.

Der allfällige Vorverstärker für die Kraftmessdose mit OPA2376 verstärkt das Brückenausgangssignal um den Faktor 300, allein mit R4 einstellbar. R2 dient zum Brückenabgleich. Durch die Gegenkopplung des OPV arbeitet die Brücke im Kurzschlussbetrieb, und es wird effektiv der Diagonalstrom in eine Spannung gewandelt.

Hinfällig: Die Variante mit dem teureren und größeren Arduino Micro verwendet den differenziellen A/D-Wandler mit umschaltbaren Verstärkungen (×1, ×10, ×40 und ×200), um verschieden starke Schläge angemessen erfassen zu können. Leider bleiben dann nur 8 Bit Auflösung laut Datenblatt übrig, und man muss die Schlagstärke a priori kennen.

Die Variante mit dem chinesischen Pro Micro verwendet einen Instrumentationsverstärker und muss asymmetrisch messen, da bei diesem weder ADC0 noch ADC1 (noch AREF) herausgeführt ist. Dafür gibt es 10 Bit Auflösung.

ATmegas sind für die Abtastung des Kraftstoßes etwas überfordert. Externe A/D-Wandler erscheinen Overkill. Daher tendiere ich nun eher zur Verwendung eines STM32F103C8T6 auf einem Bluepill-Board. (Liegt schon zu Hause herum.) Den fälligen USB-Seriell-Konverter, den man leider zum Betanken dieses Boards benötigt, gewinne ich vom FT232R-Adapter für den Linak-Servo.

Der 12-bit-A/D-Wandler schafft 1 MSa/s, und es sind zwei davon drin. Leider nicht differenziell, daher Single-Ended-Konvertierung mit OPA2376 + INA155 (liegen herum, waren wohl kostenlose TI-Muster gewesen). Das USB-Interface wird wieder als WebUSB implementiert. Um Betriebsspannungskollisionen auszuschließen liefert der Linak-Servo die 5 V für den Verstärker vom PWM-Ausgang: Die Linak-Steuerung bekommt einen Analogwert nur dann, wenn diese auch 5 V liefert, also eingeschaltet ist. So kommt die gesamte Schaltung ohne wacklige 5 V vom USB aus, sondern vom 3,3-V-Festspannungsregler auf dem BlackPill-Board.

Die verwendeten Analogschaltkreise:

• OPA2376 = Vorverstärker 300× für Kraftsensor
• INA155 = Differenzverstärker (Potenzialversetzer) 10× oder 50× für Kraftsensor
• LM393 = Pegelwandler 1,5 V => 3,3 V für Messschieber
• OPA2350 = Pegelwandler 3,3 V => 5 V für Analogausgang

Blaue Pille, Schwarze Pille

Hoppla, ich hatte wohl die schwarze und nicht die blaue Pille genommen! Da unterscheidet sich die Pinbelegung ganz erheblich! Die Pin-1-Festlegung der Stiftleisten erscheint willkürlich, ich habe es hier wie bei DIL-Schaltkreisen umlaufend nummeriert.

 

Zur besseren Übersicht über herausgeführte Pins und deren Sonderfunktionen diese sortierbare Tabelle — Angaben ohne Gewähr:

Hinfällig: Um sich den Analogvergleicher zu sparen (leider ist keiner drin) erfolgt die Pegelkonvertierung vom Messschieber mittels A/D-Wandler. Der ist mit seinen 1 MSa/s eh' schnell genug.

Urschleim: Der Urlader

Der STM32F103 kommt leider ohne USB-Urlader ab Werk. Und leider ist das Angebot von Urladern aus der Arduino-Szene ungenügend. Der beste zu findende ist ein HID-Urlader von serasidis.gr (aus Griechenland) mit 2 KiByte Platzbedarf, leider per Jumper BOOT1 zu starten: Zu umständlich. Eine Neukompilierung ohne Interrupts und ohne angezogene Handbremse (hier: USB-FIFO-Größe von 8 auf 64 Byte geändert) ist nun so gestaltet, dass man mit der Reset-Taste zum Urlader kommt; alle anderen Reset-Ursachen (bspw. Strom weg) führen zum Anwendungsprogramm, für das noch 62 KiByte Flash-Platz übrig bleibt. (Auf 1 KiByte ist der Urlader wohl nur mit ARM-Assembler hinzubekommen, wenn überhaupt. Wenn man bedenkt, dass der „Original“-Arduino-Urlader schlappe 20 KiByte wegschnappt, ist das schon ganz gut.) Zudem waren die Programme für seriellen Zugriff (stm32flash.exe) und HID-Zugriff (hid-flash.exe) viel zu groß; wurden mit MSVC6 auf 1/4 der ursprünglichen Größe eingedampft, ohne den Quelltext auszulichten. Bei „hid-flash“ ging mir der Zwang zum COM-Port (!) auf den Keks, dieses ist jetzt allenfalls optional, da eine Steuerung von BOOT1 nun nicht mehr erforderlich ist.

Hier ist alles dokumentiert und herunterladbar.

Implementierung

Auf einem für mich neuen Mikrocontroller etwas zu implementieren, was auch noch an die Grenzen des Machbaren geht, ist ein Weg mit vielen 🪨 Stolpersteinen.

USB

Das WebUSB-Interface war, ausgehend vom Urlader, recht schnurstracks hinzubekommen. Man muss allerdings aufpassen, dass der Controller nicht in Interruptroutinen erstickt! Im Gegensatz zum AVR, wo bei 100 % Interruptlast das Hauptprogramm mit wenigstens 1 Instruktion pro Interrupt vorankommt (also im 🐌 Schneckentempo), geht beim STM32F103 „dank“ Interruptverkettung (tail chaining) gar nichts mehr! 🛑 Man sagt, die Hauptschleife verhungert. Und so suchte ich den Fehler prompt an der falschen Stelle.

Messschieber

Bei der Entscheidung, den Analogvergleicher LM393 wegzulassen und stattdessen den A/D-Wandler zu benutzen hatte ich mich wohl 🐎 vergaloppiert! Denn das Taktsignal des Messschiebers kommt mit immerhin 80 kHz, man muss es mit 200 kSa/s abtasten. Das passt gerade so ins Taktregime, wenn man die 4 A/D-Eingänge zyklisch abtastet, mit minimaler Abtastzeit: Der A/D-Wandler, der mit 12 MHz getaktet wird, benötigt 14 Takte pro Kanal, das ergibt eine Kanalabtastrate von 12 MHz/14/4 = 214 kSa/s. Aber eine Flankendetektierung pro Abtastwert geht nicht, der Controller stirbt an Interrupt-Überlast. Vorbereitung: Das Taktregime gewissenhaft kontrollieren, dass der Controller, der A/D-Wandler und die übrige Peripherie tatsächlich mit dem maximal möglichen Durchsatz läuft. Die Lösung: Die Wandlerdaten werden en bloc von bspw. 16 Quadrupeln eingesammelt und in einer Schleife deserialisiert. Das senkt die Interruptfrequenz und damit die Last. Das verlustfreie Abholen der Daten erfolgt per DMA und Interrupts bei halbem und vollem Puffer; die jeweils inaktive Pufferhälfte wird verarbeitet. Der Messschieber verwendet ein 2 × 24-Bit-Binärprotokoll, von dem nur der 2. Block ausgewertet wird. Ein Skalierungsfaktor wird dann im WebUSB per JavaScript angerechnet. Die Ausgabe erfolgt auf 1/100 mm.

Schließlich wurde doch noch ein LM393 spendiert, in invertierender Beschaltung, und das Ganze an SPI1 zu betreiben. Der Pferdefuß steckt im Detail: Wie empfängt man mit dem Mikrocontroller 49 Bit? Die einzige Möglichkeit, die 49. Taktflanke zu verschlucken (= Rücksetzen des internen Bitzählers) besteht mit der Steuerung von Slave-Select. Aus- und Einschalten des SPI-Moduls tut's nicht!!

Kraftsensor

Im Prinzip ist eine Art Einstrahl-Oszilloskop gefragt, bei dem 100 kSa/s genügen. Durch den Messschieber kommen ohnehin bereits reichlich 200 kSa/s an. Die Triggerbedingung in Software zu realisieren führte erneut zum Verhungern der Hauptschleife, auch wenn man größere Blöcke verarbeitet. Daher wurde kurzerhand das Regime so geändert, dass der DMA-Puffer riesig ist und die Triggerbedingung per ADC-Watchdog 🐕 läuft. Da dazu zeitraubende Fallunterscheidungen nötig sind, wurde das Problem dadurch gelöst, die Interruptvektortabelle in den RAM zu verlegen und den Vektor bedarfsgerecht umzustellen. Das funktioniert nun am Fallbeispiel einer steigenden Flanke so:

1. Für die Prätrigger-Zeit wird nichts gemacht. Dazu wird der Timer3 im Einzelschuss-Modus gestartet.
2. Mit der Timer3-ISR wird die Trigger-Vorbedingung am A/D-Wandler gesetzt: Der A/D-Wert muss sich unterhalb der unteren Triggerschwelle befinden. Der Timer3 wird deaktiviert oder zur Auto-Triggerung verwendet.
3. Mit dem nächsten Interrupt vom A/D-Wandler, der nur vom Watchdog kommen kann (die Werte werden unabhängig davon per DMA abgeholt) wird die Trigger-Hauptbedingung am A/D-Wandler gesetzt: Der A/D-Wert muss sich oberhalb der oberen Triggerschwelle befinden. Dazu wird die Interruptroutine für den A/D-Wandler umgebogen.
4. Mit dem nächsten Interrupt vom A/D-Wandler, der nur vom Watchdog kommen kann, wird der Watchdog deaktiviert (simplerweise durch Laden von 0xFFF in HTR) und der Timer3 mit der Post-Trigger-Zeit im Einzelschussmodus gestartet. Dazu wird die Interruptroutine für den Timer3 umgebogen.
5. Mit dem Eintreffen des Timer3-Interrupts befinden sich alle gewünschten Sampledaten im DMA-Puffer. Allerdings nicht in der passenden Reihenfolge; der Schnitt ist irgendwo mittendrin: Die Position des DMA-Schreibzeigers bekommt man durch Auswerten von CNDTR. Diese müssen nun (leider nur per Software) aus dem Puffer herauskopiert werden, während der DMA-Controller weitere neue Werte hineinschreibt. Deshalb dimensioniert man den DMA-Puffer ein bisschen größer und beginnt beim Herauskopieren mit dem ältesten Wert.
   Alternativ könnte man mit 2 DMA-Puffern arbeiten, aber da diese viel Platz fressen, ist das nicht so toll.
6. Mit dem erneuten Scharfmachen des Triggers muss man wiederum die Prätrigger-Zeit abwarten, sonst kann es passieren, dass ein Signalverlaufsabschnitt mehrfach angezeigt wird. Daher wird wieder Timer3 im Einzelschussmodus gestartet, und es geht wieder von vorn los. Damit kein Ergebnispuffer verloren geht, bevor sie zum USB gehen, gibt es mehrere davon in einem weiteren Ringpuffer.

Wegpotenziometer

Späterhin fiel die Entscheidung, zusätzlich oder an Stelle des Messschiebers (mit 10 µm Auflösung) einen Absolut-Wegsensor einzubauen. Am einfachsten ein Potenziometer. Denn ein inkrementeller Wegsensor, hier der Messschieber kann beim schnellen Versetzen (per Hammerschlag) springen oder (wahrscheinlicher) Striche verschlucken. In Verbindung mit dem internen 12-Bit-A/D-Wandler wird eine Auflösung von 60 mm / 4096 = 20 µm erreicht, mit Rauschanteil verlässlich 0,1 mm, das reicht.

Damit kann man nun durch Erweiterung der Oszi-Funktion auf „Zweistrahlbetrieb“ Kraftstoß und Verschiebung gleichzeitig messen und verfolgen. Die dazu notwendige Halbierung der Einzelabtastrate auf ca. 400 kSa/s ist vertretbar. Gefordert sind gar nur 200 kSa/s, sodass sogar Drei- und Vierkanalbetrieb offen steht.

D/A-Wandler

Zunächst wurde die Schaltung so aufgebaut, dass der eingebaute D/A-Wandler genutzt und das Ausgangssignal auf 5 V verstärkt wird. Aber Pustekuchen! Das STM32F103-Datenblatt ist dazu gemacht, zigtausendfache Umweltsünden zu begehen!! Man muss es nämlich ausdrucken und alle nichtzutreffenden Passagen durchstreichen! Das sind sehr, sehr viele. Dann bleibt gar nicht mehr so viel übrig (und wichtige Seiten über den Interruptcontroller fehlen noch), und das D/A-Wandlerkapitel entfällt ganz! Ist also gar keiner drin. Also das übliche: Mit PWM. (Ein echter D/A-Wandler stand schwachsinnigerweise im Pflichtenheft.) Als AVR-Verwöhnter hat man es mit STM32F103 echt schwer. Ein zutreffend gefiltertes Datenblatt ist man auch von 8-Bit-PICs sowie EZUSB gewöhnt. Hingegen kenne ich keinen 16- oder 32-Bit-Controller mit zutreffendem Datenblatt, vom C167 vielleicht abgesehen.

Brems-Potenziometer

Das Brems-Potenziometer braucht nur gelegentlich abgefragt zu werden. Da das eine lückenlose Erfassung des Kraftsensors behindert, wurde es trotzdem in das 200-kSa/s-Regime hineingepresst. Mit dem zweiten A/D-Wandler sollte es möglich sein, das Potenziometer und auch die Chiptemperatur nach dem Telegramm vom Messschieber abzufragen; die Pause ist ziemlich lang. Dazu muss der Kraftsensor vom ADC2 angefragt werden, der dann durchlaufen muss. Das Datenblatt schweigt sich IMHO aus, was passiert, wenn ADC1 lange (17,1 µs vorgeschrieben für Temperatursensor) abtastet und ADC2 währrenddessen laufend neue A/D-Werte produziert. Und wie sich das Ganze resynchronisiert. Günstig erscheint es für diesen Ansatz, die 3 langsamen Werte (Potenziometer, Temperatur, Referenzspannung) per „eingespritzten“ (injected) Wandlungsprozess in die laufende Erfassung der Takt- und Datenleitung vom Messschieber einzuschieben.

Die Verwendung von ADC2 für die Oszilloskopfunktion des Kraftsensors ermöglicht es, den Analog-Watchdog des ADC1 für die Erkennung von Taktimpulsen zu verwenden. Damit kann man die Interruptlast für den Messschieber dramatisch senken.

Der durchgestrichene Text ist hinfällig, weil der Messschieber nicht mehr per A/D-Wandler sondern per Pegelwandler und SPI abgefragt wird. Dadurch kann sich ADC1 um die Oszilloskopfunktion mit Trigger kümmern, und ADC2 kümmert sich um alles andere. Temperaturmessung fällt dadurch flach, weil diese nur an ADC1 möglich ist und der Hardware-Trigger (notwendig für das Oszi) ebenfalls an ADC1 hängt.

Linak-Servo

Der wichtigste Teil der Servosteuerung ist der D/A-Wandler. Alle anderen Parmeter des Servos werden über die serielle Schnittstelle des STM32F103 vermittelt. Das erspart einen gesonderten USB-RS232-Umsetzer, hält einen USB-Port frei und die Apparatur kompakt.
TODO: Noch zu implementieren

Das letztendliche Problem ist eine verbleibende Diskrepanz zur Praxis, weil während des Einschlagimpulses der Widerstand nicht zunimmt wie beim kegelförmigen Formstück (echtes Implantat) sondern nach Überwindung der Haftreibung in etwa konstant bleibt. Ein dem echten Einschlag entsprechenden Widerstand könnte man durch kegelförmige Gleitflächen erreichen (dann fixer Zusammenhang zwischen Weg und Kraftzunahme in Verbindung mit den Federkonstanten des Zustellsystems) oder durch eine schnellwirkende Wegmessung und Bremskraftveränderung, die dann in Mikrosekunden (!) reagieren müsste. Was an Railguns erinnert: Schneller als Körperschall zu sein. Angemerkt 220913, recht spät für so ein Projekt!

Mechanischer Aufbau

Das Ganze ist eine „Brettschaltung“, die schließlich auf einen stabilen Tisch montiert wird. In der Mitte befindet sich der Linearmotor, der über ein raumgreifendes Hebelgestänge und einen Bowdenzug eine Fahrradbremse betätigt, die den (zunehmenden) Widerstand beim Einschlagen simuliert. Im linken Teil befinden sich Netzteil, Linak-Steuerung sowie die via USB angeschlossene Gesamtsteuerung mit STM32F103-Mikrocontroller und analoger Außenbeschaltung. Auf der rechten Seite befindet sich der Hüftknochen-Simulator, in den ein stangenförmiges Gebilde mit Schlagkopf eingeführt wird, welches dem medizinischen Gerät einigermaßen nachgebildet sein soll. Es besteht nicht aus teurem Medizin-Edelmetall.

Firmware für STM32F103 — siehe Makefile zum Bau und Flashen

WebUSB-Äpp — Zugriff auf das Gerät über das WebUSB-Interface

WebHID-Äpp — Zugriff auf das Gerät über das HID-Interface

DLL 32+64 Bit mit Test-🦎Echse und ⛲Quelle

Messwerte

Damit passt die Dimensionierung der Verstärkerschaltung zum Problem. Der Jumper JP1 ist nicht gesteckt. Die Linearität lässt zu wünschen übrig. (Die Steilheit sollte gleich sein.) Ob die Firmware oder die PC-Software die Linearisierung vornehmen soll ist noch unklar.

Reinfälle

• „Freies“ Pin der Linearmotorsteuerung (MicroMaTch-6) ist nicht frei: Keine Analogsteuerung möglich (mit der darüber geführten Ader)
• Messschieber springt, Absolutwertgeber (Potenziometer) erforderlich, Neukonstruktion von Hardware, Firmware und Software
• Kraftmesser mit Adernabriss: Reparatur (erledigt) und Ersatzneubau (inspe)
• Unklares Kalibrierungsergebnis mit Nichtlinearität, aber 40 kN als Endwert erscheinen richtig.
• Zu starkes Rauschen und Störspannungseinkopplung bei externen Schalthandlungen und Motorbewegung (führt zu Triggerereignis)
• Irrsinnige DLL-Konstruktion, nicht nachmachen! HID nicht zielführend und WinUSB/WebUSB neuer Favorit, dazu CDC für die Linak-Steuerung. Falls es zu einer Überarbeitung kommt. Kraftstoß = Impuls hat negative Anteile. Kraftmaximum (zusätzlich) gewünscht.
• 2211xx: Das Wegmesspoti mit Seilzug wurde ergänzt. Und funktioniert erstaunlich gut.
• 221207: Firmware-Umstrukturierungen fehlgeschlagen nach 3 vollen Tagen Arbeit. Zunächst ging es darum, die Report-Struktur auf float statt int16_t umzustellen. Wie sich schließlich herausstellte, ist das Quatsch und verdammt viel unnütze Arbeit. Weiterhin wurde das Handpotenziometer von ADC9 auf ADC4 umgeroutet. Sowie der ADC1-Scanbetrieb auf 2 Kanäle erweitert. Letztlich scheint es so zu sein, dass die DMA-ISR mit einer Aufruffrequenz von 6 kHz keine zwei Statistikeinträge (je 2 Vergleiche und 1 Addition) aktualisieren kann, dann blinkt die blaue LED nicht mehr, und USB enumeriert nicht. Bei 72 MHz CPU-Taktfrequenz. Ohne zwei Statistiken kann das Wegpotenziometer nicht ausgewertet werden! Ein zunächst vermuteter Überlauf von DMA-Puffern scheint doch nicht in Betracht zu kommen. Daher ein nahezu komplettes Rollback. Geblieben ist:
  • Meldung des WebUSB-Gerätes: Umleitung auf app-hid.htm (statt app.htm) (damit ist WebUSB „nur noch“ zur Ausgabe der Redirektion da)
  • Brems-Potenziometer an ADC4 (vormals ADC9)
  • Abtasten von ADC8 (Kraftmessdose) + ADC9 (Wegpotenziometer)
  Der neue Zweikanalbetrieb erfordert das Ändern der DLL zur Impulsberechnung! Nicht geschafft wurde:
  • Umstellung der Reportstrukturen: Statt min max sum und einem globalen n besser (und ausreichend) min max avg (Wurde implementiert aber durch Rollback vernichtet)
  • Statistikwert für Wegmesspoti (Wurde implementiert aber durch Rollback vernichtet)
  • Doppelpufferung der Statistikwerte und Swap über Zeiger statt Interruptsperre (Wurde implementiert aber durch Rollback vernichtet)
  • Kraft-Nullwert ermitteln (Member repI.kraftnull)
  • Automatische Bremsenbetätigung bei Betätigung des Brems-Potenziometers = Entreißen der Kontrolle über den Servo vom PC zum Potenziometer
  • Kraftintegration zur Impulsbestimmung (erfordert Skalierung vor Summierung; Nichtlinearität bereitet Kopfzerbrechen
  • Laden und Speichern von Kalibrierdaten
  • Trigger-Test mit dem Hammer
  • Nur noch WebUSB, kein WebHID, damit's auch am Smartphone geht, dann auch DLL entsprechend umstellen. Hauptvorteil: Dynamische Report-Länge für die Oszilloskopdaten über Bulk-Endpoint.
  Zur Untersuchung der Fehlerursache wird wohl ein ausreichend großer Messplatz (nicht der Mini-Wackeltisch) mit Oszilloskop oder Logikanalysator benötigt, um dem unerklärlichen Zeitverhalten auf die Schliche zu kommen. Denn der STM32F103 sollte schnell genug sein, alle A/D-Werte in eine Statistikauswertung einfließen zu lassen. Er hat sonst nichts zu tun.
  Das mit der „anscheinend knappen“ Rechenzeit in der DMA-ISR ist mir bereits von Anfang an bekannt aber verdrängt. Die Vergrößerung des DMA-Puffers von anfänglich 64 auf nunmehr 256 uint16_t schien nichts gebracht zu haben, obwohl damit direkt die ISR-Auffrequenz sinken sollte. Ursprünglich war sogar die Triggerung in Software implementiert, ohne die umständliche Wurstelei mit dem Hardware-Trigger und den umschaltenden ISRs. Sogar mit parallel synchron laufenden ADCs, wobei ADC1 den Messschieber, das Handpoti und die Temperatur abgefragt hat und ADC2 (nur) den Kraftsensor. Aber das klappte damals ebenfalls überhaupt nicht, gleiches Problem: Zu wenig Rechenzeit. Alles extrem fraglich.
• 220206: Erneut wurde nur Stück­werk programmiert, diesmal mit 2 Debug-Ausgängen, die Rechen­zeiten anzeigen, und ein Digital-Oszi. Seitdem ist es möglich, mit den DMA-Daten (> 800 kSa/s) sogar Multiplika­tionen über alle Samples auszuführen (für die Berechnung der Standard­abweichung mittels Verschiebungs­satz). Dabei geht 60% der Rechenleistung drauf, da ist also noch Luft für den Rest. Ein Integer-Wurzelzieh-Algorithmus rundet das derzeitige Programm so ab, dass alles hübsch ohne Gleit­komma auskommt. Das Problem ist, dass kleinste Programm-Änderungen mal zum Absturz führen und mal nicht. Ein Trigger-Ereignis schickt den Mikro­controller in die ewigen Jagd­gründe.
• 220207: Der (selbst geschriebene) Urlader oder das (selbst geschriebene) Flash-Programm hat ein Problem, dass entweder das Flash-Schreiben (ohne Fehlermeldung) misslingt oder der Sprung in das Anwendungsprogramm nicht klappt. Lästig, weil das einem Firmware-Fehler ähnlich sieht: So oft Reset drücken und flashen bis es geht.
  Nachtrag 220316: Scheint eher ein Ansprung-Problem oder ein Windows-Problem zu sein. Ab- und Anstecken ist daher die bessere Lösungsfindung.
• 220313: Das Trigger-Ereignis führt jetzt nicht mehr zum Absturz, aber es passiert nichts. Mit den gemachten Änderungen hat das wenig zu tun: die Absturzursache ist unbekannt.
• 220314: Es triggert endlich: wValue hat zwischen JavaScript und Mikrocontroller nicht gepasst. Aber ohne Antwort. Hier und da herumgefummelt (u.a. in der USB-Senderoutine) und es kommt endlich die Antwort. Der Feature-Deskriptor ist jedoch total falsch. Schier endloses Wühlen brauchte einen Linkerfehler oder objcopy-Fehler zum Vorschein: Die Initialisierungsdaten liegen in der HEX- oder BIN-Datei 8 Bytes hinter __etext. 💩 Toll!
• 220315: Das (synchrone) Senden von USB-In-Datenblöcken musste nochmal überdacht und mit Timeouts versehen werden. Die Fälle, wenn ein herumgammelndes altes (nicht zum Host gesendetes) Paket vorgefunden wird, welches nicht nach 1..2 ms verschwindet:
  • Belassen um Reihenfolge zu behalten, usb::send() liefert false. Erforderliches Verhalten für Folge-Transfers (> 63 Byte) aus mehreren Paketen.
  • Löschen und neu beschreiben, usb::send() liefert true: Bulk-Paket wurde von (nicht laufender) WebUSB-Äpp nicht abgeholt, der frisch gestarteten WebUSB-Äpp keine alten Daten präsentieren.
  • Länger warten, weiter beim ersten Punkt. (Hier allenfalls beim Interrupt-Endpoint)
  • Löschen und STALL setzen. (Hier nicht)
• 220316: Verflixt, bei HID kommt weder das Oszillogramm noch das entsprechende Flagbit in RepI an, wobei bei WebUSB alles ganz sauber funktioniert. Während letzteres Problem sich schließlich von selbst löste, war das mit dem Oszillogramm wie verhext: Ursache war ein großzügig angesetztes bInterval im Endpoint-Deskriptor: bInterval ist auch für das Inter-Paket-Intervall (eines längeren Transfers) zuständig!! Dadurch brach usb::send() mit dem 2-ms-Timeout ab, und usbhid.sys ignoriert schweigsam dieses Problem. Ein aggresives bInterval = 1 erschlägt das Problem, aber die Moral von der Geschicht': Über den HID-Interrupt-Endpoint übertrage man gefälligst keine Oszilloskop-Tracedaten! Wenn schon HID dann sollte das via getFeature() erfolgen.

• 230322: Die Firmware-Umstellung auf variable Kanalzahl des Oszilloskops hat versagt: Vollabsturz. AC-Kopplung funktioniert. Triggerquellen-Umschaltung funktioniert nicht bei laufendem Betrieb, nur zur Voreinstellung. Das Wegmess-Poti rutscht bei Schlägen durch: Neukonstruktion mit Formschluss erforderlich! Keine Zeit dafür bis zum Vorführtermin morgen.
• 230323: Die Triggerkopplung wurde auf AC voreingestellt. Das Triggersystem arbeitet nunmehr mit „Triggervorbereitung“ (wie bisher) und „Triggerhysterese“ (neu). Diese ist positiv für steigende Flanke und negativ für fallende Flanke. Während die „Triggervorbereitung“ bei AC-Triggerkopplung alle 100 ms vom Mittelwert nachgeführt wird, bleibt die „Triggerhysterese“ konstant. Die beiden Schwellen des A/D-Watchdogs werden entsprechend nachgeführt. Die Umschaltung der Triggerquelle funktioniert endlich, wird aber (mit dem kaputten Wegmesspoti) nicht benötigt.

Potimechanik

Irgendwie wird der Kraftsensor überhaupt nicht mehr ausgereizt, die maximal erreichbaren Kraftwerte liegen bei 4 kN (400 kp). Also nur bei 10 % vom Endwert. Dabei ist der gesamte Kraftstoß etwa 1 ms breit, während sich die Potimechanik rund um das Wegmesssystem eher 4 ms Zeit lässt, bei straffer Bremse. Ob das jetzt die gebremste Masse oder aber die Seilkonstruktion um die Potiachse ist lässt sich nicht ohne weiteres feststellen. Mit einer High-Speed-Kamera vielleicht. Der ermittelte Kraftstoß liegt so bei Werten um 20 (nach der Division mit dem 1-ms-Integrationsintervall). Und die Maximalkraft bei reichlich 100. Wohlgemerkt, bei einem 12-Bit-A/D-Wandler. Alles in allem eine schlechte Dimensionierung. Aber für's Prinzip reicht es jetzt: Es kommen für unterschiedlich starke Schläge unterschiedlich starke Impulse, Kraft-Maxima und Verschiebewege. Die AC-Triggerung ist hinreichend empfindlich. Das Ergebnis bei poll() kommt sehr schnell, innerhalb von 30 ms. Das ist IMHO der größte Vorteil der Umgestaltung. Weiterhin stimmt der Weg-Wert immer (weil Absolutwertgeber), der Messschieber springt gelegentlich. Werte vom Messschieber werden von der DLL nicht mehr geliefert. Die DLL braucht das Oszillogramm nicht (wie bisher) auszuwerten, das macht jetzt die Firmware. Die Firmware ist nunmehr als ein bis-zu-4-Kanal-Oszilloskop ausgelegt. Die Triggerquellenumschaltung funktioniert jedoch nicht so recht. Die Voreinstellung in der Firmware ist 2 Kanäle (ADC8+ADC9), 4 ms Samplezeit, Triggerhysterese +50, Triggerquelle ADC8, AC-Kopplung, kurzer Prätrigger. Die Voreinstellung wird nach Reset wirksam, daher hilft beim irrtümlichen Verstellen das Ab- und Anstecken. Allerdings kann man nicht ohne Neuübersetzung andere Voreinstellungen (bei geänderten Aufbau­parametern, bspw. mehr Rauschen, was mehr Hysterese erfordert) festlegen. Mit den 4 ms ist der RAM des STM32F103 nahezu erschöpft, das sind knapp 2 K Samples pro Kanal. Für mehr Zeit müsste man die Summenabtastrate heruntersetzen. Strukturell steht eine DMA-Pufferumschaltung bei Triggerereignis an. Das erspart die murksig erscheinenden memcpy()-Aufrufe. Für die nächste Firmware-Überarbeitung …