www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Welcher ARM ist für mich der Beste?


Autor: Tüddel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute,
ich habe mal ein Paar Fragen zum ARM. Ich habe bald meinen Jahresurlaub 
(2 Wochen) und will mich doch auch mal mit dem ARM außeinander setzen.
Mein Problem ist nur... welches Device!
Ok ich denke ein ATMEL(AT91) oder ein NXP(LPC2000) sollte es schon sein, 
da man die ja fast schon in der Grabbelbude um die Ecke findet. Aber das 
war es auch schon.

Was ich denke zu brauchen:
- ~64 - 256k Flash
- mind. 16 16k RAM (idealerweise 32 - 64)
- mind. 1x SPI und das möglichst schnell (~10MHz)
- mind. 1x UART für RS232
- mind. 1x CAN
- 16-... IO's
- idealerweise als 44 oder 64 Pinner

was auch noch wichtig ist:
- ein möglichst schnelles Flash da viel aus ihm gelesen werden muss
- DMA währe optional daher auch ganz fein
- falls es soetwas gibt, eine Programmierschnittstelle ohne extra Geräte 
also idealerweise (ohne vorherigen Bootloader zu schreiben) direct via 
USB oder RS232
- GCC Support (auch der rest an Tools sollte kostenfrei sein)
- möglichst günstig (nicht über 20€ pro Chip)
- möglichst wenig "Hünerutter" rings rum um das Ding zum laufen zu 
bekommen ;-)


