32-bit uCs - AVR32 vs. ARM

Den Cortex-M3 gibts von ST, TI und NXP auch.

Ich kann den nur empfehlen - und gleichzeit von dem XMega DRINGEND abraten. Der 128A1 ist auch in der H-Revision bis oben hin voll mit Silicon Bugs, der avr-gcc unterstützt ihn nur mit zahlreichen non-Mainline Patches, per JTAG ist das Ding mit dem Atmel mkii unter Linux gar nicht Debugbar (nicht ganz richtig, aber man kann z.B. keine Breakpoints setzen -> unbrauchbar), unter Windows stürzt dieses unsägliche AVR Studio öfters ab.

Bei den Cortex M3 finde ich persönlich die TIs am besten, ST ist wohl aber günstiger. Lassen sich super auch unter Linux betreiben, der gcc beherrscht ARM eh aus dem FF, der GDB kann prima benutzt werden.

Cortex-M3 hier mit gcc. Keinerlei Beschwerden. Du wirst nicht mehr zurück zum 8-Bitter wechseln wollen.

Ciao, Henrik

Hallo Thorsten,

n=20

d=20

ege=20

t=20

it=20

die=20

ich w=FCrde grunds=E4tzlich eher einen ARM nehmen - da hast Du insgesamt doch die gr=F6=DFere Auswahl und kannst je nach Projekt auch durchaus mit=

verschiedenen Herstellern arbeiten, je nachdem welcher Chip gerade optimal f=FCr die Anwendung pa=DFt.

=20

Alle g=E4ngigen Hersteller haben da inzwischen gute Auswahl, NXP hat auch=

einige sehr interessante Chips (z.B. LPC17xx).

Nicht n=F6tig.

F=FCr ARM, egal welcher Hersteller: Code::Blocks als IDE, dazu GNUARM (ic= h nehme die Yagarto Toolchain). Debugging =FCber OpenOCD-USB - die Software=

dazu (OpenOCD, Telnet-Terminal und Insight) ist ein bi=DFchen gew=F6hnungsbed=FCrftig, aber vielleicht schon ausreichend.

Investition: 40 Euro f=FCr den OpenOCD-USB Adapter und einige Zeit zum Einarbeiten... :-)

Tilmann

Hast du mal einen Link, wo das kompakt beschrieben ist?

Ich arbeite momentan auch mit AVRs und habe mit vor einigen Monaten von ST einen STM32 Primer 2 gekauft, bin aber noch nicht dazu gekommen, damit etwas zu machen.

Aktuell habe ich aber eine Kundenanfrage hier liegen (USB-Stick am Microcontrollersystem), wo ein Cortex-M3 sicher besser wäre.

Entwicklungstools waren bei dem Primer 2 soweit dabei, aber ich würde doch gerne das ganze etwas Prozessor/Hersteller unabhängiger haben und GCC einsetzen.

Gruß

Stefan DF9BI

Mhh ARM ist ja an sich ne feine Lösung (wobei ARM nicht gelich ARM ist); nur leider kommt man da beim Stromverbrauch kaum unter 50mA. Da sollte man dran denken, wenn es batteriebetrieben sein soll.

M.

Am 16.12.2010 17:25, schrieb Matthias Weingart: (wobei ARM nicht gelich ARM ist);

Das ist wohl eines meiner Probleme...

nur

Der STM32 Primer2 läuft hier seit einigen Monaten im Standby aus einem Lithium Akku...

Gruß

Stefan DF9BI

- vs -

Ja was denn nun?! :) Was macht er denn im Standby, bzw was läuft da genau? Der Core wohl nicht, sondern ein Timer, der ihn regelmäßig weckt oder so?

Ich frage, weil ich auch dringend was mit ARM machen muss. Für ein Projekt hatte ich mir einen ARM7 mit 256k Flash von Atmel auf einem Eval-Board schicken lassen, da es den Chip schön günstig und gut verfügbar gibt.

Stefan Huebner :

