Welches ARM-Derivat für die nächsten 10Jahre

Ingolf Pohl schrieb:

Sowas riecht nach STM32, z.B. die F103 Derivate (Cortex-M3) - klasse Ausstattung, unglaublich preiswert.

Das kann m.E. wohl niemand vorhersagen... Aber diese Controller sind so

ARM7 ist alt - und verletzt definitiv Deine Forderung nach einem ordentlichen Interruptsystem, der VIC vom ARM7 ist eine Katastrophe.

Leistung preiswerter).

Tilmann

Am 21.05.2015 um 17:29 schrieb Tilmann Reh:

inneren Ohr wieder Ex-Kollegen fluchen...

Kannst Du 'ne einfache Entwicklungsumgebung unter Linux empfehlen? Ich kann durchaus mit Editor oder Geany leben. Welchen JTAG-Adapter nimmt

substituieren...

Am 21.05.2015 um 16:12 schrieb Ingolf Pohl:

...

gcc kompilieren, mit openocd flashen und mit gdb debuggen. Spansion (ex Fujitsu) FM3 geht angeblich nur mit bloatigem Eclipse

Aus gegebenem Anlass noch der Rant:

Auch das Abschalten de "Auf-diesem-Pin-ist-was-spezialles"-Bits hilft oft nicht.

Bustakten oder dem JTAG oder dem SWD Interface die Sonderkonfiguration "Mach-den-Port-kaputt" nach Reset eingeschaltet ist.

weil's sonst "Usage faults" habelt...

Ich bin aber selbst schuld: Das Eine ist auf Seite 37 der AN-XYZ und das Andere auf Seite 567 des "Peripheral-Manual-Oder-So" in je einer

Im Ernst: Die ARMs hochzufahren ist eine ganze Ecke aufwendiger als bei einem popeligen AVR. Da helfen dann IDEs, mit denen man sich die Konfiguration zusammenklicken kann, schon mal weiter.

Falk

Ingolf Pohl schrieb:

Halb so wild, die Vielfalt hat ein fast orthogonales System. Dadurch

Man liest ja immer viel von Eclipse, aber die war mir bei meinen Tests

haben.

Projekte auch die Keil-IDE nehmen (Vorteil: schnellerer Einstieg), die

Einfacher als JTAG: SWD - und ST-Link als Adapter. Linux? Keine Ahnung...

Wie Falk schon schrub, ist ARM eine ganz andere Welt als die kleinen

System mit Startup-Code, Initialisierung, Linkerscript etc.

Danach aber ist das sehr angenehm und komfortabel, und die Teile sind

deren Vernetzung ist klasse, da kann man schon recht komplexe Dinge komplett im Hintergrund (ohne CPU) ablaufen lassen.

Viel Erfolg, Tilmann

Am 21.05.2015 um 22:55 schrieb Tilmann Reh:

Na ja, die Rechner sind schneller geworden...

(Intel Atom Singlecore) startete. Kein Geschwindigkeitsrausch, aber auch nicht unbrauchbar langsam.

Hanno

Wie Tilmann schon schrieb, heutzutage ist eher Cortex-M4 angesagt.

Ich bin kein uC-Experte, aber ich habe derzeit ein uC gesteuertes Projekt in Arbeit und dabei den ADSP-CM408F von Analog Devicves gewaehlt. Die sind immer noch am rumruehren in den Toepfen und das Dingen ist schon so lange im Pre-Release oder wie immer das heisst, dass mir langsam unwohl wird. Doch wenn was rauskommt, bleiben Sachen bei Analog Devices meist fast ewig in Produktion. War bei mir einer der Gruende fuer die Entscheidung.

Dieser uC muesste Deine Wuensche erfuellen. BGA mag ich ebenfalls nicht, zu anfaellig. Wir nehmen Flat Pack. Dann haben wir noch EZ Kits dafuer gekauft, wo man mit fast fertiger Hardware probieren kann, bevor unser Board fertig ist.

Ansonsten hat unser SW-Guru gesagt, dass er sich weitgehend an die CMSIS Libraries haelt, womit ein Umstieg auf einen anderen M4 ohne grosse Klimmzuege laufen soll. Wir machen das auch ohne RTOS.

Die Entwicklungsumgebung von IAR war teuer, IIRC mit allem PiPaPo so bei $6000. Etwas enttaeuschend war dann, dass hoehere Weihen wie USB nur mit irgendeinem sehr teuren RTOS von Micrium oder passender Lizenz gehen. Zum Glueck koennen wir das umschiffen, indem wir eine serielle Schnittstelle mit Bleifuss betreiben.

Joerg schrieb:

Ich schrieb "Cortex-M", je nach Anforderung kann das dann M0(+), M3, M4

gibt es sogar ANs mit konkreten Hinweisen).

bisher noch nie benutzt haben (und auch nicht vorhaben, das zu tun).

Details im Internet zusammensuchen und steckt dann etwas mehr Zeit rein,

Wir nutzen USB mit M3 Controllern (STM und NXP) - ohne teures RTOS und

Herstellern eine PID.

Tilmann

