Auch in der World of Embedded aendert sich die Technologie hin zu "echten" Prozessoren in mobilen Anwendungen.

 

Man hilft sich mit workarounds um Regelalgorithmen wie die Clark-Park Transformation effizient und aeusserst schnell auf Microcontrollern, unter Beruecksichtigung von MISRA, zu implementieren. Das geht natuerlich nicht wirklich gut. Man stelle sich nur eine Multiplikation einer Matrix mit einem Vektor vor welches schon in C unter Verwendung von Zeigern und dynamischem Speicher Rechenintensiv ist. Von einer Matrix-Multiplikation oder gar Division wollen wir erst garnicht reden. Das ganze dann noch in zwei parallel laufenden Strukturen wie die Clark-Park und inverse Clark-Park Transformation, das sind zwei parallel laufende Threads.

 

Um solche Sachen zeitnah, robust und genau wie als auch speicheroptimiert zu rechnen, benötigt man am Besten eine Hardware.

Auch werden z.B. bei der Raumzeigerregelung manche Prozesse am Besten hard parallel gerechnet. Mit uC geht sowas dann nicht, die Teile sind zu langsam und es ist nicht einfach ein thread scheduling zu implementieren. Meistens existieren keine geeigneten Btriebssysteme fuer diese embedded uC. uC besitzen auch keine FPU und meistens auch keine DSP Einheit, bei welcher man wenigstens fixed point Arithmetik nutzen kann. Es existieren ja in DSP Hardware Multiplyier und Divider usw, aber der Kern ist trotzdem noch ehr zu langsam. Das ist auch klar, uC wurden nie fuer Rechenintensive und parallel laufende Strukturen geschaffen sondern vielmehr als super kleine low Power Devices, ehr fuer die Steuerungstechnik und wenig rechenintensive Sachen. Insgesamt muss man bei der implementierung von sensored FOC mit Feldschwaechung oder sogar sensorless FOC inklusive der Integration eines exakten Maschinenmodels im Chip, Abstriche hinnehmen.

 

Nun ja, FPGA sind sehr gut geeignet um rechenintensive numnerische und symbolische Prozesse in hard parallel zu implementieren. Es gibt nichts schnelleres als hardware Implementierungen. Auf FPGA koennen auch Prozessor Kerne implementiert werden. Diese IP Cores kann man auch fuer sehr viel Geld kaufen. uP Hersteller wie z.B. Intel prototypen die Intel uP auch auf FPGA. Weil alles in HDL beschrieben ist, kann im Anschluss dann ein Asic programmiert werden, dann ist alles fuer immer fest im Chip. Sowas kann man dann in Grossserie herstellen und im Laden kaufen.

 

Mit FPGA arbeiten ist nun fuer Mikrocontroller und Prozessor- Softwareentwickler nicht so einfach. FPGA erfordern eine mehr oder minder lange Einarbeitung und ein komplett anderes Denken. Ein FPGA ist erstmal nichts weiter als eine Matrixansammlung von D Flip Flops plus logische Gatter und manchmal ist noch ein uC und Speicher mit auf der FPGA Platine. Bei einem FPGA wird man z.B. einen ADC mit 22bit durch HDL, z.B. Verilog, beschreiben, mit einer Art Compiler in eine Netzliste SYNTHETISIEREN und dann durch einen uC aus dem Speicher bei Systemstart in den FPGA Laden. Nun ist der FPGA ein 22 bit ADC. Ein FPGA kann aber auch viel viel mehr HW beinhalten und die einzelnen HW Module koennen hard parallel arbeiten und kommunizieren durch einen Bus der wiederum durch die HDL Beschreibung implementiert werden muss usw usw. Man kann also sehr viel HW chips, die normaerweise einzeln auf einem Board geloetet sind, in einen einzigen grossen chip bringen. Die Beschreibung solcher Chips wie I2C, SPI controller, CAN FD controller etc, ist immer rein digital. Ein FPGA kann kein Analog. Daher muss, um Spannungen zu messen, z.B. auch ein ADC erstmal beschrieben werden und dann ab in den FPGA damit, ein Bus auch, damit die ADC Daten weitergeleitet werden.

 

Immer dann wenn man im Geschaeft einen Chip kauft, wurde dieser vom Hersteller in der Entwicklung auf einem FPGA geprototypt, getestet, veraendert, verbessert und dann in einen ASIC geschrieben. Das ist das was wir im Laden kaufen und nicht weiter veraendern koennen, weil ein ASIC kann nur einmal beschrieben, "gebrannt", werden.

 