Ich hab mir da mal ne Reihe von ARM's angesehen; es gibt nur ganz wenige, die stromsparend arbeiten können (energymicro). Die einzige Möglichkeit, die schlafen zu legen, ist oft die on-board-RTC (Uhr mit 32kHz Quarz, auch nicht bei allen ARM's verbaut) die ihn dann zyklisch aufwecken kann; allerdings dauert das u.U. zehn bis ein paar hundert ms (bis der Quarz angelaufen ist). Wenn man z.B. nur auf Nutzereingaben wartet (keyboard- Abfrage und ab und an mal nen Zeichen zum Display und warten auf Interrupts vom Prozess) kriegt man den Strom kaum runter: das zyklische Aufwachen per RTC ist da zu lahm. Zugegeben bin ich vom MSP430 da recht verwöhnt ;); für mich war das beim Stromverbauch erstmal wieder nen Schritt zurück in die

8051-Steinzeit ;-). Die C*-M3 von TI z.B. brauchen im sogenannten "low power mode" immer noch 50mA, bei Fullspeed dann so um die 100mA; recht schlechtes Brutto/Nettoverhältnis.

Thema hatten wir schon mal:

M.

Danke für die Hinweise.

10ms wären für mich ok, 100 auch noch, aber "ein paar hundert" ist mir zu vage. Muss ich wohl mal testen, wie sich konkret mein ARM7 verhält. Für das Datenlogger-Projekt kann ich den wohl knicken, wird dann doch ein ATmega oder vielleicht mal ein MSP430.

Stefan Huebner :

