WINAVR Portpins setzen

@ Guru:
Schalte mal 'nen Gang runter, auch seine PORTC Adresse liegt doch 
offensichtlich unter 0x20, also reitest du auf dem falschen Gaul rum.

@ Peter:
Der Code sieht so aus, als ob du die Optimierungen nicht aktiviert hast. 
Also -Os benutzen.

Peter schrieb:

> Nun so wie es aussieht ist der GCC ein Code Monster.
> Ich kenne den von IAR und der macht es viel besser,

Der GCC ist vor allen Dingen eines:
Ein C-Standard konformer Compiler, der vom kleinesten µC ausgehend bis 
hinauf zu den Monster-Numbercrunching-Supercomputern eingesetzt wird. 
Jedesmal eine andere Architektur, jedesmal ein anderer CPU Aufbau, 
jedesmal vollkommen andere Architektur-Bitbreiten, jedesmal gänzlich 
andere Anforderungen an den Compiler.

Der IAR Compiler hingegen ist sozusagen massgeschneidert auf den AVR. 
Den beherrscht er, mehr aber auch nicht.

Es ist immer leicht schnell und clever zu sein, wenn man nicht allgemein 
flexibel sein muss.

> entsprechend. Bin auch schon am überlegen das Setzen mit ASM Befehl zu
> machen (ein Makro benutze ich da für sowieso schon).

SPar dir den Unsinn und benutz den Optimizer.
Wenn dein Timing davon abhängt, ob ein Bitsetzen durch eine tatsächliche 
OR-Operation oder durch sbi gemacht wird, dann ist in 95% der Fälle die 
Kacke sowieso an ganz anderer Stelle am dampfen.

> Mir wäre es auch lieber der GCC würde das auch ohne Optimierung machen.
> Dann könnte ich den Code auch vernünftig debuggen.

Zum Debuggen muss der Compiler nicht das letzte aus dem Code 
herausholen. Hingegen ist es beim Debuggen wichtig, dass jede 
Instruktion auch so umgesetzt wird, wie sie der Programmierer 
hingeschrieben hat. Und genau das macht der GCC.

> Ich habe ein anders Projekt was mit Optimierung überhaupt nicht läuft.
> Was da aber falsch läuft kann ich nicht erkennen (31K Binär Code).

Natürlich kommt es vor, dass Optimizer Fehler enthalten. Sind aber 
selten. Sehr viel wahrscheinlicher ist, dass du als Programmierer einen 
Fehler gemacht hast. In den meisten Fällen begründet sich dieser Fehler 
mit fehlenden bzw. ungenügenden Kentnissen der Programmiersprache C. Da 
dein Compiler aber sehr gut C 'versteht', nützt er gnadenlos Dinge aus, 
die du aus Unkentnis falsch gemacht hast.

Wie gesagt: Das ist der häufigste Fall, wie es bei dir ist weiß ich 
nicht.

> Womöglich werden da delays und Abläufe zusammen gefasst, was zwar
> Programmtechnisch OK ist aber ablauftechnisch eine Katastrophe ist.
> Ich beziehe das jetzt mal nur auch Port Zuweisungen.
> PortA = 0x10
> PortA = 0x00
> darf dann halt nicht zu
> PortA=0 werden, auch wenn das am ende raus kommt.


Ach komm.
Lern C, schau dir an wie die Dinge definiert sind und du wirst sehen, 
dass solche Sachen durch die entsprechenden C-Konstrukte und Anwenden 
der C-Regeln nicht vorkommen können. Im konkreten speziellen Fall lautet 
das Stichwort dazu 'volatile'. Und wie durch ein Wunder sind die Ports 
als 'volatile unsigned char *' definiert. Und somit darf der Compiler 
die beiden hintereinander folgenden Zuweisungen eben nicht zu einer 
einzigen zusammenfassen.
Aber dazu muss man halt C auch wirklich können und nicht nur einen 
Schnellsiederkurs mit einem windigen Tutorial aus dem Web gemacht haben.

Peter schrieb:
> Mir wäre es auch lieber der GCC würde das auch ohne Optimierung machen.

Ohne Optimierung ist nur für Programme möglich, wo die Ausführungszeit 
völlig egal ist.
Auch andere Compiler werden da nicht besser sein. In der Regel ist aber 
per default schon eine Optimierung eingeschaltet.


> Dann könnte ich den Code auch vernünftig debuggen.

Debuggen hat erstmal nicht mit Optimierung zu tun und benötigt auch 
nicht zwingend ein Debuginterface.
Man kann Funktionen für sich testen oder simulieren. Man kann sich die 
Ausgänge mit einem LA ansehen. Man kann Debugausgaben (UART, LCD) 
einfügen. Man kann aber auch das Fehlerbild analysieren (was wird 
erwartet, was passiert statt dessen) und dann nochmal in den Quellcode 
schauen.

Nur zu sagen, es funktioniert nicht und dann planlos zu debuggen ist die 
schlechteste Methode und dauert am längsten.


