Hi, ich versuche unter WINAVR einzelne Portpins zu setzen. Der Code der dabei raus kommt ist aber viel zu lang Aus PORTC |= 0x80; wird ldi r30, 0x35 ; 53 ldi r31, 0x00 ; 0 ld r24, Z ori r24, 0x80 ; 128 st Z, r24 Erwarten tue ich aber was mit sbi Wie kann man den GCC dazu bringe das der das macht? Peter
>Wie kann man den GCC dazu bringe das der das macht?
Kann man nicht.
Den Grund dafür kann man in der Befehlsreferenz finden.
sbi lässt sich nur auf I/O-Register unterhalb 0x20 anwenden.
Wieso macht dann ein anderer Compiler so etwas wie sbi 0x1b,6 PORTA |= (0x80); Muss also gehen, nur wie?
Ich möchte nicht unhöflich sein, aber willst Du jetzt jedesmal wenn ich Dir einen Einzelfall erkläre, einen anderen Port wählen um dann zu einem anderen uC, zu einem anderen Compiler etc. überzugehen? Ein bischen musst Du schon selbst denken.
???????? Ich habe noch eine Demo Version von einem Anderen Compiler. Aber wie das mit Demos ist sind die nett anzusehen aber halt Demos. Der Code funktioniert auch nur unter WINAVR und den will ich auch nicht wechseln. Aber da ich Timing Probleme habe, habe ich halt nachgesehen und verglichen.
Guru schrieb: > sbi lässt sich nur auf I/O-Register unterhalb 0x20 anwenden. Peter schrieb: > sbi 0x1b,6 Klingelts?
Hmm. Wie sage ich es meinem Kinde? :-) Ich schrieb ja als Antwort auf Deine erste Frage, das der Compiler aus genau dem Grunde nicht sbi anwendet, weil der Befehl nur mit I/O-Adressen unterhalb 0x20 geht. Als nächstes fragst Du, warum aber sbi 0x1b,6 geht. Nun, 0x1B ist eine Zahl kleiner als 0x20. Vorbeugend möchte ich mitteilen, das dies auch für die Zahlen 0x0, 0x01, 0x02, usw. bis 0x1A, und 0x1C, 0x1D usw. bis 0x1F gilt (jeweils einschliesslich). Wenn ich also schreibe das ein Befehl nur für I/O-Adressen kleiner als 0x20 funktioniert, dann verwundert mich die Nachfrage warum dieser Befehl bei 0x1B geht. Mit dem Compiler hat das erstmal nichts zu tun. Auch nicht damit, ob der Compiler eine Demo-Version ist.
>Klingelts?
Wohl dem, der sich noch ein paar Groschen aufgehoben hat. :-)
@ 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.
Auf so Kleinigkeiten (Wert < 0x20) achte ich doch nicht. Aber das alles erklärt mir immer noch nicht warum beides funktioniert, aber total unterschiedliche Adressen und Methoden benutzt werden.
@Stefan Ernst Das ist es! Danke Ich hatte nur -O an um die Delay Funktionen nehmen zu können. Normalerweise habe ich gar keine Optimierung an, sonst kommt beim Debuggen nur Mist raus (Code und singelstep passen nicht).
Ja, Stefan Ernst, ich habe da was falsches geschrieben. Tut mir leid, Peter.
Habe ich das jetzt richtig verstanden? Ohne Optimierung erzeugt der Compiler 5 Assembler-Instruktionen zur Bewältigung einer Operation, für die der Prozessor grundsätzlich (*) einen speziellen einzelnen Befehl beherrscht? Ist es vermessen, daraus auf einen (zumindest an dieser Stelle) "etwas" übertrieben simpel zusammengestellten Compilers zu schließen? Der bei der Übersetzung fröhlich d'rauflosschwafelt, nach dem Motto: Nach mir die Codeflut. Der Optimizer wird's schon richten? (*) Selbst wenn der Spezialbefehl nur einen Teil der möglichen Portadressen abdeckt, würde ich die entsprechende Fallunterscheidung bereits im Compiler und nicht erst im Optimizer erwarten. Was am Fließband nicht vermurkst wird, muß bei der Qualitätskontrolle nicht repariert werden.
Ob der Optimizer die hier angesprochenen ASM-Befehle rauswirft und den sinnvollen kürzeren nimmt kannst doch einfach faststellen, einmal mit und einmal ohne optimize compilieren. Wenn nur die Anweisung "PORTC |= 0x80;" da steht, kann der Optimizer keine Anweisungen wegoptimieren. -Was logischer weise zu einem anderen Code führt- Aus dem 8051-Bereich kenne ich das auch (Keil-Compiler). Obwohl die 8051-Derivate den Befehl "jb" "Jump if Bit gesetzt" kennen, Bits können in einem best. Bereich des Ram definiert werden, macht der Compiler immer ein "copy bit ins Carry" mit anschließendem "jump if Carry set" daraus. Egal in welcher Optimierungs-Stufe! Die Konsequenz: Wenn es zeitlich klemmt, dann C-Code als Assembler darstellen lassen, den Assembler-Code von Hand optimieren und als ASM-Modul einbinden. Hatte ich beim 8051-Projekten hin- und wieder erfolgreich gemacht. (Die Doku vom Keil-C und Asm ist sehr gut)
@Guru Kein Problem, Deine Aussagen waren ja nicht falsch, es fehlte halt nur der entscheidende Hinweis zu der Optimierung. @Seneca Nun so wie es aussieht ist der GCC ein Code Monster. Ich kenne den von IAR und der macht es viel besser, aber kostet auch entsprechend. Bin auch schon am überlegen das Setzen mit ASM Befehl zu machen (ein Makro benutze ich da für sowieso schon). 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. 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). 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. Da würde mir mein Impuls am Pin fehlen. Peter
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 Dannegger schrieb: >> 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. Das Umsortieren führt aber nicht dazu, daß der Code mit Optimierung nicht mehr läuft. Es mag ein paar ganz bestimmte Spezialfälle geben, bei denen der gcc (ganz konform zum C-Standard) Befehle so umsortiert, daß im Mikrocontroller-Umfeld was anderes rauskommt, als der Programmierer wollte, aber das Problem des TO liegt zu 100% nicht daran. Ich stimme da Karl-Heinz völlig zu: Wenn es mit Optimierung nicht funktioniert, stecken Fehler im Programm. Immer. Oliver
Was " Karl Heinz Buchegger" über die Compiler sagt ist leider richtig! Das Port Beispiel war nur so dahin geschrieben um aufzuzeigen was da möglicherweise vom GCC falsch gemacht wird. Ob das da wirklich sauber gemacht wird habe ich nicht getestet. Nun ein Fehler ist nicht im Programm, sonst würden ca. 200 Produkte 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. Diesen speziellen Code hatte ich dann doch wieder mit dem IAR gemacht (läuft damit einwandfrei) und wir haben in der Firma den GCC wieder raus geworfen. Privat nehme ich den GCC und da ist mir das mit den Portpins und dem Debugger unangenehm aufgefallen. So nach 25 Jahren C Erfahrung sollte ich fast alle Tricks kennen! Nur so ein Compiler wie der GCC (AVR) bringt mich immer wieder zum verzweifeln. 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.
Compiler Fehler habe ich frühe auch schon einige gefunden. Aber die werden auch immer besser und somit ist die Wahrscheinlichkeit das in einem Compiler (IAR, Keil, ...) ein Fehler drin ist heute doch recht gering. Der Code in der Firma müsste schon einen sehr sehr blöder Fehler sein. Sonst hätte den schon jemand gefunden, bin da kein Einzelkämpfer. Auch Tools wie zB.Lint werfen keine Meldungen. Das hat schon das mit dem GCC zu tun. Aber das ist für die Firma nicht mehr interessant. Nur für mich Privat. Kann sein das der Fehler auch inzwischen raus ist WINAVR 2010... ist ja nun auch schon ein Jahr alt. Und nur gibt es ja die MHV AVR Tools und von Atmel einen Compiler. Was davon wiederum die bessere Wahl ist kann ich nicht beurteilen.
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.
Peter schrieb: > 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. Irrtum. Die Aussagen "Programm läuft" und "ist zu 100% fehlerfrei" haben erfahrungsgemäß nichts miteinander zu tun. Jeder Compiler optimiert anders, auch verschiedene Versionen von ein- und demselben. Programme, die unter älteren gcc-Versionen noch funktioniert haben, laufen unter neueren nicht mehr, wenn man z.B. volatiles nicht wirklich konsequent verwendet hat. Trotzdem optimeren auch die neueren gcc's eindeutig nur Sachen, die sie nach C-Standard auch dürfen. Das es m mit einer "laxen" Programmierung mit anderen Compilern oder mit älteren Versionen trotzdem funktioniert, ist halt Glück, aber ohne Garantie. Oliver
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 Dannegger schrieb: > Ich hab auch ne Weile gebraucht, daß Konzept, was hinter "volatile" > steht, zu verstehen. Die meisten Probleme mit dem GCC beruhen darauf. Dabei ist das doch wirklich nicht schwer zu verstehen. Und ein Konzept, bei dem ich dem Compiler explizit mitteilen kann, daß sich eine bestimmte Variable "ohne sein Wissen" ändern kann, finde ich allemal gelungener, als irgenwelche Pauschalfestlegungen, die dann zu 90% nicht zutreffen. Peter Dannegger schrieb: > Soviel Variablen werden es ja nicht sein. Genau so ist es. Oliver
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
Wollen wir mal nicht so auf dem IAR Thema herum reiten. Das Ergebnis ist richtig und der Code ist nach entsprechenden Richtlinien geschrieben und mehrfach validiert worden. @Johann L. Auch ein Referenz System kann Fehler haben! Dieser spezielle Code jeden falls nicht. 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. Ab wann sich der Fehler bemerkbar macht ist mit Sicherheit recht aufwendig herauszufinden. Ein kleines Programm wird da erfahrungsgemäß nicht reichen. Außer um festzustellen, ob Warteschleifen einfach entfernt werden und dadurch das Timing zerstört wird.
Peter schrieb: > Aber es geht um den GCC und der macht je nach Optimierungsstufe halt > unbrauchbaren Code. Das ist äußerst unwahrscheinlich. Wenn es dir gelingt, diesen Fehler in einem Codebeispiel nachzubilden, dann ist es tatsächlich ein Compilerbug. Aber in 99,9999999999999% aller Fälle sitzt der bug vor dem Computer. Um welche Compiler- bzw. WinAVR-Version handelt es sich denn? Oliver
Peter schrieb: > Außer um festzustellen, ob Warteschleifen einfach entfernt werden und > dadurch das Timing zerstört wird. Nachtrag: Wenn das passiert, ist es ein klassischer Programmierfehler. Das optimierte Schleifen mit ziemlicher Sicherheit schneller laufen, als nicht optimierte, sollte auch berücksichtigt werden. Oliver
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.
@Peter Dannegger Ich werde nächste Woche mir das Projekt wieder auf den Rechner holen und diesen Test mal durchführen. Hast Du einen Wunsch Compiler dafür? Ansonsten nehme ich den letzten WINARV Stand (201001...).. Ein Code-Beispiel würde ich ja hier zeigen, wenn ich mir dann keinen neuen Job suchen könnte und eine Millionen Klage am Hals hätte. Bei meinen Privaten Projekten hatte ich dieses Problem ja noch nie. Da war mir halt nur aufgefallen das die Portpins umständlich angesteuert werden. Und danach hatte ich eigentlich hier auch nur gefragt. Peter
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.