Lohnt sich der Umstieg auf 32-Bit Controller

Hallo Martin,

ich arbeite seit 1982 mit 8051ern und habe auch seit 3 Jahren PICs
und MAXQs hier.  Drzeit bin ich dabei, meine GESAMMTE Produktpalette
auf 32 Bit umzustellen, weil es einfach einfacher ist und vor allem
eigene Bibliotheken austauschbar.

Ich verwende ARM Cortex MO (NXP LPC11Cxx + LPC11Uxx), ARM CORTEX M3
(TI LM3S5T36, NXP LPC1751 + LPC1769), ARM 7 (Atmel SAM7XC + SAM7SE),
ARM 9 (Atmel AT91SAM9263, ...) sowie großkaliber ARM 11 und A9 
(Marvel
und TI)

Alle Microcontroller sind kompatibel mit dem Sourcecode was die
Entwicklung WESENTLICH einfacher macht und man benötigt definitiv nur
eine Entwicklungsumgebung.

Ich kann die 32biter nur empfehlen.

Ich habe für meinen eTruck erst 8051er genommen, bin aber dann an den
fähigkeiten der Microcontroller gescheitert, da ich Drehzahl-Steuerung,
-Erfassung, ASR, und andere Dinge für die BLDC Motoren beötige.

Der PIC32 (MX795HL) ist zwar nett, hat mich aber den lezten Nerv 
gekostet womit ich auf einen LPC1769 umgestiegen bin, welcher für mich 
zudem noch wesentlich billiger war und mehr funktionsumfang bot.

Grüße
Michelle

Dass 32-Bit Controller sich beim Umgang mit Daten >16-Bit leichter tun 
liegt auf der Hand. Aber der Umgang mit Adressräumen ist mindestens 
ebenso wichtig.

8/6-Bit Controller können entweder nur zusammen 64KB adressieren, oder 
sie haben mehr oder weniger getrennte Adressräume für Code und Daten. 
Dadurch wird es oft notwendig, Daten im ROM und Daten im RAM 
unterschiedlich zu adressieren, Pointer entsprechend zu kennzeichnen 
(soweit im Compiler überhaupt möglich).

Für manche Architekturen besitzen C Compiler daher getaggte/gemanagte 
Pointer für mehrere Adressräume, mit zeitraubenden Laufzeitfunktionen 
beim Zugriff. Andere Architekturen betten ein wählbares ROM-Fenster in 
den Datenadressraum ein (PIC30) oder umgekehrt den Datenadressraum in 
einen grossen Gesamtadressraum (M16C/M32C).

Bei 32-Bit Controllern entfällt diese Gewürge mit Adressräumen 
vollständig. Ob Daten im ROM oder im RAM liegen ist für den Zugriff 
darauf völlig irrelevant. Den Programmierer kann sich die Mühe sparen, 
sich bei den Pointern stets über deren Erfassungsbereich Gedanken zu 
machen.

Was die I/O-Module angeht hat dies auch zur Folge, dass der Hersteller 
die I/O-Registerstruktur nicht platzsparend implementieren muss, was zu 
grösserer Flexibilität im Umgang einläd. Wenn ein I/O-Modul komplette 
4KB frisst stört das nicht weiter.

Martin schrieb:

> Überall hört man dass die 32-Bit Controller in das Segment der 16 Bit
> Controller sogar teilweise in das Preissegment der 8 Bit MCUs.
> Theoretisch kann ich meine Anwendung vermutlich mit einer 16 Bit MCU
> oder einer 32 Bit MCU lösen aber was würdet Ihr empfehlen?
> Macht es Sinn heute schon auf den 32 Bit Hype aufzuspringen und welche
> Vorteile habe ich den eigentlich wenn ich eine 32Bit MCU nehme?
> Ich habe größere Register aber so viel bringen mir die doch auch nicht,
> wenn ich z.B. sowieso nur 12 Bit ADC´s hab.

Hast Du denn schon eine Ahnung davon, was für Algorithmen zur 
Ansteuerung eines BLDC Motors erforderlich sind? Bist Du fit in den 
mathematischen Grundlagen? Schon mal was von der Clarke und der Park 
Transformation gehört? Schon mal mit PID-Reglern gearbeitet?

Bei solchen Teilen muss heftig gerechnet werden. Ihr braucht auch eine 
gewisse Rechengenauigkeit.