Irgendwie finde ich genügend Pros & Kontras für viele ARM`s von Atmel 
und NXP, aber die letzte Festlegung kann ich nicht treffen. Ein genaues 
Projekt schwebt mir momentan noch nicht vor, aber ich würde ersmal viele 
meine früheren Apps von MSP430`s und AVR`s auf den ARM portieren um 
erstmal mich einzuarbeiten. Ein Anfänger bin ich nach ~4 Jahren mit uC`s 
nicht mehr unbedingt, aber nachdem ich viel mit AVR`s und MSP430`s 
rumhantiert habe, denke ich das es ganz schön währe mit einem 
Industriestandard anzufangen. Zum 8051 habe ich irgendwie keine 
Mutivation gefunden und ARM`s (so haben mir viele aus der Industrie 
bestätigt) wird langsam genauso wichtig wie 8051'er.

Könnt Ihr mir da ein oder zwei Typen nennen, die genau das sind, die ich 
brauche?

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mach mal bitte die "Deppenapostroph-Funktion" aus. Ich würde Dir den 
AT91RM9200 empfehlen, aber es gibt bestimmt 1000 Leute, die etwas 
anderes sagen würden. Du kannst doch sicher auch Datenblätter lesen? Da 
Du schon sehr genaue Vorstellungen hast, was Du haben möchtest, sollte 
sich doch sicher in 1-2 Stunden Recherche etwas finden lassen. Geht 
bestimmt schneller, als hier auf Antworten zu warten...

Autor: Rooney Bob (rooney)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es wenn du einfach auf der ATMEL Homepage vorbeischaust. Dort 
werden alle ARM Typen in einer Matrixauflistung verglichen. Also viel 
einfach gehts dann wirklich nicht mehr!!!

Autor: Tüddel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hmm, nagut...
ich glaube ich habe mit dem LPC2148 ungefähr das gefunden, was ich 
brauche...

Ist es eigentlich eine "Glaubensfrage" ob man einen Atmel oder einen NXP 
nimmt, oder gibt es da klare Pros und Kontras?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Seitens LPC2000 gibt es CAN in den schon älteren gut verfügbaren 
LPC2129/2294 und den neuen LPC2300. Auf letztere wirst du allerdings 
noch ein paar Monate warten müssen, es sei denn dir reicht erst einmal 
ein entsprechendes Experimentierboard (gibt's wohl von Keil oder so). 
Bei den älteren sollte man unbedingt die Bugliste lesen, FullCAN ist 
aufgrund von Bugs unmöglich, BasicCAN geht aber.

Günstiges Header/Bastelboard mit LPC2119 siehe 
http://stores.ebay.de/Micro-Research_W0QQcolZ4QQdi... 
oder http://www.futurlec.com/index.shtml. Solltest aber noch ein bischen 
Zeit bis zum Urlaub haben, denn zumindest bis das von MicroResearch 
verschifft ist dauert's etwas.

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ich glaube ich habe mit dem LPC2148 ungefähr das gefunden, was ich
> brauche...

Seit wann ist da CAN drin?

Ach ja, der LPC2119 hat zwar SPI, aber bei 7,5MHz ist Schluss.

> ob man einen Atmel oder einen NXP nimmt

Man nimmt beispielsweise was man schon kennt und auch kriegen kann. Ist 
beides neu, kann man ja nach den Funktionen gehen. Bei Header- und 
Experimentierboards ist LPC2000 verbreiteter als SAM7, weil schon länger 
auf dem Markt.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein paar Unterschiede Atmel SAM7... genenueber NXP LPC2...

Dieser Vergleich ist etwas biased, da ich bei NXP arbeite aber 
vielleicht kann ja ein Atmel Mitarbeiter einen aehnlichen Vergleich zur 
Verfuegung stellen, der ebenfalls auf Fakten beruht:

1. CPU-Takt max. bei NXP 60-72 MHz abarbeiten aus dem Flash, Atmel 55 
MHz
2. Max. Performance bei Atmel im Thumb-Mode, bei NXP im ARM Mode. Flash 
Breite ist der Flaschenhals bei Atmel. Das spielt eine grosse Rolle bei 
der Spitzengeschwindigkeit aus dem Flash aber keine grosse Rolle bei der 
Durchschnittsgeschwindigkeit.
3. Um maximale Geschwindigkeit zu erreichen muss der Code bei SAM7 ins 
SRAM geladen werden, beim LPC2000 auch. Der Verlust an Performance wenn 
aus dem Flash gearbeitet wird ist bei NXP ca. 5%, bei Atmel ca. 30% 
jeweils bei der max. Clock Rate. D.h. ein LPC2000 ist vom Flash bei 60 
MHz ein klein wenig schneller als ein Atmel bei 55 MHz vom SRAM.
4. Angenommen max. Performance ist nicht so wichtig, bei 30 MHz sind 
beide praktisch gleich schnell, weil SAM7 da auch vom Flash im ARM mode 
fahren kann.
5. Stromverbrauch ist aehnlich zwischen diesen beiden Familien und beide 
sind viel besser als der Rest der ARM7-Welt
6. GNU-Tools gibts fuer beide (schau ach mal rein bei YAGARTO !)
7. Aeltere LPC2000 benoetigen 2 externe Spannungen, 1,8V und 3,3V, die 
SAM7 sind spaeter an den Markt gekommen und haben alle einen internen 
DC/DC, brauchen somit extern nur 3,3V. Der LPC2119/01 oder der 
LPC2129/01, der fuer die Anforderung passen koennte brauchen 2 
Spannungen.
8. DMA gibt es bei NXP nur in den LPC23xx und LPC24xx, bei SAM7 haben 
das alle. Diese LPC23/24xx Teile sind noch neu und wie schon gesagt 
etwas schwierig zu bekommen. Derzeit am einfachsten auf Evaluation 
Boards. 100-pin ist auch das kleinste Gehaeuse. Positiv waere 
natuerlich, das absolut beste Preis/Leistungsverhaeltnis, 2 CAN 
Schnittstellen, bis zu 3 schnelle SPI, obendrauf USB und Ethernet und 
trotzdem aehnlicher Preis wie LPC2129. Bei Digikey kostet der LPC2364 
nur 6,06 Euro! mit der Moeglichkeit auf einen 2366 oder 2368 
drop-in/kompatibel aufzuruesten. Voraussichtliche Verfuegbarkeit 
weiterer Teile bei Digikey, Ende September.

Entwarnung fuer Errata Sheets LPC2119/01 und LPC2129/01 haben die CAN 
Probleme behoben! Ausserdem geht auch eine SPI mit der SSP Funktion bis 
15 Mbit/sek, Siehe Data Sheet Kapitel 6.13
Errata Sheet:
http://www.standardics.nxp.com/support/documents/m...

Data Sheet:
http://www.standardics.nxp.com/products/lpc2000/da...

Zusammenfassend:
Egal ob es ein SAM7 oder ein LPC2000 wird, beide Familien bieten sehr 
gutes Preis/Leistungsverhaeltnis. Der groesste LPC Vorteil ist die 
Spitzenperformance aus dem Flash wogegen die flexible DMA 
Implementierung bei Atmel schon hilfreich ist.

Robert

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Travel Rec

hast Du Dir die Minute genommen um die Frage von Tueddel zu lesen?
Er fragt nach einem Flash micro (hat der AT91RM9200 nicht), mit CAN (hat 
der AT91RM9200 nicht), am besten im 64-pin Gehauese (das kleinste 
AT91RM9200 Gehaeuse ist 208-pin), mit moeglichst wenig Huehnerfutter 
drum rum (braucht der AT91RM9200 jede Menge)
Ausserdem ist der AT91RM9200 ausgestattet mit einer veralteten CPU, fast 
alle neueren Teile haben eine verbesserte ARM926 CPU.

You can do better than that ;-)

Robert

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert: Ich habe mir mal die aktellen Erratas angesehen. Bei 2138/2148 
komme ich mir bei den Workarounds zum neu entdeckten MAM Fehler etwas 
auf den Arm genommen vor:
MAM.1: MAM auf Mode 2 stellen, sonst Müll.
MAM.2: MAM auf Mode 1 stellen, sonst Müll.

Besondern gefällt mir ja die ausgesprochen wolkige Beschreibung von 
MAM.2 (der offenbar auch in den .01 Versionen rumgeistert): Wenn das 
Problem bei ihnen auftritt, dann.. - nur dass diese Art Problem 
verteufelt schlecht zu diagnostizieren ist, zumal kein Tip gegeben wird, 
in welcher Konstellation das auftreten kann. Irgendwie klingt das so als 
ob NXP noch selber im Nebel stochert.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem koennte mit bestimmten Bus-Zustaenden in der Simulation 
erklaert werden. Evtl. sogar noch mit bestimmten Assembler Sequenzen 
aber da fast jeder in "C" programmiert, laesst sich die Beschreibung 
nicht so greifbar beschreiben wie es jeder gerne haette.

Fakt ist, das Problem taucht in einer Konfiguration immer oder gar nicht 
auf. Das MAM.2 Problem ist ein reproduzierbares.

Wenn MAMCR auf 1 gesetzt wird, ist das MAM auch enabled, so dass MAM.1 
nicht mehr auftritt.

Zugegeben, die Wortwahl ist mehr als ungluecklich :-((  ich werde das an 
die betreffenden Mitarbeiter weiterleiten.

Robert

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Robert: Schon recht, bin nicht bei den ARMen zuhause, der 9200 ist der 
einzige, den ich mal in Aktion gesehen habe und über den ich somit 
berichten kann ;-)

Autor: Tüddel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Robert Teufel

Danke für deine Übersicht. Aber Sie beschreibt gut mein Problem! Welches 
Device denn jetzt. Klar, eine eierlegende Woll-Milch-Sau ist zwar schön, 
aber manche Features brauche ich (erstmal nicht). So dass ich z.B. 
erstmal auf CAN verzichten kann (und falls doch, dann habe ich noch ein 
paar MCP2515 rumfliegen)

Ich glaube, ich bestell mir erst mal dieses Board 
http://shop.mikrocontroller.net/csc_article_detail...
und spiele damit rum. Das sollte mir erst einmal als Basis genügend 
Spielraum bieten! Und durch Seriell ist es auchnoch flashbar.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tüddel
Gute Wahl, sehr gut verfuegbar, hohe Kompatibilitaet falls Du spaeter 
auf einen LPC23xx umsteigen moechtest und nicht zu komplex.

Go for it!

Robert

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
ich würde dir auch zu NXP raten. die ausführung von code aus dem flash 
ist wesentlich schneller als bei den AT91xxx. die AT91SAM7 können kein 
IIC-Slave (voll doof)! dafür ist das DMA bei den LPC's recht mies 
(umständlich zu konfigurieren, nur 2 channels und transfers gehen nur 
in's/vom USB-RAM).
...und die LPC's sind bei ähnlicher ausstattung sogar billiger als die 
Atmels

-> Peter

Autor: Tüddel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sollte ich mir auch einen JTAG adapter besorgen, oder wird der ser. 
Bootloader wohl reichen?

Gibt es auch irgendwo ein C tutorial für LPC`s -> so wir unser AVRGCC 
Tutor hier? Ich habe zwar schon viel Gegoogelt, aber soetwas 
ausführliches wie eben das AVRGCC Tutorial nicht gefunden.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Sollte ich mir auch einen JTAG adapter besorgen, oder wird der ser.
> Bootloader wohl reichen?

