Hallo Gemeinde,
ich möchte/ muss mich in einen der beiden Typen einarbeiten und wollte
Mal fragen welcher von der Komplexität schwerer zu handhaben ist?
Gruss Peter
Würde ich - was die Chips angeht - grob in die gleiche
Komplexitätsklasse einordnen. Wär eher die Frage, wofür man man wo
besser Support bekommt und welche Entwicklungsumgebung man im Auge hat.
Hier im Forum sind die PIC32 jedenfalls weniger präsent (vielleicht sind
sie sind so trivial, dass niemand jemals ein Problem damit hatte ;-).
Mag anderswo anders sein.
Bei PIC32 kommt alles aus einer Hand: Chip, Debugger, Compiler, IDE,
Libraries. Das passt daher auf Anhieb zusammen.
Bei den ARMs (dazu gehört auch STM32) musst Du Dir alles auf dem Markt
von verschiedenen Herstellern zusammensuchen.
fchk
Hallo,
danke euch schon einmal für eure Antworten. Die Sache ist die, ich komme
mit den 8.Bittern AVRs und den 16-Bittern MSP schon ganz gut klar. Jetzt
soll halt ein großer 32 Bitter für die Ansteuerung eines Touchscreen und
als CAN Sniffer mit SD her. Ich habe mir schonmal ein STM 32 Board
gekauft und damit zwei Tage herumgespielt. Ich fand die Art und Weise
der Programmierung teils ziemlich komplex. Ich wäre aus dem Datenblatt
nie auf des Ergebnis in den Beispielen gekommen, was bei den AVRs nie
der Fall ist (gut....Äpfel mit Birnen....). Aber wenn ihr sagt die PICs
sind ähnlich, denn werde ich wohl weiter mit den STM spielen um die
Teile zu verstehen. Geld ist nicht der wichtigste Punkt. Klar will ich
keine 5000 Euro für einen Compiler zahlen, aber die Boards und Debugger
müssen jetzt nicht unbedingt unter 100 Eu liegen.
Hängt auch vom Vorwissen ab. Wer schon mit PIC24, dsPIC gearbeitet hat,
kennt die Peripherie und/oder Microchip-Libraries wahrscheinlich schon.
Ansonsten kann ich mich den Vorrednern nur anschließen: Alle Tools aus
einer Hand, gut integriert, läuft. Offizielle C++ Unterstützung gibt es
allerdings erst seit kurzem und nur für PIC32 (falls man auf PIC24/dsPIC
zurück will).
Ähnlich gute Integration aus einer Hand gibt es afaik nur bei den
Cortex-M3 von SiLabs (IDE, Compiler, Debugger, AppBuilder, etc.).
Ungefähr gleich: Beide haben einen Systick :-)
Spontan fallen mir folgende Dinge ein
- Startup beim Cortex-M ist in C möglich, und die Linker-Skript sind m.
E. einfacher beim ARM. Wenn Du das Komplettpaket von Microchip nimmst,
wird dies vermutlich keine Rolle spielen. Ich kenne den PIC32 nur mit
mips-elf-gcc, also komplett ohne Microchip-Zutaten, und da benötigen
die ISRs einen speziellen ISR-Wrapper in Assembler.
- Beide verfügen über Exception-Handler, beide benötigen in diesen etwas
Assembler. Der Cortex-M3/M4 verfügt vermutlich über mehr Register,
welchen den "fault" besser eingrenzen.
- Die Kompilate von mips-elf-gcc sind - verglichen mit arm-none-eabi-gcc
/ thumb2 - wesentlich größer. Vielleicht holen hier die
Microchip-Ergänzungen für "deren" GCC mehr heraus:
- Beim Timer gibt es beim PIC32 nur ein paar fixe Prescaler, die ARMs
haben i. d. R. einfach ein Register für einen beliebigen. Gelegentlich
etwas lästig.
- Ähnlich beim "clocks setup". Das ist beim ARM schwieriger, aber etwas
flexibler.
- Dafür hat der MIPS einige Dinge, die eher so aus dem Prozessor- und
nicht aus dem µC-Bereich kommen, da bin ich nicht so bewandert. Auf dem
PIC32 läuft retrobsd: http://retrobsd.org/wiki/doku.php. Die neue
MIPS-Architektur geht da wohl noch weiter mit Virtualisierung. Da passt
der Vergleich zu einem Cortex-M allerdings nicht mehr.
- Der Vorteil der Verfügbarkeit des PIC32 in DIP ist Geschichte.
Die andere Frage ist allerdings leider die nach der Zukunft. MIPS hat
seine Patente ausgerechnet an ARM verhökert und steht zum Verkauf -
leider hat Microchip MIPS nicht vorher aufgekauft.
STM32F4: gewaltiger Prozessor der alle anderen alt aussehen läßt.
Einarbeitung durchaus mühevoll aber lohnenswert. Mit Coocox eine gute
und kostenlose Entwicklungsumgebung verfügbar.
PIC32: große Errata, kein Standard wie ARM. MPLab ist ok, lässt sich
auch
für 1000e andere PICs verwenden. Beherrschung setze ich voraus für
Entwickler.
MSP: gut, billig, gute Entwicklungsumgebung von TI. Gut im Low-Power
Bereich
und Cap Anwendungen. Günstige Eva Kits (Launch Pad).
XMega: mit denen bin ich bis jetzt am besten gefahren. Schnell wie die
kleinen ARMs. AVR Studio 6 ist ok. Damit kann man auch schnell die Atmel
AVR32er abdecken.
NXP (Philips) : auch lohneswert sich anzusehen. Kenne ich aber nicht so
gut.
Nette Enticklungsumgebung mit interessanten und günstigen Boards ( zB.
LPC11C24 LPCXpresso )
uva.
Hallo Raland,
danke für die ausführliche Antwort. Genau die Clockconfig war das, was
mich total genervt hat. Wahrscheinlich für jeden, der damit umgehen kann
eine Freude welche Freiheiten diese bietet. Für mich einfach nur
verwirrend.
Beispiel:
Ich wollte die USART Schnittstelle in betrieb nehmen. Mit
Prject-Templates und fertigen Systminit, bei denen ich nur noch die
Tacktfrequenz einkommentieren musste kein Problem. Jetzt wollte ich aber
in meinem Programm in den LowPowerRun Mode wechseln. Dazu sollte man den
Systemtackt reduzieren. Das kann man ja machen, aber was passiert denn
mit der Peripherie? Reicht es die Prescaler anzupassen also im gleichen
Verhältnis herunter zu setzen? Ich habe es auf jeden Fall nicht
hinbekommen, bzw. habe es nicht weiter probiert weil die Zeit nicht da
war.
Das Problem ist: Wenn man hier eine Frage über einen nicht AVR stellt,
kann man nur auf eine Antwort hoffen, da viel Pros wahrscheinlich
besseres zu tuen haben, als hier regelmäßig zu lesen. Kennt jemand sonst
noch eine Plattform, auf der STM32 Experten unterwegs sind
Roland H. schrieb:> Ich kenne den PIC32 nur mit> mips-elf-gcc, also komplett ohne Microchip-Zutaten, und da benötigen> die ISRs einen speziellen ISR-Wrapper in Assembler.
1
#pragma interrupt foo IPL4SOFT
2
voidfoo(void)
3
// oder
4
void__attribute__((interrupt(IPL4SOFT)))foo(void)
>> - Beide verfügen über Exception-Handler, beide benötigen in diesen etwas> Assembler.
Nein. Bootstrap Exceptions
> If the user application provides an implementation of> _bootstrap_exception_handler(), that implementation will be used instead.
General Exceptions
> If the user application provides an implementation of> _general_exception_context(), that implementation will be> used instead.> void _general_exception_handler (unsigned cause, unsigned status);> - Die Kompilate von mips-elf-gcc sind - verglichen mit arm-none-eabi-gcc> / thumb2 - wesentlich größer. Vielleicht holen hier die> Microchip-Ergänzungen für "deren" GCC mehr heraus:>>
1
>28260441204295087344
2
>build/comparison-lpc1114-4.6.2.elf
3
>3365060142035130893a
4
>build/comparison-stm32f407-4.6.2.elf
5
>47872184240050456c518
6
>build/comparison-pic32mx440f256h-4.5.2.elf
7
>
Müsste man sich mal ansehen, woran das liegt. Normalerweise kennt der
PIC32/m4k auch den 16-Bit Befehlssatz MIPS16e...
> Die andere Frage ist allerdings leider die nach der Zukunft. MIPS hat> seine Patente ausgerechnet an ARM verhökert und steht zum Verkauf -> leider hat Microchip MIPS nicht vorher aufgekauft.
Nicht an ARM, aber solange genügend Kunden da sind, sollte das kein
Problem sein.
Chose schrieb:> STM32F4: gewaltiger Prozessor der alle anderen alt aussehen läßt.
In der Werbung und/oder mit Compilern die für Normalsterbliche eher
nicht geeignet sind (GHS)...
Beim CoreMark/MHz liegen RX600 und PIC32 vor M4 und M3
Pete schrieb:> Genau die Clockconfig war das, was> mich total genervt hat. Wahrscheinlich für jeden, der damit umgehen kann> eine Freude welche Freiheiten diese bietet. Für mich einfach nur> verwirrend.
Naja, die nervt immer. Beim AVR verfust man sich. Ich persönlich finde
die MSP430 am "schlimmsten", da es dort nicht durchgängig ist. Ich würde
es so formulieren, nach dem dritten Mal tut's nicht mehr so weh :-)
Beim PIC32 muss man vermutlich unterscheiden: Mit den Microchip-Tools
kann es mit ein paar Klicks oder pragmas erledigt sein. Zu Fuß ist es
dann schon auch komplexer, eine PLL mit input und output divider gibt es
auch.
> Jetzt wollte ich aber> in meinem Programm in den LowPowerRun Mode wechseln. Dazu sollte man den> Systemtackt reduzieren. Das kann man ja machen, aber was passiert denn> mit der Peripherie? Reicht es die Prescaler anzupassen also im gleichen> Verhältnis herunter zu setzen?
Da kommt dann eher ein Vorteil von ARM zum Tragen, nämlich dass die LPM
relativ ähnlich sind (z. B. zwischen lpc und stm32), da einige der
Register Teil des gleichen ARM-Kerns sind.
Du hast die Wahl: Der einfachste LPM, alle (benötigten) Takte belassen
wie sie sind, nur der Core wird abgeschaltet, WFI (wait for interrupt),
fertig.
Oder halt die anderen Modi, welche mehr Energie sparen, aber auch etwas
karger sind. Und ggf. eine Reinitialisierung der "clocks" benötigen.
Das ist m. E. bei den MSP430 gut gelöst, man kommt ziemlich problemlos
bis in LPM3, weil einfach der watchdog timer gut darauf abgestimmt ist.
Das ist bei den ARMs m. W. nach eher schwieriger.
Zum PIC32 kann ich hier nichts beitragen.
> Ich habe es auf jeden Fall nicht> hinbekommen, bzw. habe es nicht weiter probiert weil die Zeit nicht da> war.
Beide Architekturen werden ihren Tribut in Form von Zeit erfordern :-)
> Das Problem ist: Wenn man hier eine Frage über einen nicht AVR stellt,> kann man nur auf eine Antwort hoffen, da viel Pros wahrscheinlich> besseres zu tuen haben, als hier regelmäßig zu lesen. Kennt jemand sonst> noch eine Plattform, auf der STM32 Experten unterwegs sind
Das empfinde ich anders. Ich finde hier gibt es sehr viele Threads zu
stm32. Die ARMs von NXP und Atmel werden deutlich weniger oft behandelt.
Etwas MSP430, ganz düster wird es bei PIC32 und Renesas RX.
Für AVR mag es deutlich mehr Threads geben, aber Quantität korreliert
nicht zwangsläufig mit Qualität :-)
Es gibt natürlich my.st.com, aber mir persönlich ist das etwas
einseitig.
Arc Net schrieb:> #pragma interrupt foo IPL4SOFT> void foo (void)> // oder> void _attribute_ ((interrupt(IPL4SOFT))) foo (void)
Und das geht auch mit dem normalen mips-elf-gcc? Es soll Leute geben,
bei denen kein xxx Studio, xxx Lab, Eclipse, Code Red etc. auf die
Platte kommt, sondern nur make + *-gcc :-)
Beim Cortex-M ist es eine normale C-Funktion:
1
extern"C"voidUART0_IRQHandler(void){
2
...
3
}
M. W. egal mit welchem Compiler, da der Kern den Rest erledigt.
Arc Net schrieb:>> - Beide verfügen über Exception-Handler, beide benötigen in diesen etwas>> Assembler.>> Nein. Bootstrap Exceptions
Ich meinte beim ARM die "faults", und beim MIPS den
general_exception_handler: Im dortigen Beispiel komm Assembler zum
Einsatz:
http://stackoverflow.com/questions/7829430/microchip-exception-handling> Müsste man sich mal ansehen, woran das liegt. Normalerweise kennt der> PIC32/m4k auch den 16-Bit Befehlssatz MIPS16e...
Auf die Schnelle kriege ich es mit "-mips16" nicht vollständig
kompiliert, Stichproben ergeben eine Verbesserung:
Mit "-mips16"
-rw-r--r-- 1 mc mc 12524 20. Dez 21:37 build/libprintf.o
-rw-r--r-- 1 mc mc 16436 20. Dez 21:37 build/libxtoa.o
Ohne "-mips16"
-rw-r--r-- 1 mc mc 13264 20. Dez 21:40 build/libprintf.o
-rw-r--r-- 1 mc mc 17316 20. Dez 21:40 build/libxtoa.o
stm32f407
-rw-r--r-- 1 mc mc 11524 20. Dez 21:46 build/libprintf.o
-rw-r--r-- 1 mc mc 14448 20. Dez 21:46 build/libxtoa.o
Arc Net schrieb:> Nicht an ARM, aber solange genügend Kunden da sind, sollte das kein> Problem sein.
Richtig. De jure nicht, de facto schon. Unabhängig davon: Was ist MIPS
ohne Patente wert? Nochmals, mir gefällt das nicht. Ich habe es erwähnt,
jeder darf für sich prüfen, ob es relevant ist.
Roland H. schrieb:> Arc Net schrieb:>> #pragma interrupt foo IPL4SOFT>> void foo (void)>> // oder>> void _attribute_ ((interrupt(IPL4SOFT))) foo (void)>> Und das geht auch mit dem normalen mips-elf-gcc? Es soll Leute geben,> bei denen kein xxx Studio, xxx Lab, Eclipse, Code Red etc. auf die> Platte kommt, sondern nur make + *-gcc :-)
Die Compiler sind Extra-Pakete und nicht Teil des MPLAB/MPLABX.
fchk
Pete schrieb:> ich möchte/ muss mich in einen der beiden Typen einarbeiten
Mein Tipp wäre, sich auch noch die RX63N/RX631 von Renesas anzusehen,
die in der gleichen Liga mitspielen. Suche nach dem HW-Manual, und Du
wirst feststellen, dass der µC dort sehr transparent beschrieben ist.
Eine Entwicklungsumgebung gibt es gratis, wobei die Codegröße nach 60
Tagen auf 128k eingeschränkt wird. Alternativ gibt es von Kpit
kostenlose Compiler auf GCC-Basis. Der Renesas-Compiler allerdings
erzeugt m.E. den besseren Code.
Zum Schnuppern gibt es ein günstiges Entwicklungs-Kit.
http://de.futureelectronics.com/de/technologies/development-tools/microcontroller-microprocessor/32-bit-eval-board/Seiten/4022487-YRDKRX63N.aspx?IM=0
Frank K. schrieb:> Die Compiler sind Extra-Pakete und nicht Teil des MPLAB/MPLABX.
Habe ich heute probiert:
http://ww1.microchip.com/downloads/en/DeviceDoc/XC32-release-1.20-src.tar.bz2
Das enthaltene Skript zum Bauen ist ein Witz.
Also wie üblich bei ARM & Co. Das ging gut bis zur newlib, welche
pic32mx nicht kennt. Es gibt aber eine pic32mx-newlib,
https://github.com/jasonkajita/pic32-newlib, von einem
Microchip-Mitarbeiter. Diese wiederum ist irgendwie festverdrahtet mit
dem chipKit-Compiler (anderer Präfix, vom gleichen Kollegen), muss also
auch angepasst werden. Dann kommt der große Witz beim Bauen der newlib:
Man erreicht -Os somit nur durch die Aufzählung der einzelnen
Optimierungen.
Dann habe ich gleich das fertige chipKit-newlib-Paket genommen (dieses
akzeptiert -Os). Auch bei diesem Projekt findet sich leider keine
Anleitung/Skript zum Bauen. Darf er vermutlich nicht publizieren.
Wie dem auch sei:
Da hat sich nichts bewegt.
Im Vergleich zu Renesas RX (KPIT), MSP430 oder ARM gibt es bei der
Unterstützung zum Bauen des GCCs noch viel zu tun. Bei Atmel gibt es
immerhin fertige Binaries.
Mir geht es auch nicht um die Kosten für den Compiler, sondern um die
Größe des Kompilats. Vielleicht führt jemand einen Vergleich mit dem
Microchip-Compiler und dem chipKit-Compiler durch:
https://github.com/jasonkajita/chipKIT-cxx/downloads
Pete schrieb:> Die Sache ist die, ich komme> mit den 8.Bittern AVRs und den 16-Bittern MSP schon ganz gut klar
Da du ja die MSP von TI schon kennst, wäre es vielleicht sinnvoller sie
LM3Sxxx Reihe von TI zu verwenden anstatt dem STM.
Damit kannst du bei der bekannten IDE bleiben. Ist nur eine neuere
Version.
Und Launchpad sowie günstige EvalBoards gibt es von den LM3Sxxx auch.
TI spinnt. LM3S ist als NRND gekennzeichnet und taucht bei einer
normalen Suche nicht mehr auf. LM4 ist zwar angekuendigt, die Bauteile
sind aber nicht normal verfuegbar. Und wenn Du die CMSIS Header
verwenden willst, dann musst Du einer Lizenz zustimmen, die jenseits von
gut und boese ist. So musst Du z.B. du die Headerdateien mit Passwort
verschluesselt auf der Platte speichern. Sehr intelligent fuer eine
Headerdatei, die man zum kompilieren braucht!
Uwe Bonnes schrieb:> So musst Du z.B. du die Headerdateien mit Passwort> verschluesselt auf der Platte speichern. Sehr intelligent fuer eine> Headerdatei, die man zum kompilieren braucht!
Ist zwar komisch, aber eigentlich kein Problem. Zumindest von deiner
Formulierung ausgehend, ich habe den Kram nicht gelesen.
Disk-Verschlüsselung ist heute gang und gäbe und Windows kann Ordner
verschlüsseln.
Es empfiehlt sich ohnehin, soweit möglich Entwicklungsumgebungen zu
virtualisieren. Idealerweise eine VM pro Zielarchitektur/IDE. Die
überlebt dann auch einen Rechnerwechsel und kann für Unterstützung von
alten Produkten als Klon eingefroren werden. Erspart Ärger, wenn ein
Update der IDE Code für Altprodukte aus der Kurve wirft. Dann muss diese
VM nur eine verschlüsselte VDisk verwenden und fertig (VMware kann, bei
anderen weiss ich es nicht).
>Komplexität STM32 vs. PIC32
Beide sind ziemlich ähnlich, urspr aus 80ern(!)
32Bit-RISC (OPcode nun nur 16/32Bit, also nichtmal in der Lage, um mal
eben einen 32Bit-imm-Wert zu laden oder zu verrechnen, oder grösseren
Membereich direkt zu adressieren)(und das obwohl seit Beg die Gatter nur
noch ca 1/1000 der Chipfläche benötigen)
MIPS hat DelayedBranches(!) und unterstützt auch Registerbänke.
>STM32F4: gewaltiger Prozessor
was soll da gewaltig sein?
>Die andere Frage ist allerdings leider die nach der Zukunft. MIPS hat>seine Patente ausgerechnet an (??) verhökert
Das kann nichts gutes heissen für MIPS!
(Auf breiter Masse waren/sind Microchip sowiso die einzigsten, die MIPS
eingesetzt haben. Die MIPS-Desins (nicht die verkauften IC-Mengen)
ausserhalb Microchip kann man wahrscheinlich an paar Fingern abzählen.)
>Beim CoreMark/MHz liegen RX600 und PIC32 vor M4 und M3
Ist aber nur ein Benchmark von vielen.
RX kann ua max 64-Bit-OPcode verarbeiten (und das auch binnen einem Takt
lesen!), also das doppelte von typ RISCs.
Aber so spottbillig (für Lowend) wie CM0(/3) ist der nicht zu kriegen.
Microchip hätte nach m.M. anstatt MIPS zu nehmen besser mal die PIC24/33
erweitern sollen.
MCUA schrieb:> Die MIPS-Desins (nicht die verkauften IC-Mengen)> ausserhalb Microchip kann man wahrscheinlich an paar Fingern abzählen.
Interessantes Argument, grad von dir. MIPS hat bestimmt mehr eigene
Core-Designs verkauft als Renesas. ;-)
Und du hast offensichtlich weit mehr als 125 Finger ;-). Soviel
Lizenznehmer hat MIPS laut Wikipedia mindestens. Lizenznehmer, nicht
lizenzierte Designs.
> Microchip hätte nach m.M. anstatt MIPS zu nehmen besser mal die PIC24/33> erweitern sollen.
Oder vielleicht besser doch nicht. Die erbten die Eigenheiten und die
Pipeline der dsPIC30, und die waren etwas sehr auf DSP-Ansprüche
optimiert. Wenn man ein Register mit 0 multipliziert um es zu löschen,
oder ein Resultat in den Speicher schreibt um es wegzuwerfen, dann ist
irgendwas falsch gelaufen. Beides geht nicht grad pfleglich mit
Resourcen um. Die Pipeline dieser PICs ist zu knapp konzipiert um gut
skalierbar zu sein und der Befehlssatz ist für diese Pipeline optimiert.
Das macht die in ihrem Bereich nicht schlecht, aber ein wirklich
effizientes Controller-Design ist es nicht. Dazu kommt, dass für ein
bestehendes Design bereits gute Compiler existieren. Und man sich die
Erfahrung böser Bugs erspart.
Atmel hat mit den AVR32 auch nicht grad viel Erfolg, will mir scheinen.
>Und du hast offensichtlich weit mehr als 125 Finger ;-).
Nicht wenn es um die 'breite Masse' geht. Von der redete ich nämlich.
> Microchip hätte nach m.M. anstatt MIPS zu nehmen besser mal die PIC24/33> erweitern sollen.
Gemeint war allgemeine Erweiterung Verbesserungen, nicht unbedingt
complett abwärtkompatibel. Die hätten dadurch einen besseren Befehlssatz
implem. können (zugegeben mehr Aufwand als was fertiges zu lizensieren).
>> RX kann ua max 64-Bit-OPcode verarbeiten (und das auch binnen einem Takt>> lesen!),>An welchen Befehl denkst Du dabei?
An jeden, denn die Befehle sind (nicht wie bei M32C,R32C) alle max 64
Bit breit.
MCUA schrieb:> Nicht wenn es um die 'breite Masse' geht. Von der redete ich nämlich.
Nö, du hast ausdrücklich auf die Anzahl verkaufter Designs und nicht auf
die verkauften ICs abgeziehlt:
> Die MIPS-Desins (nicht die verkauften IC-Mengen)
Was die Masse angeht: Der gleiche Artikel vermeldet ~500 Mio Exemplare
pro Jahr. Das ist zwar ein Fliegenschiss verglichen mit ARM, aber so
direkt wenig nun auch wieder nicht. Nur sind diese Dinger offenkundig
weniger sichtbar.
Ach ja, unter den Lizenznehmern von MIPS ist übrigens Renesas ;-).
Vielleicht eine Erblast.
>> Nicht wenn es um die 'breite Masse' geht. Von der redete ich nämlich.>Nö, du hast ausdrücklich auf die Anzahl verkaufter Designs und nicht auf>die verkauften ICs abgeziehlt:
Nö, gemeint war die Menge an Designs mit MIPS-CPUs (nicht die
Produkt-Anzahl je Design), und das ist im Vergleich zu anderen extrem
gering.
Die, die MIPS lizensieren vergraben das norm in ihr Produkt und stellen
damit keine GeneralPurpose-CPUs (für die breite Mase her) her (Ausnahme
Microchip, IDT)
Thread beobachten
Seitenaufteilung abschalten