Hüftknochen-Einschlagapparat

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.

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!!

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.

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.

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.

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.

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!

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.

• „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.

Foto
3D: Gesamtkonstruktion

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 …