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
Naja die Cortex M3 von NXP ticken mit 100Mhz !! MFG Patrick
>- 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.
@Wolf Nutzt ihr wirklich die DSP Funktionen des dsPIC ? Wie ich weiß hat da der Compiler noch leichte Probleme diese zu nutzen. MFG Patrick
Eine Empfehlung wäre der SH7286. Auch ohne FPU rechnet er sehr schnell. Auf dieser Seite findet sich wiederholt Werbung dafür. http://eu.renesas.com/fmwk.jsp?pk=002_0002_1&cnt=/sh_child.htm&fp=/products/mpumcu/reach_further/child_folder&site=i&title=SuperH&campaign=reachfurther Ein weiterer Typ wäre der SH7216, der angeblich jetzt verfügbar sein soll. Es sind affengeile µCs, wenn ich das so sagen darf :-)
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/
NEC hat auch 32-bitter für Motor-Control im Angebot. Gruß Christian
Der STM 32 schafft "nur" 1,17 us bei 72 Mhz - siehe http://www.st.com/stonline/products/literature/rm/13902.pdf Seite 199 Bzw die Access Line STMF101xx schafft nur 1,55 us bei Fullspeed.
@Wolf Was für mathematische Funktionen nutzt ihr den für die Servosteuerung ? Verwendet ihr Float oder Fix Point ? MFG Patrick
@ Wolf, ... Von der Performance sind wir am Limit... was bedeutet das ? Was ist der Aufwand ?
@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
>Der ARM Cortex M3 ist quasi der 8051 der 32Bit-Welt.
Dann sollte man wohl besser die Finger davon lassen :-)
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
@sepp: >Es gibt auch V850 mit mehr als 24KB Ram auf der speziellen motion-control Registerkarte siehe http://www.eu.necel.com/micro/product/device_overview.php?category=32-bit-MC-AllFlash hört es aber bei 24 KB Ram auf. Muß vielleicht noch schauen, was der Unterschied zu den anderen NIcht-Motion-Typen ist. Gruß Wolf
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.