Mikrocontroller: "Compiler-Optimizer-Fehler" finden?

[Manuel Reimer]

Hallo,

um einen STM32F103 via USB flashen zu können wollte ich mir eigentlich
folgende Bootloader bauen:

https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms

Leider habe ich diesen auch nach vielen Versuchen nie zum Rennen
gebracht. Bis mich jemand auf die Idee gebracht hat statt mit dem, von
meinem Distributor ausgelieferten, GCC 4.9 mal mit GCC 4.8 zu bauen.

Ergebnis: Mit GCC 4.8 läuft der Bootloader plötzlich einwandfrei. Mit
einem großen *aber*. Und zwar klappt das ganze nur mit bestimmten
Optimierungs-Einstellungen. Mit "-Os" mit GCC 4.8 gebaut läuft der
Bootloader. Mit "-O3" gebaut läuft das resultierende Binary auch mit GCC
4.8 nicht. Mit GCC 4.9 gebaut bekomme ich, egal welche Einstellungen,
kein lauffähiges Binary hin.

Nach dem Eingrenzungs/Ausschlussverfahren habe ich als erste Kandidaten
für das Problem diese zwei Zeilen ausgemacht:

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

Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
den Sinn kommen was da das Problem sein soll...

Hat jemand einen Tipp?


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?

Danke im Voraus

Gruß

Manuel

[Christian Zietz]

Manuel Reimer schrieb:

> Nach dem Eingrenzungs/Ausschlussverfahren habe ich als erste Kandidaten
> für das Problem diese zwei Zeilen ausgemacht:
>
> https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L62
> https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L63
>
> Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
> den Sinn kommen was da das Problem sein soll...
>
> Hat jemand einen Tipp?

Wie sieht denn der zugehörige Assembler-Quelltext aus, in der
lauffähigen und in der nicht lauffähigen Version? So habe ich vor langer
Zeit mal einen Bug im Optimizer des gcc für AVR32 gefunden... und gefixt.

> 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?

Compiler-Bugs kann es überall geben, selbst auf dem PC. Das ist nicht
uC-spezifisch. Wenn Dir deshalb die Lust vergeht, dürfest Du gar nicht
programmieren.

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

[Manuel Reimer]

On 02/18/2015 07:42 PM, Christian Zietz wrote:
> Wie sieht denn der zugehörige Assembler-Quelltext aus, in der
> lauffähigen und in der nicht lauffähigen Version? So habe ich vor langer
> Zeit mal einen Bug im Optimizer des gcc für AVR32 gefunden... und gefixt.

Wow. Respekt! Mir ist C oft schon zu "nah an der Hardware"...

Funktionierend:

dfuInitXXX:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r2, .L2
ldr r3, .L2+4
str r2, [r3]
ldr r3, .L2+8
add r2, r2, #17408
str r2, [r3]
bx lr
.L3:
.align 2
.L2:
.word 536873984
.word .LANCHOR0
.word .LANCHOR1
.size dfuInitXXX, .-dfuInitXXX
.section .text.dfuInit,"ax",%progbits
.align 2
.global dfuInit
.thumb
.thumb_func
.type dfuInit, %function


Nicht funktionierend:

dfuInitXXX:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
movw r2, #:lower16:.LANCHOR3
mov r0, #3072
movw r3, #:lower16:.LANCHOR4
mov r1, #20480
movt r2, #:upper16:.LANCHOR3
movt r0, 8192
movt r3, #:upper16:.LANCHOR4
movt r1, 8192
str r0, [r2]
str r1, [r3]
bx lr
.size dfuInitXXX, .-dfuInitXXX
.section .text.dfuUpdateByReset,"ax",%progbits
.align 2
.global dfuUpdateByReset
.thumb
.thumb_func
.type dfuUpdateByReset, %function


"dfuInitXXX" ist eine Hilfsfunktion in die ich die zwei Zeilen
ausgelagert habe. So kann ich die Optimierung für diese eine Funktion
auf "-Os" setzen.

> Compiler-Bugs kann es überall geben, selbst auf dem PC. Das ist nicht
> uC-spezifisch. Wenn Dir deshalb die Lust vergeht, dürfest Du gar nicht
> programmieren.

Was mir nur etwas Kopfzerbrechen bereitet hat ist die Frage ob hier ein
"volatile" zu viel oder zu wenig schuld sein könnte. Am PC braucht man
die in aller Regel garnicht.

Gruß

Manuel

[Johannes Bauer]

On 18.02.2015 19:34, Manuel Reimer wrote:

> Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
> den Sinn kommen was da das Problem sein soll...

Wie unterscheiden sich denn die Linkerskripte zwischen den zwei
Compiler-Varianten? Üblicherweise funktioniert das so, im Linkerskript
sind Symbole am Anfang und Ende der Sektionen, die jeweils von Interesse
sind (in deinem Fall wohl .bss oder .data). Die werden dann von C aus
als "extern" irgendwo eingeblendet und deren Adresse verwendet. Also
angenommen im Linkerskript steht

.data : AT (__exidx_end) {
__data_start__ = .;
*(vtable vtable.*)
*(.data .data.*)
*(.gnu.linkonce.d*)
. = ALIGN(4);
__data_end__ = . ;
} >SRAM

Dann steht irgendwo im Startup-Code beispielsweise sowas

extern int __data_start__;
extern int __data_end__;

memcpy(&__data_start__, source, &__data__end - &__data__start);

Wenn die Zuweisungen schief gehen, dann würde ich mich mal auf die Suche
machen, wozu USER_CODE_RAM expandiert (ich tippe darauf, dass das wie
oben ist) und mich auf machen, im Assembly nachzuprüfen was nach dem
Linken da dann tatsächlich für Werte drin stehen.

> 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?

Naja, kommt immer ein bischen drauf an. Die 8 Bitter von Atmel können
halt viel weniger sind aber schon einfacher für den Anfang. Und hängt
natürlich auch von der Reife der Produkte ab, ich hatte bei Einführung
der XMegas auch mal ein Paar extrem fiese Bugs in der gcc-Toolchain
suchen und fixen müssen (IIRC war da beim IRQ-Prolog RAMPD nicht
gesichert worden, das nur in der XMega-Familie präsent ist).

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>

[Johannes Bauer]

On 18.02.2015 19:47, Manuel Reimer wrote:

> .word .LANCHOR0
> .word .LANCHOR1

Das Problem ist, das die Symbole erst vom Linker aufgelöst werden und du
nicht weißt, was der einsetzt. Also doch mal komplett kompilieren und
dann disassemblieren, dann weißt du genau was passiert. Kann sein, dass
der Code funktioniert (wenn der Linker das richtige einsetzt), muss aber
nicht.

Am besten wäre es, wenn du mit beiden Compilern Binaries erzeugst und
die dann mit objdump rausdumps und vergleichst. Dann hast du den Fehler
ruckzuck gefunden :-)

[Christian Zietz]

Manuel Reimer schrieb:

> Wow. Respekt! Mir ist C oft schon zu "nah an der Hardware"...

Der Fehler war damals einfach auszumachen: Der Optimierer hat eine
Operation einfach wegoptimiert. Der Fix war schon komplizierter, weil
ich dazu ja erst lernen und verstehen musste, nach welchen Regeln der
Optimierer des gcc arbeitet.

> Funktionierend:

> [...]

> Nicht funktionierend:

> [...]

Jetzt kenne ich mich mit der Assembler-Syntax von Cortex-M3 leider zu
wenig aus, um dort hinterhältige Bugs zu sehen. Grundsätzlich scheinen
aber in beiden Fällen die selben Werte (0x20000C00 und 0x20005000) an
zwei Speicherstellen geschrieben zu werden. Verweisen denn .LANCHORx auf
die korrekten Adressen? Hast Du die Möglichkeit, den Code on-chip zu
debuggen?

> "dfuInitXXX" ist eine Hilfsfunktion in die ich die zwei Zeilen
> ausgelagert habe. So kann ich die Optimierung für diese eine Funktion
> auf "-Os" setzen.

Dass die Funktion Probleme macht, ist offenbar bekannt, denn es gibt ein
GIT commit " Fixing DFU bugs that makes it compiable with -Os", damit es
überhaupt mit "-Os" funktioniert, vorher ging wohl nur "-O0".
<https://github.com/tormodvolden/maple-bootloader/commit/f718fee97ab16653e07cd087a94bdd1d7017a7bf>

[Reinhard Forster]

Am Wed, 18 Feb 2015 19:53:39 +0100 schrieb Johannes Bauer:


> Am besten wäre es, wenn du mit beiden Compilern Binaries erzeugst und
> die dann mit objdump rausdumps und vergleichst. Dann hast du den Fehler
> ruckzuck gefunden :-)

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

Da Manuel (nach dessen Posting) "C schon oft zu nah an der Hardware" ist,
wird er da wohl Probleme bekommen.

Manuel, nichts für ungut. Aber es gibt da eines von Murphy's Laws, das
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".

Zu meiner Studienzeit war der DWIM¹)-Compiler ein beliebtes
Forschungsprojekt ....

Ade

Reinhard

¹) Do What I Mean

[Olaf Kaluza]

Christian Zietz <newsgro...@chz.xyz> wrote:


>Jetzt kenne ich mich mit der Assembler-Syntax von Cortex-M3 leider zu
>wenig aus, um dort hinterhältige Bugs zu sehen. Grundsätzlich scheinen

Das wuerde auch nicht reichen. Bei den modernen Prozessoren muss man
schon tiefer drin stecken um Fehler zu sehen. Besonders wenn es
vielleicht sogar echte Bugs im Prozessor sind um die der Compiler
rumprogrammieren sollte.

>Dass die Funktion Probleme macht, ist offenbar bekannt, denn es gibt ein
>GIT commit " Fixing DFU bugs that makes it compiable with -Os", damit es
>überhaupt mit "-Os" funktioniert, vorher ging wohl nur "-O0".

Der ist auch nicht schlecht: mfix-cortex-m3-ldrd

Olaf

[Olaf Kaluza]

Manuel Reimer <Manuel.N...@nurfuerspam.de> wrote:


>Hat jemand einen Tipp?

Noe. Ich kann dir aber Bestaetigen das es Probleme gibt. Ich habe
gerade ein einfaches Hello-World Programm fuer den STM32F103 (DSO203)
uebersetzt. Da fuehren auch kleinste Aenderungen im Programm dazu das
es entweder problemlos laeuft oder abstuerzt. Oder je nach Optimierung
stuerzt dasselbe Programm ab oder auch nicht.
Bei mit dem 4.7.0.

Ich habe mit demselben Compiler auch schon Sachen fuer den STM32F407
uebersetzt und da sind mir keine Probleme aufgefallen.

Hiermit habe ich es momentan mit dem F103 laufen:

cross-arm-gcc -Wall -O2 -I. -Iinc -Werror -Wno-pointer-sign
-Wno-unused-variable -fomit-frame-pointer -fno-common -mcpu=cortex-m3
-mthumb -msoft-float -mtune=cortex-m3 -mfix-cortex-m3-ldrd
-mstructure-size-boundary=64 -MD -I ../stm/FWLib/inc -c -o Draw.o
Draw.c

Ich will aber nicht nicht ganz ausschliessen das es vielleicht an mir
liegt da dies wirklich die ersten Versuche mit dem F103 sind.

>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 verwende hier den denselben Sourcecode des 4.7.0er und hab mir
daraus Crosscompiler fuer ARM, SH2, SH2A, M16C, R8C, 68k, 68332 und
AVR erstellt.

Probleme machte bisher nur der F103. Allerdings wuerde ich mit dem
veralteten AVRs keine Zeit mehr verschwenden. Die koennen einfach zu
wenig.

Olaf

[Manuel Reimer]

On 02/18/2015 08:04 PM, Christian Zietz wrote:
> Jetzt kenne ich mich mit der Assembler-Syntax von Cortex-M3 leider zu
> wenig aus, um dort hinterhältige Bugs zu sehen. Grundsätzlich scheinen
> aber in beiden Fällen die selben Werte (0x20000C00 und 0x20005000) an
> zwei Speicherstellen geschrieben zu werden.

Passt. So sieht meine "vorgeparste" dfuInitXXX aus:

void dfuInitXXX(void) {
userAppAddr = ((u32)0x20000C00);
userAppEnd = ((u32)0x20005000);

}

> Verweisen denn .LANCHORx auf
> die korrekten Adressen?

Gute Frage.

Ich frage mich auch, ob ich mit den zwei Zeilen überhaupt auf dem
richtigen Weg bin. Ich habe schon öfter gesehen, dass Änderungen an ganz
anderen Stellen plötzlich Auswirkung auf die Funktion haben. Irgendwie
ziemlich frustrierend das ganze...

> Hast Du die Möglichkeit, den Code on-chip zu
> debuggen?

In der Theorie hätte ich die Hardware da (ST-Link V2). Ich verwende den
zu Programmieren der Chips. In der Praxis wüsste ich mit einem Debugger
aber nichts anzufangen.

> Dass die Funktion Probleme macht, ist offenbar bekannt, denn es gibt ein
> GIT commit " Fixing DFU bugs that makes it compiable with -Os", damit es
> überhaupt mit "-Os" funktioniert, vorher ging wohl nur "-O0".
> <https://github.com/tormodvolden/maple-bootloader/commit/f718fee97ab16653e07cd087a94bdd1d7017a7bf>

