Die Controllerauswahl

Vorwort

Wie so oft bin ich der Zeit am grübeln, was man noch anders und besser machen kann bei den Motorreglern. Der größte Punkt ist hier bei für mich eine maximal saubere Strommessung. Bisher bin ich mit den ACS Sensoren von Allegro wie auch der Lowside Shuntmessung nicht zufrieden.

Bei der Lowside-Messung stört es mich, dass ich nur einen Messwert pro PWM-Periode zur Verfügung habe und darauf angewiesen bin, dass zum Zeitpunkt der Messung der OP auch auf die korrekte Ausgangsspannung eingeschwungen ist. (Stichwort: settling time / slew rate)

Bei den ACS Sensoren kann ich zwar mehrere Messwerte pro Periode aufnehmen, aber diese Sensoren haben gerade bei Strömen um 0A herum das Problem einer Hysterese. Der Sensor kann quasi keine 0A ausgeben sondern er gibt entweder -0,1A oder +0,1A aus. Bei einem Nulldurchgang des Stromes von negativ nach positiv bleibt der Sensor erst auf -0.1A kleben und springt auf 0.1A wenn der Strom auf 0,1A gestiegen ist. Im Mittel geht sich das meißt aus für langsame Signale. Jedoch hört man die Verformung des Stroms bei höheren Drehzahlen.

Da ich die Motorregler ohne kommerziellen Hintergrund baue und beim Hobby immer gilt: Wie kann ich mit möglichst viel Aufwand Zeit und Geld verbrennen, will ich mich mit diesen Lösungen nicht zufrieden geben auch wenn sie gut funktionieren.

Lange Rede kurzer Sinn: Die STM32 sind mir zu General Purpose. Ich suche einen Motor Control spezifischeren µC mit Cortex M Kern und Floating Point Unit um das portieren und die Einarbeitung möglichst einfach zu halten.

2 Interessante Kandidaten sind hier für mich der ADSP-CM403 von Analog Devices und der XMC4700 von Infineon.

ADSP-CM403

• ARM Cortex M4 Core with Floating Point Unit to support advanced programming models and complex algorithms with speed grades of 100 to 240 MHz.
• Dual 16 bit SAR ADCs with no missing codes, 13+ ENOB, 380ns conversion speed for high precision closed loop control.
• 128 to 384KB SRAM and 256KB to 2MB flash memory options for a wide range of program and data memory requirements.
• Advanced PWM and timer functions for improved PV inverter and motor drive performance.
• Two CAN interfaces, three UARTS, two SPIs, two SPORTs, eight 32-bit timers, two two-wire interfaces and four quadrature encoder interfaces.
• SINC filters for glueless connection to AD74xx isolated converters.
• Harmonic Analysis Engine for compliant grid connection.
• 14x14 120 lead LQFP package with 40 GPIO pins, 24 ADC input pins and 2 DAC output pins optimized for PV inverter applications.
• Up to 105C ambient operating temperature for support of industrial applications.

XMC4700

• ARM ® Cortex ®-M4 @ 144MHz
• 1536kB Flash, 276kB RAM
• Data and IP Protection on Flash
• 6 x CAN nodes
• EthernetMAC, USB-OTG, SD/MMC
• 6 channel USIC (configurable to SPI, UART, IIC, IIS)
• External Bus Unit
• 4 x 12-bit ADC, 18 input channels, 4 x parallel sampling and conversion
• 2 channel 12bit DAC
• 4 channel ∆Σ Demodulator
• 24 x 16-bit special purpose timers, dead time generation
• 2 x Position Interface
• Watch Dog Timer, Real Time Clock
• XMC4000 Functional Safety Package
• LQFP100
• -40 - 85°C

Der ADSP ist ein ziemliches Monster mit 240MHz und 16Bit ADCs die eine effektive Auflösung von mehr als 13Bit liefern. Der Infineon stellt quasi den vernüftigen Mittelweg dar, aber der ADC ist nicht wirklich besser als der des STM32. Nur die Timer sind vielfältger.

Wenn man einmal genau überlegt was Analog mit dem ADSP für einen Proze baut bin ich tief beeindruckt. Auch wenn die Dinger doppelt so teuer sind. Der STM32 kommt auf eine ENOB von 10,8Bit bei einem 12Bit ADC ist das meiner Meinung nach schon sehr hingelogen. Aber Analog gibt mehr als 13Bit ENOB für den SAR ADC des ADSP an. Das bedeutet eine um mindestens 4mal (fast 8mal) höhere Auflösung als der STM32 liefern kann.

Ich hatte ursprünglich gedacht ich nehme für den Pitchregler des Constant Speed Prop einen XMC1100 aber irgendwie nervt es, sich für so ein im Vergleich kleines Projekt in einen anderen Prozessortyp einzuarbeiten. Ich hatte eigentlich gehofft das DAVE von Infineon mit seinen konfigurierbaren Peripherieblöcken mir die Arbeit bei der Konfiguration der Timer usw. abnimmt. Aber diese Blöcke sind quasi nicht zu gebrauchen. Ein LED Blinky ist damit zu machen, vllt. auch eine LED dimmen und das war es dann auch schon. Für so eine elementare Funktion wie ein Capture für PPM-Eingänge gibt es nicht. Das ist echt schade. Sonst wäre DAVE eine echte Alternative um schnell die Peripheriekonfiguration zusammen zu kloppen und sich dann um die Applikation zu kümmern.

Deshalb gehe ich wieder auf dem STM32F3 für den Pitchregler und die nächste Ausbaustufe für den ThunderDrive wird dann mit dem ADSP-CM4xx implementiert. Leider bietet Analog nur Beispiele und Code-Unterstützung für IAR an. Ich müsste also für eine freie IDE den Startup Code und das Linkerstript für den Prozessor erstellen. Das sollte aber kein allzu großes Hindernis sein. Vor der Konfiguration des Caches des Prozessors habe ich mehr Respekt. Was solls das ist ja schließlich Hobby. Wenn ich so eine voll Inbetriebnahme mit neuer Toolchain in Angriff nehme ist es denke ich auch gleich sinnvoll nicht auf den betagten GCC zu setzen sonder auf cLang zu gehen. Aber da muss ich mich erstmal weiter belesen, wie die cLang Integration mit Eclipse und dem GDB funktioniert.