Bei CPLD ist es sehr ähnlich, wenn auch einfacher. CPLD sind sehr gut für reine diskrete kleinere Einzelsysteme geeignet wie z.B. die Encoderauswertung bei schnelldrehenden Maschinen und die anschliessende Anflanschung an einen uC oder uP. Sowas entlastet einen uC extrem. Der uC kann derweilen andere Sachen machen.

 

Ein uProzessor (uP) ist eine Art Mutter der uController (uC). Prozessoren können sehr schnelle Kerne wie als auch mehrere parallele Kerne enthalten. Von daher sind uP sehr gut geeignet zum schnellen Rechnen wie es z.B bei der Vektorregelung (FOC) von PSM und Raumzeigermodulation (SVM) benötigt wird.

 

uC sind die sehr einfachen uP, welche dafuer aber meistens über embedded HW für spezielle Anwendungen verfuegen. uC sind daher sehr gut als Co-Prozessoren zum uP geeignet.

 

Fuer meine kleine BLDC Servospindel, hatte ich ja einen sensorless Modellbauumrichter in der Vorentwicklung genommen und einen weiteren uC zugebaut und dadurch eine Hallsensorauswertung angeforscht. Das Konzept ist schon aufgegangen. Dann kam mein eigener mini Umrichter mit FOC, Feldschwaechung und SVM, also Clark-Park, Raumzeigermodulation, Feld orientierte Regelung.

Ich habe es so gemacht das ich die Regelungen und HMI auf einem ARM A54 64 bit Quadcore unter Ubuntu Linux Core implementiere und nutze dabei auch shared memory und pthreads. Dabei wird der gesamte Sourcecode in ANSI C und C++ geschrieben. C++ nutze ich in erster Linie wegen der Klasseneigenschaften wie protected und private wie als auch Vererbung und mehrere Copyconstructor zur Objectinitialisierung. Das bietet den Vorteil das man eine Sammlung von Grundklassen erstellen kann, z.B. die Clark Transformation. Spaeter kann man diese auch als Basis Klasse nutzen um eine neue Clark Transformation fuer eine Sechsphasige Maschine zu erstellen. Dabei muss die Grundarbeit der Clark nicht mehr neu erstellt werden. Wie sowas genau geht muss man lernen und es braucht sehr vuiele Jahre bis man das beherrscht. Gerade bei Zeigern in das Shared-Memory muss man extrem ordentlich und gut arbeiten. Man benötigt sehr viel Erfahrung dabei. Zeiger können ein komplettes System crashen. Hacker bedienen sich z.B. der Zeigerumlegungstechnik und schon steht die Roboterfertigung fuer den Rest des Tages. Multiplikationen, Divisionen leicht oder schwer, kein Thema....uebernimmt die FPU da uP immer eine Floating point Einheit (FPU) enthalten. Floats, reals, Zeiger auf Zeiger auf Zeiger in virtuellen overloaded Functions, copy constructor, default constructor inheritance usw alles normal, alles da. Eine Effizienzbremse wie MISRA wird dabei nicht mehr eingehalten und das soll auch nicht, da der Umrichter schnell und sicher sein muss. Viele Umrichter treiben Motoren im hohen kW bis in den MW Bereich. Eine Software Denkpause oder ein abstuerzen ist da absolut nicht erlaubt.

 

Trotzdem benoetigt man ein embedded Daughter board, einen Coprozessor sozusagen, sowas wie frueher der mathematische Coprocessor beim i386SX war. Bei mir ist das momentan ein DSPIC33EP 70 Mips. Der hat die 12 bit ADC und die mitten bezogenen PWM Generatoren fuer die Raumzeigermodulation und den richtigen SPI um Daten schnell ins Shared Memory bzw. zum Prozessor zu schaufeln plus.......da schau her, natuerlich eine HW Encoderauswertung. Die Encoderauswertung kann man auch extern mit Gattern oder im CPLD mumsetzen, aber der PIC hat die HW dafuer schon drauf.

 

Noch ist das Steuergeraet ein Brassboard, aber ein EC-Karten Brassboard. So wie es aussieht ist das Teil sogar auch bestens geeignet fuer den Modellbau.

 

Weitermachen.....