Ja, den Commit kenne ich. Mit dem Commit geht -O0 und -Os aber *nur* mit
GCC 4.8. Mit GCC 4.9 geht garnix...

Schon irgendwo merkwürdig an was man da alles denken soll/muss um diese
STM32 zu programmieren...

Gruß

Manuel

[Christian Zietz]

Manuel Reimer schrieb:

> Ich frage mich auch, ob ich mit den zwei Zeilen überhaupt auf dem
> richtigen Weg bin.

Nochmal konkret nachgefragt: Du hast diese zwei Zeilen (+ die benötigten
"extern" Verweise auf die Variablen, die ggf. benötigten #defines) in
eine eigene Datei kopiert, richtig? Wenn Du die Optimierer-Einstellungen
nur für diese Datei änderst und das resultierende Objekt-File zum sonst
unveränderten Rest linkst, dann geht es mal und mal nicht? Dann musst
tatsächlich herausfinden, an welche Adresse Deine Werte nun geschrieben
werden, wie Johannes schon vorgeschlagen hat.

>> Hast Du die Möglichkeit, den Code on-chip zu
>> debuggen?
>
> In der Theorie hätte ich die Hardware da (ST-Link V2). Ich verwende den
> zu Programmieren der Chips. In der Praxis wüsste ich mit einem Debugger
> aber nichts anzufangen.

Hm, das wäre halt ein Weg, festzustellen, ob a) die Variablen korrekt
beschrieben werden und sie b) zum Zeitpunkt der späteren Verwendung
immer noch den richtigen Wert haben.

Richtig böse wird es, wenn es tatsächlich ein Bug in der CPU ist, der
beim Single-Stepping mit dem Debugger nicht auftritt. Alles schon gehabt...

> Ja, den Commit kenne ich. Mit dem Commit geht -O0 und -Os aber *nur* mit
> GCC 4.8. Mit GCC 4.9 geht garnix...

Dann hat sich der erzeugte Code also irgendwie geändert. Vergleichen und
Schlüsse daraus ziehen.

> Schon irgendwo merkwürdig an was man da alles denken soll/muss um diese
> STM32 zu programmieren...

Wenn ich Olafs Posting lese, glaube ich auch, dass der STM32F103 evtl.
nicht ganz ausgegoren ist.

[Manuel Reimer]

On 02/18/2015 10:14 PM, Christian Zietz wrote:
> Nochmal konkret nachgefragt: Du hast diese zwei Zeilen (+ die benötigten
> "extern" Verweise auf die Variablen, die ggf. benötigten #defines) in
> eine eigene Datei kopiert, richtig?

Nein. Die Funktion steckt in der gleichen Datei. In der zugehörigen ".h"
steht:

void dfuInit(void);
void __attribute__((optimize("Os"))) dfuInitXXX(void);

Aus der "dufInit" rufe ich meine "dfuInitXXX" auf in der diese zwei
Zeile stehen.

Wenn ich das "__attribute__((optimize("Os")))" rausnehme läuft der Code
nicht mehr. Mit dem Attribut läuft alles wie gewünscht.

>> Ja, den Commit kenne ich. Mit dem Commit geht -O0 und -Os aber *nur* mit
>> GCC 4.8. Mit GCC 4.9 geht garnix...
>
> Dann hat sich der erzeugte Code also irgendwie geändert. Vergleichen und
> Schlüsse daraus ziehen.

Vermutlich hat sich der Code dermaßen umfangreich geändert, dass ich den
relevanten Teil nicht finden werde.

> Wenn ich Olafs Posting lese, glaube ich auch, dass der STM32F103 evtl.
> nicht ganz ausgegoren ist.

Oder es ist GCC der hier einen Fehler hat. Wenn man so sucht scheinen
die STM32-Controller auch nicht unbedingt extrem verbreitet zu sein.

Wer bei GCC erfolgreich einen Bug melden will sollte aber auf jedem Fall
mindestens den grundlegenden Befehlssatz der betroffenen CPU auswendig
können:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64953

Gruß

Manuel

[Christian Zietz]

Manuel Reimer schrieb:

> Wenn ich das "__attribute__((optimize("Os")))" rausnehme läuft der Code
> nicht mehr. Mit dem Attribut läuft alles wie gewünscht.

Auch wenn das __attribute ja nur lokal auf die Funktion wirken sollte:
Hast Du überprüft, dass der Rest des resultierenden Codes tatsächlich
unverändert bleibt? Falls ja, dann bleiben ja wirklich nur noch die zwei
Codezeilen. Bitte prüf doch wenigstens -- wie von Johannes vorgeschlagen
-- auf welche Adressen jeweils zugegriffen wird.

Am besten wäre wirklich, den Code einmal im Debugger durchzusteppen.

[Sieghard Schicktanz]

Hallo Reinhard,

Du schriebst am 18 Feb 2015 19:24:33 GMT:

> Manuel, nichts für ungut. Aber es gibt da eines von Murphy's Laws, das
> 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."
(Oder, wenn lieber, auch in der "Du"-Form. Transformation als Leseraufgabe.)

> Zu meiner Studienzeit war der DWIM¹)-Compiler ein beliebtes
> Forschungsprojekt ....

Das ist er doch immer noch.

(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?)

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

[Edzard Egberts]

Manuel Reimer wrote:
> Ergebnis: Mit GCC 4.8 läuft der Bootloader plötzlich einwandfrei. Mit
> einem großen *aber*. Und zwar klappt das ganze nur mit bestimmten
> Optimierungs-Einstellungen. Mit "-Os" mit GCC 4.8 gebaut läuft der
> Bootloader. Mit "-O3" gebaut läuft das resultierende Binary auch mit GCC
> 4.8 nicht.

Das ist ganz normal und kann Dir auch auf dem PC passieren, ich
optimiere daher immer nur mit maximal "-O2".

> Mit GCC 4.9 gebaut bekomme ich, egal welche Einstellungen,
> kein lauffähiges Binary hin.

Neue Compiler sind meistens etwas "kritischer" und moppern über Code,
der schon ewig gut lief. Schmeißt das Ding denn keine Warnungen oder
andere Hinweise?

> Nach dem Eingrenzungs/Ausschlussverfahren habe ich als erste Kandidaten
> für das Problem diese zwei Zeilen ausgemacht:
>
> https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L62
>
> https://github.com/tormodvolden/maple-bootloader/blob/unify_platforms/dfu.c#L63
>
> Zwei eigentlich recht "langweilige" Zuweisungen. Mir will echt nicht in
> den Sinn kommen was da das Problem sein soll...
>
> Hat jemand einen Tipp?

Vor der Zuweisung ist ein Semicolon zu viel, aber das sollte eigentlich
nichts ausmachen. Welchen Wert haben denn die Konstanten?

> Mikrocontroller-Programmierung

> Reicht es
> von ST-Mikrocontrollern Abstand zu halten oder hat man z.B. bei einem
> Atmel ähnliche Probleme?

Natürlich hat man da ähnliche Probleme. Ich habe z.B. eine Notiz
vorliegen "Wegen Bug in den avr-binutils ab 2.20. musste in den
Einstellungen "C/C++ Build" -> "Settings" -> "AVR C++ Linker" ->
"General" die Option "Relax branches" deaktiviert werden", aber auch die
Controller selber schießen einem gerne in den Fuß, wenn man irgend ein
Bit übersieht. Wer es nicht gewohnt ist, mit Engelsgeduld besonders
sorgfältig zu arbeiten, wird mit Mikrocontrollern wohl nicht so froh...

[Matthias Weingart]

Edzard Egberts <ed...@tantec.de>:

>> Mit GCC 4.9 gebaut bekomme ich, egal welche Einstellungen,

>> kein lauffÇÏhiges Binary hin.
>
> Neue Compiler sind meistens etwas "kritischer" und moppern Ǭber Code,
> der schon ewig gut lief. SchmeiÇYt das Ding denn keine Warnungen oder
> andere Hinweise?

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); toll war, dass er auch direkter Ansprechpartner für
Bugs war und er die dann auch kurzfristig fixte (meist war das Problem aber
nicht der Compiler, sondern sass hinter meinem Bildschirm :-). Das machte
dann Spass mit dem Prozessor zu arbeiten.
Naja heute spielt der GCC mit dem MSP430 besser, TI hat auf dem GCC aufbauend
ne kostenlose EntwicklungsSuite auf die Webseite gestellt. Nachteil nun, Paul
verdient mit seinem Compiler kein Geld mehr - aber wenigstens pflegt er ihn
noch. Er lebt jetzt von seinem ARM-Compiler. Vielleicht ist der ja auch ne
Alternative zum gcc für den OP? (crossworks.com)

M.
--

[Reinhard Forster]

Am Thu, 19 Feb 2015 00:38:08 +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 ...

Ade

Reinhard

[Johannes Bauer]

On 18.02.2015 22:24, Manuel Reimer wrote:
>> Wenn ich Olafs Posting lese, glaube ich auch, dass der STM32F103 evtl.
>> nicht ganz ausgegoren ist.
>
> Oder es ist GCC der hier einen Fehler hat. Wenn man so sucht scheinen
> die STM32-Controller auch nicht unbedingt extrem verbreitet zu sein.

Unter Privatanwendern sind die STM32 sicher noch nicht so verbreitet.
Aber kommerziell kenne ich einige Anwendungen, die ausschließlich auf
CM3 (u.A. STM32) basieren. Und zwar produktiv im Feld und mit gcc übersetzt.

> Wer bei GCC erfolgreich einen Bug melden will sollte aber auf jedem Fall
> mindestens den grundlegenden Befehlssatz der betroffenen CPU auswendig
> können:

Naja, das ist immer hilfreich. Thumb2 ist zum Glück extrem einfach
gestrickt und sehr schnell zu lernen. Und damit erschlägst du dann die
ganze Familie an neuen Controllern und eine ganze Latte an Herstellern
(TI, NXP, STM, Atmel).

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.
So sind gerade bei undefiniertem Verhalten (laut C-Standard) einige
Optimierungen dazugekommen, die das ausnutzen. Zum Beispiel ist signed
integer overflow in C undefined behavior (UB), obwohl man's vielleicht
nicht vermutet.

Viel Erfolg,

[Johannes Bauer]

On 18.02.2015 20:24, Reinhard Forster wrote:
> Am Wed, 18 Feb 2015 19:53:39 +0100 schrieb Johannes Bauer:
>
>
>> Am besten wäre es, wenn du mit beiden Compilern Binaries erzeugst und
>> die dann mit objdump rausdumps und vergleichst. Dann hast du den Fehler
>> ruckzuck gefunden :-)
>
> Kann es sein, dass Du (wie ich) mit (Z80?-)Assemblerprogrammierung groß
> geworden bist?

Oh Mann, das ist aber lang her :-)

> Da Manuel (nach dessen Posting) "C schon oft zu nah an der Hardware" ist,
> wird er da wohl Probleme bekommen.

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.

[Olaf Kaluza]

Matthias Weingart <mwn...@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

[Olaf Kaluza]

Manuel Reimer <Manuel.N...@nurfuerspam.de> wrote:


>Oder es ist GCC der hier einen Fehler hat. Wenn man so sucht scheinen
>die STM32-Controller auch nicht unbedingt extrem verbreitet zu sein.

Verbreitet sind die schon. Allerdings sollte das ja eigentlich sogar
egal sein. Der Compiler weiss ja garnicht ob der M3 jetzt von ST ist
oder von einem anderen Lizenznehmern.
Und so wie ST mit Demoboards um sich wirft muss die einfach jemand
verwenden. :-)

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.

