mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik 32 Bit Controller für Motion Control


Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Vlad Tepesch (vlad_tepesch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
schau dir mal die AD Blackfins an.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja die Cortex M3 von NXP ticken mit 100Mhz !!

MFG Patrick

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>- 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?

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolf

Nutzt ihr wirklich die DSP Funktionen des dsPIC ?
Wie ich weiß hat da der Compiler noch leichte Probleme diese zu nutzen.

MFG Patrick

Autor: Schluck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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=/...

Ein weiterer Typ wäre der SH7216, der angeblich jetzt verfügbar sein 
soll. Es sind affengeile µCs, wenn ich das so sagen darf :-)

Autor: blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Fralla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: C. H. (_ch_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
NEC hat auch 32-bitter für Motor-Control im Angebot.

Gruß
Christian

Autor: blabla (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Wolf
Was für mathematische Funktionen nutzt ihr den für die Servosteuerung ?

Verwendet ihr Float oder Fix Point ?

MFG Patrick

Autor: oha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Wolf,
... Von der Performance sind wir am Limit...

was bedeutet das ? Was ist der Aufwand ?

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Karl M. (movex)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Michael K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>- 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.

Autor: sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Joachim B. (jojo84)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schluck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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 :-)

Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schluck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Der ARM Cortex M3 ist quasi der 8051 der 32Bit-Welt.

Dann sollte man wohl besser die Finger davon lassen :-)

Autor: H.j.Seifert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Patrick Weinberger (seennoob)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Michael K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schluck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: oha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Schluck (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: sepp (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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

Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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_overv...

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

Autor: Wolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Helmut S. (helmuts)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Alex Schmidt (alex_muc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.