Am 21.05.2015 um 22:55 schrieb Tilmann Reh:

nach deinen Vorgaben.

Erleichtert den Einstieg ungemein, auch wenn die Funktionen teilweise

Tilmann Reh :

Ist die Peripherie denn zwischen der verschiedenen Herstellern aucg gleich, ich denke bei nem Wechsel des Chips musste da deine ganze Peripherie anpassen?

Mhh warum nicht ein fertiges RTOS nehmen? Muss ja nicht Linux sein. M.

reparieren.

Matthias Weingart schrieb:

unterschiedlich - ich bezog mich auf STM32, dort ist die *gesamte*

Je nach Anwendung: Kanonen auf Spatzen, Wasserkopf.

Am Ende braucht man einen 150 MHz M4, damit das RTOS schnell genug ist,

ans Laufen gebracht werden.

Tilmann

Das ist schon wahr, doch wir moechten flexibel bleiben. Falls AD wider Erwarten die Markteinfuehrung in den Sand setzt.

Schon, aber Zeit ist auch Geld und die Firma muss sowohl meine als auch die Stunden des SW-Consultants bezahlen. Er war mit IAR bereits vertraut, was nochmals Stunden spart. Ich brauchte auch einen lokalen SW-Spezi und dieser ist sogar in gut 30 Minuten mit dem Mountain Bike erreichbar.

Bei ST war mir bisher der Support zu schlecht. Ausser wenn ich fuer grosse Firmen arbeite, dann ist er gut. NXP habe ich auch mit geliebaeugelt, aber die von AD haben bessere S-Port Anbindung. Auch der Support ist besser, da inlaendisch.

Am 22.05.2015 um 08:58 schrieb Michael S:

(direkter Registerzugriff). Mit einem STM32F4 mit 168 MHz kann man da

Rolf

Brot-und-Butter-Version zu sein, die gibt es sogar bei Reichelt. Ich habe

meisten Sonderfunktionen nur 1-2 feste Pins zur Wahl haben.

man direkt, wo es knallt. Das ist Java, wenn man die fertige Installation

gebaut - da die verschiedenen Varianten nahezu pinkompatibel sind (es gibt migration guides), sollte da jetzt STM32F0, STM32F1 und STM32F4 'draufpassen, wenn ich nichts verbasselt habe.

Bei NXP/Freescale (die haben auch beide nette Teile, Freescale finde *ich*

Evalboards abgeschreckt - das tut nur mit Code Red, und das wiederum nicht auf meinem Debian.

Auf keinen Fall - der Zug ist abgefahren, die werden sicher noch einige Zeit gebaut, solange es Kunden gibt, die die einsetzen, aber das Ende ist am

cu Michael

Form eines STM32-Nucleo-Boards - die sind spottbillig und haben einen ST-Link-Debugger 'drauf, der mit OpenOCD wunderbar zusammenarbeitet und mit dem man auch eigene Boards debuggen kann. Einziger Knackpunkt: unbedingt ST-Link "V2", "V1" ist unter Linux hakelig, aber IIRC gab es bei den Nucleo-Boards nur V2:

(251609973875) - da ist ein STM32F101 mit Original-ST-Firmware 'drin, und

Firmware.

Wenn Du was universelles willst:

Ach so: mit den ST-Links kann man auch nicht-ST-Chips ansprechen, ich

Crosscompiler gibt es bei

Alternativ, wenn Du eine komplett integrierte IDE willst:

Das Gnu ARM Eclipse-Projekt hat auch Installationsanleitungen und Binaries

habe mich so durchgebissen, libopencm3 steht noch auf der Todo-Liste.

ST bewirbt seit kurzem

empfunden - ein nacktes Eclipse auf dem gleichen Rechner war deutlich besser.

auf eigene Versionen von Startupcode, Linkerscript & Co abgestimmt sind und dort leichte Anpassungen brauchen. Ich benutze inzwischen die Linkerscripte

• startup-Code, die beim cross-gcc dabei sind, und passe den Rest entsprechend an.

cu Michael

Freescale hat konkrete Angaben 10 / 15 Jahre:

sie dann an wen liefern. Distributor ( abgesehen von Rochester )

Die Controller sind nach 10 Jahren relativ teuer weil Preis von ehedem.

Anno end-of-life "in Stickstoff einlagern" gabs auch noch als Variante. Hat man aber Beschaffungs- und Lagerkosten.

Nur wer wegen Zulassungen nicht neu entwickeln kann klebt an alten Controllern.

MfG JRD

Oder Leute, die 2nd Source und mehrere Jahrzehnte Produktionsdauer brauchen. Stichwort 8051.

Hallo Joerg,

Du schriebst am Sat, 23 May 2015 11:28:11 -0700:

Der 89C51, den ich Anfang der 90er in ein Medizingeraet setzte, wird heute noch produziert und ein Ende ist nicht abzusehen. Das Medizingeraet wird ebenfalls noch produziert.

Eben genau der Fall Zulassungen. Bei Freescale ist Medizintechnik wie automotive ( Ersatzteile 12 Jahre nach Produktionsende )

MfG JRD