[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:

Das sollte "volatile" doch bewirken, iirc.

--
Schöne Grüße,
Wolfgang

[Michael Schwingen]

On 2015-02-19, Johannes Bauer <dfnson...@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.N...@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.

[Matthias Weingart]

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

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.
--

[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-13...@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.

[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

[Matthias Weingart]

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

> On 2015-02-19, Johannes Bauer <dfnson...@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.
--

[Olaf Kaluza]

Johannes Bauer <dfnson...@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

[Olaf Kaluza]

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


>?ber sowas bin ich auch schon gestolpert, das zeigt doch mal wieder das C
>eigentlich ziemlicher Murks ist.

Sagen wir mal so, es ist der Menschheit in 30Jahren schon gelungen
bessere Sprachen zu entwickeln. Aber es ist doch schoen das man immer
dieselbe Sprache verwenden kann.

>Raum bewegt: Broswer,Flash,Java etc. ist da jemals abzusehen, das da kein

>Sicherheitsupdate mehr n?tig ist? (Ganz abgesehen davon, das st?ndig

Nein. Ueberleg dir auch mal wieviele arbeitslose Programmierer es dann
geben duerfte.

Olaf

[Olaf Kaluza]

Edzard Egberts <ed...@tantec.de> wrote:

>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.

Da hast du natuerlich recht. Aber wenn du dich einmal durch diese
UNERTRAEGLICHE Konfiguration von Eclipse durchgewurchkelt hast und
willst dasselbe eine Woche spaeter auf einem anderen Rechner nochmal
machen so ist es sehr unwahrscheinlich das am Ende dasselbe rauskommt.

Da ist ein Makefile einfach die einfachere Loesung. Die kann man einem
Kollegen schnell per Email schicken und man weiss das es laufen wird.

>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)

Hihi..ich hab in der Firma Eclipse mit Emacs-compatiblen Editor
laufen. Das sorgt dafuer das die Kollegen wenn sie bei mir mal eben
was machen wollen schnell boese kucken. :-D

Aber wenn man Source hat an dem ein Dutzend Programmierer arbeiten,
Multitasking Betriebsystem, verschiedene Funktionalitaet jetzt nach
verwendeter Zielhardware dann ist der Luxus der Grafikoberflaeche
manchmal schon ganz hilfreich. Muss man auch mal zugeben, egal wie
schlimm der Rotz sonst so ist.

Olaf

[Johannes Bauer]

On 20.02.2015 17:17, Olaf Kaluza wrote:
> Johannes Bauer <dfnson...@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.

Naja, ne, das ist wirklich eine Spezialität des gcc, der in der Hinsicht
extrem doof programmiert ist. Ich hoffe ja immernoch dass der
langfristig von llvm abgelöst wird. Der ist nämlich wirklich ein Traum.

Und eignetlich "sollte" das ja mit dem gcc auch gehen. Also multilib.
Und geht wohl möglicherweise auch, wenn man bestimmte Sachen rumpatched.
Mit Vanilla hat man aber keine Chance, zumindest dann nicht, wenn man
Hardfloat mit Softfloat mischt. Da gibts dann Linkerfehler, weil die
libgcc mit dem falschen Floatset kompiliert wurde und die Selektion
funktioniert nicht richtig.

Hat mich aber auch einige Stunden im Bugtracker wühlen gekostet.
Vielleicht finde ich meine Posts von damals noch, dann verlinke ich sie
hier.

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

Also ich muss sagen ich finde Thumb2 ist ein extrem guter Wurf. Das ist
ein genial einfaches, aber trotzdem sehr mächtiges Instruction Set. Und
die Standardisierung des NVIC ist auch ziemlich cool.

> >Ich hab hier eigene gcc-Versionen für M0, M3 und M4 rumliegen.
>
> Kannst du mal ein gcc -v fuer die einzelnen Versionen posten?

Klar, ist aber alles ziemlich straightforward:

joequad joe [~/bin/gcc]: arm-cm0/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cm0/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/joe/bin/gcc/arm-cm0/libexec/gcc/arm-none-eabi/4.9.2/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/home/joe/bin/gcc/arm-cm0/
--without-headers --with-gnu-ld --with-gnu-as --with-dwarf2
--disable-werror --disable-threads --disable-nls --disable-shared
--disable-libssp --disable-libmudflap --disable-libgomp
--target=arm-none-eabi --with-newlib --with-cpu=cortex-m0
--with-tune=cortex-m0 --disable-interwork --disable-multilib
--with-float=soft --with-mode=thumb --enable-languages=c
--with-system-zlib --enable-target-optspace
Thread model: single
gcc version 4.9.2 (GCC)


joequad joe [~/bin/gcc]: arm-cm3/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cm3/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/joe/bin/gcc/arm-cm3/libexec/gcc/arm-none-eabi/4.8.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/home/joe/bin/gcc/arm-cm3/
--with-gnu-ld --with-gnu-as --with-dwarf2 --disable-werror
--disable-threads --disable-nls --disable-shared --disable-libssp
--disable-libmudflap --disable-libgomp --target=arm-none-eabi
--with-newlib --with-cpu=cortex-m3 --with-tune=cortex-m3
--disable-interwork --disable-multilib --with-float=soft
--with-mode=thumb --enable-languages=c,c++ --with-system-zlib
--enable-target-optspace
Thread model: single
gcc version 4.8.1 (GCC)


joequad joe [~/bin/gcc]: arm-cm4/bin/arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-cm4/bin/arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/home/joe/bin/gcc/arm-cm4/libexec/gcc/arm-none-eabi/4.8.1/lto-wrapper
Target: arm-none-eabi
Configured with: ../configure --prefix=/home/joe/bin/gcc/arm-cm4/
--with-gnu-ld --with-gnu-as --with-dwarf2 --disable-werror
--disable-threads --disable-nls --disable-shared --disable-libssp
--disable-libmudflap --disable-libgomp --target=arm-none-eabi
--with-newlib --with-cpu=cortex-m4 --with-tune=cortex-m4
--disable-interwork --disable-multilib --with-fpu=fpv4-sp-d16
--with-float=hard --with-mode=thumb --enable-languages=c,c++
--with-system-zlib --enable-target-optspace
Thread model: single
gcc version 4.8.1 (GCC)

[Ewald Pfau]

Matthias Weingart <mwn...@pentax.boerde.de>:

> Broswer,Flash,Java etc. ist da jemals abzusehen, das da kein

> Sicherheitsupdate mehr n?tig ist?

Konsultieren wir die unschlagbare Autorität in so wichtigen Fragen,
siehe die --> markierte <-- Stelle -

-------------------
<http://huffman.sourceforge.net/tao/tao-of-programming.html>

Book 5 - Maintenance
Thus spake the master programmer:
“Though a program be but three lines long, someday it will have to be
maintained.”

5.1
A well-used door needs no oil on its hinges.
A swift-flowing stream does not grow stagnant.
Neither sound nor thoughts can travel through a vacuum.
--> Software rots if not used. <---

These are great mysteries.
----------------------

[Michael Schwingen]

On 2015-02-20, Olaf Kaluza <ol...@criseis.ruhr.de> wrote:
> Michael Schwingen <news-13...@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.

OK - mache ich teilweise auch. Trotzdem ist das effektiv der gleiche
Compiler, mit den gleichen specs, Linkerscripten, dem gleichen Startupcode
und der gleichen libc wie der, der bei Atmel oder bei arduino verwendet
wird.

Die Unterschiede, die da auftreten, sind geringer als zwischen den
verschiedenen Kombinationen von IDE/Startupcode/Herstellerlibraries im
ARM-Umfeld.

> >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.

Du klickst in der IDE auf "neues Cortex-M0 Projekt mit STM32F030" und
versuchst dann, das zu übersetzen. Anstatt eines Makefiles übernimmt die
IDE die Kontrolle welcher Startupcode, welches Linkerscript etc. verwendet
wird - das kann aus dem Lieferumfang von IDE (bzw. Prozessor-Plugin) sein,
oder aus dem Portfolio des crossgcc. Teilweise werden partielle Makefiles
gebaut, wo wieder nicht klar ist, woher die restlichen Definitionen kommen.

Wenn es nicht funktioniert (oder Du nur nachsehen willst, *was* da
eigentlich passiert), ist das übel.

Ich bin auch eigentlich eher ein Freund von emacs+make, aber da ich wissen
wollte, wie das notfalls auch mal unter WIndows geht, habe ich mir die
diversen angebotenen IDEs halt mal angesehen. Als einzige brauchbare Lösung
ist dann vanilla eclipse mit OpenOCD-Debugger-Plugin übriggeblieben - und
make. Wenn es funktioniert, ist die Debugunterstützung schon sehr nett.

> >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.

Ich habe das auf AVR nie benutzt, die Tools und Protokolle sind IIRC nicht
wirklich offen. Auf ARM sieht es da deutlich besser aus.

> >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.

Ja - damit sind aber die ganzen von den Herstellern gepimpten
Eclipse-Versionen (Code Red, Coocox, ...) Unsinn - deren Mehrwert liegt ja
größtenteils in den Teilen, die ich mit make eh nicht benutze.

Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist - das war
aber mein erster Kontakt mit Eclipse.

> >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.

Was ja nicht schlecht ist - wenn ich für weniger Geld eine CPU bekomme, wo
ich mich nicht mit den Einschränkungen des AVR 'rumschlagen muß, ist das OK.

> >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.

Schon klar. Und auch da ist das Feld weit - ARM hat derzeit den Vorteil, daß
die Tool-Unterstützung gut ist, und die Unterschiede, die es zwischen den
herstellern gibt, liegen eher an der Peripherie oder der Prozeßtechnologie.
Wenn die Meldungen zum neuen STM32L4 stimmen (sprich: braucht wirklich
weniger Strom als ein MSP430), ist das ein gutes Beispiel dafür.

Wobei: im Batteriebetrieb sind die ganzen Herstellerangaben ja sowieso mit
extremer Vorsicht zu genießen. Interessanter Artikel, der die
Marketing-Angaben von "10 Jahre mit einer Batterie" ins rechte Licht rückt:

http://www.ganssle.com/reports/ultra-low-power-design.html

> >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. :-)

Ja, tut bestens - der ST-Link war halt als einer der ersten mit
SWD-Unterstützung im OpenOCD dabei. Was mir an den ARMs gefällt, ist die
Offenheit - die Kerne sind incl. Debug-Schnittstelle gescheit dokumentiert,
so daß es brauchbare freie Tools dafür gibt.

> Beruflich nutze ich derzeit Silabs/Gecko. Die sind technisch in
> Ordnung. (vielleicht von ihrem beknackten Gehauese mit dem fetten
> Massepad mal abgesehen)

Die LPC812 sind süß ...

> Bloss die Datenblaetter...manoman. Die wurden wohl von einem
> Marketinghengst mit Powerpoint (ausspuck) geschrieben.

Die ST-Datenblätter sind OK, aber teilweise etwas unübersichtlich verteilt -
subjektiv aber grob in der Klasse wie die Freescale-PowerPC-CPUs, die wir in
der Firma einsetzen und damit durchaus benutzbar.

cu
Michael

[Michael Schwingen]

On 2015-02-20, Edzard Egberts <ed...@tantec.de> 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.

Ja. Aber wie sage ich z.B. einem Coocox-Eclipse, daß ich jetzt einen anderen
Startupcode haben will, und nicht den, den er nimmt? das ist IMHO tief in
irgendwelchen Plugins versteckt und nicht wirklich im Projekt
konfigurierbar. Wenn man das Projekt nicht explizit auf "ich habe eigene
Makefiles" einstellt, übernimmt Eclipse selber die Kontrolle, was wie mit
welchen Optionen gebaut wird.

> 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)

Wenn Du keinen Sourcelevel-Debugger benutzt: korrekt.

Eclipse übernimmt halt nicht nur die Aufgaben des Editors, sondern auch von
make, makefile, gdb + gdb-Frontend.

cu
Michael

[Marc Santhoff]

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

> On 2015-02-20, Olaf Kaluza <ol...@criseis.ruhr.de> wrote:
> > Michael Schwingen <news-13...@discworld.dascon.de> wrote:


> > >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.
>
> Du klickst in der IDE auf "neues Cortex-M0 Projekt mit STM32F030" und
> versuchst dann, das zu übersetzen. Anstatt eines Makefiles übernimmt
> die IDE die Kontrolle welcher Startupcode, welches Linkerscript etc.
> verwendet wird - das kann aus dem Lieferumfang von IDE (bzw.
> Prozessor-Plugin) sein, oder aus dem Portfolio des crossgcc.
> Teilweise werden partielle Makefiles gebaut, wo wieder nicht klar
> ist, woher die restlichen Definitionen kommen.
>
> Wenn es nicht funktioniert (oder Du nur nachsehen willst, *was* da
> eigentlich passiert), ist das übel.
>
> Ich bin auch eigentlich eher ein Freund von emacs+make, aber da ich
> wissen wollte, wie das notfalls auch mal unter WIndows geht, habe ich
> mir die diversen angebotenen IDEs halt mal angesehen. Als einzige
> brauchbare Lösung ist dann vanilla eclipse mit
> OpenOCD-Debugger-Plugin übriggeblieben - und make. Wenn es
> funktioniert, ist die Debugunterstützung schon sehr nett.

Oder man geht anders vor, das meint Olaf wohl:

Neues Projekt erzeugen, aber nicht mit der Standardeinstellung für
"project root" und dann den Ort angeben, wo die Quellen und das
Makefile liegen. Da packt Ecslipse dann nur ein paar Verzeichnisse dazu
(.project und ein oder zwei andere).

Dann noch das Standard Build Kommando auf make -f ... setzen, und man
kann auch aus Eclipse make benutzen wie bisher und trotzdem per vi
oder auch edlin von der Konsole arbeiten.

> > >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.
>
> Ja - damit sind aber die ganzen von den Herstellern gepimpten
> Eclipse-Versionen (Code Red, Coocox, ...) Unsinn - deren Mehrwert
> liegt ja größtenteils in den Teilen, die ich mit make eh nicht
> benutze.
>
> Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist -
> das war aber mein erster Kontakt mit Eclipse.

Man muß sich schon Zeit nehmen zu lernen, die Doku ist jedenfalls
umfangreich und detailliert.

Klar, Konfiguration ist ggf. eklig oder frickelig, aber nur eimalig zu
erledigen, unterstützt durch x-fach vorhandene Tutorien. Und im
professionellen Umfeld sollte die dann auch sorgfältig dokumentiert und
akribisch mit den benutzten Software-Versionen archiviert sein.

Das sind die Kosten, gewinnen tut man grafischen Schnickschnack:

- Code Folding
- Syntax Highlighting
- Quelltextnavigation
- Debugger eingebunden
- Unit Test übersichtlich
- Versionsverwaltung ebenfalls,
usw., usw.

Ich finde es jedenfalls ab einer kritischen Masse gerechtfertigt und
deutlich produktiver, leistungsfähige IDEs zu benutzen. Bei
Trivialprogrammen, LED am Mega8 blinken lassen, lohnt es aber kaum.

Marc

[Michael Schwingen]

Äh - liest Du eigentlich, was ich hier schreibe?

Das ist doch genau das, was ich nach Ausprobieren dieser IDE-Sackgasse
gemacht (und weiter oben im Thread beschrieben) habe.

Das ist nur die Methode, die von den Chipherstellern nicht unterstützt wird
(gerade nochmal nachgesehen: ST liefert zwar eigenen Startupcode mit ihrem
HAL-Framework, aber kein dazu passendes Linkerscript - und das von
gcc-arm-embedded passt nicht zu den ST-Sourcen). Wenn man sich das selber
passend macht, klappt es - aber dann brauche ich kein STM32-Plugin für
Eclipse mehr.

Wobei: bei TI gibt es im Quickstart Guide zum CC3200 tatsächlich ein Kapitel
"wie mache ich das mit einem nackten gcc + make" - es besteht also noch
Hoffnung!

>> Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist -
>> das war aber mein erster Kontakt mit Eclipse.
>
> Man muß sich schon Zeit nehmen zu lernen, die Doku ist jedenfalls
> umfangreich und detailliert.

Dann gib' mir bitte mal Starthilfe und erklär' mir, wie ich mit dem in
Eclipse eingebauten Buildsystem konfiguriere, welches Linkerscript und
welchen Startupcode er nimmt (Makefile gilt nicht - *das* funktioniert, aber
dann sind halt die ganzen Konfigurationsdialoge in eclipse für die Katz').
Mein Kollege mit längerer embedded-Eclipse-Erfahrung konnte mir da nicht
helfen (dafür an anderer Stelle - der Indexer findet jetzt tatsächlich nur
die Sourcen, die auch zum Projekt gehören).

> Klar, Konfiguration ist ggf. eklig oder frickelig, aber nur eimalig zu
> erledigen, unterstützt durch x-fach vorhandene Tutorien. Und im
> professionellen Umfeld sollte die dann auch sorgfältig dokumentiert und
> akribisch mit den benutzten Software-Versionen archiviert sein.

Ich bin nicht wirklich überzeugt, daß Dokumentation der Art "klicken Sie
hier auf Option X" wirklich zu reproduzierbaren Builds führt, wenn man das
mal auf einem Ersatzrechner hochziehen muß. Wenn dann Teile der Sourcen (der
Startupcode gehört für mich dazu) von Eclipse (incl. Plugin) geliefert wird
und nicht aus meinen Sourcen und auch nicht vom Compiler/libc-Paket, dann
ist es mit der Reproduzierbarkeit völlig vorbei - solche Abhängigkeiten kann
ich nicht ins Versionskontrollsystem einchecken.

> Das sind die Kosten, gewinnen tut man grafischen Schnickschnack:
>
> - Code Folding
> - Syntax Highlighting
> - Quelltextnavigation
> - Debugger eingebunden
> - Unit Test übersichtlich
> - Versionsverwaltung ebenfalls,
> usw., usw.
>
> Ich finde es jedenfalls ab einer kritischen Masse gerechtfertigt und
> deutlich produktiver, leistungsfähige IDEs zu benutzen. Bei
> Trivialprogrammen, LED am Mega8 blinken lassen, lohnt es aber kaum.

Ich sehe einen Teil der Vorteile, aber wirklich spürbar besser als bei
emacs+Terminal ist nur die Debugger-Integration. Dafür ist es dann zäher zu
bedienen, weil ich öfter zur Maus greifen muß.

cu
Michael

[Marc Santhoff]

Schon, aber scheinbar zu flüchtig bzw. fehlte mir ein wenig Redundanz
in deinem Vortrag.

> Das ist doch genau das, was ich nach Ausprobieren dieser IDE-Sackgasse
> gemacht (und weiter oben im Thread beschrieben) habe.
>
> Das ist nur die Methode, die von den Chipherstellern nicht
> unterstützt wird (gerade nochmal nachgesehen: ST liefert zwar eigenen
> Startupcode mit ihrem HAL-Framework, aber kein dazu passendes
> Linkerscript - und das von gcc-arm-embedded passt nicht zu den
> ST-Sourcen). Wenn man sich das selber passend macht, klappt es - aber
> dann brauche ich kein STM32-Plugin für Eclipse mehr.

Die gehen einen anderen Weg. Da gibt es doch dieses .... ach da,
STM32CubeMX. Entweder standalone oder auch als Eclipse-Plugin. DAmit
wird ein passendes Project Template erstellt.

> Wobei: bei TI gibt es im Quickstart Guide zum CC3200 tatsächlich ein
> Kapitel "wie mache ich das mit einem nackten gcc + make" - es besteht
> also noch Hoffnung!
>
> >> Ich wollte einfach nicht glauben, daß das wirklich so schlimm ist -
> >> das war aber mein erster Kontakt mit Eclipse.
> >
> > Man muß sich schon Zeit nehmen zu lernen, die Doku ist jedenfalls
> > umfangreich und detailliert.
>
> Dann gib' mir bitte mal Starthilfe und erklär' mir, wie ich mit dem in
> Eclipse eingebauten Buildsystem konfiguriere, welches Linkerscript und
> welchen Startupcode er nimmt (Makefile gilt nicht - *das*
> funktioniert, aber dann sind halt die ganzen Konfigurationsdialoge in
> eclipse für die Katz').

Kann ich aus dem Ärmel auch nicht sagen, eben weil ich Makefiles
benutze. <g>

Ich würde erstmal die "Build Configurations" anpassen wollen, da sollte
sich sowas lösen lassen. Damit wird doch die Abstraktion zum konkreten
Build-Werkzeug hergestellt.

> Mein Kollege mit längerer
> embedded-Eclipse-Erfahrung konnte mir da nicht helfen (dafür an
> anderer Stelle - der Indexer findet jetzt tatsächlich nur die
> Sourcen, die auch zum Projekt gehören).

Dürfte per "C/C++ General - Path and Symbols - Includes" in
den Projektoptionen einzustellen sein, Pfadliste passend
zurechtdengeln. Oder für den Indexer nochmal separat?

> > Klar, Konfiguration ist ggf. eklig oder frickelig, aber nur eimalig
> > zu erledigen, unterstützt durch x-fach vorhandene Tutorien. Und im
> > professionellen Umfeld sollte die dann auch sorgfältig dokumentiert
> > und akribisch mit den benutzten Software-Versionen archiviert sein.
>
> Ich bin nicht wirklich überzeugt, daß Dokumentation der Art "klicken
> Sie hier auf Option X" wirklich zu reproduzierbaren Builds führt,
> wenn man das mal auf einem Ersatzrechner hochziehen muß. Wenn dann
> Teile der Sourcen (der Startupcode gehört für mich dazu) von Eclipse
> (incl. Plugin) geliefert wird und nicht aus meinen Sourcen und auch
> nicht vom Compiler/libc-Paket, dann ist es mit der Reproduzierbarkeit
> völlig vorbei - solche Abhängigkeiten kann ich nicht ins
> Versionskontrollsystem einchecken.

So will ich das auch nicht haben. Allerdings sollten all diese
Einstellungen eben in den Projektspezifischen Konfigurationsdateien von
Eclipse zu finden sein, die gehören ins Repository.

> > Das sind die Kosten, gewinnen tut man grafischen Schnickschnack:
> >
> > - Code Folding
> > - Syntax Highlighting
> > - Quelltextnavigation
> > - Debugger eingebunden
> > - Unit Test übersichtlich
> > - Versionsverwaltung ebenfalls,
> > usw., usw.
> >
> > Ich finde es jedenfalls ab einer kritischen Masse gerechtfertigt und
> > deutlich produktiver, leistungsfähige IDEs zu benutzen. Bei
> > Trivialprogrammen, LED am Mega8 blinken lassen, lohnt es aber kaum.
>
> Ich sehe einen Teil der Vorteile, aber wirklich spürbar besser als bei
> emacs+Terminal ist nur die Debugger-Integration. Dafür ist es dann
> zäher zu bedienen, weil ich öfter zur Maus greifen muß.

Tastenkürzel sind konfigurierbar.

Wie benutzt Du dann Debugger und andere externe Tools, in Emacs im
Subfenster oder in parallelen Terminals? Bei Emacs hast Du ebenso das
Einbindungsproblem (+Lisp), bei Terminals hampelt man wie doof mit
Alt-Tab rum - nicht viel schneller IMHO, aber jeder hat so seine
Arbeitsweise.

Marc

[Marc Santhoff]

Marc Santhoff <m.san...@t-online.de> schrieb:

> > Dann gib' mir bitte mal Starthilfe und erklär' mir, wie ich mit dem
> > in Eclipse eingebauten Buildsystem konfiguriere, welches
> > Linkerscript und welchen Startupcode er nimmt (Makefile gilt nicht
> > - *das* funktioniert, aber dann sind halt die ganzen
> > Konfigurationsdialoge in eclipse für die Katz').
>
> Kann ich aus dem Ärmel auch nicht sagen, eben weil ich Makefiles
> benutze. <g>
>
> Ich würde erstmal die "Build Configurations" anpassen wollen, da
> sollte sich sowas lösen lassen. Damit wird doch die Abstraktion zum
> konkreten Build-Werkzeug hergestellt.

Ist auch so, vorausgesetzt das C-Projekt ist auf "managed make"
eingestellt.

In den Projektattributen eine neue Build Configuration erstellen, dabei
die bestehende Kopieren. Dann in den Einstellungen für den Linker
einfach nur bei den Optionen ein fröhliches "-Tram.ld" eintragen -
oder was Du so machen möchtest.

Dann kann man im Menü Project - Build die aktive Konfigruation
setzen, ausführen dann mit STRG-b wie immer.

Die grundsätzliche Projekterstellung mit den Einstellungen aus dem
Makefile kann man lösen, indem man ein vorhndenes Projekt in eine
neues, erstmal leeres C-Projekt importiert und sich daraus eine
Schablone bastelt.

Die Einstellung landen nicht wie ich vermutete in Verzeichnissen sondern
i.d.F. in der Datei ".cproject" im Quellverzeichnis bzw. beim
Projekt-Hauptknoten.

Marc

[Michael Schwingen]

On 2015-02-22, Marc Santhoff <m.san...@t-online.de> wrote:
>>
>> Das ist nur die Methode, die von den Chipherstellern nicht
>> unterstützt wird (gerade nochmal nachgesehen: ST liefert zwar eigenen
>> Startupcode mit ihrem HAL-Framework, aber kein dazu passendes
>> Linkerscript - und das von gcc-arm-embedded passt nicht zu den
>> ST-Sourcen). Wenn man sich das selber passend macht, klappt es - aber
>> dann brauche ich kein STM32-Plugin für Eclipse mehr.
>
> Die gehen einen anderen Weg. Da gibt es doch dieses .... ach da,
> STM32CubeMX. Entweder standalone oder auch als Eclipse-Plugin. DAmit
> wird ein passendes Project Template erstellt.

Ja. Nette Idee, funktioniert auch grundlegend und ist als Starthilfe sehr
nett. Der code des HAL scheint mir etwas dick zu sein - zusammen mit der
nicht superkompakten newlibc-nano kommt ein LED-Blinken-HelloWorld auf 5k
Code (knapp 4k mit -flto), aber optimieren kann man später, wenn es
funktioniert, und nur da, wo es drückt.

Dummerweise erzeugt STM32CubeMX ein Projekttemplate mit Code, wo
Linkerscript und Makefile fehlen - und die vom gcc nicht passen.

>> Mein Kollege mit längerer
>> embedded-Eclipse-Erfahrung konnte mir da nicht helfen (dafür an
>> anderer Stelle - der Indexer findet jetzt tatsächlich nur die
>> Sourcen, die auch zum Projekt gehören).
>
> Dürfte per "C/C++ General - Path and Symbols - Includes" in
> den Projektoptionen einzustellen sein, Pfadliste passend
> zurechtdengeln. Oder für den Indexer nochmal separat?

Nein. Mein Makefile setzt abhängig vom target unterschiedliche Includepfade,
z.B. für den HAL für 32F0xx vs. 32F1xx, und teilweise noch je nach C-File
unterschiedlich - das läßt sich in den Projektsettings nur schlecht statisch
abbilden. Aber: der build parser kann sich das prinzipiell aus den
Compilerausgaben beim make zusammenpuzzeln, wenn man ihm sagt, daß der
Compiler nicht "gcc", sondern ".*gcc" heißen darf. Wenn es funktioniert
(aktuell hakt es teilweise unter Windows wieder), ist das definitiv sehr
nett, auf Knopfdruck an die *richtige* Stelle zu springen, wo ein Symbol
definiert ist.

>> Ich bin nicht wirklich überzeugt, daß Dokumentation der Art "klicken
>> Sie hier auf Option X" wirklich zu reproduzierbaren Builds führt,
>> wenn man das mal auf einem Ersatzrechner hochziehen muß. Wenn dann
>> Teile der Sourcen (der Startupcode gehört für mich dazu) von Eclipse
>> (incl. Plugin) geliefert wird und nicht aus meinen Sourcen und auch
>> nicht vom Compiler/libc-Paket, dann ist es mit der Reproduzierbarkeit
>> völlig vorbei - solche Abhängigkeiten kann ich nicht ins
>> Versionskontrollsystem einchecken.
>
> So will ich das auch nicht haben. Allerdings sollten all diese
> Einstellungen eben in den Projektspezifischen Konfigurationsdateien von
> Eclipse zu finden sein, die gehören ins Repository.

Gut, damit ist man dann auf exakt diese Eclipse-Version und -Umgebung
festgenagelt. Ein Projekt aus Coocox (das ja auch eigentlich nur eine
eclipse-Variante zu sein scheint) läßt sich in einer nackten eclipse
jedenfalls nicht übernehmen. Ich denke, das spricht wieder sehr für
Makefiles :-)

>> Ich sehe einen Teil der Vorteile, aber wirklich spürbar besser als bei
>> emacs+Terminal ist nur die Debugger-Integration. Dafür ist es dann
>> zäher zu bedienen, weil ich öfter zur Maus greifen muß.
>
> Tastenkürzel sind konfigurierbar.

Ja, aber gefühlt brauche ich mehr Aktionen, gerade um Fenster zu wechseln.
Gut möglich, daß das besser geht, wenn mansich das alles mal passend
einstellt.

> Wie benutzt Du dann Debugger und andere externe Tools, in Emacs im
> Subfenster oder in parallelen Terminals? Bei Emacs hast Du ebenso das
> Einbindungsproblem (+Lisp), bei Terminals hampelt man wie doof mit
> Alt-Tab rum - nicht viel schneller IMHO, aber jeder hat so seine
> Arbeitsweise.

Make im emacs, gdb/ddd extern per Terminal. Wenn man zwischen passenden
virtuellen screens umschaltet, geht das recht gut - das ist aber definitiv
der Punkt, der bei der Eclipse-Lösung dicke Pluspunkte sammelt.

cu
Michael

[Michael Schwingen]

On 2015-02-23, Marc Santhoff <m.san...@t-online.de> wrote:
>> Ich würde erstmal die "Build Configurations" anpassen wollen, da
>> sollte sich sowas lösen lassen. Damit wird doch die Abstraktion zum
>> konkreten Build-Werkzeug hergestellt.
>
> Ist auch so, vorausgesetzt das C-Projekt ist auf "managed make"
> eingestellt.
>
> In den Projektattributen eine neue Build Configuration erstellen, dabei
> die bestehende Kopieren. Dann in den Einstellungen für den Linker
> einfach nur bei den Optionen ein fröhliches "-Tram.ld" eintragen -
> oder was Du so machen möchtest.

Danke - gut versteckt, mal probieren. Wobei: so richtig drängt es nicht
mehr, Make ist besser verständlich.

cu
Michael

[Marc Santhoff]

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

> >> Ich bin nicht wirklich überzeugt, daß Dokumentation der Art
> >> "klicken Sie hier auf Option X" wirklich zu reproduzierbaren
> >> Builds führt, wenn man das mal auf einem Ersatzrechner hochziehen
> >> muß. Wenn dann Teile der Sourcen (der Startupcode gehört für mich
> >> dazu) von Eclipse (incl. Plugin) geliefert wird und nicht aus
> >> meinen Sourcen und auch nicht vom Compiler/libc-Paket, dann ist es
> >> mit der Reproduzierbarkeit völlig vorbei - solche Abhängigkeiten
> >> kann ich nicht ins Versionskontrollsystem einchecken.
> >
> > So will ich das auch nicht haben. Allerdings sollten all diese
> > Einstellungen eben in den Projektspezifischen Konfigurationsdateien
> > von Eclipse zu finden sein, die gehören ins Repository.
>
> Gut, damit ist man dann auf exakt diese Eclipse-Version und -Umgebung
> festgenagelt. Ein Projekt aus Coocox (das ja auch eigentlich nur eine
> eclipse-Variante zu sein scheint) läßt sich in einer nackten eclipse
> jedenfalls nicht übernehmen. Ich denke, das spricht wieder sehr für
> Makefiles :-)

Ist da in deinem Umfeld eine ernstgemeinte Anforderung, aus beliebigen
anderen IDEen die Projekte nach Eclipse zu übernehmen? OK, wenn man vom
Hersteller oder aus dritter Quelle Zeugs geliefert bekommt, daß man
benutzen muß, da wäre vorstellbar.

Wenn man sowas tatsächlich oft oder wiederkehrend machen muß, würde man
sicher über ein Konverterprogramm nachdenken, in Konfigurationsdateien
geht es gewöhnlich streng formal zu.

Marc

[Marc Santhoff]

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

Ich hab's nur aus Neugier rausgesucht und dabei eine Menge über CDT
gelernt. Garnicht so geheimnisvoll eigentlich, und die Doku ist ganz OK.
Außerdem habe ich dabei gelernt, daß Makefiles *doch* besser sind. ;)

Marc

[Michael Schwingen]

On 2015-02-25, Marc Santhoff <m.san...@t-online.de> wrote:
>> Gut, damit ist man dann auf exakt diese Eclipse-Version und -Umgebung
>> festgenagelt. Ein Projekt aus Coocox (das ja auch eigentlich nur eine
>> eclipse-Variante zu sein scheint) läßt sich in einer nackten eclipse
>> jedenfalls nicht übernehmen. Ich denke, das spricht wieder sehr für
>> Makefiles :-)
>
> Ist da in deinem Umfeld eine ernstgemeinte Anforderung, aus beliebigen
> anderen IDEen die Projekte nach Eclipse zu übernehmen? OK, wenn man vom
> Hersteller oder aus dritter Quelle Zeugs geliefert bekommt, daß man
> benutzen muß, da wäre vorstellbar.

