Hallo MCU Freunde, Wir starten im Moment bei uns auf der Arbeit ein neues Projekt in Richtung Motorsteuerung eines BLDC Motors inkl. FOC. Jetzt geht es natürlich um die Auswahl des Mikrocontrollers und da wäre es schön wenn Ihr mich ein wenig mit Eurer Erfahrung Unterstützen könntet. Ü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. Vielleicht könntet Ihr mich ein bisschen aufklären über den Unterschied 16/32 Bit das wäre echt super :) Die Controller, welche ich mir mal angeschaut habe sind: 16Bit: dsPIC33, Freescale 56F80X 32Bit: TI C2000, STM32, Renesas hat glaube ich auch noch etwas sowohl 32 Bit als auch 16 Bit. Bin einfach mal auf Eure Meinungen gespannt. 16 Bit oder 32Bit für Motor Control Danke! Gruß Martin
Martin schrieb: > 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. Wenn das Dein Problem ist, nimm einen 8-Bitter.
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
Hi Frank, Ja bin mir eigentlich schon über die Algorithmen bewusst. Clarke Park inverse Clarke Park, svpwm, Speed estimation.... Das Probelm ist halt, dass ich das laut Hersteller sowohl auf einem c2000, einem dspic33, einem stm32 und einem 16 Bit freescale Controller hinbekomme. Deshalb bin ich gerade noch auf dedr Suche nach anden Vorteilen der 32 Biter. Beim Stm32 gefällt mir der Befehlssatz 16/32 Bit wobei der c2000 das ähnlich macht. Der dsPic hingegen mit seinen 22bit befehlen macht das wiederum ein wenig änderst. 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.... Gruß Martin
Und was sind die stichhaltigen Argumente GEGEN einen 32bit Controller?
Hi Läubi, Also teilweise ist es noch der Preis der z.B. Gegen einen 32 Biter spricht. Gerade wenn ich mal so in Richtung 32bit und BLDC Control schaue gibt es im unteren 32bit Segment nicht viele die die entsprechende Peripherie mitbringen. Bei Arm wie schon geschrieben der Stm32f103 mit 64kb Flash und 48 Pins. Bei der folgenden Aussage möchte ich bitte korrigiert Weden, falls sie falsch ist. 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, 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. Der Controller lädt dort einen 32bit wert und muss die übrigen 16 Bit erst wieder löschen. Wie gesagt korrigiert mich bitte wenn ich falsch liege Martin
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.
A. K. schrieb: > Was ist "spän"? Spän ist das Ergebniss ovn IOS in Verbindung mit einem rechtschreibfehler und mein sparen =) Sorry A. K. schrieb: > s 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. Blöde frage aber was genau ist der Unterschied zwischen uint16_t und uint_fast16_t?
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
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.
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
Es gibt 8/16 Bit MCUs, mit PointerRegistern >16 Bit, da ist die Adressierung in der Realität kein Problem (und hunderte MBytes an Code hat man meist sowiso nicht). Von daher wäre kein 32Biter nötig. Aber bei uCs mit viel Periferie und/oder RAM/Flash ist selbst bei (optimierten) 32 Bitern ist die SiliciumFläche rel gering im Vergleich zum ges. Controller, was heisst der uC ist deshalb nur unwesentlich teurer, als 8/16 Biter. >Das Probelm ist halt, dass ich das laut Hersteller sowohl auf einem >c2000, einem dspic33, einem stm32 und einem 16 Bit freescale Controller >hinbekomme. Hersteller behaupten immer alles mögliche, die Frage ist, wiel lange der uC wirklich braucht, um das zu berechnen. Aber bei Motor-Control (bsp Vector-Regelung) ist einiges an Rechenleistung nötig. -Toshiba haben CM3's mit spez. implem. Hardware für Motorcontrol (da ist dann keine Programmierung mehr nötig) -TI haben nen F28.. DSP mit angehängtem CM3. -Freescale-Kinetis haben CM4 mit FloatingPnt -Renesas SH, M16/32C.. , RX
Manche 32Biter haben auch Nachteile oder sind langsamer, wenn es um Bearbeitung von Daten kleinerer Bitbreiten geht.
> Hersteller behaupten immer alles mögliche, die Frage ist, > wiel lange der uC wirklich braucht, um das zu berechnen. Ich glaube auch das was man braucht haengt irgendwie vom Angebot ab. :-) Ich habe hier eine Palette 10Jahre alter SH7045 rumliegen. Das ist ein Controller mit 32Bit, 28Mhz und Cache. Ich meine irgendwo gelesen zu haben das dies damals der schnellste Microcontroller war den man kaufen konnte. Gedacht war er unter anderem als Motorcontroller. Heutzutage duerfte der vermutlich von einer ganze Menge Standardcontroller ueberholt werden. Also sollten die eigentlich alle dafuer geeignet sein. > Manche 32Biter haben auch Nachteile oder sind langsamer, wenn es um > Bearbeitung von Daten kleinerer Bitbreiten geht. 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. Ich koennte mir aber auch vorstellen das es relativ lahme Controller gibt die sich Wacker schlagen weil sie bestimmte Dinge in Hardware implementiert haben. Ich meine z.B es gab/gibt ein paar unauffaellige R8C die extra als Motorcontroller beworben werden. Ausserdem muss man die eigene Faulheit einkalkulieren. Man kann viele Dinge mit kleinen Bitbreiten realisieren, aber es ist halt bequemer wenn man aus dem vollen Schoepfen kann. Ich wuerde wirklich nur noch extrem ungern einen 8Bit Controller anpacken nachdem ich einmal 16/32 genutzt habe. Die naechste Stufe sind dann wohl die faulen Saecke die alles mit Matlab designen wollen und dann erwarten das ein automatisches Tool ihnen den Source fuer den Microcontroller generiert. Da muss es dann sicher auch eine Nummer dicker sein als frueher als man es noch selber in Handarbeit gemacht hat. Olaf
...kommt immer drauf an, wo du deinen fokus setzt. kurze entwicklungszeit ? ...dann ein klickediklack-generierecode-kit für bldc + foc. da musst du mal gurgeln, gibt es für TMS320xxx z.B. und andere uC/DSP auch. evtl. beim motorhersteller um unterstüzung bitten und/oder beim uC-hersteller. oder möglichst niedriger komponentenpreis, weil hohe stückzahlen ? ...dann billigsten uC nehmen und design reinquetschen und beten das es tut. oder möglichst flexibel + second source bzw. möglichst einfache portierbarkeit ? ...dann z.B. Cortex M3 nehmen, CMSIS benutzen und mit etwas bedacht kannst du null problemo von einem zum anderen portieren ohne deine applikation anfassen zu müssen. ist halt eine gleichung mit mehreren eingabegrössen. gruss, tom.
@ 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
Frank K. schrieb: > Schon mal was von der Clarke und der Park Transformation gehört? Wirklich eindrucksvolle Namen für eine simple Drehmatrix phasenverschobener Vektoren ...
>oder möglichst flexibel + second source bzw. möglichst einfache >portierbarkeit ? > ...und mit etwas bedacht kannst du null problemo von einem zum anderen > portieren ohne deine applikation anfassen zu müssen. Kann man vergessen. Es gibt fast keine SecondSources von Controllern. Wenn die CPU die Gleiche ist, heisst das noch lange nicht, dass der Controller der Gleiche ist. >Die meisten ARM sind da grausam langsam ... ua auch weil das Flash meist langsam ist >.. der braucht je nach Adressierung auch 4-5 Takte. Unser allseits beliebter > AVR braucht EINEN bis maximal ZWEI! Aber je nach gewünschter Adressierung braucht AVR dafür auch wieder mehrere Befehle, weil RISC! Viele andere Controller sind dafür auch höher taktbar.
@ 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
>Man kann ja auch aus dem RAM arbeiten, das ändert nichts. Und wenn das Progr ausm Flash ausgeführt werden soll, kommen Waitstate's zus. noch dazu. (und RAM für Progr-Ausführung muss man erst mal haben) >Aber je nach gewünschter Adressierung braucht AVR dafür auch wieder >mehrere Befehle, weil RISC! Für manche CISC-Befehle sind gleich mehrere RISC-Befehle nötig, das wird oft unterschätzt. (Und der Hersteller v. RISC wirbt nicht damit). Oft braucht RISC dann mehr Takte als CISC.
Wobei das auch hinkt. RISC hat den großen Vorteil einer Pipeline. Im Idealfall folgt ein Befehl dem anderen. Schwierig wird nur bei Sprüngen oder Interrupts, wenn die Pipeline neu befüllt werden muss. AFAIK haben deshalb die LPCs auch eine 128Bit breite Flashanbindung. Damit kann die Pipeline sehr schnell wieder gefüllt werden. Bei echtem CISC ist eine Pipeline nicht möglich.
Frank K. schrieb: > In der Industrie ist die Entwicklungsumgebung eigentlich nicht der > ausschlaggebende Faktor. Das kann man so nicht sagen... Wenn die Entwicklungsumgebung nur Probleme generiert, ständig abstürzt, nur ineffizienten Code ausspuckt und eine Firma soetwas einsetzt, kann sie ziemlich schnell den Laden dicht machen. Olaf schrieb: > Die naechste Stufe sind dann wohl die faulen Saecke die alles mit > Matlab designen wollen und dann erwarten das ein automatisches Tool > ihnen den Source fuer den Microcontroller generiert. Überlege dir mal was bei einem komplexen Regelkreis passiert, wenn du nur eine Rückkopplung entfernst. Da müsstest du in C einige (hundert) Zeilen Code ändern. Der Embeddet-Coder hat sicherlich seine Daseinsberechtigung, obwohl der Code furchtbar ist, der da am Ende rauskommt.
>Bei echtem CISC ist eine Pipeline nicht möglich.
Quatsch.
-----------
Auch eine 128Bit breite Flashanbindung verhindert nicht Waitstates ausm
Flash, weil die ASM-Befehle im Normalfall nie continuierlich aufeinander
folgen.
@MCUA: Wie soll eine Pipeline bei CISC funktionieren? x86 CPU haben eine Pipeline, allerdings sind die nur noch nach aussen hin CISC, intern arbeiten die auch mit RISC. /Edit: Ich hab noch keinen 8051er mit Pipeline gesehen, lasse mich aber gerne vom Gegenteil überzeugen.
>Wie soll eine Pipeline bei CISC funktionieren? OP-Codes müssen nicht alle gleiche Länge haben, um in die Pipeline eingebaut werden zu können. Es gibt genug moderne CISCs uCs, gugg dich mal um. Aber nenne nicht 8051, das is ne olle Camelle.
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.
A. K. schrieb: > Allerdings ist NXP damit die > > Ausnahme, üblicherweile liegen die Ports auf den langsameren > > Peripheriebussen. 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. Bei den Vorgängern waren es noch 2 Takte, da am APB. Was allerdings auch nicht wirklich langsam war.
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.
>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) Nicht, wenns ausm Flash läuft!
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.
Hallo Martin, ich würde Dir aus eigener Erfahrung zu einem 32Bitter für die FOC raten. Das ist natürlich eine Pauschale Aussage aber mit 16Bittern habe ich die Erfahrung gemacht das die FOC zwar realisierbar ist, man aber viele Kompromisse eingehen muss um alles zum laufen zu bringen, d.h. ich musste immer viel auf den Prozessor optimieren, was letztendlich zu schlecht portierbarem Code geführt hat. Insgesamt müsstest Du aber mal abschätzen welche Performance du benötigst, d.h. - wie häufig muss Deine Regelung gerechnet werden - welche sonstigen Funktionen müssen parallel zum Motor laufen ( z.b. Busse, Steuerungsaufgaben, ...) - welche Timinganforderungen haben die anderen Funktionen - ... Ich habe dazu meistens im vorraus mal ein paar Testfunktionen auf den Controllern implementiert und dann ungefähr hochgerechnet wie die Endgültige Auslastung ist. Was vielleicht auch noch ein Punkt ist: 32Bit Controller gibt es meist nur mit 3,3V Versorgung, d.h. alle Signale müssen auf 3,3V umgesetzt werden. Hieraus ergeben sich ggf. auch ein paar Nachteile aus EMV Sicht. Viele Grüße, Jupp
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.
@michelle Du arbeitest Du mit Linux. Ist für jeden von Dir aufgezählten Controller auch eine GCC toolchain verfügbar ? jöög
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?
Wenn der Sinus per Reihenentwicklung und nicht per Lookuptable berechnet wird, hören sich für mich 40 Takte OK an. Mit der Pipeline habt ihr wohl recht. Hab da wohl zu sehr an halbwaren Aussagen vom Studium gehangen.
@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...
Zu der Zeit konnte sich warscheinlich keiner Vorstellen das es Menschen gibt die eine 20 Stufige Pipeline für Complexe Instruktionen, die "out of order" auf verschiedene Ausführtungseinheiten aufgheteilt werden und dabei auch noch stalls in Hardware ausgeschlossen werden. Natürlich Alles mit Sprungvorhersage die den Zukünftigen Code nach statistescher Analyse aus dem Speicher im voraus läd. Und jetzt bitte nachbauen !
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
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.