Hi, ich möchte in die ARM Welt einsteigen und hätte gern eine Empfehlung für einen einfachen, kleinen und gut erhältlichen ARM. Ich meine jetzt nicht sowas wie einen Raspi Pi sondern eher ein Arduino Die komplette Toolchain soll unter Linux laufen, auch die Programmierhardware. Welchen Controller würdet ihr mir empfehlen? Gruß Markus
Markus B. schrieb: > Ich meine jetzt nicht > sowas wie einen Raspi Pi sondern eher ein Arduino Irgendein STM32 Board vielleicht und dann https://elinux.org/STM32
:
Bearbeitet durch User
Thomas W. schrieb: > und dann https://elinux.org/STM32 Ich hab mich vielleicht etwas ungenau ausgedrückt. Ich meinte mit Toolchain für Linux einen Compiler, Software zum Programmieren, eventuell Debugger und sowas, kein Linux für den Controller selbst
Im Artikel STM32 ist alles erklärt. Da sind auch IDEs und Toolchains aufgelistet. Das ganze wurde doch schon 1000x durchgekaut, wer das schon wieder fragt war zu faul zum suchen.
Oder man ist von der Masse an Informationen einfach überfordert und will die Parameter erstmal eingrenzen. Es gibt ja nicht nur STM32 sondern auch LPC oder SAM. Ich will erstmal ganz klein anfangen mit einem Cortex M0 anfangen, eventuell mit einem SSOP20 oder LQFP32 Gehäuse. Und während ich das schreibe fällt mir ein, dass ich sogar seit ein paar Jahren ein paar Teensy LC Boards hier im Haus liegen habe. An die hab ich nicht mehr gedacht. Damit werde ich wohl anfangen.
> Ich hab mich vielleicht etwas ungenau ausgedrückt. Ich meinte mit > Toolchain für Linux einen Compiler, Software zum Programmieren, > eventuell Debugger und sowas, kein Linux für den Controller selbst Der Compiler heisst gcc. :-) Kannst du vielleicht irgendwo in deinem Repository fertig runterladen, kannst du dir aber auch einfach selber uebersetzen. Keine grosse Sache. Fuer den gdb gilt dasselbe. Ausserdem wuerde ich dir empfehlen dir einen j-link zu kaufen. Laeuft unter Linux vollkommen problemlos und tiefenentspannt. Als Entwicklungsumgebung ist alles von vi ueber emacs mit einem umweg ueber eclipse bis zu qt-creator verwendbar. Ist halt eine Frage des persoenlichen Geschmacks. Olaf
Der J-Link ist ein guter Tipp, danke Edit: uhh, teuer.
:
Bearbeitet durch User
> Edit: uhh, teuer.
Die EDU-Version gibt es fuer 50-60Euro. Das finde ich nicht teuer.
Ausserdem gibt es wohl auch noch eine Platinenversion die noch
preiswerter ist aber dafuer langsamer.
Olaf
PlatformIO und VSCode. Sowas wie ein TrinketM0 ist auch erheblich umfangreich für den Einstieg. Erst recht wenn man sich da durch die Funktions-Einheiten arbeiten will. Wobei ich das mit der "ARM Welt" inzwischen etwas nüchterner sehe. Beim Spielen mit dem Longan-Nano und seinem RISC-V habe ich schnell gemerkt, dass der Core als Anwender so ziemlich das letzte ist was einen interessiert. Die Peripherie und die Unterstützung dafür sind viel interessanter. Hier wird zwar oft, gerne und laut STM32 geschrien, aber weder gibt es den STM32, noch sind die hunderte Versionen allesamt so gut wie vollmundig angepriesen und am Ende muss man sehr genau hin schauen welcher Typ denn nun zur Anwendung passt. Ich kann die STM32 insgesamt nicht gebrauchen, weil nicht einer von denen Automotive qualifiziert zu bekommen wäre. Nach einem sehr kurzen Blick auf die HAL war ich da bei den STM32F4xx angenehm überrascht, nachdem mich das bei den STM32F1xx eher abgestossen hat. Die STM32G441 finde ich zum Beispiel sehr interessant, nur habe ich gerade festgestellt, dass da zwar offenbar ein Bosch M_CAN für den CAN-FD verbaut ist, allerdings in einer heftig kastrierten Version. Zwei RX-FIFOs mit je nur 3 Botschaften Tiefe und nur 28 Filter für 11-Bit und 8 Filter für 29 Bit, dazu nur drei TX-Buffer - nee, dann lieber doch nicht. Und so muss man schauen was man überhaupt braucht, STM32 ist nicht die Lösung wie es hier gerne lautstark propagiert wird weil ST gerne mit Eval-Boards um sich wirft.
Der GCC ARM Embedded ist eine GCC-basierte Toolchain für Cortex-M, die auch unter Linux geht. Hat gegenüber den bei den Distros mitgelieferten Paketen den Vorteil aktueller zu sein und ist praktisch die "Einheits-Version" welche von den meisten IDEs genutzt wird und mit der die meisten Projekte funktionieren; die Distributions-Versionen sind da teilweise abweichend: https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads IDEs wie das Atollic Studio für STM32 liefern das sowieso mit. Cortex-M3 sind übrigens einfacher zu programmieren als Cortex-M0, da aktueller und leistungsfähiger. Falls du dich für Assembler interessierst: ARM-ASM-Tutorial Rudolph R. schrieb: > STM32 ist nicht die Lösung wie es hier gerne lautstark propagiert wird > weil ST gerne mit Eval-Boards um sich wirft. Das nicht, aber weil es viele Hobby Anwender nutzen gibt es sehr viele Einsteiger Informationen dazu. Wenn man sich damit in das ganze ARM Ökosystem eingearbeitet hat, ist es einfach auf beliebige andere ARM Prozessoren umzusteigen wenn man speziellere Bedürfnisse hat, wie eben Automotive.
> Das nicht, aber weil es viele Hobby Anwender nutzen gibt es sehr viele > Einsteiger Informationen dazu. Ich persoenlich koennte euch ja die Silabs-Gecko empfehlen. Aber dann bekommen hier wieder alle nervoese Pickel auf der Unterlippe weil sie 0.5er DFN mit exposed Pad auf ihre Testboards loeten muessen. :-D Ich wuerde mal sagen das es vollkommen egal ist fuer welchen Typ man sich entscheidet. Aus der Sicht von Compiler, Jlink, gdb ist das vollkommen egal. Die Unterschiede liegen eher in der Peripherie und der Qualitaet der Dokumentation. Die STM32 sind nur deshalb so beliebt weil die Firma jeden mit Demoboards bewirft der irgendwo im Wald steht und nach Entwickler aussieht. Bei anderen Firmen musst du mindestens mal 3min mit dem FAE reden. .-) Olaf
Olaf schrieb: > Die STM32 sind nur deshalb so beliebt weil die Firma jeden mit > Demoboards bewirft der irgendwo im Wald steht und nach Entwickler > aussieht. Bei anderen Firmen musst du mindestens mal 3min mit dem FAE > reden. .-) Für Privatpersonen durchaus ein Argument. Warum soll ich Leute überzeugen mir was zu verkaufen, wenn die Konkurrenz bei eBay zu finden ist... Olaf schrieb: > Die Unterschiede liegen eher in der Peripherie und der Qualitaet der > Dokumentation. Genau, und für STM32 gibt's einfach Unmengen an Tutorials. In der Fahrschule bin ich auch mit einem hässlichen übermotorisierten SUV rumgefahren. So ein Auto würde ich mir nie kaufen, aber zum lernen war's gut.
> Genau, und für STM32 gibt's einfach Unmengen an Tutorials.
Ich fand aber gerade die Dokumentation von ST nicht so toll weil sich
immer alles auf mehrere PDFs verteilt und man jedesmal raetzeln muss ob
der aktuelle Controller jetzt noch timer5 und uart3 enthaelt oder eher
nicht. Da finde ich Renesas und auch Silabs viel besser wo man alles in
einem File hat. Und von dem unheimlich kranken gebastel das ST einem als
Softwarelibarie aufdraengt rede ich da noch gar nicht. Aber das muss
(und sollte) man ja auch nicht nutzen.
Olaf
Da wir ja hier gerade so nett plaudern... Hat hier schonmal jemand Erfahrungen mit einem PSOC4 unter Linux gemacht? Damit wollte ich mich auch schon immer mal beschaeftigen, allerdings ist mir noch nicht so ganz klar wie ich unter Linux ohne die Originalumgebung den analogen Kram im IC konfiguriere. (Hab ein CY8CKIT-049-42xx PSoC4 rumliegen) Olaf
Ich mag die Nucleos von STM, lassen sich einfach an den USB-Port stecken und mit den Toolchains und IDEs von ST kann man sofort loslegen. Man ist dann eben nicht der große Held weil man nicht 4 Wochen harte Arbeit gebraucht hat um das erste Programm auf den µc zu kriegen. Und niemand hindert dich daran auch damit zu frickeln und mit jeden Bit auf der Kiste schon mindestens 10 mal Geschlechtsverkehr gehabt zu haben.
Schau mal unter http://www2.keil.com/mdk5/selector siehe unten Dort gibt es für die sonst 5000,-€ teure IDE kostenlose Entwicklungsumgebungen für verschiedene Drivate. Mit einem Eval-Board wo auch der Debugger drauf ist, kann man schnell starten und hat kurzfristig Erfolgserlebnisse. ---------------------------------------------------------- https://platformio.org/ Platformio (Visual Studio Code + mbed + evt. STM32) ist eine 2. relativ einfache Möglichkeit. Allerdings auch nicht ganz unkompliziert, wenn man tiefer einsteigt und sehr volatile was Änderungen und Doku betrifft. Man kann dort schon viel Zeit investieren. Ingesamt erfordert es aber ein erhebliches Investment in Zeit und Wissensaufbau. ----------------------------------------------------------------- MDK for Holtek Cortex-M0+: The MDK for Holtek Cortex-M0+ is a license paid by Holtek. It is free-to-use for software developers working with Holtek devices based on the Arm Cortex-M0+ cores. MDK for Nuvoton Cortex-M0/M23: The MDK for Nuvoton Cortex-M0/M23 is a license paid by Nuvoton. It is free-to-use for software developers working with Nuvoton devices based on the Arm Cortex-M0 and Arm Cortex-M23 cores. MDK for STMicroelectronics STM32F0, STM32G0, and STM32L0: The MDK for STMicroelectonics STM32F0, STM32G0, and STM32L0 is a license paid by STMicroelectronics. It is free-to-use for software developers working with STM32 devices based on the Arm Cortex-M0 and Arm Cortex-M0+ cores
> Mit einem Eval-Board wo auch der Debugger drauf ist, kann > man schnell starten und hat kurzfristig Erfolgserlebnisse. Hast du das subject gelesen? Olaf
Markus B. schrieb: > Ich will erstmal ganz klein anfangen mit einem Cortex M0 anfangen http://stefanfrings.de/stm32/stm32l0.html > Der J-Link ist ein guter Tipp, danke....Edit: uhh, teuer. Schau Dir meine Empfehlungen auf der Seite an. Die sind (ab 2,50€) nicht teuer.
Markus B. schrieb: > ich möchte in die ARM Welt einsteigen und hätte gern eine Empfehlung für > einen einfachen, kleinen und gut erhältlichen ARM. Was verstehst du unter "einsteigen"? Dieses Wort ist eigentlich extrem unklar, wird aber von vielen Leuten gebraucht, wenn sie eine IDE und eine Toolchain und ein Hersteller-Lib suchen, um ein wenig mit dem Programmieren in C und Debuggen per SWD/JTAG anfangen wollen. Also schreib erstmal, was genau du denn anzielst. Ich kann ja verstehen, daß du für den Anfang nicht viel Geld ausgeben willst und daß du auch nicht einen zu umfänglichen und damit unübersichtlichen Chip haben willst. Aber wie gesagt, der Anfang ist anders, denn der geht normalerweise von irgend einer Idee aus, also von etwas, das du basteln willst. Und daher frag dich zuvörderst, was du für deine Ideen an Peripherie des Controllers benötigst und suche dir eine Reihe dafür geeignet erscheinender µC aus. Das wäre der 1. Schritt von allem. Wenn du dafür noch keinerlei Idee hast, dann gebe ich dir hier mal eine: Stell dir vor, du machst eine Frontplatte für ein Gerät, wo du folgendes drauf hast: - ein monochromes (billiges) Grafik-LCD mit 128x64 Pixeln - einen Drehgeber - zwei Tipptasten - und alle anderen Controller-Anschlüsse sind an Pins oder Steckverbinder geführt. Der 2. Schritt wäre, daß du dir die Referenzmanuals deiner ausgesuchten µC anschaust. Zum allerersten, ob du mit diesem Manual klar kommst oder eher nicht und danach, wie das Einstellen der Pin-Funktionalität des µC aussieht, also wie man festlegt, ob so ein Pin nun Port oder UART oder Counter-Input oder sonstwas sein soll. Bei manchen geht das easy, bei anderen ist das eher eine Kröte, die man nur ungern schluckt. So. Und wenn du bis hierher durchgehalten hast, dann ist der Rest keine große Hürde mehr. W.S.
Ich hab viel mit AVR gemacht, also sind Mikrocontroller nicht neu für mich. Ein spezielles Projekt habe ich noch nicht. Ich will nur erstmal mit ein paar Pins wackeln und ein paar Daten zum PC senden können.
Markus B. schrieb: > Die komplette Toolchain soll unter Linux laufen, auch die > Programmierhardware. > > Welchen Controller würdet ihr mir empfehlen? Als Toolchain würde ich mbed-cli empfehlen, dann kannst du die ganze Palette von M0...H7 nutzen. Das mbed-cli ist Multi Kulti und läuft unter Windows, Linux und MacOS. Zum Einstieg: https://github.com/ARMmbed/mbed-os-example-blinky Vorletzte Woche habe ich das mal zum Spaß auf einem RPi4 installiert, läuft auch. Obwohl, etwas unter Linux zu installieren ist nicht wirklich Spaß... Ich musste mehrmals Phython Module von Hand installieren. Ein requirement sind die ARM cmsis packs, da fand jemand es toll die in Rust zu schreiben. Für den RPi habe ich die nicht als binary gefunden und selbst nach einem 'sudo apt-get install rust*' und stundenlangen compilierorgien gabs noch Fehler. Aber diese packs waren nicht wirklich nötig und 'mbed compile' funktionierte. Mit dem aktuellen mbed-os kann man auch wieder die 'kleinen' µC benutzen (für meine LPC824 kompiliert es auch wieder), das eingebaute RTX RTOS ist optional und kann einfach (ok, das config system ist nicht soooo einfach) abgeschaltet werden. Nach oben hin ist Support für die Standardschnittstellen, Ethernet, USB, Filesystem(e), Eventqueues, viel Funk Gedöns uvm drin.
Johannes S. schrieb: > Als Toolchain würde ich mbed-cli empfehlen, dann kannst du die ganze > Palette von M0...H7 nutzen. Der GCC und die binutils unterstützen natürlich die ganze Palette. Je mehr "Toolchain" drum herum gepackt wird, umso eingeschränkter wird die Palette? > Obwohl, etwas unter Linux zu installieren ist nicht wirklich Spaß... Naja, kommt stark drauf an, was und aus welcher Quelle man installiert. Unter Debian ist ein Original-Debian-Paket vollkommen stressfrei, jede bessere Distributionen sollte das genauso gut können. Besonders interessant ist archlinux. Deren Pakete sind sehr aktuell, auch in 32-Bit verfügbar und das Beste: man kann die arm-none-eabi-Pakete einfach in irgendein Verzeichnis (z.B. /opt/arch/) entpacken und loslegen, ohne Installation, auf jedem Linux (na gut, nur mit Debian getestet). Also, mir scheint, manche Leute machen sich das Leben freiwillig schwer.
'toolchain' ist für mbed-cli natürlich nicht die richtige Bezeichnung, hätte ich gleich in Anführungszeichen setzen sollen. Buildsystem trifft es eher. Quelle in ein Verzeichnis packen, 'mbed compile' und fertig, kein Stress mit makefiles. archlinux: läuft sowas auch auf dem RPi? Ja, wenn Pakete binär für die Zielplattform vorhanden sind ist apt auch bequem. Aber wehe wenn nicht. Windows: Installer starten, fertig.
Ich habe mir gerade Manjaro KDE auf einem Odroid N2 installiert. arm-none-eabi-gcc gibt es da direkt aus den Paketquellen. Mal schauen, ob ich von da auch ein Programm auf den Teensy LC bekomme Danke schonmal für die Hilfe
> Naja, kommt stark drauf an, was und aus welcher Quelle man installiert. > Unter Debian ist ein Original-Debian-Paket vollkommen stressfrei, jede > bessere Distributionen sollte das genauso gut können. Das ist sicherlich so. Allerdings kommen hier ja Leute zusammen die einen Mikrocontroller <blink> programmieren <blink off> wollen. Da sollte man doch eine gewisse Minimalkompetenz voraussetzen koennen. Damit ist es auch kein Problem sich den gcc, die libs und den gdb passend zur Zielplattform selber zu uebersetzen. Ich hab das z.b gemacht weil ich ein halbes dutzend unterschiedlicher Zielplattformen mit demselben Compiler bedienen moechte. (SH(A),ARM,M16C, R8C,68k) Man muss es nicht, aber man kann es und es ist kein Problem. Probleme treten erst auf wenn man die schoenen Schickimickittools wie z.B Eclipse und aehnliches nutzen will die darauf aufbauen. Die sind naemlich neue und wurden von Leuten geschaffen die sich im Informatikstudium gelangweilt haben. Ab da braucht es ploetzlich fuer jedes kleinste Tool eine eigene Programmiersprache, am besten noch in einer speziellen Version, irgendein make-derivat oder was ganz anderes, wenigstens drei Scriptsprachen und lustige Pakete die bei der Installation aus dem Netz runtergeladen werden wollen am besten noch jede Woche auf einem anderen Versionsstand. Ab da kann es dann kacke werden wenn man Linux nicht auf Gurulevel drauf hat. Aber keine Angst. Fuer Dummen oder Verzweifelten unter euch, man drueckt das natuerlich netter aus, gibt es jetzt Linux als monolitischen schreibgeschuetzten rundum Sorglosklotz. :-) (siehe aktuelle c't von morgen) Olaf
Johannes S. schrieb: > kein Stress mit makefiles Was genau ist jetzt stressig an makefiles? Johannes S. schrieb: > Ja, wenn Pakete binär für die > Zielplattform vorhanden sind ist apt auch bequem. Aber wehe wenn nicht. Wenn es kein Binärpaket ist, dann ist es wohl ein Quellpaket. Und wo ist dann das Problem? Wäre es eventuell möglich, dass Deine Probleme mit Linux Software-Installationen daher rühren, dass Du versuchst Software mit der Brechstange zu installieren statt mit den dafür vorgesehenen Tools?
Markus B. schrieb: > Ein spezielles Projekt habe ich noch nicht. Ich will nur erstmal mit ein > paar Pins wackeln und ein paar Daten zum PC senden können. Siehe http://stefanfrings.de/mikrocontroller_buch2/index.html
Johannes S. schrieb: > archlinux: läuft sowas auch auf dem RPi? Warum fragst du das, willst du auf dem Raspberry Pi die Entwickler-Tools laufen lassen? Dafür ist das Ding nicht gedacht, lass das mal besser. Arbeite lieber mit einem PC oder Laptop, meinetwegen auch in einer virtuellen Maschine oder dem Linux Subsystem von Microsoft.
Markus B. schrieb: > Die komplette Toolchain soll unter Linux laufen, auch die > Programmierhardware. gcc-arm-none-eabi gibt's in jeder größeren Distribution. Wenn einem die Version der Distribution nicht neu genug ist (warum eigentlich, wenn man noch nicht weiß, mit welchem Controller man überhaupt arbeiten will?), dann https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads Danach wird's dann konfessionsabhängig. Je nach Deiner Glaubensrichtung make, eclipse, libopencm3, ChibiOS, FreeRTOS, ... bis hin zu den Hersteller-abhängigen LPCXpresso, CubeMX,... (wobei das eine jeweils das andere nicht ausschließt, es sei denn man ist vernagelt.) Markus B. schrieb: > Welchen Controller würdet ihr mir empfehlen? Den, der zu Deiner Anwendung passt. Wenn's ums Geld geht, glaube ich nicht, dass man unter ein China STM32 Bluepill und einen STLink Clone drunter kommt. Oder auch ein STM32F0 Dev Board. Auch bei z.B. TME, Reichelt, usw. und kleinen Stückzahlen sehe ich eher STM32 (z.B. die G0) am unteren Preisrand.
Stefan ⛄ F. schrieb: > Warum fragst du das, willst du auf dem Raspberry Pi die Entwickler-Tools > laufen lassen? Dafür ist das Ding nicht gedacht, lass das mal besser. Na nicht aus Armut, einen Arbeits PC hAbe ich schon noch. Den RPi hatte ich gerade installiert und dachte das cli geht mal eben so. Einen GCC 8.x gibt es, aber eben nicht alle Python libs. Pip sucht binärfiles und kompiliert selber wenn nötig. Nur die Rust Quellen Arm-pack-Manager waren eine zu harte Nuss. WSL benutze ich auch, auf dem RPi wollte ich da einfach Sachen unter Linux testen. Der 4er ist sehr fix, auch mit VSCode als Editor/IDE kann man brauchbar arbeiten. Aber mir ging es nicht um Linux, sondern darum das Mbed eine sehr gute Alternative ist.
Thomas W. schrieb: > Irgendein STM32 Board Er sagte einfach, und da empfiehlst Du den ARM mit der verknotetsten verkorkstesten Peripherie auf diesem Planeten überhaupt!
Bernd K. schrieb: > da empfiehlst Du den ARM mit der verknotetsten > verkorkstesten Peripherie auf diesem Planeten überhaupt! Ich vermute, dem TO wäre mehr damit geholfen, wenn Du einen unverknoteten Controller mit völlig unverkorkster Toolchain und Linux-kompatibler Programmierhardware vorschlügest, der leicht und günstig in kleinen Stückzahlen aufzutreiben ist.
Np R. schrieb: > Bernd K. schrieb: >> da empfiehlst Du den ARM mit der verknotetsten >> verkorkstesten Peripherie auf diesem Planeten überhaupt! > > Ich vermute, dem TO wäre mehr damit geholfen, wenn Du einen > unverknoteten Controller mit völlig unverkorkster Toolchain und > Linux-kompatibler Programmierhardware vorschlügest, der leicht und > günstig in kleinen Stückzahlen aufzutreiben ist. Kinetis
Leute, ich steige gleich auf Risc-V um wenn ihr euch wegen ARM die Köppe einschlagt PS: günstig ist im übrigen nicht so entscheidend. Es ging mehr um einfach und leicht verfügbar. Mich haben nur die J-Link Preise von 250€ aufwärts überrascht
:
Bearbeitet durch User
Ja, beim RISC-V ist die Qual der Wahl erträglich :) STM32 funktionieren trotzdem und haben viel Peripherie, ich denke bei ADC, Grafik und Speichermenge sind die weit vorne. Wenn du lieber die Register selber ansprechen möchtest finde ich die LPC zB auch deutlich freundlicher. Aber hinter einer Abstraktionsschicht sind sie alle gleich. Bei den Herstellern findet man auch Übersichten zu den Familien.
Markus B. schrieb: > günstig ist im übrigen nicht so entscheidend. Es ging mehr um > einfach und leicht verfügbar. Mich haben nur die J-Link Preise von 250€ > aufwärts überrascht Dann schau mal da: https://github.com/blacksphere/blackmagic/wiki https://1bitsquared.de/products/black-magic-probe
Markus B. schrieb: > Mich haben nur die J-Link Preise von 250€ > aufwärts überrascht Tja. So isses eben. Da mußt du dich eben entscheiden: Entweder.. .. du hältst den Ball flach und wählst dir einen µC mit eingebautem Bootlader aus (LPCxxx und STM32Fxxx) und kannst dann mit einem popligen USB/Serial-Konverter für zwofuffzig deinen Chip programmieren, aber nicht per SWD debuggen oder.. .. du greifst in deine Haushaltskasse und kaufst einen J-Link in der Amateur-Ausführung (J-Link edu), die zwar baugleich ist zum normalen J-Link, aber weniger an Lizenzen enthält (da du nicht Krösus heißt, wirst du den 'richtigen' J-Link garantiert nicht kaufen) oder.. .. du greifst zu einem herstellerabhängigen Ding (ST-Link, Nu-Link, wie das Ding bei LPC Expresso heißt hab ich vergessen). Jede von all diesen Geschmacksrichtungen hat ihre Nachteile. Lies ein bissel in diesem Forum: Die Mehrzahl der Leute brauchen den Debugger häufiger als alles Andere, die programmieren halt mit dem Debugger und sind immer wieder überrascht, was der Compiler aus ihrer Quelle gemacht hat. Wenn das deiner Intention nahe kommt, dann kauf dir den J-link. Wenn du es dir hingegen zutraust, wenigstens einigermaßen fehlerfreien Code zu schreiben, ohne per Debugger nachschauen zu müssen UND das ReferenzManual lesen kannst, dann reicht auch die Bootladerversion als die billigste Variante, aber damit sind Freescale-µC (Kinetis) und Nuvoton und andere außen vor. W.S.
> Warum fragst du das, willst du auf dem Raspberry Pi die Entwickler-Tools > laufen lassen? Dafür ist das Ding nicht gedacht, lass das mal besser. Hm..warum eigentlich nicht. Ich weiss jetzt nicht ob es die Jlinksoftware fuer Arm gibt, wenn man vom Raspberry flashen kann sehe ich keinen Grund es nicht zutun. Was mich an den Raspberry fasziniert ist das man fuer ein Taschengeld eine Kiste bekommt die in jeder Beziehung besser ist als der teure Desktopcomputer mit dem ich damals mit Linux angefangen habe. Okay, auf Eclipse sollte man vermutlich aus Geschwindigkeitsgruenden verzichten. :) > .. du greifst in deine Haushaltskasse und kaufst einen J-Link in der > Amateur-Ausführung (J-Link edu), die zwar baugleich ist zum normalen > J-Link, aber weniger an Lizenzen enthält (da du nicht Krösus heißt, > wirst du den 'richtigen' J-Link garantiert nicht kaufen) Hast du schonmal mit dem J-Link edu unter Linux gearbeitet? So wie ich das sehe ist die einzige Einschraenkung das jflash nicht unterstuetzt wird und das kann man ersetzen. Ich hab zum Beispiel das hier in meinem Makefile stehen: download: JLinkExe -if SWD -speed 1000 -commanderscript ./burn.jlink more burn.jlink device EFM32GG230F1024 speed 4000 loadbin LCD_Tester.bin 0 r g exit 0 Damit reicht dann ein make download und der Controller ist gebrannt. DEbuggen mit gdb geht auch. Aus Eclipse raus geht auch alles. Uebergabe von Daten (printf) ueber den Debugger funktioniert. Ich hab mir sogar mal ihr Tool fuer Linux nach programmiert mit dem ich zur Laufzeit Variablen beobachten kann. Geht alles mit dem EDU problemlos. Wenn man langweile haette koennte man jflash vermutlich relativ schnell nachprogrammieren. :-D Olaf
W.S. schrieb: > Die Mehrzahl der Leute brauchen den Debugger häufiger als alles Andere, > die programmieren halt mit dem Debugger und sind immer wieder > überrascht, was der Compiler aus ihrer Quelle gemacht hat. Wenn das > deiner Intention nahe kommt, dann kauf dir den J-link. > > Wenn du es dir hingegen zutraust, wenigstens einigermaßen fehlerfreien > Code zu schreiben, ohne per Debugger nachschauen zu müssen UND das > ReferenzManual lesen kannst, dann reicht auch die Bootladerversion als > die billigste Variante, aber damit sind Freescale-µC (Kinetis) und > Nuvoton und andere außen vor. Ah, der Narzisst mit Profilneurose ist wieder da. Guck doch mal in den USB Thread, da wurden mithilfe eines Debugegrs einige Bugs in deinem USB VCP Code gefunden ;) -> Beitrag "Re: USB CDC von Stefan Frings und WS" Also halt dich erstmal selber an deine eigenen Regeln bevor du mal wieder andere beschimpfst!
Markus B. schrieb: > Leute, ich steige gleich auf Risc-V um wenn ihr euch wegen ARM die Köppe > einschlagt Dann mach das doch. Im Ernst: Du wirst nur ganz selten in eine Situation kommen, wo Du den Prozessorkern unter Dir merkst. Ob Du jetzt nun ARM, MIPS, Risc-V oder PPC programmierst, ist eigentlich egal. Der gcc deckt das alles weitgehend zu. Von daher kannst Du genauso gut einen PIC32MX250F128B (MIPS M4K Kern mit 50 MHz) im SDIP28 nehmen, dazu einen PICKIT3-Clone vom Chinamann für 20€, MPLABX, XC32 und Harmony vom Microchip-Server ziehen, und bist sofort im Geschäft. Läuft hervorragend unter Linux. Ja, da gibts die Ideologen, die Dir sagen wollen, dass der XC32 unfrei und veraltet und beschnitten ist, was zwar irgendwo auch stimmt, für Dich aber keine wirklichen Auswirkungen hat. Es funktioniert einfach, und alles passt zusammen. Und wenn Du später mal Geld hast, und einen JLink (die Kosten sind zu 90% für die Firmware, die Hardware hat einen Wert von 20€) haben willst, dann kann der neben ARM auch MIPS, RISC-V und irgendwelche Renesas-Architekturen. fchk PS: https://www.amazon.de/ARM-Emulator-32-Bit-64-Bit-Downloader-STM32-Unterst%C3%BCtzung-Hochgeschwindigkeits-Download/dp/B07SFWCLBT/ref=sr_1_1?__mk_de_DE=%C3%85M%C3%85%C5%BD%C3%95%C3%91&keywords=jlink&qid=1583049159&sr=8-1
Ganz einfach: Windows + STM32CubeIDE. Denn: Nucer schrieb: > Ich mag die Nucleos von STM, lassen sich einfach an den USB-Port stecken > und mit den Toolchains und IDEs von ST kann man sofort loslegen. > > Man ist dann eben nicht der große Held weil man nicht 4 Wochen harte > Arbeit gebraucht hat um das erste Programm auf den µc zu kriegen. Vollste Zustimmung. Ich nutze ganz einfach die Software, die offiziell vorhanden ist. Dazu gehört auch ein Betriebssystem. Auf dieses Gefrickel mit Toolchains habe ich schon seit über 10 Jahren keinen Bock mehr. Warum tut man sich das noch an? Weil man ein Windows / Linux Fanboy ist? Wenn es nur eine offizielle Toolchain für Linux gibt, dann nutze ich diese. Wenn nur für Windows, dann diese. Peng aus!
Olaf schrieb: > Ich hab mir sogar mal ihr Tool fuer Linux nach programmiert mit dem ich > zur Laufzeit Variablen beobachten kann. Kannst Du ein bisschen mehr dazu sagen, ich trage mich auch mit dem Gedanken sowas zu tun? Hast Du vielleicht sogar ein paar Schnipsel Code die zeigen wie das geht oder kannst Du grob umreißen was dazu nötig ist?
Giloper schrieb: > Wenn es nur eine offizielle Toolchain für Linux gibt, dann nutze ich > diese. Wenn nur für Windows, dann diese. Peng aus! Es gibt die offizielle ARM-Toolchain für alle Betriebssysteme, und sie hat ihre Wurzeln in der Linux-Welt. Und das merkt man. Wenn jemand lieber mit Linux arbeitet dann liegt das daran daß letzteres im Gegensatz zu Windows von Grund auf für die Zielgruppe Softwareentwickler maßgeschneidert ist und so unendlich viele Dinge dort einfacher zu bewerkstelligen sind als unter Windows.
Du startest den gdb-server von Segger und redest mit ihm.
Ich haenge mal meine Methoden dafuer an..
Damit kann man dann beliebige Adressen aus dem Controller auslesen.
Als naechstes muss man nur noch wissen auf welche Adressen die Variablen
im Controller liegen.
Dafuer hab ich noch das hier im Makefile:
@nm -n -S BoardTest |grep '^2' |grep ' 0000' |grep -v '__'
>variable.txt
Das gibt dann im Prinzip so ein File:
more variable.txt
20000000 00000004 d SystemLFXOClock
20000004 00000004 d SystemHFXOClock
20000008 00000001 d rs232.5882
20000009 00000001 d lcd.5881
2000000a 00000001 D char_color
2000000c 00000004 d lcdreset
20000010 00000002 b cmuStatus
20000014 00000018 b i2cTransfer
[..]
Das kann man dann in seinem Programm einlesen und so Variablen
auswaehlen und ihren Inhalte auslesen.
Ich empfehle ausserdem noch das hier zu lesen:
https://www.huihoo.org/mirrors/pub/embed/document/debugger/ew_GDB_RSP.pdf
Segger selbst hat auch noch einiges an Doku zu ihrer Software die man
lesen sollte. Ein laufender Wireshark ist bei der Entwicklung
hilfreich...
Olaf
Giloper schrieb: > Ganz einfach: Windows + STM32CubeIDE. > > Ich nutze ganz einfach die Software, die offiziell > vorhanden ist. Dazu gehört auch ein Betriebssystem. Ähhm. Dir ist aber schon aufgefallen, daß es die STM32CubeIDE auch für Linux gibt? Ganz offiziell? Tatsächlich sind die meisten Teile der IDE, die nicht Java (und damit sowieso plattformunabhängig) sind, ursprünglich mal auf einem unixoiden Betriebssystem entwickelt worden. Z.b. gcc oder openocd. Sogar Java und Tcl sind das. Das ist alles erst nachträglich auf Windows portiert worden. Wie kommst du da auf das schmale Brett, man müsse für die Benutzung dieser Software ein Windows erdulden?
Axel S. schrieb: > Ähhm. Dir ist aber schon aufgefallen, daß es die STM32CubeIDE auch für > Linux gibt? Ganz offiziell? Tatsächlich sind die meisten Teile der IDE, > die nicht Java (und damit sowieso plattformunabhängig) sind, > ursprünglich mal auf einem unixoiden Betriebssystem entwickelt worden. > Z.b. gcc oder openocd. Tut mir leid euer Ehren. Ich habe eben auf st.com kurz nachgesehen und habe nur etwas von Windows gelesen. Schein ich überlesen zu haben. Aber noch besser! Dann kann er sich ja das STM32CubeIDE unter Linux download und nutzen. Fertig! ?
Olaf schrieb: > Das kann man dann in seinem Programm einlesen und so Variablen > auswaehlen und ihren Inhalte auslesen. Bei laufendem Programm in Echtzeit, so wie JScope?
:
Bearbeitet durch User
> Bei laufendem Programm in Echtzeit, so wie JScope?
Yep.
Olaf
Olaf schrieb: >> Bei laufendem Programm in Echtzeit, so wie JScope? > > Yep. Na dann hab ich ja jetzt mal ne Aufgabe: Ein JScope mit vernünftigem UI das so ist wie es eigentlich immer hätte sein sollen anstatt einen in den Wahnsinn zu treiben und das auch noch für Linux.
Bernd K. schrieb: > Np R. schrieb: >> Ich vermute, dem TO wäre mehr damit geholfen, wenn Du einen >> unverknoteten Controller mit völlig unverkorkster Toolchain und >> Linux-kompatibler Programmierhardware vorschlügest, der leicht und >> günstig in kleinen Stückzahlen aufzutreiben ist. > > Kinetis Interessanter Vorschlag. MCUXpresso läuft ja unter Linux. Aber für den Einsteiger wären ja noch ein paar andere Dinge interessant: - günstige Bezugsquellen für kleine Stückzahlen? (Reichelt und TME fallen da schon einmal aus) - günstige Entwicklungsboards? - Tutorials und Beispielprojekte? (Auf Mikrocontroller.net leider keine) Und für die Glaubensrichtung, die sich nicht von einer Hersteller-IDE abhängig machen will: Was sind die Alternativen zu MCUXpresso? Und wie "einfach" werden die dann? (libopencm3 geht ja leider nicht) Bitte nicht als Kritik an Deiner Entscheidung verstehen. Aber um diese Entscheidung auch Ein-/Umsteigern schmackhaft zu machen, fehlt doch noch etwas. Von der perfekt "unverknoteten" Peripherie merkt ein Einsteiger, der irgendeine Abstraktionsschicht nutzt, doch erst einmal gar nichts.
Np R. schrieb: > Was sind die Alternativen zu MCUXpresso? mbed-cli, hatte ich ja schonmal genannt, das unterstützt auch einige LPCXpresso Boards. Die LPC und Boards bekommt man bei Mouser oder anderen Distris. Viele der Boards wurden von EmbeddedArtists gebaut, auf deren Website findet man einiges an Doku. ST ist mit seinem Marketing deutlich aggressiver, die haben da viel mehr in den Markt geworfen. ST hat geschickterweise viele µC pinkompatibel gebaut, damit haben die recht wenig Aufwand schnell ein Board mit einem neuen µC rauszubringen. Das mbed-cli lässt sich gut in VSCode als IDE benutzen. Das ist etwas aufwändiger als eine 1-Klick Installation wie andere IDE, aber wer Linux benutzt sollte das auch hinbekommen. Um den Compiler aufzurufen genügen ein paar Einträge in die tasks.json, den Debugger (Cortex-Debug Extension) kann man über launch.json einbauen. Mit LPC/MCUXpresso habe ich auch lange gerne gearbeitet, aber für einen STM32 brauchte man dann SW4STM32, Atollic oder Eclipse mit den gnuarmeclipse Plugins. Dann kommt ein neues Eclipse Release und wieder viele Updates für viele IDE. Das ist mit VSCode jetzt für mich vorbei, damit kann ich STM32/LPC/Nordic/TI/GD und andere benutzen. Wenn es eine neue ARM gcc toolchain gibt kann ich die auch sofort benutzen oder durch umschalten des Suchpfades eine beliebige ältere Version.
W.S. schrieb: > Die Mehrzahl der Leute brauchen den Debugger häufiger als alles Andere > die programmieren halt mit dem Debugger Wirklich? So könnte ich nicht effizient arbeiten.
Zwecks Bezugsquellen für Kinetis und LPC muss ich mal an Farnell und Develektro erinnern. Farnell hat z.B. 62 verschiedene Kinetis M0+ im Bastler-freundlichen Gehäuse auf Lager (und zum Vergleich 129 STM32 Typen); also, man könnte die durchaus einzeln kaufen, nicht nur bei Mouser oder Arrow. Geheimtipp falls die Suche bei Develektro hakelt: bei Farnell suchen und die Farnell-Bestellnr. bei Develektro eingeben.
Np R. schrieb: > Interessanter Vorschlag. MCUXpresso läuft ja unter Linux. Man braucht kein MCUXpresso oder dergleichen. Bei Kinetis sind die Register so übersichtlich organisiert und einfach zu benutzen, da braucht man keine HAL und Codegeneratoren wie bei STM die das erst mal entknoten muß. Die programmieren sich so einfach und straightforward wie ATMega, sogar noch einfacher weil noch logischer und geordneter. Er hat auch explizit nur verlangt daß die Toolchain unter Linux läuft, und die ist ja gleich für alle ARM Cortex. Nur noch ein möglichst simpel gestricktes Beispiel-Makefileprojekt aus dem Netz ziehen, nen Blick drauf werfen wie das innerlich tickt, RefMan griffbereit daneben legen und los gehts. Immerhin will er einsteigen(!) und nicht nur schnell streifen, also auch von daher wäre sowas wie MCUXpresso oder vergleichbares dem Lernerfolg eher abträglich.
:
Bearbeitet durch User
Brauche ich für diese Nucleos Boards die CubeIDE oder geht das auch mit den "normalen" Tools? Dann würde ich mir vielleicht Mal ein oder zwei bestellen
Markus B. schrieb: > Brauche ich für diese Nucleos Boards die CubeIDE oder geht das auch mit > den "normalen" Tools? > > Dann würde ich mir vielleicht Mal ein oder zwei bestellen Funktioniert auch mit allen anderen Tools, da ist auch nur ein der Microcontroller + Programmer (STLinkv2, bei den G4 nucleos sogar ein STLinkv3) mit USB-UART Wandler drauf.
@Bernd K: Gibts denn die CMSIS Header für die Periph irgendwo frei verfügbar? Damit wäre dem TE ja schonmal geholfen, dann muss er keine Register abtippen.
Markus B. schrieb: > Brauche ich für diese Nucleos Boards die CubeIDE Natürlich nicht. Du brauchst den gcc und binutils für Cortex-M (das sind die *-arm-none-eabi Versionen) und optional noch gdb und die newlib. Außerdem sinnvoll ist openocd zum Download/Debuggen per SWD/JTAG. Wenn es ein STM mit ST-Link Adapter ist, alternativ das 'stlink' Programm. Bis auf letzteres hat das jede vernünftige Linux-Distro schon dabei. Der Charme der Nucleos besteht darin, daß sie den ST-Link SWD Adapter schon mitbringen. Einfach an den USB stöpseln und schon kanns losgehen. Den ST-Link kann man auch abtrennen und anderweitig verwenden. Durchaus auch für Cortex-M von anderen Herstellern. Die Intelligenz steckt nicht im Adapter, sondern in der Software auf dem PC. Mw E. schrieb: > Gibts denn die CMSIS Header für die Periph irgendwo frei verfügbar? Die kann man sich aus den SPL bzw. Cube-HAL Paketen extrahieren.
:
Bearbeitet durch User
Axel S. schrieb: > Mw E. schrieb: >> Gibts denn die CMSIS Header für die Periph irgendwo frei verfügbar? > > Die kann man sich aus den SPL bzw. Cube-HAL Paketen extrahieren. Bernd redet aber über die Kinetis. Die STM32 CMSIS Header liegen aber auch auf vielen Github Projekten frei rum. Die Kinetis werden bei Hobbyisten jetzt nicht so oft genutzt. Google mit "CMSIS Kinetis" brachte jetz nich so viel zu Tage.
Mw E. schrieb: > Axel S. schrieb: >> Mw E. schrieb: >>> Gibts denn die CMSIS Header für die Periph irgendwo frei verfügbar? >> >> Die kann man sich aus den SPL bzw. Cube-HAL Paketen extrahieren. > > Bernd redet aber über die Kinetis. Tja. Wenn es doch nur eine Möglichkeit gäbe, den Post zu zitieren, auf den man sich beziehen will. Das wäre so praktisch!!1!elf
> Außerdem sinnvoll ist openocd zum Download/Debuggen per SWD/JTAG. Wenn > es ein STM mit ST-Link Adapter ist, alternativ das 'stlink' Programm. Also ich arbeite nicht bei Segger, aber ich moechte trotzdem dringend empfehlen sich einen originalen Jlink zu besorgen. Ich hab mit den ST-Link auch mal unter Linux rumgespielt und das war immer irgendwie wackelig. Es ging schon irgendwie, aber auch nur irgendwie. Nicht gerade das was sich ein Anfaenger zumuten will. Allerdings gibt es ja mittlerweile die Moeglichkeit die Testboards von Segger auf Jlink umzuflashen. Ich hab aber keine Erfahrung wie zuverlaessig das unter Linux laeuft. Allerdings wird man damit dann wieder nur ST Zeugs flashen und debuggen koennen und nicht jeden beliebigen Arm der einen ueber den Weg laeuft. Olaf
Axel S. schrieb: > Tja. Wenn es doch nur eine Möglichkeit gäbe, den Post zu zitieren, auf > den man sich beziehen will. Das wäre so praktisch!!1!elf @Bernd K war eindeutig genug ;)
Olaf schrieb: > Also ich arbeite nicht bei Segger, aber ich moechte trotzdem dringend > empfehlen sich einen originalen Jlink zu besorgen. Ich hab mit den > ST-Link auch mal unter Linux rumgespielt und das war immer irgendwie > wackelig. Nicht wackelig, sondern langsam. Beim Durchsteppen merkt man eine Bedenkzeit beim STLink. Beim JLink merkste keine Verzögerung.
Olaf schrieb: > Allerdings gibt es ja mittlerweile die Moeglichkeit die Testboards von > Segger auf Jlink umzuflashen. Ich hab aber keine Erfahrung wie > zuverlaessig das unter Linux laeuft. Naja, das umflash script läuft nur unter Windows (funktionierte bei mir in einer VM), danach lässt sich der JLink einwandfrei benutzen. Mit wine hab ich das reflash script nicht dazu gebracht das Nucleo board zu finden.
Markus B. schrieb: > Dann würde ich mir vielleicht Mal ein oder zwei bestellen Es gibt eine Variante der Nucleos eines anderen Herstellers: https://www.waveshare.com/product/mcu-tools-2/core-boards-compact-boards/stm32-nucleo/xnucleo-f411re.htm https://www.waveshare.com/wiki/XNUCLEO-F411RE
Bernd K. schrieb: > da braucht man keine HAL und Codegeneratoren wie bei STM Die braucht man bei STM auch nur, wenn man sie sich aufschwatzen lässt.
Markus B. schrieb: > Brauche ich für diese Nucleos Boards die CubeIDE oder geht das auch mit > den "normalen" Tools? Die Cube IDE ist ein normales Tool. Genau gesagt ist eine Eclipse IDE mit ziemlich gewöhnlichen Plugins, die auch andere Entwickler für ihre Mikrocontroller nutzen. ST hat da lediglich das Cube MX integriert. Das kannst du nutzen, musst du aber nicht. Alternativ gibt es zum Beispiel die "System Workbench for STM32", basiert auch auf Eclipse kommt aber nicht von ST und enthält kein Cube MX.
Mw E. schrieb: > Gibts denn die CMSIS Header für die Periph irgendwo frei verfügbar? Die sind in den Sogenannten "Firmware Packages" von ST enthalten. Kannst du einfach dort heraus ziehen. Oder meine Kollektion benutzen. Schau Dir mal diese Seiten an: http://stefanfrings.de/stm32/index.html
Stefan ⛄ F. schrieb: > Mw E. schrieb: >> Gibts denn die CMSIS Header für die Periph irgendwo frei verfügbar? > > Die sind in den Sogenannten "Firmware Packages" von ST enthalten. Die gibt es auch einzeln, ohne Email-Adresse und trotzdem original: https://github.com/STMicroelectronics/STM32CubeL0/tree/master/Drivers/CMSIS/Device/ST/STM32L0xx/Include https://github.com/STMicroelectronics/STM32CubeL4/tree/master/Drivers/CMSIS/Device/ST/STM32L4xx/Include usw.
Bauform B. schrieb: > Die gibt es auch einzeln, ohne Email-Adresse und trotzdem original Interessant, gut zu wissen.
Olaf schrieb: >> Außerdem sinnvoll ist openocd zum Download/Debuggen per SWD/JTAG. Wenn >> es ein STM mit ST-Link Adapter ist, alternativ das 'stlink' Programm. > > Also ich arbeite nicht bei Segger, aber ich moechte trotzdem dringend > empfehlen sich einen originalen Jlink zu besorgen. Ich hab mit den > ST-Link auch mal unter Linux rumgespielt und das war immer irgendwie > wackelig. Details? > Es ging schon irgendwie, aber auch nur irgendwie. Nicht gerade > das was sich ein Anfaenger zumuten will. Details? Ich bin jetzt zwar nicht unbedingt ein Anfänger, was Computer oder Linux oder µC betrifft. Aber ich war durchaus ein Anfänger mit Cortex-M, als ich mit einem STM32F030 und dann mit einem Bluepill Board und dann mit einem Nucleo L073 rumgemacht habe. Und ich hatte da genau gar keine Probleme mit dem ST-Link. Sogar den verschrienen China-Klones (eigentlich für den STM8 angeschafft). Sowohl mit Texane stlink als auch mit openocd. Flashen ging. Debuggen ging (nicht STM8, wohl aber STM32). Ich zweifle nicht, daß ein J-Link toll ist. Ich glaube auch unbesehen, wenn jemand sagt, er sei besser als ein ST-Link. Was ich aber absolut bezweifle ist, daß man einen J-Link dringend braucht, um mit einem Cortex-M µC loslegen zu können. Noch dazu, wenn das ein STM32 ist und man den ST-Link auf einer Ecke des Nucleo-Boards praktisch hinterhergeworfen bekommt. > Allerdings gibt es ja mittlerweile die Moeglichkeit die Testboards von > Segger auf Jlink umzuflashen. Allerdings wird man damit dann > wieder nur ST Zeugs flashen und debuggen koennen und nicht jeden > beliebigen Arm der einen ueber den Weg laeuft. Und welche Relevanz hat das? Wenn man doch den ST-Link auf einem STM32 Nucleo nutzt? Darf ich nochmal auf den Betreff dieses Threads hinweisen? Markus sucht eher nicht die eierlegende Wollmilchsau, mit der er alle jetzt und in Zukunft am Markt existierenden ARM-basierenden µC auf die bestmögliche Art flashen/debuggen kann. Er sucht den Einstieg. Ein Nucleo-Board von ST ist IMNSHO eine gute Möglichkeit dafür. Das Geld für einen J-Link (oder vielleicht besser ein BMP?) kann er danach ja immer noch in die Hand nehmen.
Axel S. schrieb: > Und welche Relevanz hat das? Wenn man doch den ST-Link auf einem STM32 > Nucleo nutzt Der vorhandene ST-Link ist halt langsam und verbuggt. Manche haben da mehr Probleme mit, manche weniger. Scheint von der Mondphase abzuhängen ob er funktioniert oder kryptische Fehler wirft (selbst mit der Original ST Software). Beim STM32F746 Discovery ist es mir bspw. überhaupt nicht gelungen, den ST-Link dazu zu bewegen, irgendwas sinnvolles zu machen. Weder mit dem ST-Link Utility, noch mit SW4STM32 noch mit texane st-link. JLink ist da einfach zuverlässiger, der Segger Marketing Spruch "It simply works" stimmt schon. Außerdem ist die Linux Software besser. Ich habe das o.g. Discovery Board umgelötet um einen JLink anschließen zu können - hat sofort funktioniert. Das Umflasehen gabs damals noch nicht. Jetzt hab ich aber alle meine ST Boards auf JLink umgeflasht und dafür extra nochmal Windows gestartet... Axel S. schrieb: > Was ich aber absolut bezweifle ist, daß man einen J-Link dringend > braucht, um mit einem Cortex-M µC loslegen zu können Nö. Wenn man aber plant viel mit ARM zu machen, ist das definitiv eine sinnvolle Investition. Ist halt ein solides Werkzeug und kann nebenbei nahezu alle ARM Prozessoren, auch die großen Cortex-A.
Programmierer schrieb: > Der vorhandene ST-Link ist halt langsam und verbuggt. Er ist um Welten schneller, als Debug Wire bei AVR. Man kann damit gut arbeiten. Verbuggt? Meine funktionieren tadellos. Ich war von Bugs noch nicht betroffen. ST bietet Firmware-Upgrades an - auch für die ST-Link 2.0 kompatiblen Klone.
> Details? Was erwartest du da als Antwort? Es war halt einfach unzuverlaessig. Ausserdem ist das schon >5Jahre her seitdem nutze ich nur noch den EDU. Und wie ich schon sagte, ich nutze nicht nur ST sondern auch ARMs anderer Hersteller. Olaf
Programmierer schrieb: > Axel S. schrieb: >> Und welche Relevanz hat das? Wenn man doch den ST-Link auf einem STM32 >> Nucleo nutzt > > Der vorhandene ST-Link ist halt langsam und verbuggt. Details? "Langsamer im Einzelschrittbetrieb" überzeugt mich irgendwie gar nicht. Einzelschrittbetrieb soll langsam sein. Das ist ja der Punkt dabei. > Manche haben da mehr Probleme mit, manche weniger. Wenn du das Problem nicht zeigen kannst, gehe ich vorsichtshalber erstmal davon aus, daß es nicht existiert. Wenn es um Computer und Software geht, sitzt in 95% der Fälle das Problem sowieso vor der Tastatur. >> Was ich aber absolut bezweifle ist, daß man einen J-Link dringend >> braucht, um mit einem Cortex-M µC loslegen zu können > > Nö. Wenn man aber plant viel mit ARM zu machen, ist das definitiv eine > sinnvolle Investition. Na dann warten wir doch erstmal, ob es dazu kommt. Wenn du dein Kind zur ersten Stunde Geigenunterricht schickst, kaufst du ihm dafür ja auch keine Stradivari.
Mw E. schrieb: > @Bernd K: > Gibts denn die CMSIS Header für die Periph irgendwo frei verfügbar? Header gibts für jeden ARM in den jeweiligen Pack-Datei (auch DFP genannt, ist ein umbenanntes .zip) entweder direkt vom Hersteller oder wenn es dort zu gut versteckt ist dann bei Keil welche die alle hier an einer Stelle sammeln: https://www.keil.com/dd2/ Darin befindet sich neben den fertigen Headern und anderen nützlichen Dateien auch immer eine .svd-Datei (Registerdefinitionen als xml) aus der man sich die Header selbst generieren kann im gewünschten Format (Flat, Structs, Structs und Enums, etc.) mit dem tool svdconv (gibts für Linux und Windows) In vielen Fällen findet man auch Startup-Code und Linkerscript, mindestens für Keil, manchmal auch für gcc. > dann muss er keine Register abtippen. Das musste noch keiner jemals, das wäre ja vollkommener Irrsinn, der einzige von dem überliefert ist daß er sowas je gemacht hat ist W.S. und der Himmel allein weiß warum. Was Du manchmal/oft machen musst ist das generische gcc Beispiel-Linkerscript an den jeweiligen Controller anpassen falls kein solches im pack zu finden ist (ist ja vorwiegend auf keil zugeschnitten) und ebenso den Startup-Code, mit etwas Übung (wenn man sowas einmal gemacht hat) geht das aber ratzfatz. Wenn man zum Beispiel den Startup nur für Keil hat, aber irgendwo in seiner Sammlung einen anderen Startup für gcc kann man letzteren mit dem was man im Keil-Assembler finden kann leicht passend machen. Ebenso einfach lässt sich ein existierendes Linkerscript passend machen. In vielen Fällen kann man sich aber auch die fehlenden Puzzlestücke (Linkerscript, Startup) online zusammensuchen.
:
Bearbeitet durch User
Stefan ⛄ F. schrieb: > Verbuggt? Meine funktionieren tadellos. Ich war von Bugs noch nicht > betroffen. Glück gehabt. Bei anderen ist das nicht so. Stefan ⛄ F. schrieb: > ST bietet Firmware-Upgrades an - auch für die ST-Link 2.0 kompatiblen > Klone. Hat bei mir nie geholfen. Axel S. schrieb: > Details? "Langsamer im Einzelschrittbetrieb" überzeugt mich irgendwie > gar nicht. Einzelschrittbetrieb soll langsam sein. Das ist ja der Punkt > dabei. Wenn ich durch einen längeren Algorithmus durchsteppen will, und öfter mal 3-10 Zeilen überspringen will, drücke ich in Eclipse 3-10x auf F6 für "Step Over". Das geht mit dem JLink instant, mit dem ST-Link dauert das jeweils 1-2 Sekunden. Nervig. Natürlich könnte man auch jedes Mal "Run to Cursor" benutzen, aber da mit der Maus zur jeweiligen Zeile navigieren dauert auch wieder. Axel S. schrieb: > Wenn du das Problem nicht zeigen kannst, gehe ich vorsichtshalber > erstmal davon aus, daß es nicht existiert. Ich krame jetzt nicht den ganzen Kram raus nur um für dich Beweis-Fotos und -Screenshots zu machen. Ich erinnere mich aber noch deutlich an die enorm hilfreiche Fehlermeldung vom ST-Link-Utility "Internal Command Error". Dazu kommt der übliche Schluckauf wenn man die "WFI" Instruktion nutzt. Mit dem JLink hat das jedenfalls immer alles wunderbar funktioniert.
Axel S. schrieb: > Programmierer schrieb: >> Axel S. schrieb: >>> Und welche Relevanz hat das? Wenn man doch den ST-Link auf einem STM32 >>> Nucleo nutzt >> >> Der vorhandene ST-Link ist halt langsam und verbuggt. > > Details? "Langsamer im Einzelschrittbetrieb" überzeugt mich irgendwie > gar nicht. Einzelschrittbetrieb soll langsam sein. Das ist ja der Punkt > dabei. Dass man bei jedem einzelnen Schritt ein oder zwei Sekunden warten muss, ist definitiv nicht nötig. Und ja es kann wirklich nerven. Stefan ⛄ F. schrieb: > Verbuggt? Meine funktionieren tadellos. Ich war von Bugs noch nicht > betroffen. Bei mir hängt sich der ST-Link regelmäßig nach N Flash-/Debugvorgängen auf. Danach muss man den ST-Link aus- und wieder einstecken. Wegen den beiden Problemen hab ich mir einen JLink EDU gegönnt. Hab's nicht bereut. Aber für den Anfang ist's nicht nötig.
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.