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.
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.
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.
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.
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
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:
formatting link
(251609973875) - da ist ein STM32F101 mit Original-ST-Firmware 'drin, und
Firmware.
Wenn Du was universelles willst:
formatting link
- es gibt ein CPLD-Binary
Ach so: mit den ST-Links kann man auch nicht-ST-Chips ansprechen, ich
Crosscompiler gibt es bei
formatting link
- dazu dann ein Makefile, Editor nach Wahl, und openocd zum Flashen und bei Bedarf gdb zum Debuggen.
Alternativ, wenn Du eine komplett integrierte IDE willst:
formatting link
- das ist nett und ich benutze das wegen der Debugger-Integration, allerdings habe ich entgegen der Installationsanleitung die Binaries (Compier + OpenOCD) im Pfad und benutze ein Makefile anstatt der Eclipse-Buildumgebung, damit bin ich flexibler und
Das Gnu ARM Eclipse-Projekt hat auch Installationsanleitungen und Binaries
formatting link
habe mich so durchgebissen, libopencm3 steht noch auf der Todo-Liste.
ST bewirbt seit kurzem
formatting link
als freie IDE - keine
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.
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.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.