> Ich habe ein anders Projekt was mit Optimierung überhaupt nicht läuft.

Das ist eine Eigenart des GCC. Er kann Code umsortieren oder entfernen.
Das Umsortieren erfolgt nach dem Faulheitsprinzip. d.h. mache etwas so 
spät wie möglich. Leider ist das oft keine Optimierung und bewirkt sogar 
etwas mehr Code.
Ich würde mir auch eine Optimierungsoption wünschen, die zwar nach Größe 
optimiert, aber nicht umsortiert.

Entfernt werden Sachen, die er für unnötig hält. Das betrifft Variablen, 
die mit Interrupts kommunizieren. Er hält ne Kopie in einem Register und 
rechnet nicht damit, daß ein Interrupt sie ihm unter den Füßen 
wegändert. Das Zaubermittel ist dann "volatile", um ihn auf den rechten 
Pfad zu zwingen.


> Womöglich werden da delays und Abläufe zusammen gefasst, was zwar
> Programmtechnisch OK ist aber ablauftechnisch eine Katastrophe ist.

Benutze die "delay.h", dann sollten alle Delays klappen.



> Ich beziehe das jetzt mal nur auch Port Zuweisungen.
> PortA = 0x10
> PortA = 0x00
> darf dann halt nicht zu
> PortA=0 werden, auch wenn das am ende raus kommt.

Macht er auch nicht, da die Ports als volatile definiert sind. Man muß 
bloß die Symbole der io.h benutzen.
Also "PORTA" und nicht "PortA".


Peter

Peter schrieb:

> nicht laufen (selbe Code Basis). Nur Produkt 201 gemacht mit dem GCC,
> macht Ärger. Ich vermute das etliche Timings nicht mehr passen oder
> Teile zusammen gefast werden die nicht zusammengefasst werden dürfen.
> Also kommt mir nicht mit so einem Unsinn das die Optimierung fehlerfrei
> arbeitet.


Wenn ich die Wahl hätte ob ich davon ausgehe, dass der Optimizer einen 
Fehler gemacht hat oder ob du einen bisher unentdeckten Programmfehler 
gemacht hast, dann weiß ich worauf ich mein Geld setzen würde. Das muss 
nicht unbedingt heißen, das ich richtig liege. Aber die 
Wahrscheinlichkeit spricht einfach gegen dich.

Und ja: Das ist mir auch schon passiert!
Programmfehler die 15 Jahre (!) unentdeckt im Code überlebt haben. Wenn 
man sowas findet, dann greift man sich auf den Kopf. Wie kann sowas 
passieren? Wie ist ein derart lange Zeit möglich? Es ist möglich!

Und ja, ich hab auch schon Compilerfehler gefunden. Ich arbeite seit 
1987 mit Microsoft C und C++ Compilern. In der Zeit konnte ich den 
jeweiligen Compilerversionen zusammengenommen ganze 3 Übersetzungsfehler 
nachweisen. So richtig mit allem drum und drann: also runter analysieren 
bis auf Assemblerebene; abklären mit dem C Standard, wie das Verhalten 
sein müsste etc.
Das heißt nicht, dass es nicht mehr gegeben hat. Aber mehr sind bei mir 
nun mal nicht aufgetaucht. Und in der Zeit werde ich wohl die 2-stellige 
Millionanzahl an geschreibenen Lines of Code schon erreicht haben.

Peter schrieb:
> Vergessen:
> Wenn ein Fehler im Code drin wäre dann hätte auch der IAR Compiler einen
> Fehler. Denn das Programm läuft zu 100% Fehler frei, mit dem IAR.

Du kannst das noch so oft wiederholen, aber dass das Programm mit dem 
IAR problemlos läuft, ist trotzdem kein Beweis für Fehlerfreiheit. Es 
gibt mehrere mögliche Szenarios. Ein Beispiel: du beschreibst ein Array 
ein Zeichen über das Ende hinaus. Ob das nun zu einem Fehlverhalten 
führt, oder nicht, hängt einzig davon ab, welche Variable hinter dem 
Array im Speicher liegt. Und bei der Anordnung der Variablen werden sich 
beide Compiler/Linker vermutlich unterscheiden.

Peter schrieb:
> Der Code in der Firma müsste schon einen sehr sehr blöder Fehler sein.

Es läßt sich drüber streiten, ob es ein Fehler des Programmierers oder 
ein Feature des GCC ist.**

Einige Mikrocontroller Compiler gehen davon aus, daß globale Variablen 
von Interrupts geändert werden können und daß leere Zählschleifen der 
Programmierer absichtlich eingebaut hat. Sie liegen damit in der Regel 
richtig.

Der GCC ist aber pingelig und implementiert nur das, was der C-Standard 
ausdrücklich vorschreibt. Er versucht nicht, aus Sicht des 
Programmierers zu denken.

