Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Olaf Kaluza]

Matthias Weingart <mwnews@pentax.boerde.de> wrote:

Hatte mal vor Jahren ?nliches erlebt mit dem GCC und MSP430; hab den nach
einem Projekt dann aber in die Tonne geworfen und den Compiler von Paul
gekauft (Crossworks);

Also ich hab die MCP430 auch eine Zeitlang programmiert. Mit ganz
normalen gcc. War kein Problem. In die Tonne werfen wuerde ich die eher
wegen ihrem unzuverlaessigen Debugger.

Olaf

 

[Manuel Reimer]

On 02/19/2015 12:38 AM, Sieghard Schicktanz wrote:

(BTW: Könnte es sein, daß die Ursache des Problems einfach ist, daß der
funktionierende Code zwischen zwei Registerzugriffen noch bisserl Zeit mit
einer simplen Berechnung verbrät, während der nicht mehr funktionierende
die vorberechneten Werte direkt aufeinanderfolgend in die Register pumpt?)

Scheint fast so...

Darf denn sowas sein? Also ich meine so dermaßen Timingabhängig. Macht
doch keinen Spaß wenn der Kram aus unerfindlichen Gründen nicht läuft
und mit ein paar "Do-Nothing-Loops" dann plĂśtzlich doch "fliegen lernt"...


Läuft nicht:

userAppAddr = USER_CODE_RAM; /* default RAM user code location */
userAppEnd = RAM_END;


Läuft:

volatile u32 dly;
for(dly = 0; dly < 400000; dly++);
userAppAddr = USER_CODE_RAM; /* default RAM user code location */
for(dly = 0; dly < 400000; dly++);
userAppEnd = RAM_END;
for(dly = 0; dly < 400000; dly++);


Klar kann ich mich so langsam zu einem funktionierenden Binary hangeln.
Aber so richtig sauber scheint mir das nicht zu sein...

Gruß

Manuel

 

[Tilmann Reh]

Manuel Reimer schrieb:

On 02/19/2015 12:38 AM, Sieghard Schicktanz wrote:
(BTW: Könnte es sein, daß die Ursache des Problems einfach ist, daß der
funktionierende Code zwischen zwei Registerzugriffen noch bisserl Zeit mit
einer simplen Berechnung verbrät, während der nicht mehr funktionierende
die vorberechneten Werte direkt aufeinanderfolgend in die Register pumpt?)

Scheint fast so...

Darf denn sowas sein? Also ich meine so dermaßen Timingabhängig. Macht
doch keinen Spaß wenn der Kram aus unerfindlichen Gründen nicht läuft
und mit ein paar "Do-Nothing-Loops" dann plĂśtzlich doch "fliegen lernt"...

Meist liegt der Fehler ganz woanders, und wenn man ihn schließlich
gefunden hat: <patsch>

Läuft nicht:

userAppAddr = USER_CODE_RAM; /* default RAM user code location */
userAppEnd = RAM_END;


Läuft:

volatile u32 dly;
for(dly = 0; dly < 400000; dly++);
userAppAddr = USER_CODE_RAM; /* default RAM user code location */
for(dly = 0; dly < 400000; dly++);
userAppEnd = RAM_END;
for(dly = 0; dly < 400000; dly++);

Bedenke, daß auch alles andere, was danach gemacht wird, nun später
passiert.

Ich habe selbst mal ziemlich lange nach einem Fehler gesucht, bei dem
eine Software reproduzierbar entweder richtig lief oder eben nicht -
abhängig davon, welchen Vorteiler ich bei einem Timer einstellte. Ich
konnte das schließlich daraufhin eingrenzen, daß eine Konstante, die in
einem einzigen Codewort ins Register geladen werden konnte (also
insgesamt nicht mehr als 8 genutzte Bits nebeneinander hatte),
funktionierte, eine größere/ungünstigere (die indirekt oder in zwei
Befehlen geladen wurde) aber nicht. Zum Haareraufen!
Ein Freund stellte dann beim Drßbersehen den tatsächlichen Fehler fest:
Der Timer lief gleich darauf Ăźber und erzeugte einen anstehenden
Interrupt, der dann später die Zählung in der ISR durcheinanderbrachte.
Je nachdem, ob das Laden des Vorteilers eine oder zwei Zugriffe
brauchte, wurde der Interrupt noch während der Initialisierung genau
eine Instruktion "zu frĂźh" ausgelĂśst. Initialisierungsroutine korrigiert
--> Fehler weg, unabhängig von den Timer-Konstanten. Bis dahin hatte es
ßber Monate hinweg /zufällig/ sehr zuverlässig funktioniert, ich hatte
bis dahin halt nie "kritische" Konstanten verwendet und der (von Anfang
an vorhandene) Fehler fiel dadurch nicht auf.

