www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Umstieg AVR->ARM


Autor: dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat jemand schon erfolgreich den Umstieg vom AVR-> ARM geschafft?
Ich will wissen wie Zeitintensiv es wird. Naturlich habe ich mich schon
mal vor gewagt. Da sind Einstellungen von der PLL und die
Interruptserviceroutiene ist auch nicht in C gehalten.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hängt vielleicht auch ein bisschen davon ab, worin Du bislang Deine
Programme geschrieben hast.

Der Umstieg AVR-Assembler -> ARM-Assembler dürfte 'ne übelst haarige
Angelegenheit sein,

der Umstieg avr-gcc -> arm-gcc sollte schon um einiges leichter fallen;
zu bedenken ist allerdings, daß der ARM (glücklicherweise) eine
von-Neumann-Maschine ist.

Ganz zuletzt kommt's natürlich auch darauf an, was Du bislang mit
dem AVR getrieben hast und was Du mit welchem ARM anstellen willst;
es gibt ja nicht den ARM, sondern aberzig* Varianten.


*) schönes Wort, nicht?

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Hat jemand schon erfolgreich den Umstieg vom AVR-> ARM geschafft?"

Was heißt hier Umstieg, die spielen doch in einer völlig anderen Liga
!

Projekte, die auf einem AVR laufen können, würde ich nie auf einen ARM
umrubeln und umgekehrt.


Du mußt Dich auch erstmal für einen ARM entscheiden (Atmel, Philips,
ST,...).

Z.B. der ST-ARM hat 16 Interruptprioritäten (!!!), aber dazu mußt Du
erstmal die 37 Seiten im Reference-Manual durcharbeiten und verstehen
und hoffen, daß sie stimmen und hoffen, daß der Chip keine Bugs hat.

Peter

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder soll es gar ein ARM-9 mit MMU werden?

Wenn Du den IAR Compiler benutzt, kostet es Dich einen vierstelligen
Betrag und ein paar Klicks, dann kannst Du Deine Projekte übernehmen.