JTAG ist gut, wenn du auf dem target debuggen willst. für reine 
downloads reicht die serielle bestimmt aus, kann natürlich bei grossen 
images recht lahm sein. es gibt ja auch freeware JTAG debugger 
(OpenOCD), da muss man sich nur ein adapterkabel für'n parallelport 
basteln und kann dann über telnet debuggen. source-level debugging soll 
damit auch gehen (mit GDB und Insight), hab's aber nie hinbekommen, 
dieses GNU-zeug ist ganz schön widerspenstig. ich benutze dann doch 
lieber IAR und JLink, das geht wenigstens 'out-of-the-box'...

Autor: Tüddel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, IAR ist für ein Bastler/Hobby ganz schön teuer!
Hab mit IAR damals (Beruflich) für den MSP430 Programmiert. Fand da die 
IDE aber recht bescheiden! Aber die mitgelieferten Tools waren schon gut

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Naja, IAR ist für ein Bastler/Hobby ganz schön teuer!
ja, das stimmt was du sagst, die IDE ist auch nicht so toll, die tools 
aber schon. auf der arbeit benutzen wir auch eine gekaufte version, aber 
privat könntest du, wenn dein unrechtsbewusstsein es zulässt, die 
gecrackte evaluation version benutzen.
es gibt übrigens noch eine uVision-variante (von keil) mit dem GCC drin. 
ich glaube die war auch umsonst. ich weiss aber nicht, ob damit das 
debuggen anständig funktioniert (ich glaube ja eher nicht). die 
vollversion mit dem echten ARM-compiler und debugger ist natürlich 
sauteuer.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Als Alternative käme noch Rowley Crossworks in Frage. Das gibt es auch 
in einer nichtkommerziellen Version, die für 150 USD verkauft wird.
Zur Zeit wird auch dieser Version ein USB-JTAG-Adapter ("CrossConnect 
Lite") beigelegt.
Die nichtkommerzielle Version entspricht der kommerziellen, darf aber 
nicht kommerziell eingesetzt werden.

Crossworks unterstützt verschiedene JTAG-Interfaces, den 
FT2232-basierenden USB-JTAG-Adapter von Olimex ebenso wie die üblichen 
"Wiggler"-Clones für den Parallelport.

Das verwendete Compiler-Backend ist hier übrigens auch gcc.

http://rowley.co.uk/arm/index.htm

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das gibt es auchin einer nichtkommerziellen Version, die für 150 USD
> verkauft wird.
'nicht-kommerziell' und 'verkauft'. wie passt denn das zusammen?

Autor: Andreas K. (a-k)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 'nicht-kommerziell' und 'verkauft'. wie passt denn das zusammen?

Kommerziell seitens Rowley, nichtkommerziell seitens des Käufers.

Autor: Tüddel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Och, ich denke ich bleibe auch weiterhin beim GCC (wie auch beim 
AVRGCC,MSPGCC, und auch sonstige GCC-Versionen für den "großen" 
Rechner).

Wenn man sich erst einmal an ihn gewöhnt hat, dann kommt man mit seiner 
Bedienung auch meist mit anderen Platformen zurecht.

Aber sagt mal ein schönes Tutorial wie "C für LPC2000" oder so gibt es 
rein zufällig nicht, oder? Habe bislang(wie oben schon beschrieben) noch 
nichts finden können.

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Aber sagt mal ein schönes Tutorial wie "C für LPC2000" oder so gibt es
>rein zufällig nicht, oder? Habe bislang(wie oben schon beschrieben) noch
>nichts finden können.

http://www.mikrocontroller.net/articles/ARM-elf-GCC-Tutorial

MfG Mark

Autor: Tüddel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das habe ich auch schon gefressen ;-) aber soooo ausführlich wie eben 
das AVRGCC Tutorial ist es leider nicht :-(

Autor: Mark .. (mork)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tüddel,

alles was Du wissen willst, findest Du im Datenblatt und in den 
Beispielen von Martin Thomas 
(http://www.siwawi.arubi.uni-kl.de/avr_projects/arm...)

Sonst kannst Du ja immer noch im Furum fragen.

Autor: mthomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Entwarnung fuer Errata Sheets LPC2119/01 und LPC2129/01 haben die CAN
>Probleme behoben!

Und bei LPC23xx gleich wieder neue eingebaut, CAN habe ich auf LPC23xx 
zwar noch nicht nutzen müssen, aber hoffentlich werden die Versionen die 
denn "bald" mal ausgeliefert werden den Fehler nicht mehr haben.


>Evtl. sogar noch mit bestimmten Assembler Sequenzen
>aber da fast jeder in "C" programmiert, laesst sich die Beschreibung
>nicht so greifbar beschreiben wie es jeder gerne haette.

Soweit ich sehe, nutzt RealView/Keil, GCC und inzwischen auch IAR das 
elf-Format (in versch. Versionen). Wenn man diese Fehler schon in 
ausgelieferten ICs hat, dann würde es NXP gut zu Gesicht stehen, eine 
Programm anzubieten, dass die elf-Datei einliest und falls entsprechende 
Sequenzen entdeckt werden, eine Warnung mit Adresse auszugeben. Dann 
wäre man zumindest sicher, dass man "sauberen" Maschinencode" hat und 
nicht ständig ein "vielleicht liegt's doch an der Hardware" im 
Hinterkopf.


>3. Um maximale Geschwindigkeit zu erreichen muss der Code bei SAM7 ins
>SRAM geladen werden, beim LPC2000 auch. Der Verlust an Performance wenn
>aus dem Flash gearbeitet wird ist bei NXP ca. 5%, bei Atmel ca. 30%
>jeweils bei der max. Clock Rate. D.h. ein LPC2000 ist vom Flash bei 60
>MHz ein klein wenig schneller als ein Atmel bei 55 MHz vom SRAM.
>...Der groesste LPC Vorteil ist die Spitzenperformance aus dem Flash...

Was kommt bei eine solchen Vergleich raus, wenn das MAM nur "partialy
enabled ist", so wie im Errata zum LPC2368 empfohlen?


>...dafür ist das DMA bei den LPC's recht mies (umständlich zu
> konfigurieren, nur 2 channels und transfers gehen nur
> in's/vom USB-RAM).

Die "LPC's" gibt es eigentlich nicht mehr. Mit LPC23xx/24xx hat sich 
einiges getan, nicht nur in Hinsicht DMA (VIC, I2S ...). Aber neue 
Fehler gibt es auch, die Mitbewerber bieten allerdings auch keine 
perfekten Produkte. Core-Frequenz und Speicherzugriff ist nicht alles. 
Bei kleineren Benchmarks mit SD-Karte/FAT/kein Code im RAM, hat ein mit 
48MHz getakteter SAM7 mit SPI-DMA gut mit einem LPC213x bei 60MHz/MAM 
und SPI FIFO mithalten können. Test mit LPC23xx und SPI-DMA steht noch 
aus. Wie immer: "kommt halt auf die Anwendung drauf an".


>Naja, IAR ist für ein Bastler/Hobby ganz schön teuer!

Die Kickstart-Version ist auf 32kB Code begrenzte (hat auch ein paar 
andere Einschränkgungen) aber kostet "nur" die Preisgabe der 
Kontaktdaten. Damit lässt sich schon vieles ausprobieren. EWARM-KS ist 
aber meines Wissens vollkommen frei verwendbar, also auch für 
kommerzielle Sachen. Habe bisher allerdings nur kurz damit "gespielt". 
(Ja, ich nutze GNU-Tools meist in Form meiner WinARM Sammlung und für 
die wenigen Cortex-M3-Spielereien das Packet von Codesourcery)


>...es gibt übrigens noch eine uVision-variante (von keil) mit dem GCC
> drin. ich glaube die war auch umsonst. ich weiss aber nicht, ob
>damit das debuggen anständig funktioniert (ich glaube ja eher nicht).

Keil bietet ein sehr veraltetes GCC-Packet für uVision zum download. 
Kein Wunder, dass die ehemals veröffentlichten Benchmarks auf viel 
Kritik stiessen. Man kann allerdings neuere GNU-Toolchains integrieren. 
Für die GNU Toolhchain aus WinARM gibt es entsprechende 
"Glue-Programme", diese sollten auch mit anderen z.B. 
codesoucery/Yagarto etc. funktionieren. Habe selbst nur kurz mit WinARM 
(was sonst ;-) ) ausprobiert. Auch bei Verwendung von GNU-Tools gilt für 
den uVision Debugger/Simulator eine Codegrößenbeschränkung (16kByte wenn 
richtig erinnert). Debuggen mit uVísion/ulink"1" funktionierte zumindest 
in ein paar oberflächlichen Tests auch bei mit GNU-tools erzeugten 
elf-Dateien problemlos. Vor allem der Simulator und die Anzeige von 
Speicherinhalten/Registern mit deren Bedeutung bei Simulation und 
JTAG-Debugging ist bei Keil schon recht schick. Falls die die Lizenz 
richtig interpretiere, darf man die Evaluierungsversion auch bei 
Verwendung von GNU-Tools nicht für kommerzielle Arbeiten nutzen.


> Och, ich denke ich bleibe auch weiterhin beim GCC

Im Hintergrund der Rowley-IDE ist eine GNU Toolchain (also "gcc") im 
Einsatz. Man zahlt nicht für den Compiler/Assembler sondern für die IDE 
inkl. Debugger, JTAG-Ansteuerung/Interface und deren selbstgemachte 
libc. Nichts was es nicht auf für wenig Geld/"umsonst" gäbe, aber bei 
Rowley besser vorgekaut. Ich habe mit dem Rowley Produkt allerdings noch 
nie wirklich gearbeitet.


Nun denn, meine x* 0,02ct dazu, vielleicht ja für jemanden nützlich.

Martin Thomas

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Tueddel

schau mal die Tutorials von Hitex an.
Hier gibts ne Menge: http://www.hitex.de/lpc2000/con-lpc2000.html
und ein tutorial bzw. zwei fuer die LPCs gibts hier:
http://www.hitex.de/download.html?download/con_dow...

Zum Thema JTAG-Debugger, nicht der billigste aber der vielseitigste ist 
Segger's J-Link. Funktioniert mit GNU, auch unter Eclipse (Yagarto), mit 
IAR, mit Rowleys und auch mit Keil.
Ist ausserdem der mit der schnellsten download Geschwindigkeit, beim 
Flashen ca. 10x schneller als die UART Loesung oder auch als andere 
Clones.

Robert

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Core-Frequenz und Speicherzugriff ist nicht alles.
> Bei kleineren Benchmarks mit SD-Karte/FAT/kein Code im RAM, hat ein mit
> 48MHz getakteter SAM7 mit SPI-DMA gut mit einem LPC213x bei 60MHz/MAM
> und SPI FIFO mithalten können. Test mit LPC23xx und SPI-DMA steht noch
> aus. Wie immer: "kommt halt auf die Anwendung drauf an".

ich habe selbiges erlebt. SAM7 und LPC2378, schreibzugriffe auf eine 
SD-karte im SPI mode. bei beiden ist der zugriff in etwa gleich schnell 
und beiden benutzten DMA (ca 4 sekunden für 1MB). der SAM7 ohne DMA war 
um etwa die hälfte langsamer (SPI-clock ~20Mhz), der LPC ohne DMA war 
genau so schnell wie mit DMA (SPI-clock ~10Mhz). aus irgendeinem grund 
konnte man die SPI clock des LPC nicht höher als 10Mhz einstellen, zudem 
kamen die besseren ausführungszeiten aus dem flash und die nötige 
kopieroperation vom USB-RAM, die dafür sorgten, dass das DMA beim LPC 
nichts brachte.

Autor: Thomas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hätte gernen noch einen Rechten Arm anstatt meinen Linken Arm. 
Irgendwie funktioniert der Rechte Arm besser.
*duck und wech

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

was Du beschreibst war der Hauptgrund weshalb die LPC so lange keine DMA 
hatten. Die schnellere Abarbeitung aus dem Flash gleicht alle DMA 
Vorteile im Bezug auf Geschwindigkeit aus (selbst bei 10-20 Mbit/sec). 
Viele Kunden wollen nicht glauben, dass ein UART mit 115200 Baud sogut 
wie keine Belastung fuer die CPU darstellt und dafuer eine DMA wirklich 
reichlich wenig bringt.
Trotzdem macht die DMA fuer Schnittstellen wie die SPI Sinn, nicht weil 
sie dadurch schneller wird, sondern weil die CPU dadurch mehr 
Rechenleistung fuer andere Dinge zur Verfuegung hat.
Im uebrigen hat der 2378 eine parallele SD Schnittstelle, sollte ca. 
Faktor 4 bringen.

Robert

Autor: Tüddel (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe nun das Board und den OpenOCD-USB Adapter von Olimex 
(http://www.olimex.com/dev/arm-usb-ocd.html). Von der mitgelieferten CD 
habe ich die Software installiert und den Treiber für den Adapter.

Wenn ich das Peispielprogramm öffnen und über Run->external 
tools->OpenOCD auswähle, macht meine Platine nen Piip (das ist ja 
anscheinend noch ok), aber wenn ich auf den Bug klicke um den Code 
einzuspielen, dann bekomme ich einen Fehler (siehe Anhang)

Auch mit Insight habe ich es probiert. Da bekomme ich eine "Memory 
access error"

...

Könnt ihr mir da auch weiter helfen?

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.