Dies nur als Beispiel, daß man manchmal an der völlig falschen Stelle sucht.

Klar kann ich mich so langsam zu einem funktionierenden Binary hangeln.
Aber so richtig sauber scheint mir das nicht zu sein...

Ist es auch nicht.

Tilmann

 

[Gerhard Hoffmann]

Am 19.02.2015 um 17:10 schrieb Manuel Reimer:

Darf denn sowas sein? Also ich meine so dermaßen Timingabhängig. Macht
doch keinen Spaß wenn der Kram aus unerfindlichen Gründen nicht läuft
und mit ein paar "Do-Nothing-Loops" dann plĂśtzlich doch "fliegen lernt"...

Einer meiner Kollegen hatte das DAMALS in einem Plattentreiber
fĂźr Unix SysV auf dem Fairchild Clipper. Ein einer vĂśllig fremden
Stelle ein printf() im Kernel und alles lief _viel_ schneller.

LĂśsung:
Der Clipper hatte einen Cache, und Fairchild hat die defekten
Cache lines per Laser deaktiviert (aber nix gesagt).
BlÜde, wenn die die Copy-Schleife im Plattentreiber zufällig
auf einer defekten Cacheline gelandet ist...

Gruß, Gerhard

 

[Christian Zietz]

Manuel Reimer schrieb:

Darf denn sowas sein? Also ich meine so dermaßen Timingabhängig. Macht
doch keinen Spaß wenn der Kram aus unerfindlichen Gründen nicht läuft
und mit ein paar "Do-Nothing-Loops" dann plĂśtzlich doch "fliegen lernt"...

Das kann das Timing sein, muss aber nicht. Ebenso kann der generierte
Code durch das EinfĂźgen der Schleife anders sein -- und sei es nur die
Registerbelegung. Oder die CPU hat einen Bug, dass zwei ganz bestimmte
Befehle nicht direkt aufeinander folgen dĂźrfen und die Schleife
verhindert das. Usw.

> Aber so richtig sauber scheint mir das nicht zu sein...

Das stimmt wohl.

Christian
--
Christian Zietz - CHZ-Soft - czietz (at) gmx.net
WWW: http://www.chzsoft.de/
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA

 

[Klaus Bahner]

On 18-02-2015 19:34, Manuel Reimer wrote:

Hallo,

[snip]

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L62

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L63

Ich habe jetzt gerade keine Lust mich in den Code in Details einzudenken
bzw. die Memorymap des benutzten Controllers naeher zu studieren, als
das folgende unter Vorbehalt:

Ich denke das Problem liegt darin, dass du den besagten Variablen
bereits bei der Deklararation die gleiche Konstante zuweist wie in dfuInit.

Mit der Optimierung bzw. anderen Compilerversion, kann der Compiler
diese Zuweisung wegoptimieren, obwohl als volatile deklariert und je
nach Optimierung als Konstanten betrachten. Je nach Memorymap kann dass
dann bedeuten, dass der Linker diese Variablen zum Beispiel in anderes
Datensegment als die Variablen laegt. Wenn der Bootloader aber davon
ausgeht, dass diese Konstanten im gleichen Datensegment wie die
Variablen liegen hast du den Salat.

Du kannst meine Theorie ueberpruefen indem du im Linker Outputfile
nachsiehst ob beim funktionierenden vs. nicht funktionierenden
Bootloader die RAM daten im gleichen Segment liegen oder nicht.


Gruss
Klaus

 

[Gerald Oppen]

Am 19.02.2015 um 17:54 schrieb Tilmann Reh:

Läuft nicht:

userAppAddr = USER_CODE_RAM; /* default RAM user code location */
userAppEnd = RAM_END;


Läuft:

