Suche schnellen µC

Lese mal diesen Artikel, da steht viel drin: STM32

Yaro schrieb:
> - Sehr gerne fpu

Das gibts sicher im ARM9, ARM11 Bereich was.

> - mehr als 60MHz

Hat jeder 32bitter (jaja, ich weiss, kuriose Ausnahmen gibt's immer...

> - 32bit Architektur

z.B ARM Cortex-M3, ARM9, ARM11

> - mehrere 16bit Timer

Hat auch jeder 32Bitter.

> - mit C programmierbar

Ist auch jeder.

> - Freier Compiler und Debugger

Gibt's auch für jeden. --> GCC

> - Umfangreiches Tutorial oder Buch sollte vorhanden und beschaffbar
> sein.

Dafür gibt's das Internet

> - Preis unter 300Euro

Im Fall eines Cortex solltest Du mit ca. 10 Euro rechnen. ARM9/11 sind 
ein bisschen, aber nicht viel teurer. Für 100 Euro kriegst Du ein Board 
mit RAM, Flash etc schon drauf.

Gruäss
Simon

Schau mal auf www.cutedigi.com. Da gibt's ein ARM11-Board mit allem Drum 
und dran für 100$. Und ein Eval dazu für 250$.

Gruäss
Simon

Hobby: Cortex-M3 / ARM7
Beruf: ARM9/ARM11 (weil teuer, weil Multilayer usw.)

Ja der STM32 hat keine FPU drin, allerdings rechnet der sehr schnell. Am 
besten mal ein kleines Demo-Board kommen lassen und einen Test 
programmieren, kostet nicht viel.

Markus Müller schrieb:
> Beruf: ARM9/ARM11 (weil teuer, weil Multilayer usw.)

Ausser eben Du nimmst so ein Board, auf dem alles schon drauf ist. Kein 
Eval-Board, sonder ein Subsystem. Die sind 'ne feine Sache und gar nicht 
so teuer. Die eigene HW kann man dann auf 'nem Mutterbrett mit 2-4 Lagen 
"selber basteln".

... oder aber ein FPGA mit Hardcore. Z.B. Smart Fusion von Actel. Die 
haben 'nen Cortex-M3 drin und jede Menge Zellen, mit denen jede Menge 
Pulspattern für jede Menge Servos für jede Menge Beine synthetisiert 
werden können.
(oder aber ein separates FPGA dafür. Ich kenne mich mit 
Hexawieheissendienochmal? Hexapods nicht aus, aber was ich auf Youtube 
gesehen habe, sieht a)cool, b) nach was mit viel so parallel laufendem 
Zeug aus. Ich sähe da durchaus Möglichkeiten, wie ein FPGA den Prozi 
unterstützen könnte.

Also erstmal: STM32 IST ein Cortex-M3.

Ein ARM9 ist einfach ein grösseres Kaliber. Hat üblicherweise MMU, 
(Cortex-M3 in einigen Fällen auch, aber seltener), und ist generell für 
"Grösseres" ausgelegt. Den solltest Du eigentlich nur mit einem 
Betriebssystem à la embedded Linux einsetzen.

So wie ich das einschätze, bist Du mit einem M3 super bedient. Das kann 
STM32, NXP oder sonstwas sein.

Der Umstieg von 8-Bittern ist definitiv viiiiiiel leichter im Fall 
Cortex-M3.

A propos Betriebssystem: Hast Du schon eins? Ansonsten kann ich Dir 
FreeRTOS ans Herz legen. Linux bringst Du in 'nen STM32 nicht rein.

Yaro schrieb:
> @Simon Huwyler: Kennst du vielleich auch ein gutes ARM9 Board?

Ob's gut ist, weiss ich erst, wenn ich's habe, bestellt ist es schon. 
:-) Auch auf cutedigi.com. Da gibt's eins für 120$.

Aber eben, ARM9 halte ich nicht unbedingt für eine gute Wahl. Das ist 
mehr was, wenn Du was mit graphischen Oberflächen machst und/oder Linux 
o.ä. machst. Was Du vorhast, sieht mir wie eine klassische uC-Geschichte 
aus. Und dazu sind die Cortex-M3 bestens geeignet.

Im Artikel STM32 sind viele Hersteller von Demo-Boards aufgelistet. 
Diese lieferan meist auch ARM9 Demo-Boards.
http://www.mikrocontroller.net/articles/STM32#Evaluation_Boards

PIC32 :) Ist pro MHz schneller als Cortex-M3, hat viel Flash und RAM. 
Compiler ist kostenlos.

Softcore im FPGA ist kompliziert und langsam. Hardcore ist zu viel und 
teuer. Um mit FPGAs überhaupt klar zu kommen, brauchst du schon paar 
Jährchen ;)

Grüße,
Anguel

Betriebssysteme müssen nicht unbedingt riesige Dinos mit 1000 Layern 
zwischen Anwendungsprogramm und Hardware sein.

Im Fall von FreeRTOS reichen Dir wenige kB Flash und ganz wenig RAM. Und 
Timings kriegst Du genau so gut in den Griff, wie wenn Du den Controller 
"direkt" ansprichst. Resp. Du SPRICHST ihn immernoch direkt an.

Wozu also ist ein Betriebssystem? Ich spreche jetzt nur von FreeRTOS. 
Das ist nämlich "nur" ein Scheduler. Der macht im Wesentlichen nichts 
weiter als verschiedene Tasks pseudoparallel laufen zu lassen. Das tut 
er, indem er sich von einem Timer periodisch ankicken lässt. Z.B. im 
Millisekunden-Takt. Kannst aber selber einstellen. Jedesmal, wenn er so 
gekickt wird, entscheidet er, welcher Task jetzt weiterlaufen kann.
Ausserdem kannst Du, gesteuert durch Interrupts, FreeRTOS jederzeit dazu 
bringen, soche Taskwechsel durchzuführen. Oder aber die ganz pressanten 
Dinge gleich selber in ISRs ausführen.