Informiert Euch erstmal über die Algorithmen, die Ihr braucht, und über 
die erforderliche Peripherie. Dann könnt Ihr selber entscheiden.

Zum Einstieg:

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1824&appnote=en530042

fchk

Und was sind die stichhaltigen Argumente GEGEN einen 32bit Controller?

Martin schrieb:

> Beim 32 bitter benötige ich meißt mehr Speicherplatz weil ich zum ersten
> mir nicht mehr unbedingt die Gedanken zum spän mache und zum zweiten,

Beim Codeverbrauch mittlerer bis grosser Programme schenken sich die 
neuere kompakten Codierungen wie Cortex-M3 gegenüber den 16-Bittern 
nicht so arg viel, liegen besser als die 8-Bitter. Der Datenverbrauch 
ist grösser, hauptsächlich weil Stacks und Pointer mehr Platz benötigen. 
Deshalb haben vergleichbare 32-Bit Controller oft mehr RAM.

Was ist "spän"?

> dass hat zumindest meine Messung mit dem stm32 ergeben, ich beim
> arbeiten mit 16 Bit Werten länger brauche als beim arbeiten mit 32 Bit
> werten.

Das hängt vom Programmierstil ab. Die Grösse statischer und globaler 
Daten geht eher gering in die Laufzeit ein. Man sollte aber keinesfalls 
skalare lokale Variablen als 8- oder 16-Bit Typen deklarieren, sonst 
handelt man sich deutlich Overhead ein.

Es gibt Leute, die für lokalen Daten konsequent den minimal nötigen Typ 
wie uint16_t verwenden. Böser Fehler. Angebracht wäre hier "unsigned" 
(oder für Puristen uint_fast16_t). Bei 8-Bit Typen ist sowas wie 
uint_fast8_t sinnvoll, was auf die jeweils schnellste Datenbreite 
rausläuft.

> Der Controller lädt dort einen 32bit wert und muss die übrigen 16 Bit
> erst wieder löschen.

Nein. Lade/Speicherbefehle für 16-Bit Daten sind heute stets vorhanden. 
Anno ARM2 war das noch anders, aber das ist über 2 Jahrzehnte her.

Was aber ein Problem ist (siehe obigen Absatz):

1

   uint16_t temp1 = a * b;

2

   uint16_t temp2 = temp1 / 2 + c; 

3

   uint16_t temp3 = temp2 ...usw.

Hier muss u.U. jedes Zwischenergebnis im Register umständlich vor der 
Weiterverarbeitung von 32-Bit auf 16-Bit runtergeschnippelt werden, was 
bös auf die Performance gehen kann.

PS: Was ich für lokale Variablen schrieb gilt gleichermassen auch für 
Parameter von Funktionen. Auch hier ist < 32-Bit u.U. ineffizient und 
spart garantiert nichts ein.

Martin schrieb:

> Blöde frage aber was genau ist der Unterschied zwischen uint16_t und
> uint_fast16_t?

uint8_t ist immer 8 Bits breit.

uint_fast8_t ist der am effizentesten zu verarbeitende Datentyp mit 
mindesten 8 Bits. Da ARMs in Registern immer mit 32 Bits arbeiten ist 
das dort folglich identisch mit uint32_t.

uint_fast16_t ist praktisch identisch mit unsigned, da C für unsigned 
mindestens 16 Bits vorschreibt.

Martin schrieb:

> Der dsPic hingegen mit seinen 22bit befehlen macht das wiederum ein
> wenig änderst.

Wobei der zwei 40 Bit Akkus für DSP-Algorithmen plus entsprechende 
Befehlssatzerweiterungen hat.

> Ich würde eigentlich auch eher zu den 32 Bitern tendieren vorzugsweise
> Arm wegen der Skalierbarkeit aber irgendwie fehlen mir noch ein paar
> stichhaltige Argumente warum ich einen 32 Biter brauche....

Was möchtest Du skalieren? Üblicherweise ist jedem Motor ein eigener 
Controller zugeordnet, der nichts anderes macht, und zwar schon alleine 
deswegen, um die Leitungslänge zwischen Controllerkarte mit der 
Leistungselektronik und dem Motor zu minimieren. Stichwort EMV. Der 
Controller muss also nur schnell genug und möglichst billig sein.

fchk