Am Anfang steht ja wohl die Frage: warum willst Du umsteigen? Und davon
hängt dann auch die Antwort ab, wie aufwendig es wird und ob es sich
überhaupt lohnt. Wenn ein Projekt einfach nicht mehr in die dicken
Atmegas "paßt", ist eine intelligente Überarbeitung des Codes
vielleicht weniger Aufwand (doch, auch Dein Code kann besser werden!
(-; ). Wenn die Rechenleistung der AVRs nicht reicht, mache Dir vorher
Gedanken, ob die ARMe da wirklich den erhofften Schub bringen. Wenn Du
doch vor allem mit Bitoperationen, aber vielen Interrupts schaffst,
wirst Du enttäuscht sein.

Autor: Peter Dannegger (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Wenn Du doch vor allem mit Bitoperationen, aber vielen Interrupts
schaffst, wirst Du enttäuscht sein."

Ganz genau !


Der ARM7 ist für viel Datendurchsatz und viel 32-Bit Rechnen und wenig
Float oder Divisionen (hatter nich).


Als Bitschubser oder Statemachine bringt er keine Punkte, aber dafür ne
viel teuere Platine und höheren Stromverbrauch.


Peter

Autor: dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es bieten zunehmend Hersteller ARM als CPU an.
ST, Philips, NetSilicon, TI, cirrus logic, Freescale und so weiter.

Ich will auch an größere Projekte ran. Bis jetzt habe ich immer die
PC-Beistellvariante. Eigentlich ist das eine Vergewaltigung des PCs,
weil der eine Grafikkarte zum schönen Darstellen und eine
Netzwerkanbindung hat. Außerdem ist immer zusätzlich noch ein PC
zuwarten.
Ich hatte jetzt an den ARM7TDMI gedacht. In die nähere Auswahl habe ich
die von Analog genommen, da es dort einen richtigen 3 Kanal DAC gibt.
Die Philips LPC210x Serie und die ST sind auch nicht schlecht.

Autor: Philipp Sªsse (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"viel teuere Platine und höheren Stromverbrauch"

Neee, jetzt muß ich den ARM doch in Schutz nehmen:

Warum sollte die Platine viel teurer sein? Solange man sich im selben
MHz-Bereich bewegt, tun die Platinen sich doch nichts gegenüber einem
dicken 8-Bitter.

Und Stromverbrauch? Mein Philips LPC2194 trinkt bei Vollast ziemlich
genau ein 1 mA pro MHz; mein ATmega128 über das doppelte, ohne
doppelten Befehlsdurchsatz zu schaffen.

Also: man kann durchaus auch ohne großen Datendurchsatz ARM nehmen,
aber nur bitte nicht in der falschen Hoffnung auf Parformance-Wunder
beim "Bit-Schubsen".

@dose: Bei der Typenauswahl kann ich mangels breiter Erfahrung nicht
wirklich behilflich sein, aber der Wechsel zwischen ARMen verschiedener
Hersteller ist ja zum Glück nicht so ein Drama.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sieh' Dir mal die ARM7-Varianten von ... Atmel an. Da gibt es
mittlerweile auch ganz nette (AT91SAM7Sxxx) mit integriertem
USB-Device-Controller.
http://www.atmel.com/dyn/products/param_table.asp?...

OKI stellt auch ARM7-Versionen her (ML67Q5003); interessant hieran ist
der SDRAM-Controller. Olimex hat wohl zwei Platinen mit diesem
Controller in Arbeit.

Autor: dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für den Tipp.
Ich habe bereits ein Board von Olimex mit dem LPC2106 und eine Jtag
Connector.
Ich wollte über den Jtag programmieren und die hardware Debuggen. Im
netz habe ich gefunden, das es nicht möglich ist über den Jtag in den
Flash zu schreiben. es ist halt teortisch alles möglich, doch dann doch
wieder ein Trauerspiel.
Leider bekommt man bei Olimex die nackte Platine ohne
Beispielprogramme.
Sei es als CD oder Downloadbereich der Homepage.

Autor: Rufus T. Firefly (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.
  "Im netz habe ich gefunden, das es nicht möglich ist über den Jtag
  in den Flash zu schreiben."

Das ist, zumindest in Bezug auf den LPC2106, vollkommener Quark.

Selbstverständlich lässt sich über das JTAG-Interface das Flash-ROM des
LPC2106 programmieren.

Das geht auch mit dem JTAG-Parallelport-Adapter von Olimex, der auch
hier im Shop verkauft wird. Den kann man sich auch selberbauen, das ist
nämlich ein Nachbau des "Wiggler" von Macraigor.

Leider taugt die meiste Software, die unter Windows mit dem
"Wiggler"-JTAG-Interface zusammenarbeiten soll, recht wenig; eine
lobenswerte Ausnahme ist Crossworks for ARM von Rowley. Das ist eine
IDE mit integriertem Debugger, gcc als Compiler-Backend und einer
vorzüglich funktionierenden Unterstützung für "Wiggler"-Clones.
Leider ist diese Software mit 500 UKP ziemlich teuer, und die
Demoversion funktioniert nur für 30 Tage, und das auch erst nach
Freischaltung.
Beiliegend sind Beispielprojekte für LPC2106 und auch direkt für die
Olimex'sche Platine.
Selbstverständlich lädt Crossworks das Programm via JTAG ins Flashrom
...

Der "OCD Commander" von Macraigor, der angeblich mit dem "Wiggler"
zusammenarbeiten soll, ist -zumindest unter neueren Windows-Versionen-
annähernd nutzlos, selbst wenn man die vielen Nachbauten fehlende
Brücke im Parallelportstecker nachlötet.

Autor: dose (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Der "OCD Commander" von Macraigor, der angeblich mit dem
"Wiggler"
zusammenarbeiten soll, ist -zumindest unter neueren Windows-Versionen-
annähernd nutzlos, selbst wenn man die vielen Nachbauten fehlende
Brücke im Parallelportstecker nachlötet."

Genau davon habe ich gesprochen. Der gleiche Treiber wird für insight
genutzt und schmiert ständig ab.

Ich hoffe auf alternative Treiber wie jtagpack
http://sourceforge.net/projects/jtagpack/
Leider ist der auch noch nicht lauffähig. Ich habe es nicht geschafft
ihn unter Windows zu kompilieren. Die Macraigor Umgebung gefällt mir
nicht, weil sie unter der Cygwin Umgebung läuft. Da gibt es Probleme
mit einer cyg...1.dll, weil ich auch den Winavr auf meinen Rechner
habe. Es bekriegen sich die DLLs mit unterschiedlichen Versionsnummer.
Ich habe es schon gesehen, dass Winavr diese DLL auf die todo Liste
gesetzt hat.

 Rowley ist mir zuteuer. Bei mir läuft das eher immer so ab. Privat
brauche ich einen technologischen Vorlauf, und wenn ich es drauf habe
wird es auf Arbeit genutzt. Ich brauche den Einstieg privat. Hier in
der Frima muss man alle Finanzen hinterlegen und wenn man nicht gleich
die Summe Umlegen kann springt die Buchhaltung mir an den Hals. Leider
verdirbt das einem manchmal den Spaß.

Autor: Stefan Ludwig (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn es darum geht eine preiswertes grosses Display zu haben
könntest Du auch den Propeller-Chip von Parallax nehmen

Der Cchip kostet ca. 30 Euro

Die IDE mit allem drum und dran gibt es kostenlos von Parallax
Die kann Assembler und eine objektorientierte Sprache namens SPIN
Er hat 8 CoProzessoren

Der hat IM PROZESSOR hardware eingebaut mit der man
über drei IO-PINS ein NTSC-Signal erzeugen kann.

Mit entsprechend mehr PINS auch VGA

Es gibt von Parallax dazu einen 2,5-Zoll NTSC-TFT-Monitor für schlappe
80 Euro

Autor: Christian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mal eine Frage am Rande...

Wenn die ARM7/9 für Bitopearationen und zum Pintogglen nicht den
extremen Schub bringen, welche Controller sind dann dafür am besten
ausgelegt?

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

>Mal eine Frage am Rande...

>Wenn die ARM7/9 für Bitopearationen und zum Pintogglen nicht den
>extremen Schub bringen, welche Controller sind dann dafür am besten
>ausgelegt?

Als Bitschubser bzw. IO Toggler sind die SX Mikrocontroller(?)
interessant. http://www.parallax.com/sx/index.asp . Die Mikrocontroller
schaffen im Turbo Mode 75Mips. Leider haben die Mikrocontroller kaum
internen Speicher, aber gegenüber ein CPLD eine sehr schoene Loesung.

Dirk

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christian,

die 8051 sind darauf optimiert.

Z.B. beim C8051F120 dauert ein Pintogglen (CPL P1.7) 2 Zyklen, also
20ns bei 100MHz interner CPU-Takt.

Mehrere Pins togglen (XRL P2, #0A5h) dauert 3 Zyklen (30ns).


Peter

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Intel Pentium Quad Core :-)

Ne...im Ernst, alles was 8bit hat, ist für einfaches Bitschubsen schon
am Besten geeignet. Nihct weil sie das jetzt viel schneller machen
würden als die ARM, sondern einfach weil das Verhältnis von Aufwand und
Nutzen stimmt.

Autor: Dominic R. (dominic)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist jetzt aber Leichenfledderei, oder?

Datum: 19.05.2005 09:05 -> Datum: 27.09.2006 14:54

Noch dazu ging es in dem Thread doch nie um Displays?

Zu Christians Frage:
Die neueren LPCs (z.B. 214x, LPC210[12]) können mit bis zu 15 MHz
Toggeln - d.h. gerade mal zwei Takte pro Schaltvorgang.
In meinen Augen macht es wenig Sinn, für Aufgaben, die ein noch
schnelleres Bitbanging erfordern, einen uC zu nehmen - programmierbare
Hardware kann Bits mit zig-Mhz Schubsen.

Gruss,

Dominic

Autor: Dirk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

>In meinen Augen macht es wenig Sinn, für Aufgaben, die ein noch
>schnelleres Bitbanging erfordern, einen uC zu nehmen -
>programmierbare Hardware kann Bits mit zig-Mhz Schubsen.


Ich sehe das nicht so, ein CPLD / FPGA kostet viel Arbeitszeit. Code
schreiben, Testbench schreiben und Simulieren, danach die Constraints
prüfen usw. bedeutet viel Arbeitszeit. Ich würde dann eher die SX
Mikros nehmen und der Programmer für 15 Dollar ist auch billiger als
ein USB Blaster bei Xilinx.

Autor: vajk (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es schon Neues zum Thema ?

Autor: Torsten (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,

weiß nicht wie weit Euer Bit-Toggle Thema ARM versa XXX ist. Nur ein 
kleinen Beitrag von mir. Ich weiß nicht, ob Ihr Euch schon mal die Mini 
ARM's von NXP LPC2103 Serie angeschaut habt. Die Teile gibt es von 8kB 
Flash + 2KB RAM bis 16kB Flash + 8kB RAM mit 70 MHz. Die Teile bekommt 
man selbst bei Reichelt, Schuricht und Digitkey in kleinen Stückzahlen. 
Bei Digikey den LPC2101 für 2.44€ (ab 25 Stück unter 2€) und den LPC2103 
ab 3.64€ (ab 25 Stück unter 3€). Dafür bekommt Ihr keinen vergleichbaren 
8Bitter mit dieser Performance/Speicher. Bis 32K könnt Ihr die IAR 
Kickstart Version kostenlos nutzen (einfach IAR Embedded Workbench for 
ARM von IAR herunterladen), dazu braucht Ihr dann noch ein J-Link von 
IAR oder Segger. Was das Bit-Toggeln angeht, die Mini-ARM's von NXP 
haben FAST-GPIO implementiert (was zur Zeit nicht bei Atmel, ST und Co 
zu finden ist), daß heißt, Ihr konnt mit vollen 17MHz von der SW aus die 
Bit Toggeln - und das mit vollen 32Bit Ausgängen. Die NXP Teile sind die 
schnellsten - laufen mit vollen 70MHz aus dem Flash heraus in ARM und 
Thumb Mode. Auch das schafft nur der NXP, nicht aber der Atmel oder ST 
ARM7. Das schafft kein 8Bitter. Nebenbei könnt Ihr noch andere Sachen 
machen. Komplette Beispiele findet Ihr auch nach der Installation. Und 
auf dem Netz tausend andere auch.

By the way, man schafft auch ein 480x480 VGA display anzusteuern - nur 
mit dem ARM in SW - findet Ihr auch auf der Webseite.

Ich selber arbeitet nur noch mit ARM7 Derivaten, weil die Teile 
günstiger und schneller sind als vergleichbare 8Bitter mit gleichem 
Speicher.


Schönen Gruß

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

Bewertung
0 lesenswert
nicht lesenswert
Nicht alle kleinen ARMe von Philips* haben Fast-GPIO implementiert; der 
sehr beliebte LPC2106 beispielsweise kann seine I/O-Leitungen nur mit 
etwa einem MHz wackeln lassen. Fast-GPIO gibt es nur in neueren ARMen.

Ansonsten hast Du recht optimistisch die Werbaussagen von Philips 
abgeschrieben - natürlich laufen LPCxxx nicht mit vollem Takt aus dem 
Flash, sondern nur meistens, dank des 128Bit-breit organisierten 
Flash-ROMs und des MAM (was eine Art primitivster Cache-Controller ist). 
Unter realen Bedingungen kann da dann eine geringere 
Verarbeitungsgeschwindigkeit draus resultieren. Volle Lotte gibt's nur 
bei Codeausführung aus dem internen RAM.


*) jaja, und Raider heißt jetzt Twix.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Torsten wrote:

> Die Teile gibt es von 8kB
> Flash + 2KB RAM bis 16kB Flash + 8kB RAM mit 70 MHz. Die Teile bekommt
> man selbst bei Reichelt, Schuricht und Digitkey in kleinen Stückzahlen.
> Bei Digikey den LPC2101 für 2.44€ (ab 25 Stück unter 2€) und den LPC2103
> ab 3.64€ (ab 25 Stück unter 3€). Dafür bekommt Ihr keinen vergleichbaren
> 8Bitter mit dieser Performance/Speicher.


Ein 8kB 32Bit-RISC dürfte vom Applikationsumfang etwa einem 2kB AVR 
entsprechen, also z.B. ATtiny2313, bloß, daß der AVR viel billiger ist 
und keine 2 Spannungsregler braucht.


Sowas lohnt sich also nur dann, wenn man mit den ARMs schon total super 
fit ist und die gleiche Entwicklungsumgebung auch für Miniprojekte 
nehmen will und der höhere Preis und die zusätzlichen 2 Spannungsregler 
nicht ins Gewicht fallen und keine 5V-Ausgänge gebraucht werden.

Bei mir ist davon nicht eines der Fall und daher haben die ARMs nur den 
Platz jenseits der 128kB Flash.



Peter

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Bei mir ist davon nicht eines der Fall und daher haben die ARMs nur den
>Platz jenseits der 128kB Flash.

Warum 128kB Flash - die AVRs gibt es inzwischen auch mit 256kB.

Ich bin im Moment auch am überlegen, ob es sich 'lohnt' sich näher mit 
ARM zu beschäftigen. Bis jetzt konnte ich alles mit AVRs 'erschlagen' 
und wenn es eng wurde, dann meist  nur der Speicher oder die IOs, nicht 
so sehr die Rechenleistung.Und wenn man sich das Datenblatt von so einem 
AT91SAM7 anschaut, da zuckt man dann schon etwas.
Für mich wäre ein ARM in erster Linie für Anwendungen interresant, wo 
viele Daten verrechnet und/oder übertragen werden müssen und evtl. eine 
Ausgabe auf ein größeres Display erfolgen müsste.
Die Fragen die sich mir stellen:
1. Wie viel muss ich invetsieren, um erste Schritte mit einem ARM (AT91) 
machen zu können - ich nehme mal an, von meinen AVR-Tools (ISP, JTAG) 
kann ich nichts verwenden.
2. Mit was für einem Zeitaufwand muss ich ungefähr rechnen, bis man 
einfachere Sachen auf einem ARM zum laufen bringt? Wenn ich mir das 
Blockdiagramm von dem AT917S anschaue, kommen mir sehr viele Sachen 
(ADC, SPI, UART, Timer, TWI) bekannt vor - wenn sie ähnlich arbeiten, 
wie bei den AVRs, sollten die neuen Sachen sein: PWM, SSC, USB, PLL, 
ROM+SAMBA und der neue Kern. Da ich nicht vorhabe in Assembler zu 
programmieren, sind die grössten schwwarzen Löcher: SAMBA und USB.

bye

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter

falls die Rechenleistung tatsaechlich interessant ist, dann wuerde wohl 
eher ein 2k ARM einem 8k AVR entsprechen, denn die Sache mit integer, 
32-bit word oder gar float ist natuerlich oberuebel mit einem 8-bitter. 
Wenn's nicht ums bit-schupsen geht, dann ist ein ARM im Thumb mode der 
Massstab fuer Codekompaktheit.

Dann gibt es da noch die Kleinigkeit mit der RAMgroesse. Der 8k ARM hat 
immerhin 2k SRAM, 16k/4k, 32k/8k, das ist viel flexibler als die 
mini-RAMs in den AVR.

Just my 2 cents,  Robert

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel, NXP wrote:

> falls die Rechenleistung tatsaechlich interessant ist, dann wuerde wohl
> eher ein 2k ARM einem 8k AVR entsprechen, denn die Sache mit integer,
> 32-bit word oder gar float ist natuerlich oberuebel mit einem 8-bitter.

Hast Du mal ne Hausnummer, wie groß die float-lib aufm ARM-GCC für die 4 
Grundrechenarten ist ?

Dieser Unterschied tritt aber nur einmalig auf, die Aufrufe dürften sich 
kaum unterscheiden.


> Dann gibt es da noch die Kleinigkeit mit der RAMgroesse. Der 8k ARM hat
> immerhin 2k SRAM, 16k/4k, 32k/8k, das ist viel flexibler als die
> mini-RAMs in den AVR.

Naja, ist genau doppelt so groß.
Aber ob das nun auch soviel flexibler ist, hängt stark von der 
Programmierung ab:
Wenn man beim ARM Variablen default als int (32Bit) anlegt, kommt sogar 
weniger raus.
Nur wenn man strikt char nimmt, wenn char ausreicht, ists auch wirklich 
das doppelte.
Den größeren Stackverbrauch (Call, Push) bei ARM noch nicht mal 
eingerechnet.


Peter

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ray:
>1. Wie viel muss ich invetsieren, um erste Schritte mit einem ARM (AT91)
>machen zu können - ich nehme mal an, von meinen AVR-Tools (ISP, JTAG)
>kann ich nichts verwenden.
vom avr kannst du nichts weiterbenutzen.
es gibt allerdings günstige jtag-ice (von olimex) und auch starterkits 
(ebenfalls olimex). die gnu tools sind ebenfalls vorhanden, auf 
www.yagarto.de findest du das komplette paket.


>2. Mit was für einem Zeitaufwand muss ich ungefähr rechnen, bis man
>einfachere Sachen auf einem ARM zum laufen bringt? Wenn ich mir das
>Blockdiagramm von dem AT917S anschaue, kommen mir sehr viele Sachen
>(ADC, SPI, UART, Timer, TWI) bekannt vor - wenn sie ähnlich arbeiten,
>wie bei den AVRs, sollten die neuen Sachen sein: PWM, SSC, USB, PLL,
>ROM+SAMBA und der neue Kern. Da ich nicht vorhabe in Assembler zu
>programmieren, sind die grössten schwwarzen Löcher: SAMBA und USB.
die in den at91sam7s integrierte peripherie hat nichts mit der im avr 
gleich (das kommt aus 2 verschiedenen "ecken" bei atmel).
im gegensatz zum avr, wo in jedem derivat die peripherie wieder anders 
funkt. oder die bits wieder mal anders verteilt sind, ist beim at91sam7s 
die peripherie immer die gleiche. auch bei den anderen familien 
(at91sam7x, at921sam7se, at91sam9xxx) findest du nahezu die gleiche 
peripherie wie deim at91sam7s.
so gesehen ist der zeitaufwand für den einstieg in den arm kurzfristig 
sicher höher aber langfristig ersparst du dir zeit.
wenn due mit den für dich neuen komponenten (noch) nichts anfangen 
kannst dann spielt das keine rolle. lass sie einfahc unbenutzt. nach 
einem reset ist keine der peripherien aktiv. du kannst dich also stück 
für stück an die neuen dinge herantasten. eine große hilfe sind auch die 
beispiele auf www.at91.com (sind allerdings für dir iar worklbench 
vorbereitet).


gruss
gerhard

Autor: RAY (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Gerhard
Hatte ich mir schon gedacht, dass es nicht ganz so einfach läuft, aber 
schaun wir mal, wird schon klappen, habe ja keinen Zeitdruck, dass ich 
schnell damit klar kommen müsste.

Noch eine andere Frage: ich habe mich vorher ein bisschen bei elmicro.de 
umgeschaut, die verkaufen neben relativ teuren (für privat) Compilern 
von Keil auch einen günstigeren von Imagecraft, hat jemand Erfahrung 
damit: wie gut/schlecht ist das Teil im Vergleich zu teureren Compilern 
oder zu den gnu sachen?


danke für die antworten

Ray

Autor: Robert Teufel, NXP (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter,

2x ist korrekt fuer ATmega8, ansonsten ist es 4x.

Woher kommt eigentlich die Info, dass der ATmega bei vergleichbarem 
Speicher billiger ist als ein ARM7? Wahrscheinlich ist meine Info von 
Digikey etwas vorgepolt aber ich finde da im Einzelstueck z.B. keinen 
ATmega16x im 44-pin Gehauese unter 5 Euro in Einzelstueck.

Wenn ich z.B. den LPC2103 damit vergleiche, 32k Flash, 8k SRAM, doppelt 
soviele serielle Kanaele, mehr und hoeher aufloesende Timer, ca. 4-fache 
MHz, je nach Anwendungen sind das locker 10x performance und der LPC2103 
kostet dieselbe Stueckzahl beim selben Distributor 3.64 Euro.

Bei groesseren Speichern ist das (Miss)verhaeltnis noch wesentlich 
gravierender.

Ich versteh einfach nicht wie es noch Diskussionen ueber Preis/Leistung 
geben kann, wier auch in deisem Thread. Die Diskussion ob sich ein 
Umstieg lohnt im Bezug auf "Time to Market", die ist jedoch sehr 
berechtigt.

Robert

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Robert Teufel, NXP wrote:

> Woher kommt eigentlich die Info, dass der ATmega bei vergleichbarem
> Speicher billiger ist als ein ARM7? Wahrscheinlich ist meine Info von
> Digikey etwas vorgepolt aber ich finde da im Einzelstueck z.B. keinen
> ATmega16x im 44-pin Gehauese unter 5 Euro in Einzelstueck.

Also Reichelt will für nen ATmega16 2,18€ haben.

Bei mir spielt allerdings der Preis nicht so die Rolle, sondern daß sie 
leicht handhabbar sind.
Es passiert schon, daß mal schnell was auf ne Uniplatine dazugepappt 
werden muß ohne extra Spannungsregler, Quarz, Reset-IC.
Ein AVR läuft halt mit nix zusätzlich außer der 100nF Pille an VCC.
Und erst später kommt dann ein richtiges Layout.


Peter

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ich hab mit den AVRs schon einige Geschichten
realisiert, zum Teil einfach fast and dirty,
Punktraster, ISP-Stecker drauf, Saft dran und los
gehts. In C oder Bascom mal schnell nen Code
gepfiemelt und ab geht die Post.
Ich hab nun hier 3 verschiedene Devboards liegen
AT91SAM7S256, AT91SAM7X256 und LPC2148 und
bin nahe am Verzweifeln.
Beim AVR GCC unter Studio4, prima zu simulieren
und zu debuggen, mit Ponyprog flashen und gut ist.
Bei den ARM siehts da ganz anders aus.
Keil IAR GCC Eclipse hitop und und und ... und
Samplecodes portieren von A nach B nur ätzend.
Bei den Atmels will mir vor allem nicht in den
Sinn warum da zigtausendmal AT91C_
in den Libs vertippt wurde !!!!
Also mir fällt der Umstieg definitiv nicht leicht,
aber ich bräucht für n Projekt ziemlich geballte
Rechenpower und da währen die ARM7TDMI n guter
Ansatz dafür.

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@marko:
und was soll uns dein posting sagen?


gruss
gerhard

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.