Das war jetzt alles recht schwammig, ich weiss. Auf freertos.org gibt's 
gute Lektüre dazu.

Quintessenz ist aber: Mit einem RTOS bist Du genau so präzise und 
schnell, wie wenn Du "direkt programmierst". Aber es macht Dir 
viiiiieles viiiiel einfacher.

Yaro schrieb:
> @Anguel S: von PICs habe ich nciht wirklich gutes gehört... Die 16bit
> PICs sollen von der Leistung mit den 8bit AVRs vergleichbar sein...
> Aber wenn PIC32 schneller ist als cortex-m... warum nicht...
> Die Programmierung sollte bei den beiden ähnlich sein, oder?

PIC32 hat MIPS Core und ist ganz anders als die alten. Programmiert wird 
er in C (MPLAB Compiler ist eigentlich ein GCC Compiler). Man muss 
natürlich dann die Lib-Funktionen lernen, aber das ist wohl überall so. 
Vielleicht sind die Entwicklungsumbegungen für ARM von Keil und IAR 
besser als das kostenlose MPLAB, kosten aber mal eben um die 4000 EUR. 
Um keinen falschen Eindruck zu hinterlassen - ich habe den PIC bisher 
nicht benutzt, aber vergleiche selbst in der letzten Zeit, was man so 
als alternativen hat. Sonst ist der neue Cortex-M4 von Freescale auch 
ganz nett und hat DSP Funktionen, ist aber eben ganz neu und evtl. etwas 
teurer...

- Die CPU selber ist auch egal, aber die eingebaute Pheriperie der 
Hersteller sollte man schon genauer anschauen. Und da bietet ST mit dem 
STM32 sehr viele Chips mit unterschiedlicher Ausbaustufe/Gehäuse usw. 
Von TI gibt es einen mit eingebauter PHY, falls Netzwerk interessiert.
- Software ist kostenlos
- JTAG-Interface kostet was, die sind zu den 3 Ausgewählten nicht 
kompatiebel.

Dann:
- Demo-Boards / Kosten
- Was gibt es im Internet? (dieses Forum hat viel STM32)

Ich nutze am liebsten STM32 und habe den schätzen gelernt. ST bietet 
eine gute FW-Lib mit über 90 Beispielprojekten und alles Dokumentiert, 
alles in einem Download.

Nicht vergessen:
Errata's lesen.

Markus Müller schrieb:
> - Software ist kostenlos
Die Compiler meistens nicht, es sei denn man ist in der Lage, sich alles 
mühevoll zusammenzubasteln.

> Dann:
> - Demo-Boards / Kosten

Genau - gibt es überhaupt Boards, die in deinen Pod passen.

> Nicht vergessen:
> Errata's lesen.
Besser nicht, sonst kauft man am Ende nix ;)

Yaro schrieb:
> @Anguel S: von PICs habe ich nciht wirklich gutes gehört... Die 16bit
> PICs sollen von der Leistung mit den 8bit AVRs vergleichbar sein...
> Aber wenn PIC32 schneller ist als cortex-m... warum nicht...
> Die Programmierung sollte bei den beiden ähnlich sein, oder?

JA, hören tut man viel - nur stimmt es meist nicht.
Gerade in etwas AVR lastigen Foren ist PIC Bashing von Leuten ohne 
Hintergrundwissen ein beliebter Sport.
Der Pendant zu den AVR sind die Pics der 16F / 18F Reihe. Wobei 
diejeniegen Bausteine die Leistungsmäßig im Bereich der ATMEGAS liegen 
eher im 18F Sektor zu finden sind. (Aber alles 8Bit.) Einige davon 
stecken die ATMEGAS auch in die Tasche.
Die 16Bit Pics (sind welten über 8Bit AVR)