Martin schrieb:
> Frank K. schrieb:
>> Was möchtest Du skalieren? Üblicherweise ist jedem Motor ein eigener
>> Controller zugeordnet, der nichts anderes macht, und zwar schon alleine
>> deswegen, um die Leitungslänge zwischen Controllerkarte mit der
>> Leistungselektronik und dem Motor zu minimieren. Stichwort EMV. Der
>> Controller muss also nur schnell genug und möglichst billig sein.
>
> Sklaierbarkeit insofern, dass man für BLDC Steuerungen mit FOC also im
> Prinzip ne PMSM Steuerung einen Cortex M3 oder M4 nimmt und für ne
> steuerung mit reiner Blockkommutierung einen M0.
> Wie schon weiter oben erwähnt ist das dann die gleiche
> Entwicklungsumgebung under der gleiche JTAG Adapter.
> Der Code ist zwar meißtens nicht 1:1 Kompatibel da die Peripherie sich
> anderst verhält und die CMSIS zwar ganz nett aber nicht 100% effizient
> ist, jedoch sind die reinen Algorithmen auf den verschiedenen Cortex
> Typen kompatibel.

In der Industrie ist die Entwicklungsumgebung eigentlich nicht der 
ausschlaggebende Faktor. Der Trend geht dahin, dass die Peripherie immer 
wichtiger und der eigentliche CPU-Kern immer unwichtiger wird. Nimm die 
billigsten Controller, die Deine Anforderungen erfüllen und die optimale 
Peripherieunterstützung haben.

fchk

@  Olaf (Gast)

>Vor allem beim bitweisen Zugriff auf Ports muss man aufpassen. Es kann
>sein das einem da einiges an Zeit verloren geht weil die Controller sich
>da auf ihren IO-Takt aufsyncronisieren muessen.

Eben. Die meisten ARM sind da grausam langsam und brauchen mehrere (Ein 
Dutzend++?) CPU-Takte. Der MSP430 ist da auch nicht do flott, der 
braucht je nach Adressierung auch 4-5 Takte. Unser allseits beliebter 
AVR braucht EINEN bis maximal ZWEI! Für Bitbanging absolut Spitze!

MFG
Falk

@  MCUA (Gast)

>>Die meisten ARM sind da grausam langsam ...
>ua auch weil das Flash meist langsam ist

Nö, das hat andere Ursachen. Man kann ja auch aus dem RAM arbeiten, das 
ändert nichts.

>Aber je nach gewünschter Adressierung braucht AVR dafür auch wieder
>mehrere Befehle, weil RISC!

Nö, bestenfalls ein oder zwei Takte mehr für ld oder lpm. Das ist 
verkraftbar.

MFG
Falk

Falk Brunner schrieb:

> Eben. Die meisten ARM sind da grausam langsam und brauchen mehrere (Ein
> Dutzend++?) CPU-Takte.

Bei der FastIO der NXP Typen dürften das so circa 2-3 Takte sein, weil 
ein LDR/STR auf dem schnellen Primärbus. Allerdings ist NXP damit die 
Ausnahme, üblicherweile liegen die Ports auf den langsameren 
Peripheriebussen.

Tilo Lutz schrieb:

> Wie soll eine Pipeline bei CISC funktionieren?

Genauso wie bei RISC. Ich sehe da kein Problem.

Die RISC/CISC Frage hat keinen wesentlichen Bezug zum Pipelining, ausser 
dass CISC Pipelines ggf. anders aussehen, z.B. wenn sie auch 
read-modify-write Befehle ohne Stall abdecken (wie Cyrix 5x86).

> x86 CPU haben eine Pipeline, allerdings sind die nur noch nach aussen
> hin CISC, intern arbeiten die auch mit RISC.

Erst ab Pentium Pro (und K5, Nx586). Bereits der ursprüngliche 8086 
hatte einen entkoppelten instruction fetch, folglich eine wenngleich 
sehr einfache Pipeline. Beim 68000 war die Pipeline schon ausgeprägter. 
Beim 486 war die Pipeline dann prinzipiell vergleichbar mit den 
Pipelines der RISCs wie MIPS.

Hannes S. schrieb:

> Auch bei ST hängen ab STM32L/STM32F2xx die Ports mittlerweile direkt am
> AHB, der Zugriff darauf benötigt nur 1 Takt. (Bei 120MHz also 8,33ns)
> Bei NXP sollte das auch nicht langsamer sein.