Sagen wir so: ich erwarte eigentlich, daß ich ein C-Projekt mit
verschiedenen IDEs übersetzen kann. Wenn das zwischen Eclipse-Varianten
schon nicht geht, ist das für mich nicht wirklich eine Methode, auf die ich
für die Zukunft setzen möchte - das ist so wie schematic entry für FPGAs, wo
dann beim nächsten Update der Hersteller ein neues schematic frontend
liefert - ohne Konverter, um die alten Designs importieren zu können.
Außerdem möchte man das auch in einer nicht-graphischen Umgebung
(buildserver) übersetzen können. Außerdem möchte ich nicht diverse
Eclipse-Herstellervarianten parallel auf einem Rechner installieren, um dann
je nach Projekt zwischen denen hin- und herzuwechseln.

Ich war beim Start irgendwie naiv davon ausgegangen, daß Eclipse halt ein
Makefile erstellt, welches man dann benutzen kann - das war wohl zuviel
erwartet.

Wie gesagt: nachdem ich meine Erwartungen neu justiert und auf manuell
erstellte Makefiles umgestellt habe, funktioniert alles, wie es soll.

cu
Michael

[Edzard Egberts]

Michael Schwingen wrote:
> Sagen wir so: ich erwarte eigentlich, daß ich ein C-Projekt mit
> verschiedenen IDEs übersetzen kann. Wenn das zwischen Eclipse-Varianten
> schon nicht geht, ist das für mich nicht wirklich eine Methode, auf die ich
> für die Zukunft setzen möchte