> @Sebastian: Dann wird der ARM9 schonmal von der liste gestrichen
> Ehm... "STM32 oder Cortex-M3".... ist das nicht das selbe (sagt Simon
> Huwyler).
JAIN Cortex M3 ist die Prozessorachitektur, also der eigendliche Kern.
Stsark verwandt mit dem ARM7
Der STM32 ist ein Produkt eines Herstellers das einen solchen Kern hat.
Andere HErsteller verwenden aber auch denselben Kern, aber andere 
Peripherie (daher nur sehr sehr eingeschränkt kompatibel - ein STM32 
lässt sich nicht einfach durch einen NXP C-M3 ersetzen. Da sind sowohl 
in der Harware wie auch in der SW teilweise erhebliche Anpassungen 
möglich.
>
>
> Im Moment sind also PIC32 AVR32 und Cortex-M/STM32 im Spiel.
> Ist das jetzt nur noch Geschmackssache, oder gibts gute Gründe für den
> einen oder anderen?

Der PIC32 ist eigendlich das Gegenstück zu den Cortex M3. Der Pic32 hat 
einen MIPS kern. Das ist neben den ARM die zweite große 
Prozessorarchitektur. Was nun besser ist - das ist eine Glaubensfrage 
ähnlich wie PIC oder AVR. Funktioniert beides.
Und auch der WEchsel von PIC32 MIPS auf STM32 CortexM3 ist nicht 
komplizierter als der WEchsel von STM32 CortexM3 auf NXP CortexM3.
Der Vorteil bei den PIC ist das man bei Microchip einen HErsteller hat 
der sehr umfangreiche und gut funktionierende LIBs von sich aus zur 
Verfügung stellt. Man kann alsoe wenn man will alles aus einer HAnd 
bekommen und muss nicht alles zusammensuchen mit den Nachteilen wei 
verschiedene nicht genau zuordbare Versionsstände durch parallele 
Weiterentwicklung usw...
Wenn man natürlich gerne OpenSorce oder DrittanbieterSW einsetzt, die 
gibt es natürlich auch - Nur etwas weniger als bei ARM- halt da die 
Notwendigkeit nicht ganz so groß ist. (Wer schreibt etwas wenn der 
HErsteller das schon hat)

Aber wie Gesagt: PIC32 und CortexM3 (egal welcher Hersteller) sind an 
sich gleichwertig. Entscheide was dir am besten erscheint (Preis, 
Verfügbarkeit, Dev. Tools usw.)

AVR32 ist eine absolute Eigenentwicklung von Atmel und spielt im 
Verlgeich zu den Technologien wie ARM und MIPS keine echte Rolle. Würde 
ich mich nicht unbedingt als erstes mit beschäftigen. Zuma Atmel ja nun 
gerade bei spezielleren Bausteinen nicht gerade für gute Verfügbarkeit 
bekannt ist!

Gruß
Carsten

Yaro schrieb:
> Aus Markus Müller und Anguel S. folgt: lieber STM32. Richtig?
ST hat wohl hier viele Fans. Ich mag aber die Boards nicht wirklich. Und 
ST hat seine Seite so kaputtgemacht, dass man da nix mehr findet.

Yaro schrieb:
> "STM32 oder Cortex-M3".... ist das nicht das selbe (sagt Simon
> Huwyler).

ARM ist eine Firma, die Prozessor IPs an Lizenznehmer verkauft. Die 
stellen aber selber keine Prozis her.

ST, NXP, Atmel etc. kaufen bei ARM diese IPs ein, packen Peripherie 
drumherum und verkaufen die dann. Wenn Du also einen STM32 kaufst, gibst 
Du Geld an ST, und die geben einen Teil davon an ARM ab.

Das coole an der Sache ist nun, dass, egal, ob Du ein NXP, ST oder 
Atmel-Teil kaufst, immer der selbe Prozi drin ist. Eben ein ARM 
Cortex-M3. Also: Gleiche Befehle, gleiches Programmer's Model, gleiche 
Grundperipherie (wie z. B. ein sog. Tick-Timer, an dem eben dann das 
Betriebssystem hängt. Somit läuft das Betriebstsystem unverändert auf 
allen Cortex-M3.

Natürlich kannst Du alles ohne Betriebssystem machen. Du kannst auch mit 
Paintbrush eine Platine zeichnen und mit einem einfachen Texteditor 
Programme schreiben. Aber es ist halt mühsam. Du wirst Dich zwangsläufig 
mit Scheduling auseinandersetzen müssen. Denn Du hast ja sicher Dinge, 
die parallel laufem müssen. 8 (edit: nö, 6, hexa, hiess es ja) Beine 
wollen gesteuert werden. Die RS232 wartet auf Konsolen-Eingaben. 
Irgendwo blinkt eine LED. Die Batteriespannung soll überwacht werden....

Natürlich kannst Du das alles hintereinander machen. Ganz schnell einer 
Endlosschlaufe, so dass es nach aussen aussieht, als ob die Spinne alle 
Beine gleichzeitig bewegen kann. Sowas nennt man dann Event-Loop.

Ein RTOS macht eigentlich genau das. Aber es macht es auf eine Weise, 
die (das ist nicht böse gemeint) von vielen sehr schlauen Leuten sehr 
genau durchdacht wurde und Möglichkeiten eröffnet, die Du Dir (wiederum 
nicht böse gemeint) wohl nicht träumen lässt.

Es ist übrigens nicht einfacher, mit einem RTOS zu programmieren, was 
das Erlernen angeht. Eher im Gegenteil. ABER: Sobald das Projekt ein 
bisschen grösser wird, hast Du eine Werkzeugkiste in der Hand, die Du 
nicht mehr hergeben willst. Und das - das muss ich nochmals betonen - 
ohne irgendein Penalty! Eben, wir sprechen hier nicht von Windows, das - 
auf einem Cortex-M3 laufend, eine Trillion Jahre bräuchte, um ein 
Fenster zu öffnen! :-)

Yaro schrieb:
> Für PIC32 gibt es einen kostenlosen
> Compiler und Entwicklungsumgebung (beides nicht sehr gut),

Wie kommst du darauf das die nicht gut sind.
Die Entwicklungsumgebung (MPLAB) finde ich einwandfrei, wobei das auch 
geschmackssache sein kann. Der Compiler ist in der Freien Version nicht 
mit den maximalen Optimierungsoptionen ausgestattet. Aber ansonsten ist 
der in Ordnung.
Und wenn man den gewerblich mit maximaler Performance braucht dann sind 
die 900Eur. im Vergleich zu anderen komerziellen Compiler ein echtes 
Schnäppchen ;-). Wenn man den braucht, dann ist man aber in REgionen wo 
ein paar Cent unterschied Bauteilkosten zwichen zwei Speichergrößen in 
der Serienproduktion über die Stückzahl eine Rolle spielt.

Aber wie gesagt: Auch mit dem M3 machst du nichts verkehrt.

Gruß
Carsten