volatile u32 dly;
for(dly = 0; dly < 400000; dly++);
userAppAddr = USER_CODE_RAM; /* default RAM user code location */
for(dly = 0; dly < 400000; dly++);
userAppEnd = RAM_END;
for(dly = 0; dly < 400000; dly++);

Bedenke, daß auch alles andere, was danach gemacht wird, nun später
passiert.

Deswegen sollte man solche WAITs wenn man sie schon benutzen muss auch
aus der Optimierung ausklammern.

Gerald

 

[Wolfgang Kynast]

On Thu, 19 Feb 2015 23:23:27 +0100, "Gerald Oppen" posted:

Am 19.02.2015 um 17:54 schrieb Tilmann Reh:

Läuft nicht:

userAppAddr = USER_CODE_RAM; /* default RAM user code location */
userAppEnd = RAM_END;


Läuft:

volatile u32 dly;
for(dly = 0; dly < 400000; dly++);
userAppAddr = USER_CODE_RAM; /* default RAM user code location */
for(dly = 0; dly < 400000; dly++);
userAppEnd = RAM_END;
for(dly = 0; dly < 400000; dly++);

Bedenke, daß auch alles andere, was danach gemacht wird, nun später
passiert.

Deswegen sollte man solche WAITs wenn man sie schon benutzen muss auch
aus der Optimierung ausklammern.

Das sollte "volatile" doch bewirken, iirc.

--
Schöne Grüße,
Wolfgang

 

[Michael Schwingen]

On 2015-02-19, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

Problematisch an deinem Problem ist, dass es durchaus sein kann, dass
der Compiler so funktioniert, wie er gedacht ist und durch die
aggressiveren Optimierungen einfach Bugs in Code offensichtlich werden.