Ich bezog mich bei den Takten der NXPs nicht auf den Bus selbst, sondern 
auf die Gesamtlaufzeit der Befehle der damit zuerst ausgestatteten 
ARM7er aus der LPC2000 Reihe. Deren GPIO der ersten Typen war 
anerkanntermassen gar schröcklich langsam, was Philips/NXP bei 
Nachfolgern zu entsprechenden Taten inspirierte.

Hallo Martin,

Ich empfehle dir dich hier mal einzuelesen.
http://focus.ti.com/lit/wp/sprt528/sprt528.pdf

Dann schaust du dich bei TI mal nach Kits um die deiner Aufgabe am 
nächsten kommen. Z. B. hier. Wenn du einen passenden findest, dann 
könntest du damit sofort loslegen (programmieren).
http://focus.ti.com/mcu/docs/mcuproductcontentnp.tsp?sectionId=95&familyId=916&tabId=2287

TI ist Marktführer bei DSPs für Motor Control.  Das bedeutet du machst 
nichts falsch, wenn du einen DSP aus der C2000 Famile wählst. Das sind 
32bit Controller mit passender Peripherie für Motor Control.

Vergiss sofort jeglichen Gedanken an 8bit Controller für diese Aufgabe.

Helmut

MCUA schrieb:

> Nicht, wenns ausm Flash läuft!

Um Waitstates wurde schon in einem anderen Thread ausgiebig gestritten, 
ich sehe kein Grund, dieses Thema in diesem Thread wieder aufzuwärmen:
Beitrag "Einregister- vs. Mehrregistermaschine"

Hat er irgendwo geschrieben, was das wirklich mal werden soll? Nen 
PC-Lüfter braucht nämlich keinen abgefahrenen 1000 MHz DSP!
Ich würd maal bei den dsPICs reinschauen, könnte ne günstige und einfach 
zu entwickelnde Sache werden, da der Befehlssatz den PIC24 ähnelt. 
Bekommt man auch Hilfe in Foren.
Aber wie gesagt, kommt auf die spezifische Anwendung an.

Falk Brunner schrieb:
> Eben. Die meisten ARM sind da grausam langsam und brauchen mehrere (Ein
> Dutzend++?) CPU-Takte

Wie sieht es da eigentlich bei TI & C2000 aus?
Ich habe mir darum ehrlich gesagt noch nie Gedanken gemacht.
Ob das Ding nun 2 oder 15 Takte benötigt ist/war mir egal.
Hauptsache es funktioniert in der geforderten Zeit...
Was mich aber teilweise ziemlich stutzig gemacht hat ist, dass die FPU 
für eine Sinusberechnung auch 40 Takte (ohne Register Sicherung, etc.) 
benötigt.
Und das nennt sich dann "Fast FPU supplement" :).

Viele Grüße

PS: Bei einer Motorsteuerung (SVPWM, FOC) würde ich keinen 8-Bitter mehr 
verwendet.

Christian W. schrieb:

> Was mich aber teilweise ziemlich stutzig gemacht hat ist, dass die FPU
> für eine Sinusberechnung auch 40 Takte (ohne Register Sicherung, etc.)
> benötigt.

Sind 40 Takte für einen Sinus wirklich sooo langsam? Wer ist denn 
schneller?

@Martin

Schaue Dir mal den Artikel STM32 an, darin stehen viele Infos die 
gerade für Einsteiger interessant sind.

Vieles lässt sich auch auf die anderen ARM Cortex-M3 Chiphersteller 
übertragen, z.B. NXP LPC17xx oder TI.

Tilo Lutz schrieb:
> Mit der Pipeline habt ihr wohl recht. Hab da wohl zu sehr an halbwaren
> Aussagen vom Studium gehangen.
Halbwahr != Halbverstanden ;-)

Schau lieber nochmal nach ich kann mir kaum vorstellen, dass das 
irgendwer ernsthaft behaupten will das eine Pipeline nur mit RISC 
funktioniert...

Tilo Lutz schrieb:

> Mit der Pipeline habt ihr wohl recht. Hab da wohl zu sehr an halbwaren
> Aussagen vom Studium gehangen.

Hier mal ein Überblick über Pipelining in einer Ära, in der neben den 
intern RISC-artig zerlegenden Cores wie Pentium-II und AMD K6 mit dem 
Cyrix 6x86MX (M2) auch noch ein echter CISC-Core vertreten war: 
http://www.azillionmonkeys.com/qed/cpuwar.html