Ich nutze schon ewig die von Mikroe, wie alle, haben die natürlich auch ihre Probleme, aber man kann damit arbeiten. Ich liebäugle immer mal wieder mit CubeMX bzw der CubeIDe aufgrund ihrer "Vorteile", aber am Ende finde ich den erzeugten Code so unfassbar unübersichtlich, von der Hall ganz zu schweigen, das ich meist schon nach wenigen Minuten abgeschreckt bin. Keil scheint auch ganz angenehm zu sein, ist aber für privat etwas teuer (Habe von mikroe die Lifetime Lizenzen) IAR sieht auch super aus und kommt mikroe wohl am nächsten? Aber was kostet der? Und wieso haben die keine festen Preise für Privatkunden? das schreckt komplett ab CrossWorks? Ich vermute mal, im Hobbybereich wird es wohl die CubeIDE sein?
1 | $ apt install gcc-arm-none-eabi |
Dazu Editor der Wahl, z.B. Vim :-) Nee, ich benutze VSCode, aber mit dem Compiler oben. Ansonsten: Cross-Toolchain selber bauen ist kein Hexenwerk.
:
Bearbeitet durch User
Oh, ok, den kannte ich noch gar nicht. Wieso nutzt du überhaupt NXP und nicht STM? Andreas B. schrieb: > MCUxpresso
Max M. schrieb: > Oh, ok, wieso nutzt du überhaupt NXP? > Warum nicht? Ich finde sie uebersichtlicher als die STM.
Einfach, weil ich den Eindruck habe, das alle Welt, also zumindest in D, auf STM setzt, ich selber auch, da ich dachte, das es da die meiste Vielfallt gibt und so Andreas B. schrieb: > Max M. schrieb: >> Oh, ok, wieso nutzt du überhaupt NXP? >> > Warum nicht? > Ich finde sie uebersichtlicher als die STM.
Max M. schrieb: > Aber was kostet der? Und wieso haben die keine festen Preise für > Privatkunden? das schreckt komplett ab > CrossWorks? > Weil Du keine Privatkunden im Business-Bereich haben willst. Eine Weiterentwicklung einer Software kannst Du heute (2023) eigentlich nur noch mit einem Miet-Modell stemmen. Der Bastler will natuerlich nicht jaehrlich zahlen, gleichzeitig muss der Software-Ersteller staendig Updates (allein wenn sich das Betriebssystem des Hosts aendert) liefern. > Ich vermute mal, im Hobbybereich wird es wohl die CubeIDE sein? Besser ausgedrueckt: OpenSource-Loesung. Eclipse ist Mah-Mah, ich bin ueber die Qualitaet von Visual Studio Code sehr beeindruckt. Sehr positiv ueberrascht (fuer ein Microsoft-Produkt).
Ich nehme Segger Embedded Studio. Leider harmoniert es nicht mit CubeMX, die Projekte zu importieren ist immer ziemlich umständlich. Ich verwende CubeMX inzwischen ganz gerne wenigstens für die CLock-Konfiguration/Initialisierung. Danach kann man mit selbstgestrickten Libs/Funktionen weitermachen wenn es nicht die HAL sein soll.
:
Bearbeitet durch User
Max M. schrieb: > Ich vermute mal, im Hobbybereich wird es wohl die CubeIDE sein? Man nimmt das, was der Hersteller (Arduino bezeichne ich auch mal als Hersteller) gratis zur Verfügung stellt. Atmel/Microchip Studio, Arduino, HWB, MPLAB, .. Ja, das ist pro Hersteller was anderes, aber man hat dabei die höchste Wahrscheinlichkeit, dass es funktioniert. Multi-Cross-Plattform, dann auch noch von Fremdanbietern, geht meist in die Hose.
Man kann CubeMX Projekte auch in VSC übernehmen, da gibt es mittlerweile eine Extension dafür. HAL (nicht Hall) oder LL generierter Code bleibt da aber auch wie er ist. Und wenn man nachträglich Änderungen an der Konfiguration in CubeMX vornimmt weiss ich nicht wie gut sich das wieder in die VSC Konfiguration übernehmen lässt. Der Debugger in der CubeIDE ist sehr gut, auch wenn man mehrere Targets gleichzeitig debuggen muss. LiveView gibt es auch oder FreeRTOS Unterstützung. Die Cortex-Debug Extension für VSC ist aber auch nicht schlecht, die hinkte anfangs etwas hinterher, kennt jetzt auch verschiedene RTOS. MCUXPresso ist ja das Gleiche in grün, bzw. das alte Eclipse für NXP. Das war auch schon immer gut, aber die Hersteller unterstützen natürlich nur ihre eigenen Produkte, obwohl das Eclipse darunter gleich ist. VSC gefällt da mir bisher am Besten, für eigene Projekte nehme ich das. Und immer noch mit Mbed, jetzt aus dem CE Fork.
:
Bearbeitet durch User
Diejenige, die vom Hersteller zur Verfügung gestellt wird.
Die Cube IDE zwingt dich nicht dazu, Cube MX oder die HAL zu verwenden. Sie unterstützt auch Projekte ohne dieses Framework.
Michael B. schrieb: > Multi-Cross-Plattform, dann auch noch von Fremdanbietern, geht meist in > die Hose. Kann ich so nicht bestätigen. Wir machen das für ein knappes Dutzend Architekturen (Linux, Windows, bare Metal, ARM926, Cortex-A (7, 9 und 35), Cortex-M (0+, 3, 4, 33), ein alter 16 bitter, x86, x86-64). Alles handgeklöpelte Makefiles mit ein paar Scripts außenrum. Editiert wird das alles nach langen Jahren Eclipse mittlerweile unter VSCode. Diverses Windows-only Zeug lassen wir mit Wine unter Linux im Bauprozess auch noch laufen. Steckt aber auch viel Setup Zeit drin was für das Hobby natürlich eher hinderlich ist.
J. S. schrieb: > Man kann CubeMX Projekte auch in VSC übernehmen, da gibt es mittlerweile > eine Extension dafür. CubeMX kann makefiles generieren und die funktionieren problemlos mit VSC.
Nialz schrieb: > Diejenige, die vom Hersteller zur Verfügung gestellt wird. Das mache ich auch. Für STM nehme ich CubeIDE, für NXP den MCUxpresso. Wobei ich Compiler, Startup-Libraries, Linker-Files etc extrahiert habe, und dann alles nur noch über make aufrufe. Dann muss ich nicht meinen Lieblings-Editor wechseln.
Im Job bekomme ich die Build-Umgebung normalerweise zur Verfügung gestellt, auf Basis von makefiles. Als Editor benutze ich VSCode. Privat nutze ich vorzugsweise VSCode mit PlatformIO. Und wenn PlatformIO nicht verwendbar ist, trotz support für fast 2000 "boards", dann nehme ich die IDE vom Hersteller. Die "platforms" "Atmel AVR" und "Atmel SAM" zum Beispiel unterstützen nur das "framework" "Arduino" bzw. "Arduino" und "Zephyr RTOS", also Bare-Metall ist nicht vorgesehen. -> Microchip Studio Die "platform" "ST STM32" unterstützt aktuell die "frameworks": "Arduino", "CMSIS", "libopencm3", "Mbed", "Standard Peripheral Library", "STM32Cube" und "Zephyr RTOS". Aber auch damit konnte ich z.B. das Nucleo-C031C6 und das Nucleo-H503RB bisher nicht verwenden. Und ich mache zwar nicht viel mit STM32, vor allem da es praktisch keine STM32 gibt die ich tatsächlich benutzen könnte, aber zumindest eine Platine habe ich mit Hilfe der STM32CubeIDE erfolgreich geplant. Und die initiale Test-Software für die Platine war zum Teil mit STM32CubeIDE generiert. Wobei mich Eclipse ganz allgemein eher ankotzt, was aber dran liegt, dass die meisten IDEs die Eclipse nutzen nicht so gut benutzbar sind wie STM32CubeIDE.
Max M. schrieb: > Ich liebäugle immer mal wieder mit CubeMX bzw der CubeIDe aufgrund ihrer > "Vorteile", aber am Ende finde ich den erzeugten Code so unfassbar > unübersichtlich, von der Hall ganz zu schweigen, das ich meist schon > nach wenigen Minuten abgeschreckt bin. Man muss sich einfach auch mal in den generierten Code einlesen (auch in die tieferen Ebenen). OK, einige Design-Entscheidungen finde ich im Detail auch eher fragwürdig, aber im Großen und Ganzen ist das Zeug durchaus logisch. Richtig fies finde ich einfach nur dieses völlig nutzlose Umbenennen von Registerbits, was ja teilweise sogar bis zu drei Mal durch die verschiedenen Schichten hindurch erfolgt. Wäre akzeptabel, wenn wenigstens der Namenskern immer erhalten bliebe. Das ist aber leider sehr oft nicht der Fall. > Keil scheint auch ganz angenehm zu sein, ist aber für privat etwas teuer > (Habe von mikroe die Lifetime Lizenzen) > IAR sieht auch super aus und kommt mikroe wohl am nächsten? Das hat doch mit den verwendeten Compilern nix zu schaffen! Das ist eine ganz andere Spielwiese. Idealerweise sollte es sogar überhaupt keine Rolle spielen, mit welchem Compiler der Kram am Ende übersetzt wird.
MPLABX von Microchip. Kostenlos und professionell. Das Geld verdienen die mit dem Verkauf der Chips.
VS2019 mit VisualGDB, schlank und schnell, mit allen Vorteilen von VisualStudio. Die Frage ist doch wohl eher Eclipse oder nicht. Wie oben schon genannt: (bei STM) Ein Projekt mit CubeMx generieren und dann in die Lieblings-Toolchain importieren (z.B. VGDB) ist schon ganz angenehm. Runout
Thomas T. schrieb: > VS2019 mit VisualGDB, schlank und schnell Die Begriffe Visual Studio und schlank und schnell in einem Satz sieht man allerdings sehr, sehr selten. Oliver
SEGGER Embedded Studio...weil ich recht günstig an die Lizenz komme ;-). https://www.segger.com/products/development-tools/embedded-studio/ Ist aber auch für nicht kommerziell interessant wegen der SFL, https://www.segger.com/purchase/licensing/license-sfl/. Ansonsten zum Debuggen kann ich Ozone empfehlen, https://www.segger.com/products/development-tools/ozone-j-link-debugger/. Dann kann man mit dem Setup seiner Wahl sein Projekt verwalten und bauen und mit Ozone IDE unabhängig debuggen.
> Einfach, weil ich den Eindruck habe, das alle Welt, also zumindest in D, > auf STM setzt, ich selber auch, da ich dachte, das es da die meiste > Vielfallt gibt und so Das ist nur bei Bastlern so weil die immer voneinander abschreiben. In Firmen wird der Controller nach ganz anderen Kriterien ausgewaehlt und der Compiler und die Umgebung ebenfalls. Ich hab in den letzten 12Monaten an Controllern von ST, Silabs, TI, Renesas und NXP programmiert. Privat nehme ich dann gerne was neues/cooles/anderes. (z.B Nordic oder RP2040) Damit es nicht langweilig wird. Vanye
> SEGGER Embedded Studio...weil ich recht günstig an die Lizenz komme ;-).
Hab ich mir vor einem Jahr mal angekuckt. War aber ziemlich kacke
weil man keine make/makefile Projekte erzeugen/nutzen konnte.
Kam mir ziemlich unprofessionell vor. Ist das mittlerweile besser
geworden oder hab ich da was uebersehen?
In der Firma sowieso nicht, aber auch privat will ich keine Projekte
haben die irgendwann von einer bestimmten Oberflaeche oder gar
einem Versionsstand abhaengig sind.
Einfach auschecken und einmal make muss immer funktionieren!
Vanye
AVRCo-Pascal und Mega-/XMega-Controller Falls jemand jetzt aufschnauft "teuer", ja das war einmal. Rolf, der Entwickler des AVRCo-Compilers, ist vor kurzem verstorben :-( und der Compiler wurde mit der Version 6 (nicht die Version 5.x!) zur Freeware erklärt. Es ist kein Programmiergerät als Dongle mehr erforderlich und es gibt keine Codegrößenbeschränkung mehr. Ich habe Rolf persönlich kennen und schätzen gelernt und bin immer noch sehr traurig. https://www.e-lab.de/downloads/
:
Bearbeitet durch User
Oh, das tut mir leid. Ich war damals aber so verärgert wie mit den Anfänger im Forum umgegangen wurde, dass ich mir inzwischen mehrere Programme von Mikroe gekauft habe (Also Pascal und C für Arm und AVR, Lebenslange Lizenzen. Aber dennoch ist es natürlich schade, dass zu lesen. Gibt es denn jemanden der es weiter entwickelt? Ich werde das mal im Freepascal Forum anregen oder ob es ins Freepascal integriert werden könnte etc. Ich denke das wäre eine sehr schöne Möglichkeit, das System noch lange weiter zu nutzen, besser als es alleine als eigenständiges System weiter zu entwickeln, wo es kaum Beachtung erfahren würde. Und bevor es so lange brach liegt, das niemand mehr Lust hat es fortzusetzen um aktuelle AVR Nachfolger zu ergänzen z.B.
Max M. schrieb: > Gibt es denn jemanden der es weiter entwickelt? > Ich werde das mal im Freepascal Forum anregen oder ob es ins Freepascal > integriert werden könnte etc. > Ich denke das wäre eine sehr schöne Möglichkeit, das System noch lange > weiter zu nutzen, besser als es alleine als eigenständiges System weiter > zu entwickeln, wo es kaum Beachtung erfahren würde. Da die Quellen und das Build-System nicht veroeffentlicht sind, ist die Wahrscheinlichkeit sehr hoch, dass dieses System in den Orcus wandert. Die Quellen unter einer OpenSource Lizenz zu Lebzeiten veroeffentlichen hatte geholfen. Jetzt geht es nicht mehr.
Naja, noch ist ja nicht alles verloren, wenn Angehörige dem zustimmen würden. Aber ansonsten hast du Recht. Dann ist es in Kürze Bedeutungslos, da keine nachfolgenden Controller mehr aktualisiert werden. Aber wenn ich mir die Diskussion im Forum ansehe, bedeutet es wohl das Ende von AVRco:-( Auch wenn ich es schon ewig nicht mehr nutze, ist es dennoch sehr schade. Zum Glück bleibt Mikroe
Ich kann mit der Version, wie sie jetzt ist, besser gesagt mit der letzten verdongelten, leben. Ich hab ca. 650 Megas/XMegas vorrätig und die sollten bis zur Kiste reichen. Schade ist, daß aktuell Dinge eingebaut werden sollen, die keiner braucht, anstatt die letzten Schönheitsfehler zu beseitigen und Codeoptimierung zu betreiben. Leider war und bin ich seit Turbo Pascal 7 da raus, ansonsten hätte ich vielleicht Rolfs Angebot, mir den Compiler zu überlassen, angenommen.
Freepascal unterstützt ja auch AVR, von daher wäre es evtl eine Alternative da mal drüber zu schielen:-) Freepascal ist sehr mächtig und deutlich weiter als AVRco Hier eine Liste der Unterstützen AVRs https://gitlab.com/freepascal.org/fpc/source/-/blob/main/compiler/avr/cpuinfo.pas?ref_type=heads#L58
Danke wußte ich nicht. Mit XMegas geht aber noch nichts? Gibt es eine Liste der Funktionen, die auf AVRs verfügbar sind?
Frag da mal direkt im Freepascal Forum nach, entweder im Deutschen oder am besten im großen https://forum.lazarus.freepascal.org/index.php Die Community ist extrem freundlich und helfen sofort gerne mit ausführlichen Infos etc. Der Umgangston ist nicht mit dem hier oder im AVRco Forum vergleichbar. https://wiki.freepascal.org/AVR_Embedded_Tutorials/de Und das beste, es wird auch ARM unterstützt, man muss sich also nicht mal umgewöhnen https://wiki.freepascal.org/ARM_Embedded_Tutorials Hier die benötigte FreePascal Deluxe Version https://github.com/LongDirtyAnimAlf/fpcupdeluxe/releases/tag/v2.4.0a Anbei das Manual https://castle-engine.io/fpcupdeluxe
Angehängte Dateien:
-
mega.png
17 KB
ICh sehe gerade, der Xmega wird wohl auch schon unterstützt https://gcc.gnu.org/onlinedocs/gcc/AVR-Options.html
Beitrag #7513203 wurde vom Autor gelöscht.
Angehängte Dateien:
-
MakeFileExport.png
11 KB
Vanye R. schrieb: > Hab ich mir vor einem Jahr mal angekuckt. War aber ziemlich kacke > weil man keine make/makefile Projekte erzeugen/nutzen konnte. Im Kontextmenü des Projektes findest du "Export Makefile" (siehe Anhang).
> Im Kontextmenü des Projektes findest du "Export Makefile" (siehe > Anhang). Ist das neu? Wie gesagt, so vor 1-2Jahren konnte ich nichts finden wie ich da ein Makefile eines vorhanden Projektes importieren. Vanye
Ab GCC v13 wird Modula-2 unterstützt. Hat das schon mal jemand ausprobiert? > Support for the language Modula-2 has been added. This includes support > for the ISO/IEC 10514-1, PIM2, PIM3, PIM4 dialects together with a > complete set of ISO/IEC 10514-1 and PIM libraries. https://gcc.gnu.org/gcc-13/changes.html#modula2
Als IDE benutze ich JetBrain CLion. als Build System verwende ich CMake was ja von Clion auch direkt unterstütz wird. Als Compiler kommen damit alle Compiler in Frage welche sich mit make/Cmake ansteuern lassen: ich nutze dabei * GCC für Arm und für den PC * Microsoft Visual Studio Compiler Clion ist leider nicht kostenlos. Aber danach wurde auch nicht gefragt. Von Jetbrain nutze ich zusätzlich noch * PyCharm (Python) * Rider (C#) * IntelliJ IDEA (Java, Kotlin) mit dem Vorteil das die IDE ziemlich identisch sind.
Crazy H. schrieb: > und der Compiler wurde mit der Version 6 (nicht die Version 5.x!) zur > Freeware erklärt. Sources? Ohne Sources wäre die Benutzung quasi "Russisch-Roulette". > Ich habe Rolf persönlich kennen und schätzen gelernt und bin immer noch > sehr traurig. Nun, es ist immer traurig, wenn jemand stirbt, den man mag. Das ändert aber nichts am technischen Sachverhalt. Insbesondere nicht für alle, die den Autor halt nicht kannten und insbesondere auch nicht die Erben und deren zukünftiges Verhalten. Allein die Tatsache, dass V5 nicht freigegeben wurde, läßt darauf schließen, dass den Erben die Intention des ursprünglichen Autors mehr oder weniger egal ist oder dass es auch schon dessen Intention war, den Gewinn zu maximieren. Dagegen ist prinzipiell nichts einzuwenden. Es ist ja schließlich absolut legitim, mit der eigenen Arbeit Geld verdienen zu wollen. Es ist sogar legitim, dass auch die Erben das wollen (auch wenn sie selber nicht an der Sache gearbeitet haben). Aber: jeder Benutzer der Sache sollte sich klarmachen, dass er nunmehr allein vom Wohlwollen der Erben abhängt. Die vermutlich nichtmal eine Ahnung davon haben, was sie da verwalten. Ich (obwohl Pascal eher zugeneigt) würde mich jedenfalls nicht darauf einlassen.
Rowley Crossworks. Zum Code schreiben aber meist mit externem Editor Slickedit. Da drinnen wird dann auch üblicherweise auch mit Tastendruck gebaut/build errors korrigiert (crossbuild.exe).
Bislang war meine Empfehlung für kleine ARM-Projekte EWARM von IAR. Bis 32 kB Code waren zeitlich unbegrenzt möglich und reichten für viele Spielereien aus. Der Debugger ist richtig gut! Genialerweise wurde die Zeit zum Ausprobieren auf 14 Tage und 12 kB verkürzt: Das ist ein schlechter Scherz! Das "Segger Embedded Studio for ARM" bietet sich als Alternative an. Die aktuelle Version 7.32 bietet auch einen guten Einstieg für den RP2040, indem Basis-Projekte inkl. Bootloader zur Verfügung stehen. Leider funktioniert der Import von IAR EWARM-Spielereien nicht so, wie es bei Vorgängerversionen war. Oder ich habe es noch nicht begriffen. Nacharbeit ist auf jeden Fall notwendig. Auch ein Beispielprogramm läßt sich zwar compilieren und via JLink-mini auf dem Pico-Board die LED blinken, der Versuch es mit Ozone zu starten, endet mit intransparenten Fehlermeldungen. Ohne Zeitzwang warte ich einfach neuere Versionen ab.
Genau sowas war für mich ein Punkt gleich mehrere Mikroe Compiler (C und Pascal für Arm und AVR) zu kaufen, da es damals Lifetime Lizenzen gab und ich damit jetzt ausreichend CPUs bis ins Alter abgedeckt habe:-) Nur neu AVR kann ich halt nicht mehr nutzen und bald sicher auch keine neuen ARm..aber so viele Arm die jetzt unterstützt werden, sind da sicher auch in 20-30 Jahren, noch welche von verfügbar:-)
> Leider funktioniert der Import von IAR EWARM-Spielereien nicht so, wie > es bei Vorgängerversionen war. Oder ich habe es noch nicht begriffen. > Nacharbeit ist auf jeden Fall notwendig. Vielleicht hilft das hier: https://wiki.segger.com/Port_Projects_from_IAR_Embedded_Workbench_to_Embedded_Studio > Auch ein Beispielprogramm läßt sich zwar compilieren und via JLink-mini > auf dem Pico-Board die LED blinken, der Versuch es mit Ozone zu starten, > endet mit intransparenten Fehlermeldungen. Ohne Zeitzwang warte ich > einfach neuere Versionen ab. Nichtssagende Fehlermeldungen sollte es natürlich nicht geben. Was war es denn? Dann gebe ich das gerne weiter. Ich habe das gerade mal mit dem RP2040 Board Support Package im embOS Cortex-M ES ausprobiert und konnte Ozone aus dem Embedded Studio heraus starten und die App dann laufen lassen. https://www.segger.com/downloads/embos/embOS_CortexM_EmbeddedStudio_Trial Was ich nicht probiert habe, ist ein neues ES Projekt zu generieren und damit Ozone zu starten. Kann ich aber im Zweifelsfall auch gerne nochmal testen. D.h. prinzipiell sollte Ozone aus ES heraus starten kein Problem sein. Alternativ kannst du natürlich auch direkt Ozone starten und ein neues Ozone Projekt anlegen. https://wiki.segger.com/Ozone
Ich habe mir das mit dem RP2040 doch gerade noch einmal mit ES V7.32 und Ozone 3.30c angeschaut. Das Problem ist der Bootloader im RP2040: https://wiki.segger.com/Debug_on_a_Target_with_Bootloader#ROM_bootloader Am besten so vorgehen: 1. ES Projekt für den RP2040 generieren und bauen. 2. Ozone aus ES heraus starten und das Ozone Projekt speichern. Ozone beenden. 3. Die Ozone Projektdatei wie im Wiki Artikel beschrieben bearbeiten. 4. Ozone über die Projektdatei öffnen und Debug Session starten. Jetzt sollte man ganz normal debuggen können. Solange Ozone noch offen ist, kannst man einfach nach ES wechseln, neu compilieren, und zurück zu Ozone wechseln. Ozone erkennt dann, dass das ELF sich geändert hat und bietet an, es erneut zu laden.
Til S. schrieb: > Vielleicht hilft das hier: > https://wiki.segger.com/Port_Projects_from_IAR_Embedded_Workbench_to_Embedded_Studio Hallo Til, der Artikel bezieht sich auf V5.32a und der Import läuft bei mir auch mit V5.70a. Bei V7.32 passiert jedoch nichts; schon die Meldung, daß Dateien importiert wurden, erscheint nicht. Das scheint ein spezielles Problem bei RP2040-Projekten zu sein. Mit STM32-Projekten läuft der Import wie erwartet. Mit dem verfügbaren RP2040-Beispielprogramm (main.c und bsp.c) blinkt die LED, wenn das Programm auf das Pico-Board gespielt wurde. Wird Ozone aufgerufen, gibt es einen Hardfault-Error. Der PC wackelt zwischen 0x30 und 0x32. Das ist wohl im RP2040 internen Speicher. Mit dem doppelten Bootloader ist der RP2040 eh ekelig zu debuggen, aber das ist ein anderes Thema. Bei anderen Versuchen bekam ich Fehlermeldungen auf rotem Feld, die den J-Link betreffen. Verbindungsfehler, fehlende Script-Datei (wie, wo, was?), obwohl der J-Link beim Laden und Ausführen der Programme einwandfrei lief. Noch ein Punkt: wenn man morgens das ES neu startet, hängt es fest und zeigt in der obersten Zeile .... (Building) an und hängt voll in den Seilen. Man muß zunächst J-Link entfernen, bevor sich das Programm dafür bedankt, daß man es benutzt ;-) Im Projekt-Manager gibt es die beschriebene Möglichkeit - Import von Dateien - irgendwie nicht. Bei RP2040-Projekten hängt ja im Hintergrund teilweise das Pico-SDK. Für mich ein "widerliches Zeug", wo man den Wald vor lauter Bäumen nicht sieht. Meine Idee war, nur die notwendigen Dateien aus dem Dateibaum ins Projektverzeichnis zu bekommen, daß man den unbenutzen Rest entfernen kann. Das Projekt würde dadurch kompakt. Man kennt das ja von CubeMX, wo optional nur die benutzen Dateien ins Projekt eingebunden werden: alles bleibt gut übersichtlich. Es gäbe noch mehr zu berichten, es würde jedoch zu lang werden. Noch habe ich meine IAR-Möglichkeit, dessen Ergebnisse ich abschließend als ES-Projekte zusammenkopieren kann, sofern ich diese öffentlich zugänglich machen möchte. Der Anwender soll dadurch in der Lage sein, ohne großen Aufwand Änderungen am Programm vorzunehmen. Mit den neuen Einschränkungen von IAR ist das nicht mehr möglich. Gerade in Bezug auf den günstigen RP2040 ist ES auch eine gute Alternative zu der Pico-SDK IDE. Selber bin ich zu blöd, das auf Windows mit CMAKE und was auch immer zu installiern. PIOASM kann man mit ein wenig Kopfarbeit auch ersetzen. Til S. schrieb: > Ich habe mir das mit dem RP2040 doch gerade noch einmal mit ES V7.32 und > Ozone 3.30c angeschaut. Das Problem ist der Bootloader im RP2040: Das kam jetzt, während ich meine Antwort geschrieben habe. Ich sehe es mir an. Noch etwas: Beim Programmlauf ohne Ozone werden zwar die PC-Adressen angezeigt, aber der Binär-Code ist "dummy". Egal, alles braucht seine Zeit.
Mi N. schrieb: > Wird Ozone aufgerufen, gibt es einen Hardfault-Error. Ja, genau, in dem Fall ist PC und SP wegen des Bootloaders nicht korrekt gesetzt und man landet im HardFault. Mi N. schrieb: > Bei anderen Versuchen bekam ich Fehlermeldungen auf rotem Feld, die den > J-Link betreffen. Verbindungsfehler, fehlende Script-Datei (wie, wo, > was?), obwohl der J-Link beim Laden und Ausführen der Programme > einwandfrei lief. > Noch ein Punkt: wenn man morgens das ES neu startet, hängt es fest und > zeigt in der obersten Zeile .... (Building) an und hängt voll in den > Seilen. Man muß zunächst J-Link entfernen, bevor sich das Programm dafür > bedankt, daß man es benutzt ;-) Das hatte ich so beides noch nicht. Passiert das auch mit der neuesten ES und J-Link Version? Wenn du andere IAR Projekte importieren kannst, vermute ich das an dem RP2040 IAR Projekt irgendwas IAR spezifisch neu/anders ist, was dann ES vielleicht noch nicht kennt. Ist nur ein educated guess. Am besten bei uns Forum melden, dann können evtl. die ES Kollegen weiterhelfen. Mi N. schrieb: > Noch etwas: Beim Programmlauf ohne Ozone werden zwar die PC-Adressen > angezeigt, aber der Binär-Code ist "dummy". Meinst du das Disassembly im ES? Ich schicke dir ansonsten auch gleich mal meine Emailadresse per PN.
Vielleicht macht ihr einen extra Thread dafür auf?
Ja, sorry, deswegen der Vorschlag mit unserem Forum und ich habe ihm meine Emailadresse per PN geschickt. Wir klären dann auf dem Weg alles weitere :-).
IDE benutze ich eigentlich gar keine, als Editor meist den vom Midnight Commander. Als Compiler für die meisten Architekturen den GCC in einer gut abgehangenen 4.92er Version, für MCS51, HCS08 und STM8 den SDCC, für PICs bin ich mittlerweise vom SDCC auf den XC8 umgestiegen. Dazu automatisch generierte Makefiles, Linkerscripts, Includes, Startup-Code sowie eine inzwischen teilweise über 2000 Funktionen enthaltene "Universal-Library", die gleichzeitig als HAL dient. Das Ganze ist dann noch auf meinen Universalprogrammer zugeschnitten, wo die Architektur es zulässt, kann man auch für Tests kleinere Programme im RAM starten. Ansonsten reicht ein "make prog". Inzwischen nutze ich das auch beruflich, um "mal schnell" kleine Testprogramme zur Überprüfung der Baugruppenfunktionalität zu schreiben. Jörg
Joerg W. schrieb: > über 2000 Funktionen > enthaltene "Universal-Library", Wo kann ich die Library bestaunen und re-use machen?!
> Wo kann ich die Library bestaunen und re-use machen?! Über eine Veröffentlichung habe ich mir auch schon Gedanken gemacht, bin aber da noch zu keinem gescheiten Konzept gekommen. Von den Lizenzen sollte es eigentlich passen, wenn ich die Lib unter GPL/LGPL stelle, bei manchen Sourcefiles müssten aber die wohl die originalen Kommentare oben rein, da die anfangs beim automatischen Erstellen der Header-Datei gestört hatten bzw. angepasst werden mussten. Zum Einem ist das Ganze inzwischen so automatisiert, dass man den zum Bauen notwendigen "Tool-Zoo" (mit fest eincodierten Pfaden ;-) auch mit veröffentlichen, anpassen und dokumentieren müsste. Dann sind die Sources sämtlicher "Highlevel-Funktionen" von einem zentralen Verzeichnis per Symlinks in die Source-Bäume der einzelnen Controller-Familien gemappt, die ließen sich zur Not beim Packen auflösen. Aber damit wird das halt nur eine Art "Snapshot". Meine eigene Versionsverwaltung auf Subversion oder Git zu portieren habe ich im Laufe der Jahre nicht nur einmal versucht, habe es aber jedes mal wieder aufgegeben, weil es mir letztendlich keinen Nutzen gebracht hat. Bis auf reine Berechnungsfunktionen, die sich sowieso alle irgendwo im Internet finden lassen sollten, baut alles andere auf controllerspezifischen Low-level Funktionen auf. Und die wiederum auf den controllerspezifischen Headerfiles, die ich zum Großteil selbst erstellt habe und oftmals auch nur die von mir genutzten Registerdefinitionen und jede Menge Konstanten enthalten. Ein Kompromiss wäre, "Pakete" für verschiedene Controller bereitzustellen (mache ich intern auch schon), die dann schon alle notwendigen Dateien nebst einem Rumpf-Projekt enthalten. Und davon getrennt die ganzen Sourcen, aber ohne die Tools und weiteren Kontext. Denn schon allein die Dokumentation der ganzen Funktionen würde einen Riesenaufwand bedeuten. Beispiele kann ich in der Zwischenzeit aber schon zur Verfügung stellen. Jörg PS: Durch einen Fehler in einem Generierungs-Script sind wohl globale Variablen mit als Funktionen gezählt worden, so dass sich die Anzahl der Funktionen auf ca. 1100-1300 reduziert. Bei den PICs noch weniger, da ich dort nur das Nötigste implementiert habe.
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.