ACK. Ich habe in den letzten 10 Jahren so 2-3 mal den Fall gehabt, daß alter
Code ("da hat seit Jahren niemand was 'dran geändert, der lief immer
einwandfrei") mit einem neuen Compiler dann doch auf die Nase fällt - und
der Compiler jeweils Recht hatte mit seiner neuerdings besseren Optimierung
und der Quellcode einfach falsch war. Besonders nett: strict aliasing (der
Compiler darf z.B. davon ausgehen, daß ein 16-Bit-Zeiger nie auf die
gleiche Adresse zeigt wie ein 32-Bit-Zeiger, auch, wenn man die 2 Zeilen
vorher per Cast zugewiesen hat).

Andererseits habe ich mit neueren AVR-GCC das Problem, daß manche meiner
existierenden Sourcen "internal compiler error" triggern.

Sprich: das kann hier sowohl ein Compiler- als auch ein Quellcodefehler
sein.

cu
Michael

 

[Michael Schwingen]

On 2015-02-18, Manuel Reimer <Manuel.Nulldevice@nurfuerspam.de> wrote:

Zusätzliche Frage am Rande: Eigentlich wollte ich mich ja schon immer
mal in die Mikrocontroller-Programmierung reinfinden. Wenn ich aber sehe
mit was für Problemen man da zu tun hat vergeht mir die Lust. Reicht es
von ST-Mikrocontrollern Abstand zu halten oder hat man z.B. bei einem
Atmel ähnliche Probleme?

Ich habe auch einen Fall, wo avr-gcc mit "internal compiler error"
abschmiert.

Sagen wir so: der Einstieg ist mit avrgcc und avr-libc einfacher - es gibt
nur diese eine (verbreitete) Toolchain, und jeder benutzt die.

Bis man mit einem beliebigen Cortex-M produktiv ist, ist die Schwelle höher:
irgendwie zurechtgedengelte IDEs, deren interne Projektverwaltung die
interessanten Details versteckt und die Fehlersuche extrem erschweren,
Beispielsourcen, die theoretisch mit gcc übersetzbar sind, aber nicht mit
anderen mitgelieferten Puzzleteilen zusammenpassen (ST-HAL, newlibc,
startupcode, ...).

Ich bin inzwischen zum Ergebnis gekommen, die ganzen
rundum-sorglos-Hersteller-IDEs liegenzulassen und nackt mit gcc-arm-embedded
plus Makefile zu übersetzen. Dazu dann http://gnuarmeclipse.livius.net/,
wobei ich nur die OpenOCD/Debug-Integration benutze und die ganze
Projektverwaltung ignoriere - dafür hat man make, da weiß man auch, welches
Linkerscript und welcher Startupcode jetzt benutzt wird.

Andererseits: wenn man die Einstiegshürde mal überwunden hat, sind die Teile
nett. Sobald man bei einem Atmel 64k Flash braucht, ist man mit einem
passenden Cortex-M in der Regel besser bedient - und teurer sind die dann
auch nicht wirklich. Ob jetzt von ST oder einem der anderen Hersteller ist
ja egal - außer Renesas und Microchip scheinen ja so ziemlich alle anderen
inzwischen auf den ARM-Zug aufgesprungen zu sein, der Unterschied ist dann
nur in der Peripherie um den CPU-Kern herum.

ST hat günstige Evalboards incl. Debugger, die gescheit mit
Open-Source-Tools funktionieren - NXP eher nicht, für den LPC1768 habe ich
einen ST-Link zum Debuggen genommen. Freescale und ARM könnten da auch
brauchbar sein, da hatte ich noch keine Zeit zum echten Testen ...

cu
Michael

 

[Sieghard Schicktanz]

Hallo Reinhard,

Du schriebst am 19 Feb 2015 10:29:16 GMT:

man nur in der Originalsprache rĂźberbringen kann: "A computer program
does what you tell it to do, not what you want it to do".

Warum soll das nur auf Englisch gehen? Auf Deutsch heißt das: "Ein
Computer-Programm tut, was man ihm aufträgt, nicht, was man mÜchte."

Geht natĂźrlich auch, klingt aber m. E. irgendwie holprig ...

M.E. klingt die englische Version holperiger.
Aber es stand ja die Behauptung an, daß das _nur_ auf Englisch ginge - und
das stimmt eben nicht.

--
--
(Weitergabe von Adressdaten, Telefonnummern u.ä. ohne Zustimmung
nicht gestattet, ebenso Zusendung von Werbung oder ähnlichem)
-----------------------------------------------------------
Mit freundlichen Grüßen, S. Schicktanz
-----------------------------------------------------------

 

[Matthias Weingart]

Olaf Kaluza <olaf@criseis.ruhr.de>:

Matthias Weingart <mwnews@pentax.boerde.de> wrote:

Hatte mal vor Jahren ?nliches erlebt mit dem GCC und MSP430; hab den nach
einem Projekt dann aber in die Tonne geworfen und den Compiler von Paul
gekauft (Crossworks);

Also ich hab die MCP430 auch eine Zeitlang programmiert. Mit ganz
normalen gcc. War kein Problem. In die Tonne werfen wuerde ich die eher
wegen ihrem unzuverlaessigen Debugger.

Ja das war dann mein letzter Auslöser. Der Compiler war aber auch recht
schlecht, der von Crosswork erzeugte Code war um Klassen besser, wesentlich
optimaler.

M.
--

 

[Matthias Weingart]

Michael Schwingen <news-1326478115@discworld.dascon.de>:

On 2015-02-19, Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:
Problematisch an deinem Problem ist, dass es durchaus sein kann, dass
der Compiler so funktioniert, wie er gedacht ist und durch die
aggressiveren Optimierungen einfach Bugs in Code offensichtlich werden.

ACK. Ich habe in den letzten 10 Jahren so 2-3 mal den Fall gehabt, daá
alter Code ("da hat seit Jahren niemand was 'dran ge„ndert, der lief
immer einwandfrei") mit einem neuen Compiler dann doch auf die Nase
f„llt - und der Compiler jeweils Recht hatte mit seiner neuerdings
besseren Optimierung und der Quellcode einfach falsch war. Besonders
nett: strict aliasing (der Compiler darf z.B. davon ausgehen, daá ein
16-Bit-Zeiger nie auf die gleiche Adresse zeigt wie ein 32-Bit-Zeiger,
auch, wenn man die 2 Zeilen vorher per Cast zugewiesen hat).

Über sowas bin ich auch schon gestolpert, das zeigt doch mal wieder das C
eigentlich ziemlicher Murks ist. Kein Wunder, dass es so viele Bugs gibt, die
permanent gefixt werden müssen; schliessen sie hier ne Lücke; reist es an ner
anderen Stelle wieder auf. Gerade auch bei Software die sich im öffentlichen
Raum bewegt: Broswer,Flash,Java etc. ist da jemals abzusehen, das da kein
Sicherheitsupdate mehr nötig ist? (Ganz abgesehen davon, das ständig
irgendwelche Features nachgeliefert werden müssen, die sowieso keiner
braucht, aber neue Löcher reissen).

M.
--

 

[Reinhard Forster]

Am Fri, 20 Feb 2015 02:12:05 +0100 schrieb Sieghard Schicktanz:

man nur in der Originalsprache rĂźberbringen kann: "A computer
program does what you tell it to do, not what you want it to do".

Warum soll das nur auf Englisch gehen? Auf Deutsch heißt das: "Ein
Computer-Programm tut, was man ihm aufträgt, nicht, was man mÜchte."

Geht natĂźrlich auch, klingt aber m. E. irgendwie holprig ...

M.E. klingt die englische Version holperiger. Aber es stand ja die
Behauptung an, daß das _nur_ auf Englisch ginge - und das stimmt eben
nicht.

Da hast Du allerdings recht.
In meinem Posting ist wohl beim Rumeditieren das "elegant" verschwunden.
Mir gefällt eben das "tell it" vs. "want it". Ist aber natßrlich
Geschmackssache.

Ade

Reinhard

 

[Reinhard Forster]

Am Thu, 19 Feb 2015 14:06:09 +0100 schrieb Johannes Bauer:

Kann es sein, dass Du (wie ich) mit (Z80?-)Assemblerprogrammierung groß
geworden bist?

Oh Mann, das ist aber lang her

Allerdings. Das war zu einer Zeit, als "C" noch als dritter Buchstabe des
Alphabets bekannt war ...

Hm ich finde es schon extrem hilfreich, wenn man das Assembly lesen
kann. Das beantwortet dann auch alle Fragen, wenn sich mal irgendwas
echt komisch verhält oder irgendein IRQ partout nicht funktionieren will
oder sowas.

Keine Frage.
Ich finde es auch interessant, wie ein Compiler "denkt", d. h. optimiert.

Ade

Reinhard

 

[Olaf Kaluza]

Michael Schwingen <news-1326478115@discworld.dascon.de> wrote:

Sagen wir so: der Einstieg ist mit avrgcc und avr-libc einfacher - es gibt
nur diese eine (verbreitete) Toolchain, und jeder benutzt die.

Jeder?

[olaf] ~/sources: cross-avr-gcc -v
Using built-in specs.
COLLECT_GCC=cross-avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/cross/libexec/gcc/avr/4.7.0/lto-wrapper
Target: avr
Configured with: ../gcc-4.7.0/configure --target=avr --prefix=/usr/local/cross --program-prefix=cross-avr- --enable-languages=c,c++ --disable-nls --disable-libssp --with-gnu-as --with-gnu-ld --with-newlib --with-checking=release
Thread model: single
gcc version 4.7.0 (GCC)

Ich uebersetze mir meine privaten Compiler lieber selber. Da weiss man
was man hat und vor allem ich habe denselben Versionsstand fuer alle
meine Controller.

Bis man mit einem beliebigen Cortex-M produktiv ist, ist die Schwelle höher:
irgendwie zurechtgedengelte IDEs, deren interne Projektverwaltung die
interessanten Details versteckt

Ach? Was hat denn die IDE mit dem Controller zutun? Ich benutze hier
je nach Tageslaune Emacs/Make oder Eclipse. Egal fuer welchen
Controller.

>und die Fehlersuche extrem erschweren,

Hat den AVR mittlerweile einen brauchbaren Debugger? Als ich vor
Jahren auf die R8C mit ihrem Debugger gestossen bin habe ich nur noch
ueber AVR gelacht und alle neuen Projekte auf Renesas umgestellt.

Beispielsourcen, die theoretisch mit gcc übersetzbar sind, aber nicht mit
anderen mitgelieferten Puzzleteilen zusammenpassen (ST-HAL, newlibc,
startupcode, ...).

Also die aktuellen Probleme mit dem M3 sind das erstemal das ich auf
Probleme stosse. Sonst gab es noch mit keinem Controller
Schwierigkeiten. Das einzige was etwas doof war, der gcc ist im
Vergleich zu den Originalcompilern von Renesas etwas lahm.

Ich bin inzwischen zum Ergebnis gekommen, die ganzen
rundum-sorglos-Hersteller-IDEs liegenzulassen und nackt mit gcc-arm-embedded
plus Makefile zu übersetzen.

Das ist ja auch die uebliche vorgehensweise bei Profis. Wie willst du bei
so einem Eclipse-Monster sonst bei der Zertifizierung auch nachweisen
wie genau den Source uebersetzt wurde oder es gar spaeter reproduzieren.
Man kann allerdings trotzdem Eclipse benutzen wenn man will.

Projektverwaltung ignoriere - dafür hat man make, da weiß man auch, welches
Linkerscript und welcher Startupcode jetzt benutzt wird.

Yep!

Andererseits: wenn man die Einstiegshürde mal überwunden hat, sind die Teile
nett. Sobald man bei einem Atmel 64k Flash braucht, ist man mit einem
passenden Cortex-M in der Regel besser bedient - und teurer sind die dann
auch nicht wirklich.

Hehe. Der Grund warum der ARM-Kram derzeit den Markt aufrollt ist das
er schlicht billiger ist.

ja egal - außer Renesas und Microchip scheinen ja so ziemlich alle anderen
inzwischen auf den ARM-Zug aufgesprungen zu sein,

Renesas auch, leider!

der Unterschied ist dann
nur in der Peripherie um den CPU-Kern herum.

Nur ist gut! Das ist bei einem Controller der MEGAENTSCHEIDENDE
Unterschied. Da die Programmierung in C erfolgt ist der Core
nebensaechlich. Es erstaunt mich immer wieder wie sich da Leute die
es selber besser wissen muessten selber einen in die Tasche luegen.

ST hat günstige Evalboards incl. Debugger, die gescheit mit
Open-Source-Tools funktionieren - NXP eher nicht, für den LPC1768 habe ich
einen ST-Link zum Debuggen genommen.

Das geht? Haette ich jetzt nicht gedacht. Allerdings finde ich die
paar Kroeten fuer einen JLink-Edu auch okay. Schon erstaunlich was
moeglich ist wenn in China die Nachbauten vom Fliessband hopsen.

Freescale und ARM könnten da auch
brauchbar sein, da hatte ich noch keine Zeit zum echten Testen ...

Beruflich nutze ich derzeit Silabs/Gecko. Die sind technisch in
Ordnung. (vielleicht von ihrem beknackten Gehauese mit dem fetten
Massepad mal abgesehen)
Bloss die Datenblaetter...manoman. Die wurden wohl von einem
Marketinghengst mit Powerpoint (ausspuck) geschrieben.

Olaf

 

[Johannes Bauer]

On 20.02.2015 16:30, Olaf Kaluza wrote:

Ich uebersetze mir meine privaten Compiler lieber selber. Da weiss man
was man hat und vor allem ich habe denselben Versionsstand fuer alle
meine Controller.

Das ist allerdings ein Tipp, den man gerade für den ARM Cortex-M*
uneingeränkt geben kann.

Der GCC ist nämlich nicht so wirklich drauf ausgelegt, unterschiedliche
M-Architekturen alle übersetzen zu können. Einige Toolchains machen da
üble Verrenkungen, um das trotzdem hin zu kriegen. Sauber ist das nicht
und kostet -- wenn es denn schief geht -- echt Nerven.

Ich hab hier eigene gcc-Versionen für M0, M3 und M4 rumliegen.

Viele Grüße,
Johannes

--

Wo hattest Du das Beben nochmal GENAU vorhergesagt?
Zumindest nicht öffentlich!

Ah, der neueste und bis heute genialste Streich unsere großen
Kosmologen: Die Geheim-Vorhersage.
- Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$1@speranza.aioe.org>

 

[Edzard Egberts]

Olaf Kaluza wrote:

Das ist ja auch die uebliche vorgehensweise bei Profis. Wie willst du bei
so einem Eclipse-Monster sonst bei der Zertifizierung auch nachweisen
wie genau den Source uebersetzt wurde oder es gar spaeter reproduzieren.

Falscher Film, mit der Übersetzung der Sourcen hat die Eclipse nicht
viel zu tun, die ruft nur die Toolchains auf, gcc -> ld usw.
Das wird auch schön in der Konsole angezeigt und man kann diese Befehle
auch von Hand aufrufen.

Auch wenn ich es ungern so ausdrücke, ist die Eclipse eigentlich nur die
Super-Mega-Bloat-Variante eines Texteditors und kann vollständig durch
den vi ersetzt werden. ;o)

 

[Olaf Kaluza]

Mir ist bei meinem STM32F103 im DS203 Taschenoszi gerade etwas
erstaunliches aufgefallen....

Ich hab hier ein banales Testprogramm:

-----------
__Clear_Screen(BLACK);


// x, y, Color, Mode, String 0,0 scheint links unten zu sein!
__Display_Str(48, 50, WHT, PRN, APP_VERSION);

__Display_Str(20, 100, WHT, PRN, "A");
// __Display_Str(30, 100, WHT, PRN, "A");
// __Display_Str(40, 100, WHT, PRN, "A");



for (k=10;k<200;k+=20)
{
for (i=60;i<200;i+=10)
{
__Display_Str(k, i, CYAN, PRN, "K");

}
}

// oprintf("Hallo [%i]",4711);

while(1);

--------------

Diese Programm funktioniert. Zum Verstaendnis sei noch angemerkt das
die __Display_Str Funktion an anderer Stelle im Flashrom des Oszis
steht. Das ist sozusagen eine Bibliotheksfunktion die auch von der
Oszi-Anwendung genutzt wird.

Wenn ich jetzt die von mir geschriebene 'oprintf' Funktion
auskommentiere so macht das Programm garnichts mehr. Also auch die
oberen Ausgaben erscheinen nicht mehr auf dem Bildschirm. Das ist
schonmal sehr erstaunlich.

Wenn ich als naechste die beiden noch auskommentierten Display_Str
Funktionen in den Code reinnehme dann geht alles. Auch meine eigene
'oprintf' Funktion funktioniert dann!


Jetzt muss man wissen das der Taschensoszi eigentlich ein cooles
Design hat. Er besteht aus:

1. Bootloader mit USB-Massenspeicherunterstuetzung
2. FPGA-Firmware die ins FPGA kopiert wird
3. Systemfunktionen/Bios welche allen Anwendungungen zur Verfuegung
stehen.
4. APP1 - Speicherbereich Programm1
5. APP2 - Speicherbereich Programm2
6. APP3 - Speicherbereich Programm3
7. APP4 - Speicherbereich Programm4

Schaltet man den Oszi ein so startet er Programm1 und das ist die
Oszifirmware.

Durch gedrueckthalten einen Taste kann man erzwingen das einer der
anderen Slots gestartet wird. Das ist ziemlich genial!

Mein oberes Programm lasse ich normalerweise in APP3 laufen. Das
Makefile erzeugt aber bei jedem make die Apps fuer alle vier
unterschiedlichen Slots ueber eigene Linkerscripte.

wenn ich jetzt eine Sourceversion nehme die in Slot3 laeuft, dann
laeuft sie in Slot4 nicht. Dabei wurde das Programm fuer Slot4 aus
denselben Objektfiles zusammengebacken. Nur der Linkeraufruf und das
LD-Script sind anders.

Das erstaunt mich jetzt!


Olaf

 

[Olaf Kaluza]

Johannes Bauer <dfnsonfsduifb@gmx.de> wrote:

Der GCC ist nämlich nicht so wirklich drauf ausgelegt, unterschiedliche
M-Architekturen alle übersetzen zu können. Einige Toolchains machen da
üble Verrenkungen, um das trotzdem hin zu kriegen. Sauber ist das nicht
und kostet -- wenn es denn schief geht -- echt Nerven.

Das wusste ich noch garnicht und es macht mir Angst. Und es fuehrt das
ganze "Hach, aber die ARMs sind ja SOOOO kompatible!" noch besonders
ins absurde, das man immer erzaehlt bekommt.

Ich glaube langsam das einzige besondere an ARM ist die
Marketingabteilung.


>Ich hab hier eigene gcc-Versionen für M0, M3 und M4 rumliegen.

Kannst du mal ein gcc -v fuer die einzelnen Versionen posten?

Olaf