Na ja, man kann sich da aber schon behelfen, indem man die Eclipse für
die jeweilige Umgebung einrichtet, so ein Projekt für weitere Projekte
dann als Template kopiert und bloß die Sourcen einfügt (.h, .cpp, .c,
etc.). Meine Linux-Sourcen synce ich bloß auf die VMs und kann den Code
dann direkt in der Windows-Eclipse laufen lassen.

[Manuel Reimer]

Hallo,

mal ein Nachtrag zu dem Thema. Habe den Fehler gefunden:

https://github.com/M-Reimer/maple-bootloader/commit/69ed54a

Das ich nicht eingrenzen konnte hat daran gelegen, dass ich nicht
beachtet habe, dass der nicht optimierte Bootloader ja viel größer wird.
Ich musste also die Zieladresse, an die die eigentliche Firmware
geflasht wird, nach hinten verlegen.

So konnte ich dann erst schrittweise immer mehr Dateien mit "-Os"
kompilieren bis die problematische Datei gefunden war. In dieser dann
mit Attributen auf Funktionen runterbrechen und wenn die gefundene
Funktion zu groß ist diese in kleinere Funktionen runterbrechen bis man
die problematischen Zeilen gefunden hat.

Gruß

Manuel

[Michael Schwingen]

On 2015-03-02, Manuel Reimer <Manuel.N...@nurfuerspam.de> wrote:
> Hallo,
>
> mal ein Nachtrag zu dem Thema. Habe den Fehler gefunden:
>
> https://github.com/M-Reimer/maple-bootloader/commit/69ed54a

Ohne Lesen der restlichen Sourcen ist mir jetzt nicht so wirklich klar, was
die Ursache war bzw. was die Änderung wirklich tut?

Zumindest das "volatile" in jumpToUser erschließt sich mir nicht - das sieht
mir mehr nach Flicken aus als nach "Ursache beheben".

cu
Michael

[Johannes Bauer]

On 04.03.2015 15:12, Michael Schwingen wrote:
> On 2015-03-02, Manuel Reimer <Manuel.N...@nurfuerspam.de> wrote:
>> Hallo,
>>
>> mal ein Nachtrag zu dem Thema. Habe den Fehler gefunden:
>>
>> https://github.com/M-Reimer/maple-bootloader/commit/69ed54a
>
> Ohne Lesen der restlichen Sourcen ist mir jetzt nicht so wirklich klar, was
> die Ursache war bzw. was die Änderung wirklich tut?

Ja, müsste man im Assembly direkt vergleichen. Ich habe es auch
angeschaut und mir dasselbe gedacht.

Grundsätzlich ist das aber, wie ja im Thread schon angesprochen wurde,
eindeutig UB, mit einem integers Arithmetik zu machen und den dan in
einen Pointer zu casten. Und der geladene Funktionspointer wird wiederum
erst in einen Integer überführt, weiß auch nicht wieso.

Und nur am Rande verstehe ich auch nicht, warum immer jedermann seine
eigenen typedefs a la "u32" und "vu32" verwenden muss. Wahrscheinlich
auch noch irgendwo ein "#define TRUE 1", statt dass die Leute einfach
<stdint.h> und <stdbool.h> verwenden :-/

Die zweite Änderung kann ich gar nicht beurteilen.

Sieht aber beides danach aus, als ob der GCC einfach nur seine
Freiheitsgrade verwendet hat.

[Michael Schwingen]

On 2015-03-04, Johannes Bauer <dfnson...@gmx.de> wrote:
>
> Grundsätzlich ist das aber, wie ja im Thread schon angesprochen wurde,
> eindeutig UB, mit einem integers Arithmetik zu machen und den dan in
> einen Pointer zu casten. Und der geladene Funktionspointer wird wiederum
> erst in einen Integer überführt, weiß auch nicht wieso.

Ja. Ich sehe da zwar auf den ersten Blick nichts, was wirklich schlimm wäre
(man kann und darf sowas in Lowlevel-Code durchaus machen, aber bitte nur wo
wirklich nötig!), aber sowas erhöht leicht die Chancen, daß der Optimizer
doch eine andere Meinung hat, was gemeint war.

> Und nur am Rande verstehe ich auch nicht, warum immer jedermann seine
> eigenen typedefs a la "u32" und "vu32" verwenden muss. Wahrscheinlich
> auch noch irgendwo ein "#define TRUE 1", statt dass die Leute einfach
><stdint.h> und <stdbool.h> verwenden :-/

Immer noch besser als
#define TRUE 0
#define FALSE 1

mit passenden Abfragen (if (var == TRUE)) überall :-)

> Sieht aber beides danach aus, als ob der GCC einfach nur seine
> Freiheitsgrade verwendet hat.

Ja.

cu
Michael

[Reinhard Forster]

Am Thu, 05 Mar 2015 16:00:26 +0000 schrieb Michael Schwingen:

> Immer noch besser als
> #define TRUE 0
> #define FALSE 1
>
> mit passenden Abfragen (if (var == TRUE)) überall :-)

Das meinst Du jetzt aber doch nicht ernst, oder?

Ade

Reinhard

[Bernd Laengerich]

Am 05.03.2015 um 17:00 schrieb Michael Schwingen:

> Immer noch besser als
> #define TRUE 0
> #define FALSE 1
>
> mit passenden Abfragen (if (var == TRUE)) überall :-)

Jo, so macht man sich Freunde. Auch schön und in so einem Zusammenhang
schon gesehen: if ( var > TRUE ) ...

Bernd

[Michael Baeuerle]

Bernd Laengerich wrote:

