Pages: 1 ... 3 4 [5] 6 
|
 |
|
|
Author
|
Topic: Hilfe beim Flashen via JLink (Read 5572 times)
|
|
DB4PLE
positron
Urgestein
 Offline
Posts: 1278
|
 |
Re:Hilfe beim Flashen via JLink
« Reply #60 on: 01. April 2016, 20:57:05 »
|
|
Hallo,
noch ein Nachsatz aus technischer Sicht: 40x vs. 439: Der Compiler selbst kennt keinen Unterschied zwischen den Prozessoren, für den ist alles ein Cortex-M4 usw. Der Unterschied entsteht eigentlich erst im Quellcode und beim Linken (da haben wir zur Zeit auch keinen, es wird nirgendwo abgefragt, ob man Prozessor X oder Y hat, nur die Familie STM32F4XX).
Wenn man irgendwelche Spezialitäten vom 439 nutzen will, ganz andere Story, dann muss man sowohl im Code als auch im Linkerscript wissen ob man 40x oder 439 etc. ist.
Was ich AUCH NICHT weiss, ist, ob der Code irgendwelche Unterschiede machen muss, damit er auf dem 439 richtig läuft (Interrupthandler-Tabelle etc.), da habe ich mich nicht eingelesen. Soweit ich aber die Bilder im Thread überblicke, ist der binäre Code auf dem mcHF schon gelaufen.
Da ist noch ein weites Betätigungsfeld, aber es gibt da ja einige mit den 4x7/9 auf der Platine.
73
Danilo
|
|
 Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #61 on: 01. April 2016, 21:11:58 »