Carsten Sch. schrieb:
> Aber wie Gesagt: PIC32 und CortexM3 (egal welcher Hersteller) sind an
> sich gleichwertig. Entscheide was dir am besten erscheint (Preis,
> Verfügbarkeit, Dev. Tools usw.)

Also ein Nachteil von der Microchip Entwicklungsumgebung MPLAB ist, dass 
sie mal gerne öfters abstürzt. Das ist einfach so. Dafür ist es komplett 
kostenlos. Alles hat seinen Preis, wobei ich noch nie mit ner 4000 EUR 
Umgebung gearbeitet habe. Ob die richtig stabil läuft, müssen andere 
sagen.

Anguel S. schrieb:
> Dafür ist es komplett
> kostenlos. Alles hat seinen Preis, wobei ich noch nie mit ner 4000 EUR
> Umgebung gearbeitet habe. Ob die richtig stabil läuft, müssen andere
> sagen.

Eclipse, CDT, GCC, OpenOCD

Alles konstenlos. Qualitativ ist dieses Gespann top. Und es ist 
"state-of-the-art".

Richtig, mann muss ein bisschen Zeit investieren, um es zum Laufen zu 
bringen. Dabei lernt man aber wiederum sehr viel. Für den 
professionellen Einsatz ist das ein Killerkriterium, weshalb auch viele 
Firmen ein genau solches Päckchen fertig zusammenstellen und für viel 
Geld verkaufen. Im Hobbybereich aber macht es m.E. keinen Sinn, 
irgendwas kommerzielles zu kaufen.

Ich habe mit einer 4000 EUR Umgebung gearbeitet. So gross ist der 
Unterschied nicht.

Carsten Sch. schrieb:

>> Im Moment sind also PIC32 AVR32 und Cortex-M/STM32 im Spiel.
>> Ist das jetzt nur noch Geschmackssache, oder gibts gute Gründe für den
>> einen oder anderen?
>
> Der PIC32 ist eigendlich das Gegenstück zu den Cortex M3. Der Pic32 hat
> einen MIPS kern. Das ist neben den ARM die zweite große
> Prozessorarchitektur. Was nun besser ist - das ist eine Glaubensfrage
> ähnlich wie PIC oder AVR. Funktioniert beides.
> Und auch der WEchsel von PIC32 MIPS auf STM32 CortexM3 ist nicht
> komplizierter als der WEchsel von STM32 CortexM3 auf NXP CortexM3.
> Der Vorteil bei den PIC ist das man bei Microchip einen HErsteller hat
> der sehr umfangreiche und gut funktionierende LIBs von sich aus zur
> Verfügung stellt. Man kann alsoe wenn man will alles aus einer HAnd
> bekommen und muss nicht alles zusammensuchen mit den Nachteilen wei
> verschiedene nicht genau zuordbare Versionsstände durch parallele
> Weiterentwicklung usw...

Dem kann ich nur zustimmen. Ich habe alle Architekturen bereits in den 
Fingern gehabt, ARM (7,9,M3), PIC*, AVR*, PPC, 68k,...

Der CPU-Kern wird immer mehr zur Nebensache. Viel wichtiger ist die 
Peripherie und die Softwareunterstützung. Und speziell als Anfänger hast 
Du bei Microchip einfach die besseren Karten. Du nimmst die MPLAB IDE, 
den C32 Compiler, dazu einen ICD3 Debugger und ein Demoboard Deiner 
Wahl, und Du wirst das ganze Zeugs innerhalb eines Tages am Laufen 
haben. Garantiert.

Klar, Du kannst auch irgendeinen GCC-Port nehmen, irgendein OpenOCD mit 
irgendeinem JTAG-Pod, dazu ein Eclipse oder Code::Blocks, und wieder 
woanders her irgendeinen IP-Stack. Kannst Du machen, kein Thema. Aber 
ohne entsprechende Erfahrung nicht an einem Tag. Schon bei der 
Inbetriebnahme des OpenOCD mit dem Billig-JTAG, den Du irgendwo im Netz 
geschossen hast, kann der einer oder andere Tag bei draufgehen. Und die 
Portierung des von irgendwoher gesaugten IP-Stacks an Deinen speziellen 
Controller geht auch nicht von selbst.
Natürlich ist das alles machbar. Das haben andere vor Dir auch 
geschafft. Aber als Anfänger ist es beschwerlich.
Du kannst Dir natürlich auch zB bei rowley.co.uk ein Crossworks for ARM 
und einen dazu passenden JTAG kaufen. Dann hast Du diese Probleme 
natürlich nicht. Aber kostenlos ist das dann auch nicht mehr.

Von daher bist Du eigentlich mit dem PIC32 ganz gut bedient.

fchk

Ein Betriebssystem braucht man, um komplexe software die man nicht 
selbst schreiben will laufenzulassen. Fuer sicherheitsrelevant Projekte 
moeglicherweise eher nicht. Oder moeglicherweise eher doch.

Yaro schrieb:
> Das ausschlaggebende Kriterium ist also wohl der Compiler und
> Entwicklungsumgebung.
>
>
>
> Eclipse, CDT, GCC, OpenOCD ist als Ersatz von MPLAB oder als Paket für
> STM32 gemeint?

Eclipse=IDE
CDT=C Development für Eclipse
GCC ist der Compiler, der Microchip C32 ist auch ein GCC
OpenOCD ist der Treiber für den JTAG-Debugger, das Bindeglied zwischen 
dem GDB (Gnu Debugger) und der Hardware. Der GDB ist Kommandozeile, und 
Elipse setzt sich da drauf. Nicht unbedingt die eleganteste Architektur.

Das obige entspricht beim PIC32 dem MPLAB plus dem C32 Compiler. Der 
Debugger ist im MPLAB drin.