> Michael Schwingen wrote:
> >
> > Immer noch besser als
> > #define TRUE 0
> > #define FALSE 1
> >
> > mit passenden Abfragen (if (var == TRUE)) überall :-)
>
> Jo, so macht man sich Freunde. Auch schön und in so einem Zusammenhang
> schon gesehen: if ( var > TRUE ) ...

Jenseits der Wahrheit liegt die absolute Wahrheit ;-)

[Reinhardt Behm]

On 06.03.2015 00:00, Michael Schwingen wrote:
> Immer noch besser als
> #define TRUE 0
> #define FALSE 1
>
> mit passenden Abfragen (if (var == TRUE)) überall:-)

Und das immer wieder beliebte:

if (expr > 0)
var = TRUE;
else
var = FALSE;

Es gibt viele Leute, die boolsche Variablen und Logik nicht kapieren.
Nur warum müssen die unbedingt programmieren?

--
Reinhardt

[Jack Ryan]

Reinhardt Behm <rb...@hushmail.com> wrote:

> Und das immer wieder beliebte:
>
> if (expr > 0)
> var = TRUE;
> else
> var = FALSE;
>
> Es gibt viele Leute, die boolsche Variablen und Logik nicht kapieren.

Hast du sie denn kapiert?

Je nach Einstellung des Lesers ist diese Variante einfacher zu Verstehen
als ein "var = (expr > 0)". Der Compiler generiert daraus sowieso
identischen Code.

[Reinhard Forster]

Am Fri, 06 Mar 2015 12:29:06 -0500 schrieb Jack Ryan:

> Reinhardt Behm <rb...@hushmail.com> wrote:
>
>> Und das immer wieder beliebte:
>>
>> if (expr > 0)
>> var = TRUE;
>> else
>> var = FALSE;
>>
>> Es gibt viele Leute, die boolsche Variablen und Logik nicht kapieren.
>
> Hast du sie denn kapiert?
>
> Je nach Einstellung des Lesers ist diese Variante einfacher zu Verstehen
> als ein "var = (expr > 0)".

... und man weiß, welchen Wert var nachher hat.

> Der Compiler generiert daraus sowieso identischen Code.

Da wäre ich mal nicht so sicher. Meines Wissens definiert C nur "TRUE"
als "ungleich Null". Je nach Compiler und Prozessor kann var auch gleich
expr sein, wenn expr > 0 ist. Oder -1 oder 0xffff oder sonstwas.

Ade

Reinhard

[Reinhardt Behm]

On 07.03.2015 22:42, Reinhard Forster wrote:
> Am Fri, 06 Mar 2015 12:29:06 -0500 schrieb Jack Ryan:
>
>> Reinhardt Behm <rb...@hushmail.com> wrote:
>>
>>> Und das immer wieder beliebte:
>>>
>>> if (expr > 0)
>>> var = TRUE;
>>> else
>>> var = FALSE;
>>>
>>> Es gibt viele Leute, die boolsche Variablen und Logik nicht kapieren.
>>
>> Hast du sie denn kapiert?
>>
>> Je nach Einstellung des Lesers ist diese Variante einfacher zu Verstehen
>> als ein "var = (expr > 0)".
>

> .... und man weiß, welchen Wert var nachher hat.

Wenn der Compiler dem Standard entspricht, weiß man das auch bei var =
expr > 0. Und das gilt schon seit K&R.

>> Der Compiler generiert daraus sowieso identischen Code.
>
> Da wäre ich mal nicht so sicher. Meines Wissens definiert C nur "TRUE"
> als "ungleich Null". Je nach Compiler und Prozessor kann var auch gleich
> expr sein, wenn expr > 0 ist. Oder -1 oder 0xffff oder sonstwas.
>
> Ade
>
> Reinhard

C definiert alles was !=0 ist als true, aber der Wert des Ausdrucks
(expr > 0) ist genau definiert, nämlich 0 oder 1, sonstiges widerspricht
dem Standard.

--
Reinhardt

[Reinhardt Behm]

Mir ging es nicht um den erzeugten Code. Und Deinen Satz würde ich
schreiben als "Je nach Kompetenz der Lesers...".

Ich habe schon viel fremden Code in den Fingern gehabt, und typisch
findet sich ncoh schimmeres dort, wo solche Konstrukionen vorkommen.
Manches sieht eher aus nach experimenteller Datenverarbeitung als nach
professioneller Arbeit.

--
Reinhardt

[Sieghard Schicktanz]

Hallo Jack,

Du schriebst am Fri, 6 Mar 2015 12:29:06 -0500 (EST):

> > Und das immer wieder beliebte:
> >
> > if (expr > 0)
> > var = TRUE;
> > else
> > var = FALSE;
> >
> > Es gibt viele Leute, die boolsche Variablen und Logik nicht kapieren.
>
> Hast du sie denn kapiert?

Du hast?

> Je nach Einstellung des Lesers ist diese Variante einfacher zu Verstehen
> als ein "var = (expr > 0)". Der Compiler generiert daraus sowieso
> identischen Code.

_Welcher_ "der" Compiler?

(Außerdem kennt C doch sowieso keine richtigen boolschen Variablen.)

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

[Reinhard Forster]

Am Sat, 07 Mar 2015 23:04:02 +0800 schrieb Reinhardt Behm:

> On 07.03.2015 22:42, Reinhard Forster wrote:
>> .... und man weiß, welchen Wert var nachher hat.
>
> Wenn der Compiler dem Standard entspricht, weiß man das auch bei var =
> expr > 0. Und das gilt schon seit K&R.

Grade habe ich nachgelesen: Du hast recht ("The C Language", Seite 41
oben).

> C definiert alles was !=0 ist als true, aber der Wert des Ausdrucks
> (expr > 0) ist genau definiert, nämlich 0 oder 1, sonstiges widerspricht
> dem Standard.

Eigentlich schon. Aber mir ist vor Jahrzehnten mal ein Compiler (IIRC für
den Z80) untergekommen, der da einfach nur irgendwas != 0 geliefert hat.
Stand dann irgendwo im Kleingedruckten.

Seither vermeide ich sowas wie

#define FALSE 0
#define TRUE 1
:
:
var = expr > 0;
:
:
if (var == TRUE) ...

Ade

Reinhard

[Wolfgang Allinger]

On 07 Mar 15 at group /de/sci/electronics in article mdf47r$dml$2...@dont-email.me

<rb...@hushmail.com> (Reinhardt Behm) wrote:

>Manches sieht eher aus nach experimenteller Datenverarbeitung

Goil, den Spruch muss ich mir merken :)


Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

--
Wolfgang Allinger, anerkannter Trollallergiker :) reply Adresse gesetzt!
Ich diskutiere zukünftig weniger mit Idioten, denn sie ziehen mich auf
ihr Niveau herunter und schlagen mich dort mit ihrer Erfahrung! :p
(lt. alter usenet Weisheit) iPod, iPhone, iPad, iTunes, iRak, iDiot

[Stefan Reuther]

Sieghard Schicktanz wrote:
>>Je nach Einstellung des Lesers ist diese Variante einfacher zu Verstehen
>>als ein "var = (expr > 0)". Der Compiler generiert daraus sowieso
>>identischen Code.
>
> _Welcher_ "der" Compiler?
>
> (Außerdem kennt C doch sowieso keine richtigen boolschen Variablen.)

Seit ca. 16 Jahren hat C einen Datentyp "_Bool", der mithilfe des
Headerfiles <stdbool.h> auch unter seinem üblichen Namen "bool" zur
Verfügung steht.


Stefan

[Stefan Reuther]

Reinhard Forster wrote:
> Am Sat, 07 Mar 2015 23:04:02 +0800 schrieb Reinhardt Behm:
>>C definiert alles was !=0 ist als true, aber der Wert des Ausdrucks
>>(expr > 0) ist genau definiert, nämlich 0 oder 1, sonstiges widerspricht
>>dem Standard.
>
> Eigentlich schon. Aber mir ist vor Jahrzehnten mal ein Compiler (IIRC für
> den Z80) untergekommen, der da einfach nur irgendwas != 0 geliefert hat.
> Stand dann irgendwo im Kleingedruckten.

Mir ist vor Jahren mal ein Compiler untergekommen, der aus
'while(variable)' manchmal eine Endlosschleife gemacht hat.
Stand dann nirgendwo im Kleingedruckten.

Sollte ich seitdem while-Schleifen meiden?

> Seither vermeide ich sowas wie
>
> #define FALSE 0
> #define TRUE 1
> :
> var = expr > 0;
> :
> if (var == TRUE) ...

Das heißt ja auch 'if (var)'.

Ich frage ja gerne Leute, die
if (var != false)
schreiben "um sicher zu sein", warum sie denn nicht
if ((((var != false) != false) != false) != false)
schreiben, um _ganz_ sicher zu sein.


Stefan

[Sieghard Schicktanz]

Hallo Wolfgang,

Du schriebst am 07 Mar 2015 13:19:00 -0300:

> >Manches sieht eher aus nach experimenteller Datenverarbeitung
>
> Goil, den Spruch muss ich mir merken :)

Das ist nix besonderes, sondern das Ergebnis von Debugging.

[Sieghard Schicktanz]

Hallo Reinhard,

Du schriebst am 7 Mar 2015 16:00:52 GMT:

> Seither vermeide ich sowas wie
>
> #define FALSE 0
> #define TRUE 1
> :
> :
> var = expr > 0;
> :
> :
> if (var == TRUE) ...

Was im wesentlichen zeigt, daß C ein boolescher Vergleichsoperator fehlt.
(Es hat zwar arithmetisches "oder" ["|"], "und" ["&"] und "nicht" ["~"] und
davon separates boolesches "oder" ["||"], "und" ["&&"] und "nicht" ["!"],
aber nur ein arithmetisches "gleich" ["=="], ein boolesches "gleich" fehlt.)

[Christian Zietz]

Sieghard Schicktanz schrieb:

> aber nur ein arithmetisches "gleich" ["=="], ein boolesches "gleich" fehlt.)

Wofür bräuchte man denn das? Statt "if (var == TRUE)" schreibt man "if
(var)" und statt "if (var == FALSE)" schreibt man "if (!var)".

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

[Guido Grohmann]

Michael Schwingen schrieb:

> Immer noch besser als
> #define TRUE 0
> #define FALSE 1

Sei einfach nur froh, daß nicht

#define TRUE 1
#define FALSE 0

da steht (weil irgendwer der Meinung war, seine [falschen] Bedingungen
nicht ändern zu wollen)

Guido

[Michael Schwingen]

On 2015-03-07, Stefan Reuther <stefa...@arcor.de> wrote:
>> var = expr > 0;
>> :
>> if (var == TRUE) ...
>
> Das heißt ja auch 'if (var)'.

aber nur, wenn expr unsigned ist.

cu
Michael

[Michael Schwingen]

On 2015-03-05, Reinhard Forster <r...@micro-forster.de> wrote:
>> #define TRUE 0
>> #define FALSE 1

> Das meinst Du jetzt aber doch nicht ernst, oder?

Doch :-(

Nicht selber gesehen, aber aus erster Hand.

cu
Michael

[Reinhardt Behm]

On 08.03.2015 04:32, Sieghard Schicktanz wrote:
> Hallo Wolfgang,
>
> Du schriebst am 07 Mar 2015 13:19:00 -0300:
>
>>> Manches sieht eher aus nach experimenteller Datenverarbeitung
>>
>> Goil, den Spruch muss ich mir merken :)
>
> Das ist nix besonderes, sondern das Ergebnis von Debugging.

Ja, man hat solange am Programm rumgebastelt, bis es irgendwie lief.
Warum weiß man nicht.

Dazu mal ein Zeit aus <http://www.ganssle.com/tem/tem278.html>

We could, for instance, begin with cleaning up our language by no longer
calling a bug "a bug" but by calling it an error. It is much more honest
because it squarely puts the blame where it belongs, viz., with the
programmer who made the error. The animistic metaphor of the bug that
maliciously sneaked in while the programmer was not looking is
intellectually dishonest as it is a disguise that the error is the
programmer's own creation. The nice thing of this simple change of
vocabulary is that it has such a profound effect. While, before, a
program with only one bug used to be "almost correct," afterwards a
program with an error is just "wrong." - E. W. Dijkstra

--
Reinhardt

[Reinhardt Behm]

On 08.03.2015 00:19, Wolfgang Allinger wrote:
> On 07 Mar 15 at group /de/sci/electronics in article mdf47r$dml$2...@dont-email.me
> <rb...@hushmail.com> (Reinhardt Behm) wrote:
>
>> Manches sieht eher aus nach experimenteller Datenverarbeitung
>
> Goil, den Spruch muss ich mir merken :)
>
>
> Saludos (an alle Vernünftigen, Rest sh. sig)
> Wolfgang
>

Das andere ist die span-abhebende Datenverarbeitung. Ich habe schon
Systeme mit Floppies gesehen, wo die oft benutzten Spuren durchsichtig
waren.
Aber das gehört schon wieder in Bereich Greisenelektronik.

--
Reinhardt

[Wolfgang Allinger]

On 08 Mar 15 at group /de/sci/electronics in article mdg5tm$rg7$1...@dont-email.me

<rb...@hushmail.com> (Reinhardt Behm) wrote:

