www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Zukunftsaussichten für den ARM7


Autor: Peter Pippinger (axis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo NG,

wie ja bestimmt alle wissen, habe ich gerade erst vor ein paar Wochen 
(oder sinds doch schon Monate) mit dem AT91SAM7S256 von ATMEL 
angefangen. Mich wuerde jetzt mal eins interessieren:

Wie sind denn so die "Halbwertzeiten" von so einem uC?

Kann man damit rechnen, dass es den ARM7 noch viele Jahre geben wird, 
oder ist da schon etwas bekannt, was mal seine Position einnehmen soll / 
wird?

MfG
Peter

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

Bewertung
0 lesenswert
nicht lesenswert
Die ARM Architektur hat im 32-Bit Sektor eine ähnliche Bedeutung wie der 
8051 im 8-Bit Sektor. Allerdings mit dem Unterschied, dass bei 8051 viel 
in Assembler gemacht wird, auf ARM eher wenig. Weshalb die Bindung der 
Kunden an die Prozessorarchitektur etwas geringer ist.

Fast jeder Chip-Hersteller hat ARM-Cores irgendwie im Programm. Sei es 
als Controller, sei es als Core für Custom-Chips. Nicht immer so ganz 
freiwillig. Von I*M heisst es beispielsweise, dass sie durch Kunden von 
Custom-Chips geradezu dazu gezwungen werden mussten, statt der 
hauseigenen Power-PC-Cores auch ARM-Cores anzubieten.

Viele Controller-Architekturen haben ein sehr hohes Alter und leben 
direkt oder in Derivaten immer noch. Neben 8051 beispielsweise 68xx, Z8 
und natürlich das noch aus den 70ern stammende lebende Fossil PIC. An 
hierzulande ehemals populären Architekturen sind eigentlich nur 8048, 
65xx und die anfangs sehr verbreiteten 3850/F8 fast oder ganz 
ausgestorben.

Was dir um Laufe der Zeit möglicherweise abhanden kommen wird, sind 
bestimmte Funktionsmodule wie UART,SPI,... weil ebendiese in anderen 
Implementierungen inkompatibel sind.

Es gibt zwar Ansätze, im bislang von ARM7 dominierten Sektor mit 
Onchip-Flash mit ARM9 Punkte zu machen, aber wenn man sich den STR9 mal 
en Detail ansieht merkt man bald, dass man sich damit nicht nur Vorteile 
einhandelt.

M.a.W: Keine Sorge. Der ARM7-Core bleibt dir im Bereich unterhalb von 
100 MHz noch lange erhalten.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
Ich sehe das ähnlich wie Andreas. ARM's sind von Anfang an ziemlich 
beliebt gewesen. Ich denke auch, daß es sie noch lange geben wird. 
Eigentlich jeder Hersteller von Microcontrollern hat ARM-basierte Typen 
im Programm, wobei die Atmel AT91SAM eigentlich mehr ein Negativbeispiel 
sind. (I2C ist ziemlicher Schrott, Slave-Modus geht gar nicht. Das 
automatische CTS/RTS beim UART ist annähernd unbrauchbar usw...). Ich 
fand es ziemlich erschreckend, mit welch halbfertigem Zeug sich Atmel 
auf den Markt traut. Sowas kannte ich bis dahin nicht.
Aber z.b. die LPC-Typen von NXP, mit denen ich auch schon was gemacht 
habe, sind da viel besser...

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

Bewertung
0 lesenswert
nicht lesenswert
PS: Die ARM-Architektur ist mittlerweile auch schon weit über 20 Jahre 
alt.

Autor: Robert Teufel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Noch eine postive Assicht:

Der ARM7 als Core wird noch SEHR lange mit verschiedenen Derivaten 
verfuegbar sein. Die SAM7, die verschiedenenSTRxx und die LPC2xxx sind 
erst so richtig am hochlaufen. Es ist allerdings auch mit einer 
Konsolidierungen zu rechnen. Heute gibt es noch viele, relativ kleine 
Hersteller im ARM7 oder auch ARM9 Markt, die werden es sehr schwer 
haben. Dieser Markt ist heiss umkaempft, deshalb auch die sehr 
interessanten Preise fuer Chips mit sehr gutem Funktionsumfang. Meiner 
Meinung zeichnet sich ein Wettbewerb zwischen den o.g. Anbietern ab.

Es ist sehr wahrscheinlich, dass es in 10 Jahren noch die allermeisten 
der heutigen ARM7 "Standard Microcontroller" geben wird, die es auch 
heute schon gibt. Es werden noch viele hinzukommen aber natuerlich wird 
auch der ARM9 Bereich bald beginnen zu wachsen.

Fuer Zukunftssicherung ist es sehr von Vorteil, dass die ARM cores 
software compatibel sind (Ausnahme Cortex M3) und somit lediglich die 
Initialisierung der Peripherals umgeschireben werden muss wenn auf 
andere Bausteine umgestiegen wird. Das ist auch kein Zuckerschlecken 
aber viel einfacher als auf eine andere Architektur zu wechseln.

Ein weiterer Grund weshalb die ARM cores so beliebt sind und auch hier 
im Forum eine gewissen Verbreitung gefunden haben sind die Tools. Von 
GNU-Tools ueber low-cost Compiler bis zu high-end Tools mit Support 
Vertrag, Betriebssysteme, Debugger, Trace Emulatoren... gibt es alles.

Also wenn irgendeine Architektur im 32-bit Bereich derzeit als 
zukunftssicher zu bezeichnen ist, dann die ARM Architektur!

Robert

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Peter:
"Aber z.b. die LPC-Typen von NXP, mit denen ich auch schon was gemacht
habe, sind da viel besser..."


Jo, klar:

Ich nenne nur mal ein nicht funktionierendes EMI, nicht funktionierendes 
CAN, etc.
NXP ist leider keinen Deut besser als Atmel oder ST, eher im 
Gegenteil...

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

Bewertung
0 lesenswert
nicht lesenswert
Andreas wrote:

> NXP ist leider keinen Deut besser als Atmel oder ST, eher im
> Gegenteil...

Die geben sich alle nicht viel. Ob NXP, Atmel, Microchip und wie sie 
alle heissen. Alle 16- und 32-Bit Controller haben etliche Bugs, vor 
allem anfangs. Damit muss man leben, oder bei AVRs bleiben.

Unterschiede gibts vor allem darin, ob erst im Datasheet alles 
versprochen wird um es dann im Erratasheet wieder zu streichen 
(NXP,STR9), oder ob das überwiegend ins Datasheet eingearbeitet wird 
(SAM7,STR7). Letzteres könnte hirnrissige Konstruktionen wie die 
RC-Oszillator betriebene RTC der SAM7S erklären.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Andreas (nicht a-k),
mach doch einen neuen Thread wenn Du denkst, dass Dein Beitrag so 
wichtig ist, was abgeschlossenes nach 5 Monaten wieder zu beleben und 
Dich ausgerechnet dann nochmals ueber die Chips zu beschweren, die 
inzwischen mit einer Rev. B in einem sehr guten Stadium sind.
Es ist muessig, sich ueber die Bugs zu streiten, es ist viel wichtiger 
ob die verbleibenden features gut genug sind die Applikation zu 
bewaeltigen. Z.B. haben wirklich ne Menge Kunden mit dem CAN gearbeitet, 
der zwischen 10-15 Erratas hatte. Hat schon fuer viele getan, war 
einfach unschoen.  Unschoen ist aber oft besser als teuer.

Robert

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da immer schnellere Schnittstellen benötigt werden, um die Daten an den 
PC zu senden, damit man dann die Ergebnisse graphisch darstellen kann, 
ist es besser wenn man zum ARM9 Kern kreift. Dieser ist von seinem 
Umpfang sicherlich nicht leicht zu händelt, wenn man dies jedoch 
geschaft hat, kann man mit Hilfe des ARM9 eine Menge machen.

Jedoch denke ich persönlich, dass der Schritt zu Mehrkehrnprozessoren 
sehr schnell kommen wird. Diese macht auch sicherlich Sinn, denn dies 
erleichtert Timingprobleme erheblich.

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

Bewertung
0 lesenswert
nicht lesenswert
Was vollintegrierte Controller angeht, also solche mit ROM/RAM intern, 
wirst du auf verbreitete Multicores noch lange warten müssen (oder auf 
spezielle Konstrukte wie den Parallax Propeller). Zwar kann man auch in 
diesem Markt mit Performance punkten, aber da gibt's noch ein paar 
bedeutendere Kriterien, wie Stromverbrauch und Kosten.

STR9 zeigt, dass ein ARM9 Core in diesem Umfeld auch keine Bäume 
ausreisst. Da muss schon etwas Cache mit rein, sonst ist das Tempo vom 
Flash das Limit, nicht der Core.

Autor: Peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Jedoch denke ich persönlich, dass der Schritt zu Mehrkehrnprozessoren
> sehr schnell kommen wird.

Der Schritt wurde längst getan. Z.B. in einigen Handys stecken 
Custom-Chips mit mehreren ARM-Cores. Der Nintendo DS hat (glaube ich) 
einen mit ARM9- und ARM7-Kern. Auch in einigen 16-Bit Controllern, z.B. 
dem Freescale HCS12X stecken zwei Kerne, eine S12 CPU und ein kleiner 
RISC-Prozessor, der speziell für I/O-Aufgaben gedacht ist.

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

Bewertung
0 lesenswert
nicht lesenswert
Ist ein Custom-Chip mit mehreren Cores automatisch ein Multicore, 
strukturell vergleichbar mit heutigen PC-Prozessoren, nur auf anderem 
Performance-Niveau? Oder ist das eher die Integration von etwas, das 
früher eine ganze Platine war, mit einem Core als zentraler CPU, einem 
separaten Tastaturcontroller, einem Prozessor im Festplattencontroller 
usw?

Autor: Marius S. (lupin) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gibt es von den SAM7 eigentlich neue Revisionen (vlt in nahegelegener 
Zukunft)?

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Gibt es von den SAM7 eigentlich neue Revisionen (vlt in nahegelegener
>Zukunft)?
es gibt ein paar "kryptische" hinweise auf at91sam7l und at91sam9rl
(keine ahnung warum man solche hinweise immer auf russischen seiten 
findet):

http://projects.org.ua/project/arm/presentation/AT...

gruss
gerhard

p.s.: ich würde aber die finger davon lassen. bei atmel gilt (wie bei 
den meisten bauteilherstellern): papier (oder auch powerpoint) ist 
geduldig.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn ihr so über die Errata Listen und das Verhalten von NXP und ATMEL 
meckert, warum verwendet ihr die denn ??

Es gibt auch ARM 7 von anderen Herstellern.
ZB TMS470 Series von TI.
Diese Teile fahren seit jahren in vielen Autos im zb ABS/ESP System rum.

Ok es gibt die nicht bei dem großen R oder C, dafür sind die µC wohl zu 
gut.

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralph,

kann schon sein, dass micros, die es seit ca. 6 Jahren gibt mehr 
ausgereift sind als diejenigen, die mehr in Richtung Innovation gehen. 
Die Teile sind sehr teuer, nicht in erster Linie weil so gut, sondern 
weil so alt. Alt -> alter Prozess -> grosses Silizium -> hoher Preis.
Es ist schon fast makaber einen Chip zu erwaehnen, der seinen Zenit 
schon lange ueberschritten hat wenn ueber die Zukunftsaussichten von 
ARM7 gefragt wird. Wenn ueber Zukunft gesporchen wird, dann meistens 
auch ueber neue Bausteine in zukuenftigen Anwendungen, da ergeben sich 
Errata Diskussionen fast von selbst.

p.s. nichts fuer ungut, die TMS470 sind sehr zuverlaessig und bieten 
fuer Automotive einen grossen Flashspeicher, einen (!) sehr flexiblen 
Timer und sehr gute ADCs, leider fehlen ein paar andere Kleinigkeiten 
wie der gern gesehene USB, Ethernet, oder aehnliches.

Robert

Autor: Torben (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wo wir bei Automotive und ARM7 sind:

Toshiba hat eine Cortex-M3-Lizenz erworben und wird sein 
Mikrocontroller-Portfolio in dieser Richtung damit ausbauen.

Autor: opacer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
.. und TI wird ARM926 und Cortex-M3 TMS470 rausbringen ...

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Meine Meinung: ARM7 wird sich zwar noch eine Weile halten, aber nach und 
nach durch ARM9 und v.a. Cortex M3 Chips ersetzt werden. Letzterer hat 
wohl architektonisch einige Vorteile gegenüber dem ARM7. Nachteil ist 
halt, dass er nicht codekompatibel ist.

Aber fang ruhig mit ARM Prozessoren an. Letztendlich programmiert man 
die Dinger sowieso in C, und da ists fast egal obs nun ein ARM7 oder 
ARM9 ist. Erst mit den DSP Erweiterungen der höheren Produktreihen (SIMD 
Erweiterung ab ARM11 und NEON ab Cortex A) ists wohl notwendig die tiefe 
Architektur und Assembler Programmierung zu durchschauen. Und wie schon 
erwähnt wurde, nahezu jeder Halbleiterhersteller hat Chips mit ARM Core 
im Angebot. Es ist also schon sinnvoll, diese mal kennenzulernen.

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

Bewertung
0 lesenswert
nicht lesenswert
Matthias wrote:

> da ists fast egal obs nun ein ARM7 oder ARM9 ist.

Nicht ganz. Grad bei Controllern nicht. Die diversen Speicher- und 
I/O-Busse, Puffer und Caches in ARM9 haben Nebenwirkungen, was die 
Datenkohärenz angeht. Also wenn man über verschiedene Busse auf die 
gleichen Daten zugreift. Noch schöner wirds wenn DMA dazukommt. ARM7 ist 
da erheblich übersichtlicher.

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also um noch etwas zu ergänzen ich programmieren den ARM7 genauer 
ARM7TDMI nur in assembler. Und arbeite auch mit CISC CPUs und muss 
feststellen, das der ARM7 gar nicht so über ist, aber er hat keinen 
brauchbaren Adressbus nach drausen, weil zumindest meinen Derivaten eine 
BUS-Arbitration Logik fehlt.
In Komplexen designs somit nie rein kommt.
Aber ich bin sehr überrascht über den speed den er zumindest in 
Assembler bringt. Und noch etwas sehr positives ist die JTAG 
Schnittstelle.

Gruß Sascha

oder gibts ein Derivat mit BUS-Arbitration ???

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

Bewertung
0 lesenswert
nicht lesenswert
Sowas findest du im Museum. Systeme mit komplexen Bussen sind nicht 
(mehr) der Einsatzbereich von ARM7. Jedenfalls nicht ausserhalb vom 
Chip, drinnen gibt das natürlich.

Autor: Matthias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme mal an du suchst sowas:
http://www.cirrus.com/en/products/pro/techs/T7.html

Der verwendete ARM720 hat im Gegensatz zum ARM7TDMI eine MMU und ist zum 
Betrieb mit externem Flash und Ram gedacht.

Ob sich das heute noch lohnt ist ne andere Frage, da kann man evtl 
gleich ARM9 nehmen.

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sascha:
Also um noch etwas zu ergänzen ich programmieren den ARM7 genauer
ARM7TDMI nur in assembler

==> Masochist

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Ralph
dann schreib deine FFT halt in C und deine Floating Point halt auch.
Irgendjemand muss es doch auch für einen Compiler tun oder ?
Grüssle Sascha

Autor: Ralph (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da kaum ein ARM7 µC einen FPU hat( ich kenne auf Anhieb keine, aber mit 
viel suchen findet sich vielleicht etwas) ist es Unsinn mit 
FloatingPoint zu rechnen.
Verwende Intergerarithmetik ==> schneller, einfacher und ebenfalls sehr 
hohe Genauigkeit möglich.
Die FloatingPoint zeigt dir eine Genauigkeit an die nicht vorhanden ist.

Nurmal so nebenbei. Da keine FPU vorhanden ist, setzt der Compiler die 
FloatingPointberechnung in Intergerarithmetik um, also kannst du die 
Intergerarithmetik auch direkt selbst verwenden.

Und außerdem, egal wie gut du die FFT und die FloatingPoint in Assembler 
programmierst,der Compiler kann es zu 99,99% besser und schneller.

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Ralph,
ich will ja nicht unhöflich sein, aber glaubst du das etwa selber was du 
hier ablässt ? oder ist dir langweilig ?
Eine Floating Point ist je nach Zahlengröße und bezüglich der 
Genauigkeit schneller als eine Integer Rechnung.
Eine Floating Point mit 32 Bit bestes Beispiel nach IEEE754 hat einen 
Exponent mit 8 bit und eine Mantisse mit 23 Bit + ein Vorzeichen.
also reicht das Zahlenspektrum von jenseitz... sihe Wikipedia IEEE754.
Und dann berechne mal LOG oder EXP mit Integer !!!
Mit welchem polynom soll das in Integer gehen ?
Oder mache ich seit 10 Jahren etwas falsch ?

Ich bin auch nicht 100% aber ich habe z.B. eine FP32 für Microchip PIC 
geschrieben, M16C,R8C,8051,AVR usw. Wissenschaftlich arbeitende Geräte 
brauchen das halt für ihre komplexen berechnungen. Oder rechne mal in 
Integer 1/x !?!


Natürlich berechne ich nicht eine FFT in FP, klar sonst wirds Nacht.


Gruß Sascha

Autor: Patrick (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was für gratis Assembler-Entwicklungswerkzeuge (simulator und co.) 
benutzt man für den ARM7? Sowas schönes wie AVR-Studio scheints nicht 
für ARM-Assembler zu geben und ohne Simulator ists mühsam Fehler zu 
suchen. C möchte ich nicht anfangen, dann könnte ich von der 
Geschwindigkeit auch gleich beim AVR bleiben. Ausserdem macht mir asm 
mehr Spass, weil man das die Algorithmen kennenlernt.

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Patrick,
jetzt wird der Thread zwar etwas zwangsentfremdet aber ich hoffe es wird 
geduldet.

Also ich arbeite was die ARMs angeht mit der 4K Limited Edition von IAR.
Denn für Assembler, was da ganz gut auch ohne C geht bin ich voll 
zufrieden.
Für Assembler gibt es auch anscheinend kein Limit ! (so Aussage von IAR)
Ich habe mir ein Eval Board von Philips gekauft, damit ich etwas 
preiswerter in den Besitz eines J-Link Debuggers komme. (wird von 
Philips sponsored...LPC-P2378-STK)
Mann kann die Software auch bei IAR downloaden und muss sich halt 
registrieren lassen (Kostet nichts). Ich arbeite mit der IDE Version 
V4.42.
Ich finde den Debugger bei IAR sehr gut und sehr schnell.
Habe auch ein Wiggler Interface gebaut und getestet geht auch ganz gut.
Womit ich den Wiggler nicht unbedingt empfehlen will.
Mann muss nur aufpassen beim Einbinden der Flasherroutine beim Debuggen 
das man das extra File vom Linker erstellen lässt, was dann der 
Flashloader zum flashen braucht.(ist oft ein Blöder Fehler....)
Und mit dem IAR Produkt geht ARM7,ARM9 und Cortex-M3.

Zukunftsaussichten des ARMs:
Ich denke das die Zukunft noch weit offen steht sogar für die, die in 
Assembler programmieren, den der ARM9 ist nicht viel anders. Und das 
Potential geht da erst richtig los.

Und wer in Assembler ran geht kann besser abschätzen, ob man im ARM oder 
Thumb Modus mehr performance herausholt.

Ich bin bis jetzt der Meinung (was sich bis jetzt bei mir gezeigt hat) 
das der ARM Modus ca. 1.3 fach schneller ist als der Thumb Mode.
Da die Befehle sehr viel gleichzeitig tun können, wenn man richtig 
Programmiert. Der Thumb Mode spart nur Speicher und Dank der C 
Programmierer haben die Bausteine heute so viel Flash das es eigentlich 
schon paradiesisch ist.

Ich wollte eigentlich nie mit ARM anfangen.... bereue es aber keinen 
Tag.

Gruß Sascha

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Sascha,

nur zur Info, Segger hat kuerzlich ein Press Release veroeffentlicht. Es 
gibt fuer Studenten (Nachweiss), das J-Link ohne Einschraenkungen sogar 
mit GDB server, fuer 98 Euro.
http://www.embedded-control-europe.com/prodnews?ca...

Info ueber GDB Server gibts hier:
http://www.segger.com/jlink_gdb.html

Froehliche Weihnachten, Robert

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ aufpasser

Zitat Sascha "Ich habe mir ein Eval Board von Philips gekauft, damit ich 
etwas preiswerter in den Besitz eines J-Link Debuggers komme. "

Meine Antwort darauf und ein sachbezuglicher Informationsinhalt 
definitiv gegeben.

Informationsinhalt Deines Posts ist wahrscheinlich nur mir entgangen ;-)

Robert

Autor: Sascha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Robert,
 Danke für die Information, ich bin nur leider kein Student mehr, aber 
ich habe damals auch bei Segger angerufen und kam irgendwie nicht 
weiter. Auch bei IAR wars mit dem Support nicht gerade einfach. Ich weis 
das Segger der Erzeuger ist. Kontakt hatte ich mal vor 2 Jahren auf 
einer Embedded Messe.
Und mir gefällt noch immer die genial Flasher Software die über JTAG 
sehr viele CPUs flashen kann. Vieleicht geht bald mein Project in Serie 
und wir können uns das Tool leisten ?

Oder reicht der Studentenausweis von irgendjemand ? (der das Ding für 
mich bestellt) ?

Nein keine Frage Gute Tools sind schon ihr Geld wert, wenn man bedängt 
mit was für einem misst man sich sonst rumplagt.

Frage: funktionieren die Security Bits beim Flashen der Analog Device 
ADuC702x Typen ? Habe da etwas gehört vom Hersteller, was aber 
vermutlich nur den seriellen (RS232) Download betrifft.

Autor: gerhard (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@sascha:
wenn du eine günstigere lösung als den j-link suchst dann schau dir mal 
die jtag tools von olimex an (gibts auch hier im shop), sind in 
verbindng mit openocd eine güsntige und auch leistungsfähige 
alternative.

seit v5.xx unterstützt auch die iar workbench nun gdb server und damit 
openocd.

gruss
gerhard

Autor: Robert Teufel (robertteufel)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sascha wrote:
> Oder reicht der Studentenausweis von irgendjemand ? (der das Ding für
> mich bestellt) ?

Du erwartest darauf nicht wirklich eine Antwort von mir oder?

> Frage: funktionieren die Security Bits beim Flashen der Analog Device
> ADuC702x Typen ? Habe da etwas gehört vom Hersteller, was aber
> vermutlich nur den seriellen (RS232) Download betrifft.

Bin mir nicht 100% sicher, ich denke aber ja, denn Segger hat ja 
schliesslich auch mIDAS-Link, sozusagen das SAM-ICE fuer die ADuC702x 
Typen gemacht.

Unsere Produktspezialisten beantworten solche Fragen auch unter 
www.segger2.com , dem neuen Support forum fuer Segger Produkte.

Gruss, Robert

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.