fchk

Yaro schrieb:
> Eclipse, CDT, GCC, OpenOCD ist als Ersatz von MPLAB oder als Paket für
> STM32 gemeint?

Dieses Paket ist für so ziemlich alles, was sich programmieren lässt, 
gemacht. Mit GCC wurde z.B. Linux programmiert. Und wohl so ziemlich 
alles, was unter Linux läuft. Und es ist ganz klar die vielfältigste 
Compiler-Kollektion, die es gibt. Aber eben: Es ist nicht plug'n'play.

Eclipse ist eine IDE, die ebenfalls extrem verbreitet ist. Auch 
open-source. Und so bekannt/beliebt, dass viele Firmen diese IDE nehmen, 
in ihr Paket integrieren und dann in der Werbung extra erwähnen, dass 
ihre IDE "eclipse-based" ist. Quasi als Garant dafür, dass sie was 
taugt.


Wenn Du PICs programmieren willst, ist MPLAB natürlich die bessere Wahl 
(ich weiss gar nicht, ob die PICs zu den wenigen Prozis gehören, die GCC 
nicht unterstützt).
Auf jeden Fall ist in MPLAB wohl alles genau so zusammengebaut, dass es 
einfach läuft.

Yaro schrieb:
> FreeRTOS geht auch auf PIC32, oder?

Ja, dafür gibts auch eine Port.

fchk

Yaro schrieb:
> Also PIC32 mit MPLAB IDE, den C32 Compiler, dazu einen ICD3 Debugger und
> ein Demoboard meiner Wahl =)
>
> Also nur noch einen passenden PIC32 und ein dazu passendes Board
> aussuchen =)
>
> Ein passender wäre z.b. der PIC32MX575F512H.... kennt ihr ein gutes
> Board dafür?

Microchip DM320004 plus DM320002 IO-Expansion Board plus AC164126 für 
Deine eigene Peripherie. Schau es Dir auf der Microchip-Seite an.

Hab ich hier auch liegen.

fchk

Yaro schrieb:
> Jetzt fehlt nur noch das richtige Board mit dem Richtigen PIC32.

Hast Du doch schon. Siehe oben: DM320004. Da ist zwar ein größerer PIC 
drauf, aber das soll Dich nicht stören.

> Was die Pins angeht, so reichen mir 64 höchstwahrscheinlich aus. MHz
> sollten es 80 sein. Flash mind. 256kb. Sram reicht wohl schon 16kb
> locker aus. Und gerne mehrere Schnittstellen.

Was anderes als 80 MHz gibts nicht. Faustregel fürs Entwickeln: den 
größen Baustein nehmen, entwickeln, und dann schauen, in welchen 
kleineren das Projekt reinpasst.

> Was muss ein gutes Board haben, außer dass die Pins nach außen geführt
> sind?

Die richtige Peripherie. Oder möglichst gar keine, damit möglichst alle 
benötigten Pins zur eigenen Verwendung frei sind. Ansonsten hast Du 
nämlich ein Problem. Das Board hat Ethernet und USB onboard, was auch 
sinnvoll ist. Alles andere bastelst Du Dir auf einem PICTAIL+ Board 
AC164126 zusammen.

fchk

Damit's auch sicher wird ;-)
Cortex-R4F in Form der TMS570 von TI (die hätten eine FPU, 1-2MiB Flash, 
128 -160 kiB SRAM beide mit ECC, 160 MHz):
http://focus.ti.com/docs/toolsw/folders/print/tmdx570ls20susb.html
http://www.ti.com/ww/en/mcu/tms570/index.shtml

Ansonsten würde ich aber auch einen PIC32 oder dsPIC empfehlen (MPLAB X 
basiert auf der NetBeans-IDE, falls man die "eigenwilligen" Vorversionen 
nicht will)

Hi,

Anguel S. schrieb:
> Also ein Nachteil von der Microchip Entwicklungsumgebung MPLAB ist, dass
> sie mal gerne öfters abstürzt. Das ist einfach so.

DAs kann ich jetzt absolut nicht bestätigen. Was ich ALLE PAAR Tage mal 
habe ist das die Kommunikation zwischen MPLAB und dem PicKit aus 
irgendwelchen Gründen aussteigt. Anscheinend forciert wenn es sowieso 
schon mit der Kommunikation aufgrund der Schaltung (Nutzung der ICSP 
Pins auch für Funktionen) etwas wackelig ist.
Meist schaft aber schon ein einfaches Abziehen und nach einigen Sekunden 
wieder neu anstecken des PicKit abhilfe. Ab und an war aber auch mal ein 
Abspeicher der Arbeit und Neustart des Programms (NICHT des Rechner) 
nötig.

Einen richtigen Absturz ohne die Möglichkeit des Abspeicherns hatte ich 
schon Monatelang nicht mehr bei MPLAB. Da die Programme ja eh bei jedem 
Übersetzen gespeichert werden hält sich aber auch in so einen Fall der 
Ärger in grenzen ;-)
Das mit den Abstürzen schein also am jeweiligen System zu liegen - wie 
fast bei aller Software.

Yaro schrieb:
> Zum Einstieg (umstieg) scheint mir PIC32 leichter zu sein, weil eben de
> angepriesene Lib.
Ja, würde ich auch so sehen - für den ersten Einstieg bist du bei 
Microchip etwas besser bedient. Gerade weil es sehr viel mehr -aus einer 
HAnd- gibt. Oft incl. Anfängerfreundlicher Doku.