Ich hab auch ne Weile gebraucht, daß Konzept, was hinter "volatile" 
steht, zu verstehen. Die meisten Probleme mit dem GCC beruhen darauf. 
Wenn man aber alle globalen Variablen der Interrupts daraufhin überprüft 
und anpaßt, sollten die Programme danach laufen.
Soviel Variablen werden es ja nicht sein.

Das default "nicht volatile" gibt dem GCC die Gelegenheit, auch globale 
Variablen temporär in Registern zu halten und besser zu optimieren.


**
Eigentlich nicht, denn alles, was nicht im Standard steht, muß logischer 
Weise ein Programmfehler sein.
Programmierer dürfen keine Annahmen treffen.


Peter

Peter schrieb:

> Das hat schon das mit dem GCC zu tun.
> Aber das ist für die Firma nicht mehr interessant.
> Nur für mich Privat.

Schon lustig: Anstatt die Möglichkeit beim Schopfe zu packen, und den 
eigenen Code robuster zu machen, wird einfach ein möglicher 
Referenz-Compiler als fehlerhaft erklärt -- und die Welt ist wieder 
heil.

Dabei ist nicht unwahrscheinlich, daß auch ein anderer Compiler früher 
oder später unsoliden Code abstraft.

@Peter (Gast)

Versuch einfach mal, ein kleines Beispielprogramm zu erstellen, welches 
mit IAR geht, aber mit AVR-GCC nicht.
Dann kann man ganz schnell erkennen, wo das Problem liegt.


Peter

Peter schrieb:
> Wie ich schon sagte lief de Code mit eingeschalteter
> Optimierung nicht

Kannst Du dieses "lief nicht" irgendwie eingrenzen, was Du damit meinst. 
Es muß ja irgendein Fehlerbild geben.

Es kann z.B. sein, daß durch die Optimierung etwas zu schnell läuft und 
eine externe Hardware dann nicht mitkommt. Z.B. Hochvolt-CMOS (CD4xxx) 
kann bei 5V nur max 1MHz ab.


Peter

Peter schrieb:
> Das Ergebnis ist richtig und der Code ist nach entsprechenden
> Richtlinien geschrieben und mehrfach validiert worden.

Ach so, sag das doch gleich. Na dann MUSS der Ausgangs-Code ja 100%ig 
fehlerfrei sein.

> Aber es geht um den GCC und der macht je nach Optimierungsstufe halt
> unbrauchbaren Code. Wie ich schon sagte lief de Code mit eingeschalteter
> Optimierung nicht, ohne lief er.

Da du auf dem Ohr taub zu sein scheinst, hat es wohl auch keinen Zweck, 
dir nochmal zu erklären, dass das KEINEN Rückschluss darauf zulässt, ob 
der Fehler nun im Source-Code, oder dem Optimierer liegt.

> "volatile" wird übrigens immer benutzt.

Und auch immer richtig? Z.B. bei Pointer?

Aber da du keine Anstalten machst, etwas Konkretes (Beispiel-Code) 
beizusteuern, mit dessen Hilfe man dem Ganzen mal konkret auf den Grund 
gehen könnte, ist das alles hier sowieso völlig sinnlos.

Man kann auch jedes C-File separat compilieren mit einer anderen 
Optimierungsstufe und dann zusammenlinken.
Dadurch kann man herausfinden, welches C-File die Optimierung nicht 
verträgt.

Man sollte die Optimierung -Os bevorzugen, da sie am meisten verwendet 
wird (Standard beim AVRStudio) und daher am besten getestet ist.


Peter

Peter schrieb:

> @Johann L.
> Auch ein Referenz System kann Fehler haben!

Klar. Mir persönlich würde sowas aber keine Ruhe lassen.
Ich würd da solange rumsuchen bis ich mit dem Finger auf den Fehler 
zeigen kann :-)

Ihr seid ja vertraut mit der Applikation, allein die Intuition gibt 
schon eine sehr gute Abschätzung, an welcher Stelle sich der erzeugte 
Code nicht verhält wie erwartet.

> Aber es geht um den GCC und der macht je nach Optimierungsstufe halt
> unbrauchbaren Code. Wie ich schon sagte lief de Code mit eingeschalteter
> Optimierung nicht, ohne lief er. Er wäre nur zu gross ohne Optimierung.
>
> "volatile" wird übrigens immer benutzt.

Hilft auch nicht gegen Race-Conditions, falschem Inline-Assembler bzw. 
COnstraints, Type-Punning / Verletzung von Strict Aliasing, falschem 
Einsatz globaler Register, ABI-Violations, etc

> Ab wann sich der Fehler bemerkbar macht ist mit Sicherheit recht
> aufwendig herauszufinden. Ein kleines Programm wird da erfahrungsgemäß
> nicht reichen.

ACK. Fehlersuche IST aufwändig.

> Außer um festzustellen, ob Warteschleifen einfach entfernt werden und
> dadurch das Timing zerstört wird.

Warteschleifen in reinem C sind eh hinfällig.