>On 08.03.2015 00:19, Wolfgang Allinger wrote:
>> On 07 Mar 15 at group /de/sci/electronics in article
>> mdf47r$dml$2...@dont-email.me <rb...@hushmail.com> (Reinhardt Behm)
>> wrote:
>>
>>> Manches sieht eher aus nach experimenteller Datenverarbeitung
>>
>> Goil, den Spruch muss ich mir merken :)
>>

>Das andere ist die span-abhebende Datenverarbeitung. Ich habe schon
>Systeme mit Floppies gesehen, wo die oft benutzten Spuren durchsichtig
>waren.

Spanabhebende Datenverarbeitung war lange vor Floppy. zB. DEC RK02...

Da gabs echte Späne oder schon früher (Bryand (?) Autolift) danach SAGEM
Festkopfplatten mit ab und zu losen Köpfen :) Tolle Geräusche, man
wusste sofort: Du brauchst Dich nicht mehr zu beeilen :)

Später wurde die Technik von IBM mit den Winchester Platten wieder
reanimiert und verfeinert. Wenn die Schmierschicht durch Fliehkräfte
nach aussen wanderte oder gar die Oberfläche endgültig verlies: entweder
Späne bei der Landung oder abgerissenen Köppe bei Schlammpflügen...

Die Floppy war eher Schlapp-Datenverarbeitung :)

>Aber das gehört schon wieder in Bereich Greisenelektronik.

Jau, aber ruft Erinnerungen zurück an die 1. Festkopfplatte von SAGEM
die mir unterkam. Mit immerhin 128 Köpfen = Spuren zu je 1k Worte
(12bit, zusammen 128kWorte). Deutlich schneller als Lochstreifen :) Der
AEG60-10 Rechner dazu hatte 32kW Kernspeicher. IIRC 11uS Zykluszeit. Die
SAGEM hatte etwa die Grösse einer Waschmaschine nur mit mehr Problemen:

Die 1. wurde auf der Seite liegend auf einer Palette aus Fronkroich
angeliefert. Die hab ich erst garnicht abladen lassen.

Die 2. wurde dann beim Abladen aus etwa 30cm Höhe unsanft abgesetzt.
Franzose als Fahrer eben. Hauptsache die Golouise(?) fiel nicht runter
aus dem Mundwinkel. Test: auch tot, mindestens 32 Köpfe abgerissen.

Die 3. wurde dann von einem AEG-Ing im VW-Bus aus F geholt und war dann
brauchbar :) jedenfalls für ungefähr 4-6 Wochen.

Nein nein, das Projekt war nach Ansicht der Franzmänner eh nicht
zeitkritisch, da sowieso schon 6 Monate zu spät :(


Schönen Sonntag :)

Saludos (an alle Vernünftigen, Rest sh. sig)
Wolfgang

[Sieghard Schicktanz]

Hallo Christian,

Du schriebst am Sat, 07 Mar 2015 22:23:55 +0100:

> Sieghard Schicktanz schrieb:
>
> > aber nur ein arithmetisches "gleich" ["=="], ein boolesches "gleich"
> > fehlt.)
>
> Wofür bräuchte man denn das? Statt "if (var == TRUE)" schreibt man "if
> (var)" und statt "if (var == FALSE)" schreibt man "if (!var)".

Und was "schreibt man" für "res= var1 == var2;", wenn var1 und var2 keine
sicheren booleschen Werte sind, das Ergebnis aber einer sein soll?
Da bleibt dann nur so eine Hilfskonstruktion wie "res= !var1 == !var2;".
Schön und einsichtig ist anders. Und das ist nur einer der möglichen Fälle.

[Sieghard Schicktanz]

Hallo Stefan,

Du schriebst am Sat, 07 Mar 2015 22:12:05 +0100:

> > (Außerdem kennt C doch sowieso keine richtigen boolschen Variablen.)
>
> Seit ca. 16 Jahren hat C einen Datentyp "_Bool", der mithilfe des
> Headerfiles <stdbool.h> auch unter seinem üblichen Namen "bool" zur
> Verfügung steht.

Achnee, wirklich? _Das_ soll ein boolescher Datentyp sein? Das ist doch
auch bloß wieder ein integer-Typ in (nicht mehr ganz) neuer Verkleidung.
Halt nur mit einem Wertebereich von (0, 1), etwa wie ein ("unsigned"!)
1-Bit-Bitfeld.

#include <stdio.h>
#include <stdbool.h>

int main (int argc, char * argv [])
{
bool b, c;
int i, k;

b= !c;
printf ("b: %d, c. %d\n", b, c);
i= b; k= c;
printf ("i: %d, k. %d\n", i, k);
b= ~k; c= ~i;
printf ("b: %d, c. %d\n", b, c);
b += 1; c -= 1;
printf ("b: %d, c. %d\n", b, c);
return 0;
}

Das läßt sich problemlos compilieren, ohne daß der Compiler über
irgendwelche Typenprobleme mosert, es wird ohne Fehlermeldung abgearbeitet
und es liefert folgende Ausgabe:

b: 1, c. 0
i: 1, k. 0
b: 1, c. 1
b: 1, c. 0

[Bernd Laengerich]

Am 08.03.2015 um 00:47 schrieb Sieghard Schicktanz:

> Und was "schreibt man" für "res= var1 == var2;", wenn var1 und var2 keine

Ein EX-NOR ist als einzelner Operator nicht enthalten, es ist auch kein
boolesches xor vorhanden. Workaround ist die normierung auf boolsche
Werte und Nutzung des bitweisen Exklusiv-Oder, wobei die Symmetrie des
xor bzgl true/false ausgenutzt wird:

res = !(!var1 ^ !var2);

Sinnvollerweise verpackt man das der besseren Lesbarkeit aber in ein Makro:

#define bXOR(a,b) (!a ^ !b)
#define bXNOR(a,b) (!(!a ^!b))

Bernd

[Reinhardt Behm]

On 08.03.2015 16:49, Wolfgang Allinger wrote:
>
> On 08 Mar 15 at group /de/sci/electronics in article mdg5tm$rg7$1...@dont-email.me
> <rb...@hushmail.com> (Reinhardt Behm) wrote:
>
>> On 08.03.2015 00:19, Wolfgang Allinger wrote:
>>> On 07 Mar 15 at group /de/sci/electronics in article
>>> mdf47r$dml$2...@dont-email.me <rb...@hushmail.com> (Reinhardt Behm)
>>> wrote:
>>>
>>>> Manches sieht eher aus nach experimenteller Datenverarbeitung
>>>
>>> Goil, den Spruch muss ich mir merken :)
>>>
>
>> Das andere ist die span-abhebende Datenverarbeitung. Ich habe schon
>> Systeme mit Floppies gesehen, wo die oft benutzten Spuren durchsichtig
>> waren.
>
> Spanabhebende Datenverarbeitung war lange vor Floppy. zB. DEC RK02...
>
> Da gabs echte Späne oder schon früher (Bryand (?) Autolift) danach SAGEM
> Festkopfplatten mit ab und zu losen Köpfen :) Tolle Geräusche, man
> wusste sofort: Du brauchst Dich nicht mehr zu beeilen :)

Ich hab's zwar nicht selbst erlebt, aber damals die Trümmer gesehen, wo
Teile einer IBM-Platte aus dem geschlossenen Gehäuse geflogen waren.

> Später wurde die Technik von IBM mit den Winchester Platten wieder
> reanimiert und verfeinert. Wenn die Schmierschicht durch Fliehkräfte
> nach aussen wanderte oder gar die Oberfläche endgültig verlies: entweder
> Späne bei der Landung oder abgerissenen Köppe bei Schlammpflügen...
>
> Die Floppy war eher Schlapp-Datenverarbeitung :)
>
>> Aber das gehört schon wieder in Bereich Greisenelektronik.
>
> Jau, aber ruft Erinnerungen zurück an die 1. Festkopfplatte von SAGEM
> die mir unterkam. Mit immerhin 128 Köpfen = Spuren zu je 1k Worte
> (12bit, zusammen 128kWorte). Deutlich schneller als Lochstreifen :) Der
> AEG60-10 Rechner dazu hatte 32kW Kernspeicher. IIRC 11uS Zykluszeit. Die
> SAGEM hatte etwa die Grösse einer Waschmaschine nur mit mehr Problemen:
>
> Die 1. wurde auf der Seite liegend auf einer Palette aus Fronkroich
> angeliefert. Die hab ich erst garnicht abladen lassen.
>
> Die 2. wurde dann beim Abladen aus etwa 30cm Höhe unsanft abgesetzt.
> Franzose als Fahrer eben. Hauptsache die Golouise(?) fiel nicht runter
> aus dem Mundwinkel. Test: auch tot, mindestens 32 Köpfe abgerissen.
>
> Die 3. wurde dann von einem AEG-Ing im VW-Bus aus F geholt und war dann
> brauchbar :) jedenfalls für ungefähr 4-6 Wochen.
>
> Nein nein, das Projekt war nach Ansicht der Franzmänner eh nicht
> zeitkritisch, da sowieso schon 6 Monate zu spät :(
>
>
> Schönen Sonntag :)

Dir auch, meiner ist ja schon fast rum.


--
Reinhardt

[Stefan Reuther]

Sieghard Schicktanz wrote:
> Du schriebst am Sat, 07 Mar 2015 22:12:05 +0100:
>>>(Außerdem kennt C doch sowieso keine richtigen boolschen Variablen.)
>>
>>Seit ca. 16 Jahren hat C einen Datentyp "_Bool", der mithilfe des
>>Headerfiles <stdbool.h> auch unter seinem üblichen Namen "bool" zur
>>Verfügung steht.
>
> Achnee, wirklich? _Das_ soll ein boolescher Datentyp sein? Das ist doch
> auch bloß wieder ein integer-Typ in (nicht mehr ganz) neuer Verkleidung.
> Halt nur mit einem Wertebereich von (0, 1), etwa wie ein ("unsigned"!)
> 1-Bit-Bitfeld.

Was ist daran kein boolescher Datentyp?

Wir reden von C, und C hat keine Hemmungen, irgendwas, was irgendwie
sinnvoll ineinander konvertierbar ist, auch einfach mal eben zu
konvertieren. C konvertiert auch enum und int nach float und andersrum
automatisch. bool ist da keine Ausnahme.