Für den STM32 gibt es auch Libs von ST. Allerdings muss ich -insbesonder 
im Moment- sagen das es ein echter Krampf ist auf deren Seite nach der 
richtigen Lib zu suchen.
Zur Krönung kommt noch dazu das ich seit DREI MONATEN dabei bin zu 
versuchen eine laut Pressemitteilung kostenlos erhältliche Audio Lib zu 
erhalten. -ICh habe mich schon quer durch die Niederlassung hier in DL 
UND Genf telefoniert. Auch habe ich es über einen Distri versucht. Auc 
gab es einen Emailaustausch mit NAchfragen was ich genau brauche den ich 
mit Link auf deren eigene Webseite beantwortet habe. Es scheint keiner 
was zu wissen!!! Für eine Anfänger ist das sicher noch deutlich 
frustrierender!

Soetwas habe ich bei Microchip noch nicht mal Ansatzweise erlebt. Wenn 
dann wirklich mal keiner die Antwort greifbar hatte habe ich zumindest 
innerhalb von 48h eine Rückmeldung bekommen.

Natürlich gibt es auch noch freie Libs für den STM32 von der 
Web-Community. Vieleicht sogar mehr als beim PIC32. Aber wie schon von 
anderen geschrieben ist der Aufwand das zusammenzusuchen und seine 
eigene Konfiguration zum laufen zu bekommen deutlich höher.

> Wie sieht es denn hier im Forum aus? Was wird präferiert?
Hier im Forum liegen die Präferenzen allerdings eher bei den AVR (8Bit) 
und ARM im 32 Bit Sektor. Zumindest schreien deren Anhänger 
(insbesondere AVR) am lautesten. Aber es gibt auch eine Menge PIC kenner 
hier. Nur die wirklich PIC lastigen Foren sind andere.