Ja mach mal, interessiert mich auch. Kann ja auch sein, dass der RTC die CPU wirklich nur per "Alarm" wecken kann und der Alarm dann nur auf die Sekunde genau eingestellt werden kann ;-(.

M.

Hallo Matthias!

Das wäre jetzt kein KO-Kriterium für mich. Wobei ich 50mA schon heftig finde. Kann man die nicht über internen Teiler runtertakten, wenn man wenig Rechenlast hat?

Gruß Thorsten

--
PGP welcome!
Thorsten online: http://www.ostermann-net.de/electronic
Rund um Schrittmotor, Fräs-Bohr-Plotter & Mikrocontroller

Wobei man dies nun Atmel /nicht/ anlasten kann, sondern der FSF: der Patch für die Unterstützung der Xmegas ist zu großen Teilen innerhalb von Atmel entstanden (anders als der ursprüngliche GCC, damals haben sie noch voll und ganz auf IAR als alleinigen Compiler gesetzt), und da die FSF darauf besteht, dass man vor Einzug fremden Codes in ihren offiziellen Tree dieses unsägliche copyright assignment unterschrieben haben muss, kannst du dir vorstellen, welch juristische Verwicklungen daraus entstehen, sowas in einer Firma dieser Größe umzusetzen (bei der ja alles erstmal durch eine Rechtsabteilung durch muss).

Das tut der Qualität der Compilerunterstützung selbst jedoch keinen Abbruch, da sie aktiv von Atmel gepflegt wird.

AVR32 ist übrigens im gleichen Boot und aus ebendiesem Grund nicht im offiziellen GCC-Tree zu finden.

Das wiederum geht in der Tat auf Atmels Konto, denn sie haben es nach wie vor nicht geschafft, die dafür notwendige Erweiterung der Appnote AVR067 zu veröffentlichen, und es hat bislang auch noch keiner Bock gehabt, das mal zu reverse-engineeren.

--
cheers, J"org               .-.-.   --... ...--   -.. .  DL8DTL

http://www.sax.de/~joerg/                        NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)

Thorsten Ostermann :

Naja genau das macht er ja; die CPU ist im Standby quasi ohne Takt. Das sind vermutlich die reinen Leckströme im Flash und der Ruhestrom des Quarzoszillators oder sowas....; konnte mir auf dem TI Tag aber keiner sagen, warum das so ist.

M.

Und so sprach Matthias Weingart:

Damit man den MSP noch verkaufen kann.

Roland

50 mA verbrauchen die nur bei Maximaltakt. Für einen kleinen STM32 z.B. werden 48 mA bei 72 MHz verbraucht, 18 mA bei 24 MHz, aber nur 8 mA bei 8 MHz (bei externem 8 MHz Takt und interner PLL, um den internen höheren Takt zu generieren). Bei internem RC-Takt mit 125 kHz kann es aber auch bis 0,5 mA runtergehen. Aber wenn super Low-Power sehr wichtig ist und Rechenleistung nicht gebraucht wird, nimm besser einen anderen Prozessor.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Frank Buss :

Takt

0,5

Da sind die STM32 dann ja doch besser; danke für die Info. Aber es ist eigentlich Quatsch den Prozessor mit niedrigem Tak laufen zu lassen; bei Bedarf mal "auf voller Drehzahl" schnell abarbeiten lassen und ansonsten schlafend beim Null Takt - können die STM das auch?

M.

Takt zur Laufzeit umschalten geht und auch schlafen legen und z.B. per Interrupt oder Timer zyklisch aufwecken. Siehe Kapitel 4 und Kapitel 6 vom Reference Manual.

--
Frank Buss, http://www.frank-buss.de
piano and more: http://www.youtube.com/user/frankbuss

Am 16.12.2010, 15:26 Uhr, schrieb Thorsten Ostermann =

:

er einen =

nd =

=BCberlege =

Ich besch=C3=A4ftige mich etwa seit Anfang 2010 mit ARM. Dazu habe ich m= ir dieses Eva-Bord

und diesen Dongle gekauft, u.a. zu bestelle= n bei siehe auch Die Source-Files =C3=A4nderte ich mit meinem Lieblings-Editor Ultra-Eidt= , kompiliere sie unter Windows mit GNU-WIN und debugge sie mit in Kombination mit =

Der noICE Debugger funktioniert nach der Installation 30 Tage lang, dann= =

kann man ihn f=C3=BCr 159 Dollar freischalten.

Unter Linux arbeite ich mit einem selbstgebackenen GNU-Compiler, insight= =

und open-OCD. Diese Tool-Kombination ist ziemlich langsam, und insight st=C3= =BCrzt manchmal ab. Bei open-OCD hatte ich =C3=B6fters das Problem, dass die De= bug- Schnittstelle nicht zur=C3=BCckgesetzt werden kann, wenn ich dann die Sp= annungs- versorgung unterbreche geht=C2=B4s manchmal danach.

Was bei mir immer funktioniert hat ist CrossWorks, ist auch sehr schnell= .

sowohl unter Windows als auch unt= er Linux. Muss man registrieren lassen, funktioniert dann 30 Tage lang. F=C3= =BCr

150 Dollar gibt=C2=B4s die Personal License, funktioniert unbegrenzt, da= rf man aber kein Geld mit verdienen.

Mit diesen Werkzeugen habe ich eine Application-Note von ST - war ur- spr=C3=BCnglich f=C3=BCr ein anderes Eva-Board geschrieben - auf mein Bo= ard =

angepasst. Wer Interesse hat, dem kann ich meine Arbeiten kostenlos zur Verf=C3=BCg= ung stellen, allerdings wie =C3=BCblich, ohne jede Garantie.

Weitere Infos auch bei =

mit freundlichen Gr=C3=BC=C3=9Fen

Franz-Josef Ehrentraut

--

Erstellt mit Operas revolution=C3=A4rem E-Mail-Modul: http://www.opera.c=
om/mail/

[..]

Verstehe ich das richtig das man ARMs nur richtig nutzen, also auch debuggen kann wenn man viel Geld auf den Tisch legt?

Dann verstehe ich nicht wieso immer alle so eine Abneigung gegen Renesas haben. Solange die maximale Binaercodegroesse dort unter 64k (R8C/M16C/R32) oder 256k (SH2) bleibt kann man dort alles umsonst nutzen auch den Debugger.

Olaf

Am 02.01.2011, 16:33 Uhr, schrieb Olaf Kaluza :

Funktioniert Renesas auch f=C3=BCr ARM Mikroprozessoren in Kombination m= it einem Wiggler-Clone oder einem anderen Dongles im niedrigen Preissegment= ? Wenn ja, wo kann man die Software downloaden?

franz-Josef

--

Erstellt mit Operas revolution=C3=A4rem E-Mail-Modul: http://www.opera.c=
om/mail/