|
|
Danke für die ausführliche Antwort,
das ist ja der Grund, warum ich das hier etwas ausdiskutiere, denn es gibt bei jedem Schritt vorwärts nun mal auch mal Gefahren oder zwei Schritte rückwärts in der Folge.
Der mcHF ist für Funkamateure ein echter Knaller, für Einsteiger und für Profis, weil er so richtig offen ist und für ein SDR auch vergleichsweise preiswert. Dazu kommt der HAM-Spirit, wenn mal wieder Lötzinn in der Luft liegt. ABER er ist von der Software her alles andere als einfach. Das liegt noch nicht einmal an den kleinen Bugs im Design, sondern SDR ist nichts, was man mal eben nebenbei macht. Und alles in Software lösen heißt ja nur, dass die Probleme dann eben nicht in der Hardware, sondern in der Software landen.
Es ist dabei auch völlig egal, welches Betriebssystem man nutzt, die Toolchain muss passen. Und wie ich gerade lese, hast Du Dich auch für die passendere Toolchain entschieden und nutzt gcc 5.2.
Ich würde auch viel lieber in der Software vom mcHF selber arbeiten, als an einer VM, aber es ist schwer un-aufgeblähte Makefiles und Linker-Scripte zu schreiben, wenn man 6 Betriebssysteme mal 6 Compiler mal 4 Build-Tools berücksichtigen muss. Das ist nicht zu pflegen.
Daher bin ich ja unschlüssig, denn wie Du sagst, der "Profi" hat auf seinem System keine Probleme mal schnell das ein oder andere Tool zu wechseln, der Laie scheitert an Dingen, die mit der Auswahl des richtigen gcc nichts zu tun haben.
Selbst wenn ich eine VM aufsetze, muss man sich immer noch die git credentials anlegen um github rein zu kommen oder sich mit gitk und cola vertraut machen.
Also ich arbeite da, wo Ihr es am nützlichsten haltet, Linker Scripte, Toolchain, VM, EPROM Treiber oder ein paar Updates der CMSIS zum Frühstück?
vy 73 de Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DF8OE
Administrator
Offline
Posts: 6268
Stellvertr. OVV I40, Jugend / Nachwuchsreferent
|
|
Re:Hilfe beim Flashen via JLink
« Reply #62 on: 01. April 2016, 21:19:48 »
|
|
Auch ich habe nichts gegen eine VM.Nur würde ich sie nicht nutzen, weil ich ein LinuxSystem in meiner Produktivumgebung habe und nicht für den mcHF eine eigene Umgebung benutzen möchte.
Wieviele von Windows auf eine solche VM umstigen woll(t)en, kann ich nicht beurteilen.
Aber ich kann beurteilen, wieviele Bugs des 4.92 mir aufgefallen sind, deit ich für den STM32 compiliere:
2.
1) der C11/C99 mode ist fehlerhaft. Das ist für mich kein Problem - ich nutze die Besonderheiten, die diese Modes voraussetzen, einfach nicht.
) Es gibt eine "Überoptimierung". Aber auch einen guten und funktionierenden Ansatz, wie man diese umschifft.
Also gab es bei all den Aktionen, die ich seitdem gemacht habe KEIN ernsthaftes Problem mit dem 4.92. Und da ich doch recht viel gemacht habe, glaube ich, dass auch andere keine Probleme finden würden. Der gesamte Code aller anderen kompiliert auch ohne Probleme auf dem 4.92.
Ich bin KEIN Freund "stets der neuesten Version". Deswegen habe ich mich bewusst für Debian entschieden - und bin auch in Sachen STM32 Development noch nicht enttäuscht worden.
Kurzfassung:
Eine VM bereichert die Einsteigermöglichkeiten. Sie sollte aber folgende Möglichkeiten beeinhalten:
1) Eclipse sollte mit drauf sein
2) der STLINK-V2 sollte unterstützt werden (sowohl zum Programmieren des STM als auch in den gdb auf Eclipse zum Debuggen).
3) Ein Dateiaustausch via Samba sollte mit dabei sein
Auch habe ich kein Problem damit,sowas zum Download zu hosten. Ich habe einen eigenen Rootserver, auf dem unter anderem unsere OV Seiten liegen. Da ist noch jede Menge Platz, und elbst GitLab könnte ich darauf installieren, wenn es irgendwann mal nötig wäre.
Aus Gründen einer einfacheren Pflege (ich betreue viele Rootserver) aber *NUR* mit Paketen aus Repositories...
vy73
Andreas
|
|
Logged
|
Wenn der Wind des Wandels weht, nageln die einen Fenster und Türen zu und verbarrikadieren sich. Die anderen gehen nach draußen und bauen Windmühlen...
qrz.com-Seite von DF8OE
-----------------------------------------------------
>>>> Die Inhalte meiner Beiträge dürfen ohne meine explizite Erlaubnis in jedwedem Medium weiterverbreitet werden! <<<<
|
|
|
DB4PLE
positron
Urgestein
Offline
Posts: 1278
|
|
Re:Hilfe beim Flashen via JLink
« Reply #63 on: 01. April 2016, 21:44:30 »
|
|
Hallo Ulrich,
meine persönliche (!) Meinung:
- eine voll eingerichtete VM wäre schon gut (trotz aller der negativen Dinge, die ich aufgezählt habe und über die man sich Gedanken machen sollte). Damit können wir dann auch mal Erfahrungen sammeln, ob sich das lohnt. Ohne das es jemand macht, werden wir es nicht rausfinden.
- Super wäre auch wenn jemand mal das Aufsetzen Debugging für die Kommandozeile beschreiben würde. (Da war CoIDE übrigens spitze: ST-Link drangesteckt und auf Debug gedrückt, so muss das sein). Im Eclipse hab ich es ja hinbekommen, aber meine Tage mit dem gdb sind sehr lange her und openocd gab es da noch nicht), da habe ich auch keine Lust dazu, debuggen geht in Eclipse so nett von der Hand, mit den HW und Peripherie-Registern direkt zum Anschauen.
Aber da das jetzt alles nicht wirklich Spass macht, hier noch ein paar Dinge mit möglicherweise mehr Spassfaktor:
- Makefiles etc. fitmachen für Nutzung mit anderer Prozessoren (wieso habe ich das Gefühl, das wir da schon drüber geredet haben ;-) )
- Rausfinden, warum wir diesen verdammten OTG HS (den gr. USB Port) nicht ans Laufen bekommen (sowohl im Bootloader als auch in der Main-App). Bootloader wäre super-praktisch, dann kann man gleich das CAT-Kabel dranlassen und mit dem Stick im USB Port eine neue FW flashen. Für die Armen ohne ST-Link (oder mit geschlossenem Gehäuse).
- Neues ordentliches Verfahren für die Speicherung der Konfiguration machen, das flexibel mit dem Rein und Raus von Parameter umgehen kann (das ist ein bißchen meine Baustelle)
- Code aufräumen, ordentliche Trennung von UI (Anzeige) und eigentlicher Funktion, dann kann man im nächsten Schritt auch endlich ein RTOS wie FreeRTOS (mein aktueller Favorit) einziehen.
- Echtes Touch UI machen, denn nur so kann man bei vielen neuen Funktionen eine ordentliche Bedienung hinbekommen (Z.B. Stations-Speicher mit Namen )
- Code aufräumen (da geht immer noch was)
- neue Funktionen einbauen
- Automatisierte Test entwerfen
- Code aufräumen (wenn man denkt, man ist fertig, ist es schon wieder soweit)
...
Und da gibt es sicher noch mehr Ideen bei anderen... Du hast es so gewollt :-)
73
Danilo
73
Danilo
|
|
Logged
|
|
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #65 on: 03. April 2016, 17:08:20 »
|
|
Hallo Ulrich,
- eine voll eingerichtete VM wäre schon gut (trotz aller der negativen Dinge, die ich aufgezählt habe und über die man sich Gedanken machen sollte). Damit können wir dann auch mal Erfahrungen sammeln, ob sich das lohnt. Ohne das es jemand macht, werden wir es nicht rausfinden.
|
|
Das sehe ich auch so. Eine eigens dafür gebaute VM kann man ja auch so präparieren, dass der Einstieg ins Projekt leicht fällt, also ein paar Icons auf den Desktop als alles in Menüs versteckt.
- Super wäre auch wenn jemand mal das Aufsetzen Debugging für die Kommandozeile beschreiben würde. (Da war CoIDE übrigens spitze: ST-Link drangesteckt und auf Debug gedrückt, so muss das sein). Im Eclipse hab ich es ja hinbekommen, aber meine Tage mit dem gdb sind sehr lange her und openocd gab es da noch nicht), da habe ich auch keine Lust dazu, debuggen geht in Eclipse so nett von der Hand, mit den HW und Peripherie-Registern direkt zum Anschauen.
|
|
Ich bin mir nicht sicher, ob man gdb auf der Kommandozeile wirklich braucht. Wenn man mit Optimierungen arbeitet, kann der gdb eben oft nicht mehr auf die aktuelle C-Zeile zurück schließen und dann ist eben Assembler angesagt. Aber der ARM Assembler ist gut lesbar  Aber dagegen hilft auch gcc auf der Kommandozeile nicht. Wenn ich eine VM baue, dann ist da Eclipse vorinstalliert, gcc 5.2 und natürlich werde ich versuchen die stlink rules in udev gleich korrekt unter zu bringen.
Aber da das jetzt alles nicht wirklich Spass macht, hier noch ein paar Dinge mit möglicherweise mehr Spassfaktor:
|
|
Alles was das Projekt voran bringt, führt letztendlich dazu, dass man Spaß damit hat. Ich hatte mir vorgenommen meinen ersten Call mit einem selbst gebauten Gerät zu machen. Ich muss noch ein paar der Änderungen einlöten, die das Senden betreffen, sowie die Endstufen FETs. Dann fehlt nur noch die bestandene Prüfung in knapp 3 Wochen.
Wäre cool, wenn ich das eigene Vorhaben umsetzen könnte
- Makefiles etc. fitmachen für Nutzung mit anderer Prozessoren (wieso habe ich das Gefühl, das wir da schon drüber geredet haben ;-) )
|
|
Das mit den Makefiles, dem Linker und alles was Low-Level ist, ist mein Spezialgebiet. Daher werde ich mich auch in dieser Ecke beschäftigen. So oder so. Viele der seltsamen Erscheinungen, mit denen das Projekt immer wieder mal kämpft, rühren daher. Abund zu verlorene Settings, Optimierungsstufen, die nicht gehen... Das ist sehr oft ein Problem mit Linker und Makefile selten auch mit einem buggy gcc.
- Rausfinden, warum wir diesen verdammten OTG HS (den gr. USB Port) nicht ans Laufen bekommen (sowohl im Bootloader als auch in der Main-App). Bootloader wäre super-praktisch, dann kann man gleich das CAT-Kabel dranlassen und mit dem Stick im USB Port eine neue FW flashen. Für die Armen ohne ST-Link (oder mit geschlossenem Gehäuse).
|
|
Wenn Du mich da mal detailliert drüber aufklärst, wenn alle Stricke reißen und der Fehler ist im ST eigenen Treiber zu vermuten, dann habe ich email Adressen und Telefonnummern bis weit nach ST hinein. Die kann ich dann gerne aktivieren.
- Neues ordentliches Verfahren für die Speicherung der Konfiguration machen, das flexibel mit dem Rein und Raus von Parameter umgehen kann (das ist ein bißchen meine Baustelle)
|
|
Dazu hatte ich mir was feines ausgedacht, und der Code ist an dieser Stelle ohnehin sowas von überarbeitungsbedürftig...
- Code aufräumen, ordentliche Trennung von UI (Anzeige) und eigentlicher Funktion, dann kann man im nächsten Schritt auch endlich ein RTOS wie FreeRTOS (mein aktueller Favorit) einziehen.
- Echtes Touch UI machen, denn nur so kann man bei vielen neuen Funktionen eine ordentliche Bedienung hinbekommen (Z.B. Stations-Speicher mit Namen )
- Code aufräumen (da geht immer noch was)
|
|
da bin ich voll bei Dir! Allerdings haben wir mit FreeRTOS dann schnell wieder die gleichen Probleme wie mit CoIDE. Diese vorgefertigten Systeme tun vieles im Hintergrund automatisch, um den normalen Anwendungsprogrammierer zu entlasten. Muss dieser dann mal die Dinge ganz weit unten optimieren, dann lassen sie das nicht zu oder stolpern über diese Änderungen. CoIDE soll sehr zickig auf Optimierungen von Linker-Scripten reagieren. Mit FreeRTOS fehlt mir die Erfahrung.
Ich habe damals die STM32 in NutO/S (www.ethernut.de) integriert und weiß, dass dieses O/S gut damit umgehen kann, wenn man die Linker-Optionen extrem auf das Projekt anpasst. Dazu kommt, dass man dieses preemptive Multitasking System auch "torpedieren" darf, also zum Beispiel am System vorbei programmierte High-Speed Interrupts laufen lassen kann, ohne dass das ganze dann explodiert.
Die meisten RTOSe nehmen es nicht hin, wenn Dinge unter ihnen laufen, die sie nicht unter Kontrolle haben.
Was das Code aufräumen betrifft, so würde Eclipse uns eigentlich schon eine Menge Arbeit abnehmen, wenn alle Verantwortlichen in Eclipse arbeiten würden, bzw. eine mal hin geht, alle Dateien öffent und den Code-beautifier laufen lassen würde. Ich arbeite grundsätzlich mit dem K&R Style, der auch im Linux kernel verpflichten ist, allerdings mit zwei Änderungen, die der Lesbarkeit und den inzwischen üblichen 16:10 Monitoren geschuldet sind: Tabulator Breite 4 statt 8 und Zeilenende bei 120 Zeichen statt 80.
Mit einer einfachen Tasten-Kombi kann man eine ganze Datei damit aufräumen:
Rechts-Klick -> Source -> Format (oder SHIFT-STRG-F) wird die komplette Datei dan formatiert.
Wenn man nur noch das Einrücken korrigieren muss, tut es ein STRG-I
In Eclipse kann man dann auch automatisiert Header erstellen, wenn man in der Zeile über einer Funktion /** tippt, werden alle Variablen gelistet und man braucht nur noch die Beschreibungen hinzufügen.
Würde man diese Dinge für das Projekt verpflichtend machen, würde der Code sehr schnell und sehr lange gut lesbar werden.
Da die Dateien aber Kraut und Rüben sind, ist es sehr schwer, für neuen Code die Leute zu einem bestimmten Style zu überreden.
vy 73 Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #66 on: 04. April 2016, 19:56:24 »
|
|
Respekt, Danilo!
Was Du da für das Setup gemacht hast, ist ziemlich exakt das, was ich auch vorhatte. Große Tabelle mit Type, Pointer, Default und valid Range. War selber gerade dabei das aus einem Projekt heraus zu schnipseln, welches ich vor Jahren mal gemacht habe.
So eine Tabelle ist die einzig vernünftige Lösung.
Ich würde jetzt gerne das Virtual-EEPROM an eine feste Adresse im FLASH legen, was aber nur auf unschöne Art geht, denn wenn wir das Linker-Script anfassen und dort ein veeprom anlegen, stolpert die CoIDE darüber.
Vorschläge?
vy 73 de 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 #67 on: 04. April 2016, 20:28:56 »
|
|
Hallo Ulrich,
soweit ich den Flash-Code verstehe, liegt der Virtual EEPROM doch an einer festen Adresse (0x8008000). Der Code geht 32k später los, bei 0x8010000.
Wäre natürlich eleganter lösbar, aber 32k sind erstmal ganz ordentlich und soo groß ist der Verschnitt auch nicht. Insgesamt 64k Flash bei min. 512K sind jetzt nicht so schlimm aus meiner Sicht, insbesondere da wir derzeit bei ca. 240k Code plus Daten liegen. Und wenn Bedarf nach mehr besteht, können wir den Code einfach weiter nach hinten legen. Oder nach vorne. Ich würde die Lage ungern verschieben, denn das würde den EEPROM losen mcHFler den Tag vermiesen können. Kann man natürlich auch im Code behandlen, aber das wäre für mich derzeit keine Prio. Verbessert gehört insgesamt die Fähigkeit mit geänderten Konfigurationstrukturen umzugehen. Wenn ein Parameter so nicht richtig ist, müssen wir derzeit die Speicherstelle "aufgeben" und einen neuen Platz verwenden. Hat zwar den Vorteil, das alte Firmware die alten Daten genau da findet, wo sie sie gelassen hat, aber je öfter man das macht, umso mehr Schweizer Käselöcher entstehen im Speicher. Irgendwann sind dann die 32k voll.
Das ist meine nächste Baustelle, aber das sehe ich inzwischen etwas relaxter, wir werden noch ein Weile mit dem Käseverfahren leben können.
Was als nächster kommen wird, ist die Konvertierung von Konfigurationsparameter von alter Firmware auf neue Firmware, so dass man mal bestimmte Daten umstrukturieren kann, ohne das der geneigte OM seine Daten verliert, weil die neuen Parameter ja nichts von den alten Strukturen wissen (sollen).
Derzeit haben wir ca. 360 Werte a 2 Byte zu verwalten, da ist eben noch Platz bis 32k.
73
Danilo
|
| « Last Edit: 04. April 2016, 20:29:20 by DB4PLE » |
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #68 on: 04. April 2016, 20:39:32 »
|
|
Ja, das ist das, was ich im Zuge eines O/S angedacht hatte.
Wir benötigen ohnehin für viele Werte einen Namen, der auch schriftlich dargestellt wird (z.B. im Menu).
Diesen kann man dann auch gleich als Namen in einer Config-Datei nutzen. Nutzt man dann 64kB als zwei 32kB Dateien, könnte man im Zuge eines Updates obsolete Parameter ignorieren und neue mit Default hinzufügen, wenn man beim Speichern immer wechselseitig die 2x 32kB nutzt.Das halbiert die Schreibyklen und mit etwas CRC oder Versions-Info in den Settings kann man sogar 1x ein Downgrade auf die letzte Version machen, ohne dass man ein einziges Setting verliert.
Ist nur so eine Idee
vy 73 de 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 #69 on: 04. April 2016, 20:59:06 »
|
|
Hallo Ulrich,
ich bin vielleicht nicht so ins Detail gegangen: Genau so läuft es im Prinzip schon, es gibt 2 Pages a 16k, die wechselweise verwendet zu werden scheinen. So genau hab ich mir das nicht angeschaut, schien erstmal zu tun und war dementsprechend nicht die erste Baustelle. Insgesamt etwas verkompliziert wird das durch den I2C EEPROM, der, soweit vorhanden und groß genug, der "Hauptspeicher" für Konfigurationen wird.
73
Danilo
|
|
Logged
|
|
|
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #71 on: 05. April 2016, 08:01:04 »
|
|
Hllo Andreas, Danilo, Astralix und weitere Code-Gurus aus diesem Forum.
kann mir einer von Euch mal erklären wie aufwändig es ist die CMSIS
Schiene von ST zu verlassen und hätte das einen Sinn, was die Über-
sichtlichkeit des Codes anberlangt.
Zwar ist mit klar, dass man dadurch die ganzen fertigen Funktionen
selber machem müsste und auch seine eigenen Hardware Includes
bauen und warten müsste, aber auch den genzen ST Overhead los
wäre.
Ist das eine naive Frage?
Ich habe im MC-Forum auch einige Fragen zu dieser Thematik gelesen
und da sind sich die jeweiligen Lager Pro/Contra auch uneinig.
Würde das aber nicht dem Opensource Gedanken nächer kommen.
Bitte nicht missverstehen und gleich schimpfen, aber nach partiellem
Durchsehen des Codes fällt mir als Laie im Bezug auf ST-MCs auf,
dass da viel Komplexität wegen der ARM Compatibilität zu anderen
Controllern steckt, die wir beim mcHF nicht brauchen, da ja die HW
so wie sie ist festgeschrieben ist.
Die eingeführte Zwischenschicht, die z.B. die Entwicklungen im 'auto-
motiv' Bereich im proffesionellem Umfeld beschleunigt, baut ja auch
auf proffesionelle Werkzeuge, die wir im Hobby-Bereich so nicht zur
Hand haben.
Trotzdem bewundere ich die Arbeit derjenigen, die in diesem festgelegten
Schema sich trotzdem gut zurechtfinden, was wohl auch dem beruflichem
Umfeld geschuldet ist.
vy73
Markus
DL8MBY
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #72 on: 05. April 2016, 21:34:13 »
|
|
Hallo Markus!
Ich darf ganz kurz ausholen
Im Grunde ist es garkein Problem die CMSIS zu verlassen. Ich habe bei einigen Projekten die CMSIS ganz oder in Teilen ersetzt. Aber es gibt eigentlich kein Problem in der CMSIS. Denn die CMSIS ist von ARM für alle CortexM Prozessoren da.
Der Code von ST ist eine andere Geschichte, der hat aber mit der CMSIS nichts zu tun, auch wenn jeder glaubt, den in den CMSIS Ordner kopieren zu müssen Dieser Code von ST ist auf Erlernbarkeit getrimmt. Daher ist er aufgebläht und an vielen Stellen wenig optimal. Man muss eben einen Bildschirm voll Zuweisungen in ein struct schubsen, bevor man einen einzigen GPIO initialisieren kann. Ich werde meinen NutO/S GPIO Treiber die Tage rüber kopieren. Ein GPIO-Init ist eine Zeile. Viele GPIOS eines Ports mit gleicher Konfiguration sind auch nur eine Zeile.
RTOS / O/S... Es gibt eine Menge Alternativen, die alle ihre Vor- und Nachteile haben. Und eine Alternative ist z.B. CoIDE oder CoCox. Diese Kombination nimmt einem viel Arbeit ab. So erstellt sie diese Linker-Scripte und Makefiles intern und "belästigt" den Anwender nicht mit Dingen, über die man trotz der wenigen Zeilen ganze Master-Arbeiten schreiben kann.
Leider haben diese integrierten Umgebungen den Nachteil, dass sie es eben nicht vertragen, wenn man manuelle Änderungen an diesen intern bestellten Dateien vornehmen muss. Andererseits sind diese internen Dateien aber so essentiell und Änderungen an ihnen so schwierig, dass die meisten Anwender sie niemals sehen wollen und froh sind, dass es automatisch gemacht wird.
Und da ist nun unser Problem. Wir haben eine ganze Reihe Mitarbeiter am Projekt, die ihren Beitrag zu dem Projekt leisten, weil sie sich mit HF und SDR und Mathematik von Filtern auskennen. Sie haben Spaß daran sich in ihrer Welt auszutoben und sich nicht um ein fragiles komplexes System aus zusammen gesteckten Editore, Compilern, Debuggern, USB Treibern... zu kümmern.
Sie starten Windows, klicken auf CoIDE und das Projekt und nach ein paar Stunden gibt es ein paar gefixte Fehler in der Software und das 18m Band kommt ebenso dazu, wie die neuen Frequenzen auf 50Mhz.
----
Andererseits ist allen bewusst, dass durch die Einfachheit auf der einen Seite und durchaus einer Reihe von Leuten, die gewillt sind auf Linux, Eclipse, gdb... sich dieser Komplexität zu stellen, im Projekt selbst gewisse Spannungen auftreten. Jemand der sauberen Code programmiert wird niemals ein Array im Code einer hart codierten Adresse zuweisen, sondern einen entsprechenden Bereich im Linker-Script mit einem aussagekräftigen Namen versehen.
Leider ist genau das der Punkt, an dem CoIDE explodiert oder man, wie bei Keil oder anderen IDEs in Untermenüs mit 15 Etagen seltsame Werte eintragen muss, damit es funktioniert.
-----
Ehrlich gesagt, ich starte NutO/S in etwa 2h auf dem System. Damit haben wir kein Radio, aber ein komplettes O/S mit Threads, Semaphoren und Mailboxen. Dazu Treiber für die meiste ST Peripherie, I2C, SPI und DMA...
Aber die Voraussetzung wäre, dass wir auf Eclipse und gcc und Makefile umsteigen. Natürlich auch ein spezialisiertes Linker-Script.
Aber wie in der Diskussion zuvor durchscheint, es geht eher um die Basics. Wir können erst alle zusammen an dem Projekt arbeiten, wenn wir alle mit dem gleichen Werkzeug in ähnlichem Umfeld arbeiten. Wir müssen dazu nicht alle in einen Hobbyraum einziehen, aber egal ob Linux, Mac, Windows man müsste alle auf die gleiche gcc Version bringen, alle die gleiche gdb Version mit STLink und auch alle Makefile und Linker-Script.
Dann wäre die IDE sogar egal, die Windows Kollegen können sogar problemlos den MS C# Editor einsetzen, dieses Visual-Dingens. Aber das müsste eben beschrieben werden und das so gut, dass das jeder einfach nachvollziehen kann und erkennt, dass das nur ne Stunde kostet und dann kann er an seiner eigentlichen Aufgabe weiter machen.
Und das muss mal einer machen...
Danach steht uns eine Welt voller Möglichkeiten offen.
Es gibt noch so viel Code aufzuräumen, dass man noch eine ganze Weile mit diesem fragilen Mischmasch an IDEs und Toolchains leben kann. Aber wenn die Varianten durch Platinen-Revisionen oder verschiedene STM32F4 Typen, EEPROMs und neue Displays mehr werden, dann kommt die Stunde der Spezialisten für Make- und Linker-Scripte
Aber dann werden die CoIDE User freiwillig auf Eclipse wechseln. Und wenn es mal ein paar Eclipse-Luna oder Kali .project Dateien geschafft den Eclipse Mars Usern das Projekt zu zerlegen, werden auch die frewillig auf Makefile-Projekt umstellen.
Also arbeiten wir zunächst mal an den Sachen die offensichtlich zu tun sind, und da gibt es noch genug, wie Danilo so schön schreibt. Und der Rest muss nur lange genug kochen, dann kommt es von alleine.
Eine gemeinsame VM zu erstellen ist ein Weg, alle auf einen Stand zu bringen. Das sollte die Hürde senken. Aber Dokumentation wäre auch eine Option.
Ein O/S drunter legen, wäre zunächst eine weitere Hürde und die Auswahl eines passenden O/S ist nicht ohne. Denn wir haben einen recht ansehnlichen DSP Teil in der Software, der recht allergisch auf Unterbrechungen durch ein RTOS reagieren würde. Das NutO/S hatte ich vorgeschlagen, weil ich weiß, dass es auch dann gut funktioniert, wenn es sich einem hart getrieben Interrupt-System unterordnen muss.
War jetzt viel Text, gibt aber im Grunde die Summe der Pros und Cons für die verschiedenen Aspekte und Meinungen wieder, die hier öffentlich und auch privat diskutiert wurden. Wichtig ist im Grunde, dass keiner vergrault werden soll. Und das gilt es in jedem Fall zu versuchen.
vy 73 de Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
dl8mby
alter Hase
Offline
Posts: 363
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #73 on: 06. April 2016, 09:09:14 »
|
|
Hallo Uli,
danke für die ausführliche Antwort.
Mir war schon bewußt, dass es da sehr schwer sein wird,
die etablierten Pfade zu verlassen aber ich hatte halt gehofft,
dass man einfacher den MC intiallisieren kann und dann sich
seine eigene main routine zusammensetzt, in der man Schritt
für Schritt die einzelnen Teile des bestehenden Codes einbinden
könnte um diese zu verstehen und sich so an den gesamten Code
anzunähern.
Leider sind die Header/Libs so ineinander verstrickt, dass es schwer
fällt (zumindest mir) kleine Teilfunktionen auszuführen.
Ich habe mir gestern die Keil CMSIS Webseiten durchgelesen, um
die Namensgebung überhaupt zu verstehen und habe dabei feststellen
müssen, dass es wohl einen sehr großen Aufwandt darstellt dieses
System im kleinen zum Laufen zu bringen, ohne die Gesamtheit
begriffen zu haben - leider.
Ich war der naiven Hoffnung verfallen, so ein mchf SW System mit einer
Anzahl von Dateien zum Laufen zu bringen, die man an zwei Händen
abzählen kann. (*.h, *.c, eventuell *.xml für die GUI).
Wahrscheinlich muss ich mich noch wesentlich mehr mit den vorhandenen
Werkzeugen auseinandersetzen als mir einentlich lieb ist.
Die Zeiten, in denen der Code auf wenige Filss verteilt war, sind wohl
schon lange vorbei.
Ich sehe es täglich in meinem Arbeitsumfeld, wo die Projekte mit
Tausenden von JAVA, ADA, C und CPP Fiels daher kommen.
Im Web Umfeld sieht es langsam ähnlich aus.
Ohne entsprechende Werkzeuge ist man bei dem Umfang vollkommen
hilflos.
Unter dem bestehenden Zeitdruck werden nur noch Module verwendet,
die man aneinander häftet und das wars. Der Overhead wird ja duch
Rechenpower und Speichergröße wett gemacht.
Ich kann mich noch gut an eine Kongress erinnern, auf dem eine neue
Software vorgestellt wurde, um ein Problem in der Datenverarbeitung
mit Satellitendaten zu lösen.
Nachdem die Vorrädner die, diese Thematik damals mit JAVA angegangen
sind, einen halben Ordner Folien presentiert haben, (liegt erst fünf Jahre
zurück, trotz Notebook Aera) das Podium verlassen habe, ist mein
Kollege mit zwei DIN-A4 Folien daher gekommen und hat das Problem
mit einem kleinen Perl Skript auf elegante aber einfache Weise gelöst.
Das war aber ganz schön peinlich - wir schmunzeln noch heute wenn wir
daran zurückdenken.
Bin jetzt bischen von Thama abgekommen - sorry.
vy73
Markus
DL8MBY
|
|
Logged
|
|
|
|
DC3AX
Interessent
noch länger dabei
Offline
Posts: 186
Ich liebe dieses Forum!
|
|
Re:Hilfe beim Flashen via JLink
« Reply #74 on: 06. April 2016, 09:33:46 »
|
|
Lass Dich nicht auf die falsche Fährte locken!
Die CMSIS ist extrem komplex im Vergleich zu der üblichen Start-Sequenz eines Arduino mit nem 8-bit AVR.
Aber man kann sie in weiten Teilen einfach so verwenden, oder man zupft sich die Teile, die man benötigt.
Ich habe vor etlichen Jahren die STM32F Serie in NutO/S portiert und das war zwar viel Fleißarbeit, aber nicht unmöglich. Dank 2..3 Mitstreiter war das Schlimmste in 2..3 Monaten erledigt. Erfreulicherweise wird das ganze bis heute noch gepflegt und so werde ich nach einigen Jahren Pause neue Projekte wieder darauf aufsetzen.
Die Arbeit ist also bereits getan und man kann leicht auf diesen Zug aufspringen. Aber selbst wenn man von jetzt auf gleich einen Monster-Commit nach git stellt, in dem man die Arbeit auf einmal getan hätte, würde man eine ganze Reihe User abhängen, da entweder ihr Code nicht mehr da ist, wo er mal war oder ihre IDE nicht mehr funktioniert.
Lustig ist eigentlich der psychologische Effekt durch den Einsatz eines O/S. Jeder denkt zuerst, ein O/S würde die Dinge komplizieren und verlangsamen, was aber eigentlich garnicht der Fall ist. Und jeder, der früher seinen Code in 15000 Zeilen in eine main() gehackt hat, schreibt plötzlich abstrahierte Funktionen in Aufgaben-spezifische c und h Dateien.
Im Grunde ist es ein Problem des bestehenden Codes, das der Code in zwei Dateien liegt, die den zwei Platinen entsprechen. Nichts spricht dagegen, wie Danilo schon schrieb, den Code nach Funktionen zu trennen. Aber ein O/S schafft dazu den psychologischen Druck.
Und natürlich ist es viel leichter gemeinsam an einem Projekt zu arbeiten, wenn man sich nicht gegenseitig dauernd in ein und der selben Datei über die Füße fährt.
vy 73 de Ulrich
|
|
Logged
|
Es gibt drei binäre Zustände: Ein, Aus und Vielleicht. Je höher die Frequenz, desto Vielleicht...
|
|
|
Pages: 1 ... 3 4 [5] 6 
|
|
|
|
|
|
|
