Author
|
Topic: Hilfe beim Flashen via JLink (Read 5593 times)
|
|
DB4PLE
positron
Urgestein
 Offline
Posts: 1278
|
 |
Re:Hilfe beim Flashen via JLink
« Reply #45 on: 31. March 2016, 18:36:06 »
|
|
Hallo Markus,
ich genau diesen Artikel genutzt beim Umbau auf die Nutzung des CCM.
BTW, hast Du schon mal ein "normales" Image und Bootloader reingeflasht?
Die Memorymaps sind ja kompatibel. D.h. fürs erste würde auch das normaler Linkerscript reichen (natürlich gibt es dann keinen extra RAM).
Bzw, funktioniert bei Dir schon was?
Würde mir evtl. auch einen 439 aufs "nächste" UI Board packen.
73
Danilo
|
|
 Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #46 on: 31. March 2016, 20:13:16 »
|
|
Hallo Danilo,
zuerst habe ich mit den Projekt *.ld Files gearbeitet,
was auch sofort geklappt hat.
Heute habe ich nach einigen Vorschlägen aus dem
mikrocontroller Foum eigene Linkerfiles benützt.
Wie kann ich in diesem Forum mehrere Anhänge
an einen Beitrag dranhängen?
Ich schaffe es nicht!
Markus
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #47 on: 31. March 2016, 20:13:57 »
|
|
Anhang #1
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #48 on: 31. March 2016, 20:14:20 »
|
|
Anhang #2
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #49 on: 31. March 2016, 20:15:48 »
|
|
Anhang #3
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #50 on: 31. March 2016, 20:25:07 »
|
|
Hallo Andreas,
hallo Forum,
wie muss ich Eclipse einrichren (Addon), damit ich unter dem
Menu Project ein Github-Project importieren kann.
Im Augenblick finde ich keine Stelle, wo ich einen Project-
Import machen kann.
Markus
DL8MBY
|
|
Logged
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #51 on: 31. March 2016, 20:29:22 »
|
|
Habe es gefunden,
Import project using "File->Import->General->Existing Project".
Sorry!
Markus
|
|
Logged
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Hilfe beim Flashen via JLink
« Reply #52 on: 01. April 2016, 06:13:48 »
|
|
Hallo Markus,
bezüglich der Linker Scripts: Der einzig relevant Unterschied ist ja das Ende des RAM (192k statt 128k) und des Flashsizes. Ich denke,wir können das in einem gemeinsamen Linker Script abhandeln, sofern wir für die beiden Prozessorklassen ein Symbol definieren, darauf kann man im Script dann reagieren. Das sollte absolut kein Problem machen, da ja im Code entsprechende #defines gesetzt werden. Werde ich heute abend mal ausprobieren. Alternative natürlich die Behandlung im Makefile. Aber bei soviel Gemeinsamkeiten wäre es besser die Dinger zusammenzuhalten.
Lediglich wie genau man die RAM/FLASH Size Expression im Linker Script schreibt, wäre zu erproben.
73
Danilo
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #53 on: 01. April 2016, 13:15:51 »
|
|
Leider geht es jetzt doch wieder durcheinander, das sollte so nicht sein...
Ich probier mal das auseinander zu fädeln...
Andreas:
Ich möchte natürlich kein Makefile erstellen, das inkompatibel zu einem der präferierten Systeme ist. Daher die Tests hier mit ein paar Freiwilligen und nicht per Commit im git. Erst wenn alles passt, wird das freigeschaltet.
Offene Punkte:
- Kompatible CPUs auf einfach Art unterstützen
- Compiler generierte Dateien (.a, .o...) in ein Verzeichnis umlenken und gewünschten Output in einem eigenen Ordner mit mehr Aussagekraft im Namen.
- Korrekte Implementation von Speicherbereichen für die verschiedenen Spezialaufgaben (virt. EEPROM, High-Speed RAM...) via Linker File
Mir fällt da noch viel ein...
Die oberste Prämisse ist Kompatibilität und einfache Benutzung, unabhängig von der IDE und unabhängig von der gcc Version.
Leider ist es nicht Einfach, die korrekten Informationen immer parat zu haben, aber es ist einfach zu viel parallel und zu viel für einen alleine alles beieinander zu halten.
Nur mal am Rande: 4.8 bis 4.9.2 sind nicht otimal bzw. buggy, erst 4.9.3 ist halbwegs brauchbar. Ubuntu installiert aus den normalen Paketquellen einen gepatchten 4.9.3, aber nur, wenn man Ubuntu 15.10 einsetzt. Ich weiß aber nur, dass in diesem 4.9.3 einige Bugs in Bezug auf den Linux kernel behoben sind.
Es gibt aus meiner Sicht eine einfache und eine zuverlässige Quelle für einen modernen gcc, das ist entweder die einfache Variante https://launchpad.net/gcc-arm-embedded oder die zuverlässige, da dort aktiv Toolchains auch für automotive und industriellen Einsatz gepflegt werden. Allerdings sind auch deren Versionen mit den bekannten Bugs der 4.8er und 4.9er behaftet, man sollte also auch da keinen Compiler älter als 2015.4 herunter laden.
Danilo,
auch wenn der Umbau auf CCM sinnvoll ist, wäre es nett gewesen nicht meinen Thread dafür zu hijacken. Nun muss ich Markus Posts ausfiltern, denn ich war ja bereits dabei sein Problem zu lösen.
Es kann nur dann ein gemeinsames Linker-Script geben, wenn man einen Compiler > 4.9 einsetzt, der kann per Linker Flags Variablen im Linker Script überschreiben, also so, wie ich es mit sram0_size in meinem Post gemacht habe.
Alle älteren Compiler können das noch nicht. Leider ist Andreas der Überzeugung, dass der 4.8er Compiler der einzige ist, der zuverlässig funktioniert.
Leider ist es tatsächlich so, dass wenn man ein und den selben Code erst mit 4.8 baut und flasht und dann mit 4.9 baut und flasht, einigen Ärger mit dem virtual-EEPROM bekommt. Das wiederum ist aber ein Problem mit dem ungeeigneten Linker Script.
Markus:
Ich nutze den gcc 5.2 (Bitte nicht noch einen ollen 5.0 oder so installieren!) und damit kann ich den mcHF vom git problemlos auch für Deinen 293IV bauen. Es gibt keine Warnings und keine Errors.
Leider weiß ich jetzt nicht mehr so wirklich, was ich tun soll, denn eigentlich sollen alle das unbeherrschbare Eclipse Projekt nutzen, statt eines einfach anpassbaren Makefiles. Parallel wird das Linker Script schon zerlegt und es wird eine komplett veraltete Compiler Version genutzt...
Ich möchte aber ungern forken und einfach alles hier links liegen lassen... Blöde zuzusehen, wie sich die Leute verrennen und keiner hört zu...
73 de Astraliix
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Hilfe beim Flashen via JLink
« Reply #55 on: 01. April 2016, 16:12:41 »
|
|
Hallo Astralix,
sorry, wenn ich eine Thread gehijackt haben soll, aber den CCM hat Markus reingebracht und ich habe lediglich geschrieben, das diese Info bereits genutzt ist. Tatsächlich ist mir Post #29 durch die Lappen gegangen, in dem Du ein andres Make und Linker-File gepostet hattest.
Ich schlage deswegen zur Beruhigung der Gemüter vor, dem sehr kontroversen Thema "Gestaltung der Build-Umgebung" ein eigenes Thema zu widmen.
73
Danilo
|
| « Last Edit: 01. April 2016, 16:17:12 by DB4PLE » |
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #56 on: 01. April 2016, 16:37:12 »
|
|
Andreas, ich wäre ja voll bei Dir... Das Problem bin aber nicht ich, sondern der gcc...
Der Alte ist buggy, der Neue kann Dinge, die das Leben vereinfachen und mein Makefile macht es egal, wo der gcc installiert ist. Der Alte wird nicht besser, nur weil er zufällig manchmal installiert ist und weil ihn alle nutzen und sich über die Probleme, die er macht, ärgern.
Mit dem modifizierten Makefile können alle den neuen gcc einfach laden, entpacken und irgendwohin kopieren. Man kann sich dann am Anfang im Makefile diesen Ort für die Toolchain eintragen und fertig.
+ gcc Ort egal
+ IDE egal
+ CPU egal
- Extra runterladen, entpacken und verlinken im Makefile
Ich kann den Ansatz verstehen, Eclipse installieren und gnuarmeclipse drüber installieren. Dummerweise verlinkt dieses dann auf den alten 4.8er "https://launchpad.net/gcc-linaro" statt dem richtigen "https://launchpad.net/gcc-arm-embedded".
Damit ist das Problem dann da.
Der 4.9 hat so viele Probleme, dass es egal ist, ob er mitgeliefert wird, er funktioniert erst ab 4.9.3. Die älteren Versionen können vorab gebaute Bibliotheken nicht linken, daher funktionieren 4.9.0-4.9.2 einfach nicht. Das Makefile vom Kernel schließt diese Versionen ebenfalls hart aus.
Ich kann gerne mal eine VM bauen, die Eclipse und einen passenden gcc beinhaltet. Wenn daran Interesse besteht, dann melden. Ich werde aber nur eine VM bauen und pflegen, nicht das jetzt jeder mit seinem eigenen Linux-Derivat kommt.
Wenn sich mehr als 10 Leute finden, die Interesse an einer mcHF VM haben, dann mache ich mir gerne die Mühe.
Müssen dann nur einen Ort finden, wo ich sie lagern kann.
Andreas, kann man dazu einen kleinen Umfrage-Thread starten?
73 de Ulrich aka Astralix
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Hilfe beim Flashen via JLink
« Reply #57 on: 01. April 2016, 16:46:40 »
|
|
Hallo Ulrich,
die GNU ARM Eclipse Website sagt ganz deutlich, für bare metal, nimm die GCC ARM Embedded Tool chain. Nur für Linux target apps (also Anwendungen, die auf Linux laufen sollen) wird Linaro empfohlen. Siehe unten.
The build plug-in is highly configurable in terms of executable names and location, so you can use any 32/64-bits ARM GNU toolchain you preffer, but, for better results, the recommended toolchain for bare metal target applications is GCC ARM Embedded (formerly GNU Tools for ARM Embedded Processors); for GNU/Linux target applications, the Linaro family of toolchains provides a large selection of choices, for various specific needs (little/big endian, 32/64-bits, etc).
Ansonsten würde ich trotzdem die Auslagerung in einen anderen Thread vorschlagen.
73
Danilo
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #58 on: 01. April 2016, 19:37:29 »
|
|
Hallo Danilo,
ist mir klar, wozu welche der Toolchains gedacht ist. Ich mache ARM Linux, Cortex embedded und ähnliches ja auch schon über 10 Jahre. Es ging mir darum zu verhindern, dass tote Pferde geritten werden, nur weil man einen Schritt beim Aufsetzen der Build-Umgebung sparen kann. Gleichzeitig fängt man sich auch noch unnötige Probleme durch bugs ein und macht sich die Konfiguration und Anpassung schwer.
Aber Andreas hat genug damit zu tun, die Features der eigentlichen Software zu pflegen und noch vieles mehr. Daher mein Angebot für alle eine VM zu bauen, in der alle einfach in die mcHF Entwicklung rein starten können. Das hätte den Vorteil, dass alle auf dem gleichen System entwickeln und die gleichen Tools nutzen. Updates von Toolchains kann man dann einmal einfach beschreiben und muss keine Rücksicht auf Unterschiede nehmen.
Wir arbeiten nämlich gerade auf die String-Theorie hin, die sind jetzt bei ca. 11 Dimensionen und wir haben unterschiedliche Linux Distris teilweise in unterschiedlichem Stand (Debian, Ubuntu 13.x bis 15.x) Windows XP, 7, 8, 10, gcc 4.8, 4.9.x, 5.x und Eclipse K, L, M...
Die paar Hardcore-Entwickler, die gerade im git eine Verbesserung nach der anderen einpflegen (Hochachtung!) sollten auf Linux unterwegs sein, also müssen wir alle anderen nur noch auf den gleichen Stand bringen. Und in der private Edition ist in Virtual-Box auch USB mit drin, man kann also auch fertige Scripte für STLink hinzufügen und das Debugging und Flashen einrichten.
Das würde verhindern, dass Markus mit seinem STM32F493IV keinen Code generieren kann, obwohl das bei mir einwandfrei funktioniert. Keiner der Linux Spezis muss jetzt auf die VM wechseln, aber ein Linux Spezi kann einem Windows User eben besser helfen, wenn der eine Linux VM einsetzt 
vy 73
Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Hilfe beim Flashen via JLink
« Reply #59 on: 01. April 2016, 20:41:58 »
|
|
Hallo Ulrich,
Kurzzusammenfassung:
ich bin absolut und uneingeschränkt dafür, das die Entwicklung für den mcHF für jeden der mitmachen will, so einfach und bequem wie möglich ist.
Deshalb findet dein Vorschlag, eine VM aufzusetzen und zu pflegen, meine volle Unterstützung, weil das für einen Teil die Hürde stark senken kann. Aber nur für einen Teil der mcHFler.
Für die, die gerne langatmige Ausführungen lesen wollen:
ABER ich darf zu bedenken geben:
Die meisten Leute mit Windows motiviert man nicht mit einer Linux VM.
Und die meisten Leute haben Windows (größer 80%). Dann noch MacOS und dann Linux erst Linux.
Ich kann jetzt noch ein paar Argumente nennen, die eine VM Lösung nicht mehr so einfach für den normalen Anwender erscheinen lassen (übrigens ist das quasi unabhängig vom Betriebssystem der VM):
- Datenaustausch:
Wie kommt das Binary aus der VM?
Mit scp/ssh [Wer kann das]?
Über Netzwerklaufwerk? Muss man das Netzwerk mit der VM ans Laufen bekommen, ist sowohl unter Linux als auch unter Windows für den Laien viel Spass.
- Debugging: Wer weiß wie man einen ST-Link in die VM einbindet?
Git/Github ist übrigens auch eine Hürde, die man nicht unterschätzen darf. Frag mal Frank, DD4WH.
Und hier der nicht noch weniger wichtige Teil:
Und mit Windows kann man auch prima für den mcHF entwicklen: Ich habe Windows 7 und 10 plus Eclipse 4.5 plus gcc 5.2.. Und vorher auch mal CoIDE, weil das wirklich am einfachsten aufzusetzen war/ist (ist beim ernsthaften Entwickeln nicht top, keine Frage, da ist Eclipse besser). Ich bin übrigens absolut kein Linux-Gegner, eher im Gegenteil. Aber bei Windows ist in der Tat die Varianz zwischen den Version sehr viel geringer als zwischen den Linux-Distributionen, da macht sich Micosoft sehr viel Mühe damit. So sind die Anleitung und die Binaries für Windows im Prinzip mindestens von Vista bis 10 so lauffähig, Windows XP weiss ich nicht, geht aber vermutlich auch. Versuche das mal mit einer ausreichend alten Linux-Distribution.
Nochmal die Zusammenfassung:
All das oben geschriebene spricht absolut nicht gegen deine Idee, sollte man diese Gedanken aus meiner Sicht beachten, wenn man andere für die Mitarbeit begeistern will. Nicht das was einem selbst am besten gefällt, ist immer auch für die Mehrheit das Einfachste/Richtige.
Das allerdings ist nur meine persönliche Meinung, das kann jeder anders sehen.
BTW, wenn es so eine VM mit Eclipse vor 3 Monaten zum Download gegeben hätte, hätte ich die vermutlich sofort benutzt. Aber ich habe auch mehr als 25 Unix-Erfahrung und bin da nicht ganz unvoreingenommen. So war für mich Windows einfacher. Meine kleine Debian Jessie VM mit der Kommandozeile haut mich da nicht wirklich vom Hocker, die nehme ich nur, wenn ich mal Spaß mit dem gcc 4.9 und make haben will.
73
Danilo
|
| « Last Edit: 01. April 2016, 20:57:30 by DB4PLE » |
Logged
|
|
|
|
|
|
|
STM32F439VITx_FLASH.ld.txt
