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
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.
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...
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
@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...
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.
@ 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
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.
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.
> 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.
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?
Gibt es von den SAM7 eigentlich neue Revisionen (vlt in nahegelegener Zukunft)?
>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/AT91SAM7L_Technical_Overview.files/frame.htm 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.
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.
@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
Wo wir bei Automotive und ARM7 sind: Toshiba hat eine Cortex-M3-Lizenz erworben und wird sein Mikrocontroller-Portfolio in dieser Richtung damit ausbauen.
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.
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.
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 ???
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.
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.
@Sascha: Also um noch etwas zu ergänzen ich programmieren den ARM7 genauer ARM7TDMI nur in assembler ==> Masochist
@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
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.
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
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.
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
@ 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?cat=1&pid=1110 Info ueber GDB Server gibts hier: http://www.segger.com/jlink_gdb.html Froehliche Weihnachten, Robert
@ 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
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.
@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
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.