Hier noch zwei Dinge von mir:
Oben wird der ICD3 als Tool Empfohlen. Das ist definitiv ein gutes Gerät 
und wenn es auf die (nicht zu viel) Euros nicht ankommt würde ich den 
auch nehmen. (selber habe ich "nur den ICD2)
Wenn du etwas sparen willst funktioniert aber auch der PicKit3 der nur 
wenig mehr Einschränkungen hat. Den nutze ich für die neueren Bausteine 
und ich muss sagen der ist echt Robust: Verpolt, Kurschluss, 
Überspannung (über 12V durch die Schaltung!) und was weiß ich habe ich 
dem Ding schon zugemutet. Funktioniert immer noch wie am ersten Tag. Und 
das bei einem Tool mit Debug funktionalität für 30Eur! (Wenn ich mir da 
anschaue was ATmel für seine AVR bietet... Entweder schweineteuer 
(JTAGICE MKII) mit dem ungefähr das möglich ist was mit dem PicKit3 
möglich ist, oder derart superempfindlich das es beim kleinsten Fehler 
stirbt (DRAGON - Forensuche!)

Als zweites: SPÄTER wenn du mit den Pic32 zurecht kommst würde ich mir 
aber die ARM zumindest auch mal anschauen. (wenn du mit ARM einsteigen 
würdest käme die Empfehlung umgekehrt). Das sind halt die beiden großen 
Architekturen und aus eigener Erfahrung weiß ich -gerade wenn du andere 
Projekte nachbauen willst oder Teile davon als Ausgangsbasis für eigene 
Ideen nutzen willst, wird dieses Projekt genau auf der von dir nicht 
Präferierten TEchnologie basieren. Meist ist es aber leichter sich dann 
damit abzufinden anstelle das mühsam zu portieren. Halt wegen der 
Peripherie. Der eigendliche Programmcode hat ja nicht die Unterschiede, 
das verdecken die Compiler schon ganz ordentlich!

Für die STM32 gib es mit dem STLink auch einen günstigen JTAG Adapter 
(ca. 25Eur), Oder falls es eine private Anwendung ist auch das 
universellere (merh asl nur STM32) Segger J-Link EDU für ca. 60Eur.
Der ST-Link kann ja nur die ST Bausteine 8Bit/32Bit

Gruß
Carsten

Bin jetzt keines falls der Profi, aber ich glaube, dass es ziemlich egal 
ist welcher Prozessor da verbaut ist. In C merkt man da nicht wirklich 
den Unterschied bzw. ist es kein großer Aufwand sich in einen anderen 
Core einzuarbeiten. Da sehe ich eher bei der Peripherie mehr Aufwand.

Und die Peripherie ist bei den ARMs sowieso von Hersteller zu Hersteller 
komplett anders. Also bin ich der Meinung, dass es egal ist ob man jetzt 
den PIC32 oder einen ARM nimmt.

Beim PIC32 kann man sich auch sicher sein, dass der auch noch in einigen 
Jahren erhältlich ist und falls nicht, ist meist ein pinkompatibler 
besserer Typ vorhanden.

Mfg Kroko

Hi,
bastler schrieb:
> Hallo Yaro,
>
> mit dem PIC32 setzt Du ziemlich auf einen Nischenprozessor, sorry die
> PIC-Fans werden mich gleich zerreissen, jedoch ist mir zumindest in
> Europa kein anderer MIPS basierter µC bekannt.

Das liegt aber dann eher an deinem Wissensstand als an der tatsächlichen 
Verfügbarkeit! DA gibt es schon einiges - Die Tage hatte ich einen von 
TI in der Hand...
Was richtig ist, das ist die Tatsache das es weniger "General Purpose" 
Prozessoren wie bei den ARM gibt. An "Bastler- Einstiegsmaterial" kenne 
ich auch nur den PIC32 aus dem Eff Eff. Die anderen sind eher im High 
End sektor zu finden:
Zitat Wikipedia
> MIPS-Prozessoren werden auch häufig in eingebetteten Systemen eingesetzt.
> Dazu zählen z. B. Cisco-Router, Suns Cobalt-Server bis RaQ/Qube2, BMW
> Navigationssysteme, die Fritz!Box, Satellitenreceiver, Dreambox, Konica
> Minolta DSLRs und Sony- und Nintendo-Spielkonsolen.

Oder bei Heise:
http://www.heise.de/ct/artikel/Prozessorgefluester-1102725.html

bastler schrieb:
> Bei den ARM's, ob Cortex-M3 oder ARM7, setzt Du auf eine viel breitere
> Basis.

Das halte ich für einen Fehlglauben - denn ich kann diesem hier nur 100% 
Zustimmen:
Stefan R. schrieb:
> ... aber ich glaube, dass es ziemlich egal
> ist welcher Prozessor da verbaut ist. In C merkt man da nicht wirklich
> den Unterschied bzw. ist es kein großer Aufwand sich in einen anderen
> Core einzuarbeiten. Da sehe ich eher bei der Peripherie mehr Aufwand.

Insbesondere da folgendes Gilt:
> Und die Peripherie ist bei den ARMs sowieso von Hersteller zu Hersteller
> komplett anders. Also bin ich der Meinung, dass es egal ist ob man jetzt
> den PIC32 oder einen ARM nimmt.

Es spielt vom Aufwand her ABSOLUT KEINE ROLLE ob ich jetzt von einem 
STM32 Cortex-M3 auf einen NXP Cortex M3 wechsle, oder ob ich von einem 
PIC32 zu einem STM32 wechsle (und umgekehrt!)
Der Kern spielt fr mich keine Rolle - ich muss sowohl das Pinning wie 
auch die meisten Lib-Zugriffe ändern. Und der Teil der zwischen allen 
ARM Plattformen beliebig austauschbar ist kann bei einem Wechsel 
zwischen MIPS und ARM genauso stehen bleiben.
Daher nützt mit die breitere Basis an Hobbyprozessoren bei ARM ÜBERHAUPT 
NICHTS! Wenn mein ausgewählter Hersteller nicht liefern kann oder die 
Produktion gar einstellt kann ich trotzdem nicht einfach ausweichen. Ich 
muss Software und HArdware trotzdem ändern.

Das ist ein Argument das stammt noch aus den Zeiten als Assembler die 
alleinige Sprache der µC war die Prozessoren mit gleichen Kern auch 
nahezu identisch im Pinning waren - von Periepherie "ON Chip" war da ja 
noch gar keine Rede...

Dazu kommt noch das man -wie geschrieben- mit Microchip einen HErsteller 
hat der sich (mit ausnahme einer MAssenabkündigung bei Ausgründung ´89) 
in den letzten 20 Jahren als sehr zuverlässig herausgestellt hat. 
Vollständige Abkündigungen gab es fast nicht - Und die wenigen die es 
gab hatten einen 100% kompatiblen Nachfolgetyp der mit einer 
Programmänderung im Rahmen von 5min Aufwand problemlos anstelle der 
ursprünglichen Verbaut werden kann.
Zudem hat dieser Hersteller viele Einsteigerinformationen einigermaßen 
gut ausfbereitet zentral bei sich auf den Seiten abrufbar. Das hast du 
in der Qualität bei den ARM (noch?) nicht.

GRuß
Carsten

Carsten Sch. schrieb:
> Das mit den Abstürzen schein also am jeweiligen System zu liegen - wie
> fast bei aller Software.
Bei mir stürzt MPLAB komischerweise meist dann ab, wenn ich die Hilfe 
anschaue :)

> Ja, würde ich auch so sehen - für den ersten Einstieg bist du bei
> Microchip etwas besser bedient. Gerade weil es sehr viel mehr -aus einer
> HAnd- gibt. Oft incl. Anfängerfreundlicher Doku.
Naja, bei deren neuem Multimedia Expansion Board hält sich die Doku 
leider sehr in Grenzen :(

> Für den STM32 gibt es auch Libs von ST. Allerdings muss ich -insbesonder
> im Moment- sagen das es ein echter Krampf ist auf deren Seite nach der
> richtigen Lib zu suchen.
Ich kaufe nix von einem großen Hersteller, der so blöd ist, seine Seite 
so zu verunstalten.

> Zur Krönung kommt noch dazu das ich seit DREI MONATEN dabei bin zu
> versuchen eine laut Pressemitteilung kostenlos erhältliche Audio Lib zu
> erhalten.
Solche Sachen wundern mich nicht mehr. Wenn es um Hard- oder Software 
geht, können sich Hersteller anscheinend alles erlauben.

> Soetwas habe ich bei Microchip noch nicht mal Ansatzweise erlebt. Wenn
> dann wirklich mal keiner die Antwort greifbar hatte habe ich zumindest
> innerhalb von 48h eine Rückmeldung bekommen.
Da bin ich jetzt gespannt, wenn die mir meine Frage zum Multimedia Board 
beantworten, sind sie echt gut. Ich bezweifele es allerdings...


> Nur die wirklich PIC lastigen Foren sind andere.
Kannst Du da was anderes als das Microchip-Forum empfehlen? Da wird 
einem nicht wirklich gut geholfen :(

> Halt wegen der
> Peripherie. Der eigendliche Programmcode hat ja nicht die Unterschiede,
> das verdecken die Compiler schon ganz ordentlich!
Genau, und bei der Peripherie sind die Libs von ARM zu ARM sehr 
unterschiedlich.

Grüße,
Anguel

bastler schrieb:
> Bei den ARM's, ob Cortex-M3 oder ARM7, setzt Du auf eine viel breitere
> Basis.
Und was hat man davon? Der Core spielt wie oben schon gesagt fast keine 
Rolle. Und MIPS ist kein schlechter Core. Außerdem steht Microchip zu 
seinen Produkten und ist eine sehr reiche Firma. Ob da Luminary/TI 
besser sind, wage ich zu bezweifeln.

> Ob man das ccs tool (eclipse basiert) mag, muss jeder selbst
> entscheiden, ich habe keine grosses Problem damit.
Das hat definitiv weniger Nutzer als MPLAB.

> Um jedoch mal mit dem weiter oben genannten Vorurteil aufzuraeumen,
> Softcores in FPGA's sehe ich nicht, als viel komplizierter an als simple
> µC.
Da lese ich in dem FPGA Forum hier von den Profis andere Sachen bzgl. 
Xilinx EDK und auch bzgl.Performance. Da lautet das Motto eher - Hard 
wenn nur möglich.

> Man muss ja nicht die SC der Chiphersteller mit Ihren
> Entwicklungsumgebungen nehmen, unter Opencores gibt es zum Bsp.
> genuegend Alternativen. Damit kann dann der FPGA seinen entscheiden
> Vorteil ausspielen: Wenn es mal zeitlich eng wird fuer den µC, kann man
> leichter  dedizierte Hardware an den Softcore anbinden um den µC zu
> entlasten.
Ach was - und mit welchem Aufwand das ganze? FPGAs muss man doch erstmal 
in- und auswendig kennen, um mit OpenCores überhaupt was anfangen zu 
können.

> Dieses kann sogar soweit gehen, das man extra Befehle für den Zugriff
> auf diese im Softcore definiert. Schneller geht es dann nicht wirklich
> mehr.
Ja möglich ist im Prinzip alles. Ich bau mir mal eben meinen eigenen 
Cortex-M5. Sorry, aber solche Aussagen verwirren die Anfänger komplett. 
Welcher Softcore kann den von der Performance her z.B. mit Cortex-M3 
mithalten? Mit welchem FPGA? Und was kostet er Spaß dann?

Yaro schrieb:
> Ich möchte einen großen Hexapod bauen und suche dafür einen schnellen
> µC.
Hier ist übrigens ein PIC32 Hexapod, der sogar malen kann;)
http://www.youtube.com/watch?v=01vDzLksecc

Grüße,
Anguel

Falls Du noch in der Evaluation steckst habe ich auch noch einen 
Kandidaten:

Renesas RX600 Serie:
http://www.renesas.com/products/mpumcu/rx/rx600/rx600_landing.jsp

Die sollten Deine gestellten Anforderungen erfüllen. FPU vorhanden, 
gehen bis 100MHz, bis 2MB flash, 128kB RAM, ...
Als kostenlose Entwicklungsumgebung kannst Du die KPIT GNU Tools nehmen:
http://www.kpitgnutools.com/

bastler schrieb:
> also rein Leistungsmaessig kann zum Bsp. ein microblaze (hier v7.2)
> locker mit der cortex-m3 architekture mithalten  (1.30DMIPS/MHz zu
> 1.2.5DMIPS/MHz)
>
> Dabei kann selbst auf den "Spar"-FPGAs (spartan) eine core Frequenz von
> 100MHz ohne groessere Probleme erreicht werden und das auch auf billigen
> Digilent Ausbildungs-Boards.
Hört sich interessant an :) Aber der Aufwand für einen Anfänger ist 
schon groß :(

> Jedoch kann die Entwicklungskette konstant bleiben
> (armgcc).
Ich dachte, dass der nicht so gut optimiert wie Keil und IAR. Wie sind 
deine Erfahrungen?

> Die obengenannten Wikipedia Beispiele zu MIPS getriebenen Geraeten,
> setzen alle keine allgemeinen µC ein, sondern meist spezielle SoC's.
Ich glaube auch, dass viele der MIPS-Beispiele eher in Richtung 64 bit 
gehen.

Grüße,
Anguel

Johnny B. schrieb:
> Falls Du noch in der Evaluation steckst habe ich auch noch einen
> Kandidaten:
>
> Renesas RX600 Serie:

Wie sieht es mit Libraries, Evalboards und Kosten aus?

Anguel S. schrieb:
> Johnny B. schrieb:
>> Falls Du noch in der Evaluation steckst habe ich auch noch einen
>> Kandidaten:
>>
>> Renesas RX600 Serie:
>
> Wie sieht es mit Libraries, Evalboards und Kosten aus?

Der Chip an sich sollte rel. günstig sein. Habe beim RX610 mal Zahlen um 
die EUR 5...6.- gehört.

Evalboards gibts z.B. von Glyn:
http://www.glyn.de/content_xl.asp?wdid=2376
http://www.glyn.de/content_xl.asp?wdid=2489

Wie es mit (kostenlosen) Libraries aussieht weiss ich leider nicht. 
Jedoch wahrscheinlich nicht sonderlich viele.

Johnny B. schrieb:
> Wie es mit (kostenlosen) Libraries aussieht weiss ich leider nicht.
> Jedoch wahrscheinlich nicht sonderlich viele.

"Um die Softwareentwicklung zu erleichtern, gibt es von GLYN neben dem 
TFT Steuerprogramm auch noch wichtige Funktionen, wie z. B. Kreise, 
Linien, und Blöcke zeichnen. Auch Fonts können verwendet werden."

Naja, nicht sehr überzeugend, was die Graphic-Libs angeht :)