> #include <stdio.h>
> #include <stdbool.h>
>
> int main (int argc, char * argv [])
> {
> bool b, c;
> int i, k;
>
> b= !c;

Das ist undefiniertes Verhalten, da c nicht initialisiert ist. Eine
uninitialisierte bool-Variable kann auch einen Wert haben, der weder
true noch false ist.

Aber das ist keine Besonderheit von C. Das kann z.B. in Pascal auch
passieren.


Stefan

[Sieghard Schicktanz]

Hallo Bernd,

Du schriebst am Sun, 08 Mar 2015 12:32:45 +0100:

> > Und was "schreibt man" für "res= var1 == var2;", wenn var1 und var2

...

> Ein EX-NOR ist als einzelner Operator nicht enthalten, es ist auch kein
> boolesches xor vorhanden. Workaround ist die normierung auf boolsche

Eben. (Wobei die Bezeichnung "EX-NOR" ein Euphemismus für "gleich" ist.)
Der Operator-Satz ist hier unvollständig, und der Programmierer muß
aufpassen, daß er immer die Löcher in der Sprachdefinition durch passende
Hilfskonstruktionen überbrückt.

> Werte und Nutzung des bitweisen Exklusiv-Oder, wobei die Symmetrie des
> xor bzgl true/false ausgenutzt wird:
>
> res = !(!var1 ^ !var2);

Das nutzt hier bloß garnichts, weil es eine genauso verquere Krücke
darstellt wie beim direkten Vergleichsoperator, es wird bloß noch eine
zusätzliche Invertierung gebraucht, die noch eine zusätzliche
Fehlermöglichkeit mehr bietet ("!" vs. "~").

> Sinnvollerweise verpackt man das der besseren Lesbarkeit aber in ein
> Makro:
>
> #define bXOR(a,b) (!a ^ !b)
> #define bXNOR(a,b) (!(!a ^!b))

Jaja, solche Makroverschlüsselungen sind ein recht wesentlicher Bestandteil
der C-Codierung - je mehr Makros zur "besseren Lesbarkeit" eingesetzt
werden, desto schlechter verständlich wird der Code...
Experten verstecken die Makro-Definitionen dann auch noch in viele Ebenen
tief geschachtelten Header-Files in Unter- oder gar externen Verzeichnissen.

[Sieghard Schicktanz]

Hallo Ralf,

Du schriebst am Sat, 7 Mar 2015 22:07:30 +0000 (UTC):

> > Was im wesentlichen zeigt, daß C ein boolescher Vergleichsoperator
> > fehlt.
>

> Nö, der ist nur nicht so offensichtlich.
...
> Du mußt halt auf logische Werte normalisieren:
> !a == !b

Genau, Du mußt der Programmiersprache eine Krücke zur Hand geben, damit sie
Dich nicht auf die Schnauze knallen läßt. Und pass` bloß auf, daß Du das
_nie_ vergißt!

[Sieghard Schicktanz]

Hallo Stefan,

Du schriebst am Sun, 08 Mar 2015 19:15:26 +0100:

> >>Headerfiles <stdbool.h> auch unter seinem üblichen Namen "bool" zur

...

> Was ist daran kein boolescher Datentyp?

Er ist _nicht_ _in_kompatibel zu arithmetischen Typen.

> Wir reden von C, und C hat keine Hemmungen, irgendwas, was irgendwie
> sinnvoll ineinander konvertierbar ist, auch einfach mal eben zu

Nicht nur was sinnvoll konvertierbar ist, C konvertiert recht wild alles,
was _darstellungsmäßig_ konvertierbar ist, ungeachtet des Zwecks.

> konvertieren. C konvertiert auch enum und int nach float und andersrum
> automatisch. bool ist da keine Ausnahme.

Eben. Wobei die Konversion zwischen int und float sogar noch eine Änderung
der _Darstellung_ beinhaltet. Wird bei Konversion zwischen enum und int
lediglich die interne Darstellung anders interpretiert, ist das bei int
versus float nicht der Fall - das _ist_ eine Ausnahme.

> > #include <stdio.h>
> > #include <stdbool.h>
> >
> > int main (int argc, char * argv [])
> > {
> > bool b, c;
> > int i, k;
> >
> > b= !c;
>
> Das ist undefiniertes Verhalten, da c nicht initialisiert ist. Eine

Hier war b "zufällig" anfangs 0, der gcc hat offenbar großzügig die
Deklarationen global angelegt. Ja, das ist ein Fehler im Programm.
Nur ändert dessen Korrektur nichts am Ergebnis und nichts an der Funktion.

> uninitialisierte bool-Variable kann auch einen Wert haben, der weder
> true noch false ist.
>
> Aber das ist keine Besonderheit von C. Das kann z.B. in Pascal auch
> passieren.

Nein. In Pascal - in _korrekt_ implementiertem Pascal - kann das _nicht_
passieren. Nein, in der Hinsicht ist FPC _nicht_ korrekt implementiert
(auch Delphi nicht). Beides sind inzwischen mehr C-Bastarde als Pascal-
Implementierungen.

[Sieghard Schicktanz]

Hallo Reinhardt,

Du schriebst am Sun, 08 Mar 2015 08:38:56 +0800:

> On 08.03.2015 04:32, Sieghard Schicktanz wrote:
> > Hallo Wolfgang,
> >
> > Du schriebst am 07 Mar 2015 13:19:00 -0300:
> >
> >>> Manches sieht eher aus nach experimenteller Datenverarbeitung
> >>
> >> Goil, den Spruch muss ich mir merken :)
> >
> > Das ist nix besonderes, sondern das Ergebnis von Debugging.
>
> Ja, man hat solange am Programm rumgebastelt, bis es irgendwie lief.
> Warum weiß man nicht.

Das ist inzwischen doch ein vielgepriesenes Standardverfahren, das sog.
"agile programming"...

> Dazu mal ein Zeit aus <http://www.ganssle.com/tem/tem278.html>

^^^^? Zitat?
...

> program with an error is just "wrong." - E. W. Dijkstra

Ja, damals (muß schon über ein Vierteljahrhundert her sein) hat man sowas
noch aussprechen dürfen. Heute ist der Fehler doch eher die Wurzel für neue
"Funktionalitäten"... (was für ein Wortungetüm...)

[Bernd Laengerich]

Am 08.03.2015 um 21:06 schrieb Sieghard Schicktanz:

> Eben. (Wobei die Bezeichnung "EX-NOR" ein Euphemismus für "gleich" ist.)

Das ist das gleiche bei boolschen Datentypen. Allerdings ist der
praktische Einsatz davon in Programmen nahezu null, wenn ich auf meine
bisherige Karriere zurückblicke.
In der CD4000-Reihe gibt es kein "Gleichheitsgatter", sehr wohl aber
XNOR, z.B. CD4077.

> Der Operator-Satz ist hier unvollständig, und der Programmierer muß

Der Operatorsatz ist immer unvollständig, den meisten Grundsprachen
fehlen einfache Operatoren für die nächste Primzahl,
Fouriertransformationen oder jeweils der übernächste Dienstag außer in
Monaten mit "R". Genausowenig findet man das
SN74-"tu-was-ich-will-Gatter" im Standardproduktkatalog von TI. Wenn man
in der Programmiersprache "Löten" arbeitet, sind die Fallstricke ebenso
vielfältig.

Bernd

[Reinhardt Behm]

On 09.03.2015 04:13, Sieghard Schicktanz wrote:
> Hallo Reinhardt,
>
> Du schriebst am Sun, 08 Mar 2015 08:38:56 +0800:
>
>> On 08.03.2015 04:32, Sieghard Schicktanz wrote:
>>> Hallo Wolfgang,
>>>
>>> Du schriebst am 07 Mar 2015 13:19:00 -0300:
>>>
>>>>> Manches sieht eher aus nach experimenteller Datenverarbeitung
>>>>
>>>> Goil, den Spruch muss ich mir merken :)
>>>
>>> Das ist nix besonderes, sondern das Ergebnis von Debugging.
>>
>> Ja, man hat solange am Programm rumgebastelt, bis es irgendwie lief.
>> Warum weiß man nicht.
>
> Das ist inzwischen doch ein vielgepriesenes Standardverfahren, das sog.
> "agile programming"...
>
>> Dazu mal ein Zeit aus <http://www.ganssle.com/tem/tem278.html>
> ^^^^? Zitat?

ups.
BTW: Jack Ganssle's Newletter ist sehr empfehlenswert.
> ....

>> program with an error is just "wrong." - E. W. Dijkstra
>
> Ja, damals (muß schon über ein Vierteljahrhundert her sein) hat man sowas
> noch aussprechen dürfen. Heute ist der Fehler doch eher die Wurzel für neue
> "Funktionalitäten"... (was für ein Wortungetüm...)
>

Zum Glück nicht überall. Wenn ich so bei meinen Entwicklungen arbeiten
würde, dann fiele der Flieger vom Himmel - und könnte mich treffen.

--
Reinhardt

[Stefan Reuther]

Sieghard Schicktanz wrote:
> Du schriebst am Sun, 08 Mar 2015 19:15:26 +0100:
>>>>Headerfiles <stdbool.h> auch unter seinem üblichen Namen "bool" zur
> ...
>>Was ist daran kein boolescher Datentyp?
>
> Er ist _nicht_ _in_kompatibel zu arithmetischen Typen.

Das liegt aber nicht an bool, sondern - wie ich schon schrieb - daran,
dass in C jeder Typ jedermanns Freund ist.

>>Wir reden von C, und C hat keine Hemmungen, irgendwas, was irgendwie
>>sinnvoll ineinander konvertierbar ist, auch einfach mal eben zu
>
> Nicht nur was sinnvoll konvertierbar ist, C konvertiert recht wild alles,
> was _darstellungsmäßig_ konvertierbar ist, ungeachtet des Zwecks.

Nein, eben gerade nicht. C konvertiert Werte. Exemplarisch: ISO
9899:1999 §6.3.1.3p2: "Otherwise, if the new type is unsigned, the value
is converted by repeatedly adding or subtracting one more than the
maximum value that can be represented in the new type until the value is
in the range of the new type", womit aus dem 'signed int' -1 mit der
Repräsentation 0x8001 (...sign/magnitude-Darstellung vorausgesetzt) der
'unsigned int' mit der Repräsentation '0xFFFF' werden kann.

>>konvertieren. C konvertiert auch enum und int nach float und andersrum
>>automatisch. bool ist da keine Ausnahme.
>
> Eben. Wobei die Konversion zwischen int und float sogar noch eine Änderung
> der _Darstellung_ beinhaltet. Wird bei Konversion zwischen enum und int
> lediglich die interne Darstellung anders interpretiert, ist das bei int
> versus float nicht der Fall - das _ist_ eine Ausnahme.

Nein, das ist der Regelfall. Um Repräsentationen zu konvertieren,
schrammt man gerne mal am undefinierten Verhalten vorbei,
int i = *(int*) &floatVar;
ist z.B. nicht zulässig (§6.5p7).

>>>int main (int argc, char * argv [])
>>>{
>>> bool b, c;
>>> int i, k;
>>>
>>> b= !c;
>>
>>Das ist undefiniertes Verhalten, da c nicht initialisiert ist. Eine
>
> Hier war b "zufällig" anfangs 0, der gcc hat offenbar großzügig die
> Deklarationen global angelegt.

Nein, gcc hat zufällig eine Speicherzelle oder ein Register mit dem Wert
0 erwischt.

>>uninitialisierte bool-Variable kann auch einen Wert haben, der weder
>>true noch false ist.
>>
>>Aber das ist keine Besonderheit von C. Das kann z.B. in Pascal auch
>>passieren.
>
> Nein. In Pascal - in _korrekt_ implementiertem Pascal - kann das _nicht_
> passieren. Nein, in der Hinsicht ist FPC _nicht_ korrekt implementiert
> (auch Delphi nicht). Beides sind inzwischen mehr C-Bastarde als Pascal-
> Implementierungen.

In Pascal haben uninitialisierte lokale Variablen genauso wie in C
undefiniertes Verhalten.

ISO 10206:1990 6.4.2.1: "The initial state denoted by an enumerated-type
or a subrange-type shall be totally-undefined." (boolean ist ein
Enumerationstyp.)


Stefan

[Edzard Egberts]

Sieghard Schicktanz wrote:
>>> #include <stdio.h>
>>> #include <stdbool.h>
>>>
>>> int main (int argc, char * argv [])
>>> {
>>> bool b, c;
>>> int i, k;
>>>
>>> b= !c;
>>
>> Das ist undefiniertes Verhalten, da c nicht initialisiert ist. Eine
>
> Hier war b "zufällig" anfangs 0

Das ist aber ein großer Zufall, nämlich 1:254. bool wird intern ja
meistens in ein Byte gepackt, nicht in ein Bit und der Operator '!' ist
bei bool meistens als bitweise Invertierung der gesamten Variablen
implementiert. So lange c also nicht zufällig als Null oder 255
initialisiert ist, ergibt "c= !c" immer true (> 0). Als Beispiel sei C=
0x0f, invertiert gibt das 0xf0 und beide Werte sind immer > 0. bool
nicht zu initialsieren ist eine böse Falle, die man unbedingt vermeiden
sollte.

[Heinz Saathoff]

Michael Schwingen schrieb:

Warum das? In C ist doch
if (var)
äquivalent zu
if(var != 0)
und damit sowohl für signed als auch unsigned variable gültig. Sogar
für float/double ist das so.


- Heinz

[Heinz Saathoff]

Edzard Egberts schrieb:

>Sieghard Schicktanz wrote:
>>>> #include <stdio.h>
>>>> #include <stdbool.h>
>>>>
>>>> int main (int argc, char * argv [])
>>>> {
>>>> bool b, c;
>>>> int i, k;
>>>>
>>>> b= !c;
>>>
>>> Das ist undefiniertes Verhalten, da c nicht initialisiert ist. Eine
>>
>> Hier war b "zufällig" anfangs 0
>
>Das ist aber ein großer Zufall, nämlich 1:254. bool wird intern ja
>meistens in ein Byte gepackt, nicht in ein Bit und der Operator '!' ist
>bei bool meistens als bitweise Invertierung der gesamten Variablen
>implementiert.

Welcher Compiler macht denn sowas? Das ist ja eine fehlerhafe
Umsetzung des Operators !
Was würdest Du hier erwarten:
int i;
for(i=0; i<256; ++i) {
printf("%d\n", !i);
}
Alles andere als 1 0 0 0 ...
wäre falsch.

[Edzard Egberts]

Heinz Saathoff wrote:
> Edzard Egberts schrieb:
>
>> Sieghard Schicktanz wrote:
>>>>> #include <stdio.h>
>>>>> #include <stdbool.h>
>>>>>
>>>>> int main (int argc, char * argv [])
>>>>> {
>>>>> bool b, c;
>>>>> int i, k;
>>>>>
>>>>> b= !c;
>>>>
>>>> Das ist undefiniertes Verhalten, da c nicht initialisiert ist. Eine
>>>
>>> Hier war b "zufällig" anfangs 0
>>
>> Das ist aber ein großer Zufall, nämlich 1:254. bool wird intern ja
>> meistens in ein Byte gepackt, nicht in ein Bit und der Operator '!' ist
>> bei bool meistens als bitweise Invertierung der gesamten Variablen
>> implementiert.
>
> Welcher Compiler macht denn sowas? Das ist ja eine fehlerhafe
> Umsetzung des Operators !

Bei dem Effekt bin ich mir sicher, bei meiner Erklärung nicht so. Kann
auch sein, dass der ! nur das Bit Null invertiert (halte ich sogar für
wahrscheinlicher als meine vorhergehende "komplett invertieren" Deutung,
weil das mit den Werten 0 / 1 besser hinkommt) und die Abfrage dann
wegen der anderen Bits durcheinander kommmt.

> Was würdest Du hier erwarten:

Ein Beispiel mit nicht initialisierten Bool-Werten.

bool a, b;
while (a!= b)
{
cout << "a!= b" << endl;
a= !a;
}