Donnerstag, 5. Januar 2017

ucLinux oder wie nutze ich übrige Rechenzeit

Ich habe mir über den Jahreswechsel viele Gedanken zu der Software des neuen Umrichters gemacht. Dabei spielte meine Abneigung gegen das Schreiben von Protokoll-Stacks zur Kommunikation eine große Rolle. Denn ansich brauche ich für den Umrichter kein RTOS oder einen Scheduler oder ähnliches Konstrukt. Aber ich und ggf. auch mal andere Leute müssen das Ding ja bedienen.

Das fängt schon mit der Anbindung an externe System an, die Sollwerte liefern sollen. Üblicherweise nimmt man dafür einen Feldbus. CAN braucht nur einen Tranceiver und los gehts. Aber so einfach ist das dann doch nicht. Denn dann bin ich wieder bei der Frage was für ein Protokoll läuft denn dadrauf usw..

Mit geringem Hardware Aufwand ließe sich z.B. CAN oder CAN-FD als Physik für die Kommunikation bereitstellen. Nur dann brauche ich z.B. einen CANOpen-Stack damit der Umrichter eine halbwegs einheitliche Schnittstelle bekommt.

Wenn ich dann weiter gehe und mir über die generelle Inbetriebnahme und Parametrierung Gedanken mache bin ich ganz schnell bei USB. Klar USB-CDC bietet ST fertig an auch ChibiOS-RT, das ich aktuell verwende hat bereits USB implementiert. Aber auch hier muss in irgendeiner Weise ein Protokoll drauf laufen. Klar das kann ich selber definieren und dann auch programmieren... kotz.

Also muss was anderes her. Und da will ich gleich mit der Gießkanne dimensionieren, denn der F7xx hat bei der aktuellen Implementierung meiner Regelung ca. 50% Freizeit. Die Sleep-Modes in der restlichen Rechenzeit zu nutzen ist totaler Humbug, also kann man die Rechnenzeit auch mehr oder weniger sinnvoll verbraten. Gerade im Hinblick auf den Pinkompatiblen H7xx muss für die restliche Rechenzeit eine gescheite Lösung her.

ucLinux

Durch den CCC der über den Jahreswechsel gerade in Hamburg war, durch neue Kontakte und auch durch meine Arbeit bin ich immer weiter gedanklich in den Unix/Linux Bereich vor gedrungen. Und dann stieß ich auf ucLinux. Eine Portierung des Linux-Kernel auf Architekturen ohne MMU, wie den Cortex-Mx und Cortex-Rx. Die Portierung ist sogar bereits in der Mainline des Kernel enthalten, es lässt sich also ein Linux Kernel für das STM32F429-Discovery bauen ohne weitere Anpassungen. Dazu gibts auch YT-Videos usw. 

Dieser Talk vom dies jährigen CCC https://media.ccc.de/v/33c3-7946-console_hacking_2016 ist übrigens Schuld :).

Das Thema ucLinux schien aber unter den Linux-Entwicklern etwas eingeschlafen zu sein und erst in letzter Zeit tut sich an der Front wieder mehr. Ich habe mir Deshalb zum Testen des Ganzen und auch für ein anderes Projekt das 32F769I-Discovery gekauft. Dieses Board ist jetzt mein erstes Opfer für meine Einarbeitung in die Linux-Entwicklung und die Portierung des Kernel auf eben dieses Boards. Da ich in dem Bereich quasi keine Erfahrung habe wird das sehr interessant für mich. Meinen Fortschritt werde ich dann hier zu gegebener Zeit veröffentlichen. 

Architektur

Noch kurz zu dem was ich eigentlich vorhabe. Die Cortex-M7 haben einen sog. TCM (tightly coupled memory). Dieser RAM Bereich hängt direkt an dem 64Bit breiten Hauptbus des Prozessorkerns. Der Speicher ist quasi genauso schnell wie der Cache der CPU. In diesen Speicher lädt ein Linux Treiber den Code des Reglers. Ein hoch priorisierter IRQ führt dann immer die Funktion aus. Da man beim Cortex-M die Interrupts nesten kann und hoch priore Interrupts gezielt aktiv gelassen werden können, auch wenn Linux in einer Critical-Section ist, hat der IRQ keine zusätzliche Latenz außer die Normale die auch im Bare Metal Betrieb da sein würde (9-11 Takte oder so). 

Das Problem dabei ist, der Regler darf auf keine Strukturen des Linux Bereiches zugreifen zu keiner Zeit. Denn ein Zugriff durch den Regler, wenn Linux nicht damit rechnet führt im schlimmsten Fall zum crash. Deshalb muss ich einen RAM Bereich für Parameter zum Regler auf dem der Regler nur ließt und einen RAM Bereich auf dem Linux nur ließt definieren. Außerdem sind die Daten auf 32Bit Breite Typen begrenzt, weil die vom Prozessor grundsätzlich in einer Instruktion gesetzt werden können. 

Interessant wird auch wie sich der Prozessor verhält wenn Linux eine Exception, wie einen Hard-Fault haben sollte, läuft dann der IRQ für den Regler noch? Kann Linux ggf. den verursachenden Prozess killen und der Umrichter läuft weiter? Das wäre ein Träumchen aber wir werden sehen.

Aber bis ich das so hin habe vergeht noch viel Zeit :) ist ja Hobby.

Keine Kommentare:

Kommentar veröffentlichen