Hallo,
ich suche eine leistungsfähigere Alternative für einen aktuell
eingesetzten dsPIC33 in einen Servoantrieb. Der aktuelle dsPIC hat 40
MIPS, 16 Bit, 128KB Flash und 16 KB RAM. Von der Performance sind wir am
Limit.
Die Anforderungen an den neuen Controller wären:
- 128 ... 512 KB Flash intern
- >= 32KB RAM
- Encodereingang
- entsprechende PWM Hardware
- AD-Wandlung <= 1us
- 32 Bit
- Prozessorfamilie sollte evtl. auch FPU-Typen beinhalten (kein muß)
- CAN-Bus
- I/O-mäßig reichen bisher 80 Pins (für den ganzen Controller
- Preis <= 15€ (Basis 1000 St.)
Angeschaut habe ich bisher
- STM32 (Cortex 3M): Leistungsmäßig (noch) ok, keine FPU, mit 72 MHz
(noch) ausreichend. Aber zumindest bei ST gibt es keine
leistungsstärkere Variante.
- TI C2000 (Piccolo): Hat ein paar Eigenarten, die ihn ausscheiden
lassen.
- Freescale Coldfire: Leistungsstärkere Typen nur mit externem Speicher?
- Freescale PowerPC: Hat gleich rießige Pinzahl, kein Flash?, Preis!
- Renesas SuperH: Ansich interessant, aber bei RAM > 32KB oder FPU-Typ
nur ROM-less Varianten.
- Infineon Tricore: Preis!
Da die ganze Steuerung im Bereich von 200-400€ Marktpreis besitzt, sind
auch hochpreisige Prozessoren problematisch.
Ich habe bei einigen Angaben ein Fragezeichen angebracht, da ich in
kurzer Zeit nicht alles 100%ig erfassen konnte. Die Portale der
Hersteller sind auch nicht immer übersichtlich.
Wer kann einen Typ empfehlen, oder helfen die Fragezeichen auszuräumen.
Vielen Dank
Wolf
>- TI C2000 (Piccolo): Hat ein paar Eigenarten, die ihn ausscheiden lassen.
Hast du dir nur die Piccolos angesehen oder auch die "normalen" C2000?
Was für Eigenarten meinst du speziell?
Wolf schrieb:
> ich suche eine leistungsfähigere Alternative für einen aktuell> eingesetzten dsPIC33 in einen Servoantrieb. Der aktuelle dsPIC hat 40> MIPS, 16 Bit, 128KB Flash und 16 KB RAM. Von der Performance sind wir am> Limit.
Vielleicht ein guter Zeitpunkt, mal über das Softwarekonzept
nachzudenken.
Die meisten Programmiersünden lassen sich nicht einfach mit roher Gewalt
bei der Hardware ausmerzen.
Für einen Servo klingen Deine Anforderungen jedenfalls deutlich
überhöht.
Peter
Hallo,
@Vlad: Die Blackfins scheinen eher für Multimedia usw. designed zu sein.
Auch von den Gehäusen sind sie schon aufwendig (BGA)
@Patrick: Danke - der NPX-Tip ist gut.
@Micha: Wenn man einen Bootloader einsetzt, so muß man beim C2000 gleich
1/4 des Flash dafür opfern. Auch die Anzahl der "General
purpose"-Counter ist nicht überwältigend.
@Peter: Auf eine gute Architektur zu achten ist auch ein oberstes Gebot
von mir. Es ist aber trotzdem so, daß ein Servocontroller, der unter
Echtzeit eine 3-Phasen PWM generiert, den Strom regelt, von außen
Wegvorgaben erhält, die Drehzahl/Position regelt, einen
4-Quadrantenantrieb enthält und sonst noch ein paar Dinge macht, daß da
die Power trotz guter Architektur bei einem dsPIC nicht ausreicht. Ein
Bekannter von mir entwickelt seit 20 Jahren hochwertige Servoantriebe.
Dort wird ein Power-PC eingesetzt.
Gruß Wolf
>Wenn man einen Bootloader einsetzt, so muß man beim C2000 gleich 1/4 des>Flash dafür opfern.
Mit Bootloader habe ich beim C2000 noch nicht gearbeitet - kann dazu
also nichts sagen. Aber brauchst du den Flash überhaupt? Du schreibst
der dsPIC hat 128k und ihr seid von der Performance her am Ende. Dann
sollten doch die verbleibenden 384k locker ausreichen.
>Auch die Anzahl der "General purpose"-Counter ist nicht überwältigend.
Brauchst du wirklich mehr als 3 Stück? Du kannst auch die Timer von den
ePWMs nutzen, dann hast du insgesamt 9 Timer zur Verfügung.
So weit ich es in Erinnerung habe
Bei den STM32 funktioniert der ADC nicht mit 1us falls der uC mit 72 MHz
läuft.
Von Renesas ist ein uC mit FPU und integriertem Flash und SRAM in
Planung/Entwicklung... Ah das ist ja oben schon gesagt worden..(SH7216)
Nebenbei:
Ich nutze auch den dsPIC33 (dsPIC33FJ16GS504
) für Schaltnetzteile. Im Moment für einen LLC Resonanzkonverter. PWM
generierung, Regelung, Synchron FET timing,
Strom/Spannungsmessungen/Temoeraturmessung Kommunikation mit dem
primären Controller, Bus. Da werden 16kb verdammt knapp. Alternative
wäre ein dsPIC aus der MotorControl Familie, doch der hat features die
nicht gebraucht werden.
>Nutzt ihr wirklich die DSP Funktionen des dsPIC ?
Ja, aber nicht aus C heraus. Was in meinm Fall ein Problem ist, ist das
dividieren. Aus dem Regler erhalte ich einen Frequenzwert
(Resonenzkonverter eben), um das PWM Register zu konfigiurieren muss es
in eine Periodendauer umgewandelt werden (entsprechend skaliert) dies
dauert aber 28 Instructions.
Doch da bietet die DSP Funktion keine Hilfe. (Ist ja ein Digital Signal
Controller, lol)
MFG
@Patrick:
>Nutzt ihr wirklich die DSP Funktionen des dsPIC ?
Nein, die DSP Funktion benutzen wir nicht. Kann man in unserem Fall
sicher "noch etwas" herausholen. Großartig wird sich aber nichts ändern.
>Wie ich weiß hat da der Compiler noch leichte Probleme diese zu nutzen.
Müßte ich erst mal schauen, ob und wie der Compiler das von sich aus
macht (Wahrscheinlich gar nicht) Microchip bietet eine Bibliothek, mit
einem PID-Regler an, der die DSP-Funktion benutzt. Die müßte man für die
Regler dann nehmen.
@blabla
>So weit ich es in Erinnerung habe>Bei den STM32 funktioniert der ADC nicht mit 1us falls der uC mit 72 MHz>läuft.
Ich habe von ST eine Einführung überflogen. Dort steht 1us
Wandlungszeit.
@Fralla: Da bieten andere aber auch "nur" das MAC an.
Ich habe mir heute etwas genauer den STM32 mit Cortex-M3 Core angesehen.
Zwei Dinge haben mir nicht so gefallen bzw. aufgefallen:
1. Bitzugriff z.B. auf einen Port. Dort verwendet der Prozessor das
sogenannte "Bit Banding". Damit sind aber mehrere Instruktionen
notwendig, um ein Bit zu setzen/rücksetzen.
2. Er kann nicht 32-Bit immediate direkt in ein Register laden.
Gibt es hier jemanden, der den Cortex-M3 einsetzt und vielleicht noch
mehr Details über den Prozessor erzählen kann?
Gruß Wolf
Fralla schrieb:
> Ja, aber nicht aus C heraus. Was in meinm Fall ein Problem ist, ist das> dividieren. Aus dem Regler erhalte ich einen Frequenzwert> (Resonenzkonverter eben), um das PWM Register zu konfigiurieren muss es> in eine Periodendauer umgewandelt werden (entsprechend skaliert) dies> dauert aber 28 Instructions.
Cortex-M3 hat einen Hardware Divider. Vielleicht kannst Du damit den
befürchteten Mangel an Performance gutmachen.
Gruß
Marcus
http://www.doulos.com/arm/
@Wolf,
- TI C2000 (Piccolo): Hat ein paar Eigenarten, die ihn ausscheiden
lassen.
Diese Frage wurde schon gestellt, aber du hast vergessen sie zu
beantworten?
Was passt euch an dem nicht?
Die normalen Mikrocontroller kann man vergessen, wenn es um
Echtzeitanforderungen wie bei der Servoregelung mit Motoren geht.
@Helmut
Was ist normal ?
Ich würd ned sagen das man "Normale" µCs für solche Anwendungen
vergessen kann!!!
Man muss eben mit der ganzen Trickkiste arbeiten (FixPoint,
LookupTables, Cordic usw)
MFG
Bzgl. PowerPC, da würden sich speziell die MPC560xP bzw. die MPC560xB
Familie im QFP Package eignen. Gerade die Cross Triggering Unit
vereinfacht es ADC und Timer für PWM in Hardware zusammenzuschalten.
Mal nebenbei bemerkt, es gibt Servosteuerungen, die mit einem Atmega
laufen. Googelt mal nach Uhu Servo, da müsste sich was finden lassen.
Z.B. http://www.uhu-servo.de/servo_de/index.htm
Hier geht es natürlich um ganz andere Anforderungen, das sollte auch nur
ein Hinweis für die "mit einem normalen µC geht nix"-Leute sein.
Mal wieder ein laengereer Beitrag von Robert :-)
Es gab hier schon verschiedene gute Tips. z.B. stellt der STM32 ca.
doppelte Leistung zur Verfuegung verglichen mit dem schnellsten dsPIC.
Der NXP LPC1768 wurde auch schon genannt, laeuft mit 100 MHz und dem
Cortex-M3 Core. Also nochmals fast 40% schnellerer Takt wie der STM32.
Noch nicht genannt wurden die neuen Typen von Luminary (TI), LM3xxx, die
jetzt auch mit 100 MHz laufen sollen.
Zum Thema ADC, da musst Du genauer hinsehen. Soweit ich weiss, kann der
STM32, z.B. der STM32F105, tatsaechlich die 12-bit bei 1 Msamples/sec,
der LPC1768 hat damit Probleme wenn ich mich nicht ganz taeusche.
Die beiden hoechst performanten Flash basierenden MCU-Familien wurden
auch schon genannt, der TriCore und der SH72xx. Schau doch mal den
SH7216 an, das Ding laeuft richtig schnell, hat den geforderten ADC,
bietet eine FPU und auch sehr nette Timer. Der Preis fuer den Chip kommt
zwar in die Naehe Deiner maximalen Zahl, doch Leistung / Preis ist er
evtl. sogar der beste.
Bei TriCore kommt die Leistung fast dran, der Preis ist auch nicht viel
anders aber die speziellen Eigenschaften des TriCore hast Du nicht als
Anforderungen erwaehnt. Sollte minimale Interrupt Response Time wichtig
sein oder ein unabhaengiger Coprocessor fuer echtzeitkritische Teile des
Programmes, dann ist der TriCore dem SH2 darin bestimmt ueberlegen. Ich
hab die Freescale Produkte nicht aufgefuehrt, weil sie meiner Meinung
nach weder an TriCore noch an den SH2 rankommen.
Mit 32-bit MCU und zwar recht verschiedenen beschaeftige ich mich
taeglich. Ich kann nicht verstehen, dass es hier immer wieder Beitraege
gibt, die allen Entwicklern, denen ein 8-bitter nicht mehr ausreicht
schlechten Programmierstil oder andere Unzulaenglichkeiten unterstellen.
Wer heute noch ein Projekt mit einem 8-bit Rechner angeht und dazu mehr
als 64k Speicher braucht, der gehoert fuer in dieselbe Kategorie wie die
Jungs, die noch ein Telex geschickt haben als das Fax so langsam von
E-mails ueberrollt wurde.
Anregungen fuer Fragestellung koennten folgendes beinhalten:
1. Reichen die Eigenschaften des uC fuer meine geplante Anwendung, so
wie Performance, Peripherals und Speicher?
2. Basierend auf meiner Erfahrung, wird das Produkt weiterentwickelt
werden und mehr Speicher/Features/Performance brauchen?
3. Kann ich ohne preislichen Nachteil bereits fuer die naechste
Generation vorplanen?
4. Wieviel Markt verliere ich wenn ich mein 8/16-bit Projekt heute auf
32-bit umstelle und dabei 3 Monate verliere?
5. Wieviel neue Maerkte kann ich erschliessen durch mehr Funktionalitaet
bei gleichem Preis?
6. Muss ich bei der naechsten Generation sowieso auf 32-bit umstellen?
usw.
Have fun!
Robert
>Wer heute noch ein Projekt mit einem 8-bit Rechner angeht und dazu mehr>als 64k Speicher braucht, der gehoert fuer in dieselbe Kategorie wie die>Jungs, die noch ein Telex geschickt haben als das Fax so langsam von>E-mails ueberrollt wurde.
Spaßvogel!
>- TI C2000 (Piccolo): Hat ein paar Eigenarten, die ihn ausscheiden>lassen.>>Diese Frage wurde schon gestellt, aber du hast vergessen sie zu beantworten?>Was passt euch an dem nicht?
Doch er hat sie beantwortet:
>>Wenn man einen Bootloader einsetzt, so muß man beim C2000 gleich 1/4 des Flash>>dafür opfern. Auch die Anzahl der "General purpose"-Counter ist nicht>>überwältigend.
Ich verstehe aber das Problem noch immer nicht, da
a) ich nicht weiß wie er darauf kommt, dass der Bootloader 1/4 des Flash
braucht.
b) es auch C2000 mit 256k/512k Flash gibt - also doppelt/viermal so viel
wie beim dsPIC. (Für nicht genutzten Flash gibt's kein Geld zurück.)
>Auch die Anzahl der "General purpose"-Counter ist nicht überwältigend.
Man kann auch die Timer von evtl. überzähligen ePWMs nutzen - so kommt
man auf 9 Timer.
Wenn ich mir die Liste der Anforderungen im ersten Post ansehe, sehe ich
nichts was gegen den C2000 spricht, außer: preislich liegt er minimal
über dem Limit, was sich mit etwas Verhandlungsgeschick aber bestimmt
lösen lässt.
Den TriCore wollten wir auch mal einsetzen, waren aber mit der
unübersichtlichen Dokumentation und dem Support nicht zufrieden und
haben dann doch einen anderen (nicht-Infineon) eingesetzt.
NEC V850
Die Decken eigentlich alle Anforderungen ab, ausser FPU. Die 128Mhz
variante sollte aber eigentlich schnell genug sein.
Die AVR32 könnten auch ganz interessant sein.
Morgen!
Ich hab zwar bereits gelesen, daß die C2000er von TI ausscheiden (warum
auch immer). Aber ich arbeite z.Z. auch mit einem TMS320F2812. Der läuft
bei 150 MHz und darauf läuft ein Programm, was für zwei
Synchronmaschinen separat den Strom regelt. Dazu noch ein überlagerter
Sliding-Mode-Beobachter für die jeweilige Drehzahlschätzung und
-regelung.
Ok, mit dem Speicher bin ich fast am Ende (ließe sich aber noch
optimieren). Und viel Puffer in meiner Rechenzeit hab ich auch nicht
mehr. Aber wie gesagt, es geht. Da das Teil keine gute
Fließkomma-Unterstützung hat habe ich das Programm komplett mit Schieben
und so auf Festkomma umgeschrieben.
Ok, das JTAG-Interface ist unverschämt teuer, aber wie gesagt, mit dem
Controller kommen wir hier eigentlich hin. Wenn meine Programmierkünste
jetzt noch besser als durchschnittlich wären könnte ich sicher noch mehr
aus dem Teil rausholen...
MfG
>Sollte minimale Interrupt Response Time wichtig>sein oder ein unabhaengiger Coprocessor fuer echtzeitkritische Teile des>Programmes, dann ist der TriCore dem SH2 darin bestimmt ueberlegen.
@Robert
Bist Du Dir da sicher und ist das Argument wirklich zündend?
Beim SH7286 sind max. 170-240ns im Datenblatt aufgeführt; min. sind es
80-150ns. Meine Messungen beim etwas schnelleren SH7211 ergaben so ca.
60ns und das mit einem 10MHz Quarz :-)
Hallo,
>C. H. und sepp: NEC hat auch 32-bitter für Motor-Control im Angebot.
Habe nachgeschaut. Haben max. 24 KB Ram. Aktuell vollkommend ok,
langfristig wäre etwas mehr nicht schlecht.
>Patrick: Was für mathematische Funktionen nutzt ihr den für die >Servosteuerung ?
Verwendet ihr Float oder Fix Point ?
Aktuell verwenden wir Fixpoint. Sehe auch aktuell kein zwingendes Muß
für Float.-Point
>Robert: aber die speziellen Eigenschaften des TriCore hast Du nicht als>Anforderungen erwaehnt
An was denkst Du dabei?
>Sollte minimale Interrupt Response Time wichtig>sein oder ein unabhaengiger Coprocessor fuer echtzeitkritische Teile des>Programmes, dann ist der TriCore dem SH2 darin bestimmt ueberlegen
Ich habe jetzt nicht speziell die Latenzzeiten angesehen, bin aber davon
ausgegangen, daß sie beim SH zumindest "normal" und brauchbar sind (eben
ein paar Takte). Ist der Tricore da außergewöhnlich?
>Michael K.:>ich nicht weiß wie er darauf kommt, dass der Bootloader 1/4 des Flash >braucht.
Hast Du da eine andere Erkenntnis?
>Man kann auch die Timer von evtl. überzähligen ePWMs nutzen - so kommt>man auf 9 Timer.
Ja - Kann man und das ist mir auch klar.
Ich will auch überhaupt nicht sagen, daß man mit dem C2000 nicht die
allerbesten Steuerungen bauen kann. Nur wenn ich eben bereit bin, einen
"Schnitt" zu machen, dann schaue ich mir alles aus einer
Idealvorstellung an und nicht gleich pragmatisch.
Und nochmals an die Cortex Experten: Stichwort Bit Banding und 32-Bit
immediate...
Gruß Wolf
Wolf schrieb:
> Und nochmals an die Cortex Experten: Stichwort Bit Banding und 32-Bit> immediate...
???
Die sauschnellen IO-Zugriffe sind doch gerade der große Vorteil der ARM
Cortex M3.
Ein normale ARM braucht dazu mindestens 3 Befehle (Lade Register mit
Adresse, lade Register Wert, gebe Wert auf Adresse aus). Und wenn ein
Bit gesetzt werden soll, ein anderes aber gelöscht, dann verdoppelt sich
das ganze (Zugriff auf Set- und Clear-Register).
Der ARM Cortex M3 ist quasi der 8051 der 32Bit-Welt.
Peter
Frage am Rande - wer setzt eigentlich noch auf 16Bit-Archtektur?
Irgendwie habe ich das Gefühl, die braucht gar keiner. Steckt bei mir in
einem einzigen Projekt (M16C), ansonsten entweder 8bit oder direkt
32bit.
Es gibt zwischen 8- und 32-bit keine klare Nische für 16-bit Cores.
Preislich und funktionell konkurrieren sie entweder mit den 8bittern
(MSP430) oder mit den massiv nach unten drängenden 32bittern, speziell
denen mit Cortex M3 Core, und wohl bald noch weiter runter mit dem
Cortex M0. Nur dass man sich mit den 32bittern den für 8/16bitter
typischen etwas nervenden Zirkus mit verschiedenen
Speicheradressbereichen für RAM und ROM erspart (Ausnahme: MSP430).
Warum setzt du dann noch 8 Bit Architekturen ein, wenn du schon 16
Bitter als Tabu ansiehst!
Manchmal kommt man eben an den Punkt wo man mehr Leistung braucht und 16
Bitter sind doch etwas billiger als 32 Bitter.
MFG Patrick
Wenn du micht meinst: von Tabu war nirgends die Rede. Ich habe nur
darauf hingewiesen, dass 16-bit Cores mittlerweise nicht mehr zwischen
8- und 32-bit Cores stehen, sondern sich den Raum mit diesen teilen.
Zumal hochkomplexe 16bit-Cores wie der vom Renesas M32C bei
vergleichbarer Chip-Tech wahrscheinlich mehr Platz auf dem Silizium
brauchen als der eines ARM7.
Was man dann persönlich wählt ist eine Entscheidung anhand einiger
Kriterien, wobei der Core und damit das Entwicklungssystem nur ein Teil
davon ist. Mich persönlich nervt es beispielsweise einerseits, zwischen
Adressräumen unterscheiden zu müssen. Andererseits sehe ich keinen Sinn
darin, für eine bessere Lüftersteuerung einen ARM zu verbraten, zumal
ich sowas gern in DIP-Bauform mache.
Und wenn man in Firmen strategische Entscheidungen für eine gewisse
Dauer treffen muss, nicht zuletzt weil professionelle
Entwicklungssysteme pro Platz 4stellig kosten, fährt man mit der
anbieterübergreifenden ARM-Familie schlicht flexibler als mit
anbieterspezifischen 16bit-Lösungen vergleichsweise enger Bandbreite.
Das dürfte mit dazu beitragen, diversen 16bittern das Wasser abzugraben.
@Peter:
>Die sauschnellen IO-Zugriffe sind doch gerade der große Vorteil der ARM>Cortex M3.
Ich habe folgendes ST-Doku angeschaut:
http://www.st.com/mcu/files/mcu/1221142709.pdf
Dort steht auf S. 18:
-------------------------------------
Any word in the peripheral and SRAM bit band regions can also be
directly
addressed word-wide so we could perform the same set and clear using the
more traditional AND and OR
approach:
GPIOB->ODR |= 0x00000100; //LED on
LDR r0,[pc,#68]
ADDS r0,r0,#0x08
LDR r0,[r0,#0x00]
ORR r0,r0,#0x100
LDR r1,[pc,#64]
STR r0,[r1,#0xC0C]
Now each set and clear operation takes a mixture of 16 and 32-bit
operations, which take a minimum of 14 bytes
for each operation and at the same clock frequency take a minimum of 180
nSec
-------------------------------------
Das scheint mir nicht gerade optimal zu sein. Beim dsPIC habe ich
Bit-set und Bit-clear Befehle, da geht sowas in einem Takt.
Gruß Wolf
>>Michael K.:>>ich nicht weiß wie er darauf kommt, dass der Bootloader 1/4 des Flash >>braucht.>Hast Du da eine andere Erkenntnis?
Ich habe ehrlich gesagt keine Erfahrung mit Bootloadern auf dem C2000,
kann mir das aber irgendwie nicht so recht vorstellen. Wie kommst du
denn darauf, dass das so ist? Irgendwo musst du diese Info ja her haben
und das würde mich sehr interessieren.
Bitbanging ist eindeutig eine starke Seite der PIC30 Familie (inkl.
24/33).
Allerdings ist obiger Code auch nicht grad optimal, denn alle mir
bekannten GPIO-Module für ARMs haben irgendeinen Methode, ganz ohne
komplexes load-modify-store einzelne oder mehrere Bits setzen oder
löschen zu können. Die Methoden dazu unterscheiden sich allerdings
teilweise erheblich, von der Adresse-als-Maske Technik der ARM Primecell
(STR9) zum ziemlich praktischen BSRR Register der STM32.
Das man bei ARMs die Adresse separat laden muss, während PIC30 die im
Befehl enthält, ist weniger relevant, denn wenn es zeitlich knapp wird,
dann wird ein guter Compiler diesen invarianten Teil aus der Schleife
kippen.
Zu allem Überfluss ist der gezeigte Code auch noch falsch. Denn wenn man
LDR r0,[pc,#68]
ADDS r0,r0,#0x08
LDR r0,[r0,#0x00]
benötigt, um den Wert von GPIOB->ODR zu laden, dann kann man ihn nicht
gut mit
LDR r1,[pc,#64]
STR r0,[r1,#0xC0C]
wieder speichern.
Korrekt wäre ohne Verwendung spezieller Peripherieregister:
LDR r0, [r1,#8]
ORR r0, r0, #0x100
STR r0, [r1,#8]
und irgendwann davor mal
LDR r1, [PC+#XXX] für die Basisadresse des GPIO-Moduls.
Mit entsprechendem Peripherieregister reduziert sich das auf
STR r0, [r1,#N] - 1:set bit, 0:ignore
und irgendwann davor mal
LDR r0, #0x100
LDR r1, [PC,#XXX] für die Basisadresse des GPIO-Moduls.
Gast schrieb:
> Hier geht es natürlich um ganz andere Anforderungen, das sollte auch nur> ein Hinweis für die "mit einem normalen µC geht nix"-Leute sein.
Wobei es mal ganz interessant wäre, zu erfahren, wodurch sich diese
besonderen Anforderungen ergeben.
Ich kenne Servoanwendungen auch nur als gemächlich, da es ja um
mechanische Bewegungen geht und da ist schon allein durch die zu
bewegende Masse die Geschwindigkeitsänderung begrenzt.
Auch haben elektromagnetische Antriebe eine beträchtliche Induktivitiät,
die der Stromänderung deutliche Grenzen setzt.
Stromändernungen im MHz-Bereich erscheinen mir daher sehr
unwarscheinlich.
Und selbst in Festplatten haben jahrzehntelang 8051-er ihren Dienst
getan (tun es wohl immer noch), wo ich ja deutlich schnellere und
genauere Reaktionen erwarte, als in Servoanwendungen.
Meistens ist es auch so, daß der exakte Fahrweg völlig uninteressant
ist, da kann interpoliert werden, was das Zeug hält. Hauptsache, die
Endposition stimmt wieder.
Aber vielleicht hat ja jemand nen Link zu solchen extrem schnellen
Servoapplikationen?
Peter
>Meistens ist es auch so, daß der exakte Fahrweg völlig uninteressant>ist, da kann interpoliert werden, was das Zeug hält. Hauptsache, die>Endposition stimmt wieder.
Das ist auch der Grund, warum der Mond um die Erde kreist: er
interpoliert noch, was das Zeug hält.
Schluck schrieb:
> Das ist auch der Grund, warum der Mond um die Erde kreist: er> interpoliert noch, was das Zeug hält.
Ist auch besser so, denn mit einem Microcontroller als Steuerung wäre er
uns längst auf den Kopf gefallen.
Wird eher so sein, dass derjenige Himmelskörper damit ausgestattet war,
der den Mond durch den Einschlag in die Proto-Erde überhaupt erst
ausgeworfen hat.
>Aber vielleicht hat ja jemand nen Link zu solchen extrem schnellen
Servoapplikationen?
Ein Scheibenwischer mit einem Brushless ... Beschleunigungskurve per
Differentialgleichung rechnen, Park-transformation,
Clark-Transformation, Stromaufnahme synchron zum 250kHz PWM, und dann
noch den 3 Phasen PWM per Bitbang raushaemmern.
Schluck schrieb:
> Das ist auch der Grund, warum der Mond um die Erde kreist: er> interpoliert noch, was das Zeug hält.
Recht vielen Dank für Deine geistreichen Kommentare.
Wenn sie fehlen würden, würde niemand sie vermissen.
Wie wärs, mal zum Unterschied auf die Frage einzugehen?
Peter
>Wie wärs, mal zum Unterschied auf die Frage einzugehen?
Oh, ich bin doch auf die Frage eingegangen; der SH7286 war mein Tipp.
Dazu gibt es einige App.Noten für Motorsteuerung; einfach mal danach
suchen.
@Michael: Die Info habe ich von einem TI-Seminar so in Erinnerung.
@A. K.: Wenn das so ist, dann sieht es etwas besser aus. Wobei ich mich
schon darauf verlasse, wenn ich ein Dokument von einem Hersteller
bekomme, in dem die tolle Performance so gelobt wird, das dann auch das
"optimale" ist. Auf alle Fälle, nachdem ich diesen Code für ein Bit
setzen gesehen habe, habe ich eben Zweifel bekommen.
Vielleicht kannst Du auch das mit dem 32-Bit immediate beantworten. Der
Arm kennt doch keine 32 Bit immediate. Wenn ich solch einen Wert in ein
Register laden will, dann brauche ich dafür doch mehrere Operationen.
Wie läuft es ab, wenn ich in R1 den Wert $12345678 laden will? das muß
doch dann mit 2* 16 Bit und schiebeoperation erfolgen, oder?
@Peter: oha hat da gar nicht so unrecht. Wir steuern auch sehr
hochpolige Motoren an. Dort kommen dann schon el. Drehzahlen von von
deutlich über 100 000/min mit Feldorientierter sinusförmiger Regelung
zustande.
Gruß Wolf
Wolf schrieb:
> Vielleicht kannst Du auch das mit dem 32-Bit immediate beantworten. Der> Arm kennt doch keine 32 Bit immediate.
Yep. Kein RISC kann das.
ARM-native kennt nur rotierte 8-Bit Konstanten, d.h. jeder 8-Bit Wert,
der um 0,2,4,6,...,30 rotiert passt, der geht rein. Damit sind alle
Einzelbits erfasst, aber Adressen und andere unpassenden Konstanten
werden i.d.R. PC-relativ geladen.
Thumb2 (Cortext M3) kann wahlweise zwei 16-Bit Hälften laden und
automatisch kombinieren, was etwas mehr Platz braucht (8 Bytes) aber
dank sequentiellem Zugriff schneller ist, oder PC-relativ aus dem ROM
laden (6 Bytes), was je nach Taktfrequenz und Waitstates vom Flash
deutlich langsamer sein kann. Ein Compiler wird sich ggf. je nach
Optimierungseinstellung entscheiden.
Was das Tempo vom Bitbanging angeht kann die Anbindung der GPIO-Module
eine wichtige Rolle spielen. Beim LPC1700 sitzen die direkt am Primärbus
und sind entsprechend schnell. Beim STM32 hingegen sitzen die an einem
Sekundärbus, was u.U. ein bischen mehr Zeit kostet.
>noch den 3 Phasen PWM per Bitbang raushaemmern.
Das sollte man doch eher in die HW verlagern!
>>C. H. und sepp: NEC hat auch 32-bitter für Motor-Control im Angebot.>>Habe nachgeschaut. Haben max. 24 KB Ram. Aktuell vollkommend ok,>langfristig wäre etwas mehr nicht schlecht.
Es gibt auch V850 mit mehr als 24KB Ram
Kurzer Nachtrag: Die NEC-Seite ist ja nicht gerade eine Meisterleistung
bezüglich Übersichtlichkeit. Aber so wie ich gesehen habe, haben die NEC
V850 Motion-Controll-Typen keinen CAN Bus. Das wäre ein K.o.-Kriterium.
Gruß Wolf
@Wolf
Bei der Auswahl des Controllers sollte man auch an die langfristige
Verfügbarkeit denken. Da schneidet TI mit Abstand am besten ab, wenn es
um "Motion-"Control geht. Ich sehe bei denen einfach am meisten
Aktivitäten in diese Richtung. TI ist da inzwischen eine Größe wie Intel
bei PC-Prozessoren. Normale Mikro-Prozessoren kämen mir da nicht in die
Tüte.
Hi.........Lust Antriebstechnik verwendet für seine Servosteuerungen nur
Infineon TriCore MCU's und die machen meines wissens mit die besten
Servoansteuerungen.
Grüße,
Alex
