Hallo,

eine Frage, die die Experten sicher schnell beantworten können:

Hat sich zwischen WinAVR 2003 09 13 und der aktuellen Version 2008 02 04
soviel geändert, daß man die alten Programme mit der neuen Version
überhaupt nicht mehr kompiliert bekommt?

Die Bitmanipulationen scheinen nicht mehr zu funktionieren, ist denn da
inzwischen alles depreceated?
Müssen z.B. Zeilen wie
 " TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWSTO); "
gänzlich neu geschrieben werden, damit es wieder funktioniert?

Und noch ein kleineres Problem:
füher konnte man schreiben
#include <avr/util/twi.h>,
jetzt wird der gesamte Pfad verlangt, also z.B.
#include <C:/Progr-MCU/WinAVR0800204/avr/include/avr/twi.h>.
Ist denn das normal oder ist da bei meiner Installation etwas falsch
gelaufen?

mfg
Peter

> Ist denn das normal

Nein.

>Hat sich zwischen WinAVR 2003 09 13 und der aktuellen Version 2008 02 04
>soviel geändert, daß man die alten Programme mit der neuen Version
>überhaupt nicht mehr kompiliert bekommt?

Ja, so ist es!

Allerdings trifft es auf die zwei von dir genannten Fänomehne nicht zu.

Peter Leistikow wrote:

> Die Bitmanipulationen scheinen nicht mehr zu funktionieren, ist denn da
> inzwischen alles depreceated?

Deprecated waren sie selbst 2003 schon.  Deine Software hat sich
offenbar nur nicht dran gehalten.

Peter Leistikow wrote:

> Müssen z.B. Zeilen wie
>  " TWCR = (1<<TWINT) | (1<<TWEN) | (1<<TWSTO); "
> gänzlich neu geschrieben werden, damit es wieder funktioniert?

Nein.
Die Zeile ist voll o.k.


> füher konnte man schreiben
> #include <avr/util/twi.h>,

Ist immer noch so.


> jetzt wird der gesamte Pfad verlangt, also z.B.
> #include <C:/Progr-MCU/WinAVR0800204/avr/include/avr/twi.h>.

Dann ist was schief gelaufen bei der Installation.


Peter

Naja...ein Compiler, der Ansprüche bei Bitmanipulationen
stellt...grummmel...

Peter Leistikow wrote:

> #include <avr/util/twi.h>,

Wenn das mal so war, hat sich das geändert.

Der Ordner util ist jetzt nicht im avr Verzeichnis, sondern eine Ebene
oberhalb! Also:

#include <util/twi.h>

bzw. geht auch

#include <compat/twi.h>

was aber auch nur util/twi.h einbindet. Dass dein kompletter Pfad
funktioniert, ist klar: dort berücksichtigst du ja, dass util nicht in
avr steht.

Stefan "stefb" B. wrote:
> Peter Leistikow wrote:
>

> Der Ordner util ist jetzt nicht im avr Verzeichnis, sondern eine Ebene
> oberhalb! Also:
>
> #include <util/twi.h>
>
Stimmt! Ich hätte genauer hinsehen sollen!

Vielen Dank
Peter

Jupp wrote:

> Naja...ein Compiler, der Ansprüche bei Bitmanipulationen
> stellt...grummmel...

Macht er doch gar nicht.  Er hat die Standard-Bitoperatoren von C schon
immer verstanden und wird sie immer verstehen.  Nur manche Nutzer tun
sich zuweilen schwer damit, diese zu verstehen, und benutzen daher
allerlei andere Darstellungen stattdessen.

Hallo,

Auch ich habe so einige Probleme mit den neuen Versionen.
20060421 ist meine letzte funktionstüchtige Winavr-Toolchain.
Alle Versionen danach liefern entweder keinen lauffähigen Maschinenkode
oder haben wie die jetztige Ausgabe ein Problem mit den ...._P
Funktionen bzw PSTR. Das heißt der selbe Quellkode bringt ohne Warning
oder Error unterschiedliche Ergebnisse. Ich verwende keine
Optimierungen. Der Grund warum ich auf eine neuere Version umsteigen
möchte, liegt in der Hoffnung dass nun vielleicht schon mehr _P
Funktionen zur Verfügung stehen.

Hat wer eine Ahnung woran das liegen könnte?

Mich wundert natürlich, dass andere keine Probleme damit haben.


Gruß
Willi

>Ich verwende keine Optimierungen.

Da solltest Du aber unbedingt tun! Verwende zumindest die Stufe O-1,
höhere Stufen bringen dann nicht mehr wahnsinnig viel.

Wilhelm Stejskal wrote:
> Hallo,
>
> Auch ich habe so einige Probleme mit den neuen Versionen.
> 20060421 ist meine letzte funktionstüchtige Winavr-Toolchain.
> Alle Versionen danach liefern entweder keinen lauffähigen Maschinenkode
> oder haben wie die jetztige Ausgabe ein Problem mit den ...._P
> Funktionen bzw PSTR. Das heißt der selbe Quellkode bringt ohne Warning
> oder Error unterschiedliche Ergebnisse. Ich verwende keine
> Optimierungen.
>
> Hat wer eine Ahnung woran das liegen könnte?
>
> Mich wundert natürlich, dass andere keine Probleme damit haben.

Wenn der Compiler nachweislich falschen Code erzeugt ist das ein Bug.
Der Compiler muss auch ohne Optimierung korrekten Code liefern.

Manche Fehler treten eben nur mit -O0 auf und bei höhrern
Optimierungsstufen nicht mehr. O0 wird selten verwendet, daher ist
vielleicht noch nicht aufgefallen. Ich erinnere mich da ab Probleme bei
local static im Zusammenhang mit PROGMEM.

Ohne Quelle ist's aber Lesen ausm Kaffeesatz...

>Mich wundert natürlich, dass andere keine Probleme damit haben.

Stell doch mal ein Beispiel hier rein, der nur mit einem 2006er WinAVR
funktioniert.

Oliver

Jetzt muss ich erst einmal mein laufendes Projekt fertigstellen. Danach
werde ich mich erneut zu diesem Thema äußern. Also bitte um etwas
Geduld.

Gruß
Willi

Ps.:
Was ich im Listing gesehen habe, könnte es sich um ein near/far-Problem
handeln.

Ich habe heute folgendes festgestellt:

Bei der Version 080610 wird beim Konvertieren des HEX-Files in ein
SREC-File (z.B srec_cat test.hex -Intel -Output test.srec -Motorola
-Line_Length 142) kein S9-Record gesetzt. Damit haben Programmer und
Bootloader schon mal ihre Probleme. Weiters führen die Funktionen
eeprom_read_byte(&test8) und eeprom_read_word(&test16) zum Absturz. Die
Schreibfunktionen hingegen scheinen keine Probleme zu machen. Ob ins
EEProm tatsächlich geschrieben wird kann ich im Moment aber nicht
prüfen. Selber Sourcecode mit einer Toolchainversion von 2006 kompiliert
läuft tadellos. WinAVR aus 2006 hat allerdings Probleme mit Windows
Vista. Darum bin ich auf die derzeitge 2008er Version angewiesen.

Wilhelm Stejskal wrote:
> Ich habe heute folgendes festgestellt:
>
> Bei der Version 080610 wird beim Konvertieren des HEX-Files in ein
> SREC-File (z.B srec_cat test.hex -Intel -Output test.srec -Motorola
> -Line_Length 142) kein S9-Record gesetzt.

srec_cat gehört zu srecord (http://srecord.sourceforge.net/) und damit
nicht zum GCC. vielleicht gibts da ne neue Option um das einzustellen?

> Damit haben Programmer und
> Bootloader schon mal ihre Probleme. Weiters führen die Funktionen
> eeprom_read_byte(&test8) und eeprom_read_word(&test16) zum Absturz.

Wer stürzt ab? deine Kaffetasse, dein Windows, AVRStudio, der
GCC-Compiler, der AVR nachher?

Oder meinst du mit "abstürzen": "er gibt eine Warn/Fehlermeldung aus,
die ich nicht lesen wollte"?


> Die
> Schreibfunktionen hingegen scheinen keine Probleme zu machen. Ob ins
> EEProm tatsächlich geschrieben wird kann ich im Moment aber nicht
> prüfen. Selber Sourcecode mit einer Toolchainversion von 2006 kompiliert
> läuft tadellos.

Kompilier doch mal mit allen Warnings eingeschaltet (-Wall), behebe die
angezeigten Probleme, und versuchs erneut.
Solche Probleme entstehen oft, wenn der Quelltext von Anfang an
Fehlerhaft war, und nur durch Zufall mit der alten Version funktioniert
hat.

Mein lieber Ernst,

Klar hast du Recht das srec_cat nicht zum gcc gehört. Aber es ist nun
mal ein Teil der Toolchain WinAVR und daher im Ganzen gesehen
erfolgsbestimmend.

Deine Frage von wegen Errors, Warnings und unsauberen Kode kann ich dir
leicht beantworten. Nein ich habe keine Errors und keine Warnings. Ein
Warning würde ich persöhnlich bereits als Error werten und somit nicht
zulassen.

Fakt ist, dass ein und der selbe Kode unterschiedliche Ergebnisse
bringt. 2006 läuft und 2007 bzw. 2008 läuft nichtmehr. Der GCC ist mit
dem Makefile standardmäßig konfiguriert (MFILE). Die einzigen Änderungen
der Konfig waren die Abschaltung der Optimierung, setzen der float für
die printf, CPU-Geschwindigkeit und der Dateiname. Gleiches neues
Makefile wurde auch für die 2006er-Version erfolgreich verwendet.

Ich hoffe das dies jetzt auch für dich klar und eindeutig beschrieben
ist und erhoffe mir anstatt wortglauberischen Standardsätzen vielleicht
doch noch zu kompetenten Antworten zu kommen.

Gruß
Willi

Wilhelm Stejskal wrote:
> Ich hoffe das dies jetzt auch für dich klar und eindeutig beschrieben
> ist und erhoffe mir anstatt wortglauberischen Standardsätzen vielleicht
> doch noch zu kompetenten Antworten zu kommen.

Glaube ich nicht. Werd' mal konkreter.

EDIT: Etwas entschärft. Sorry ;)

Wilhelm Stejskal wrote:

> Fakt ist, dass ein und der selbe Kode unterschiedliche Ergebnisse
> bringt. 2006 läuft und 2007 bzw. 2008 läuft nichtmehr. Der GCC ist mit
> dem Makefile standardmäßig konfiguriert (MFILE). Die einzigen Änderungen
> der Konfig waren die Abschaltung der Optimierung, setzen der float für
> die printf, CPU-Geschwindigkeit und der Dateiname. Gleiches neues
> Makefile wurde auch für die 2006er-Version erfolgreich verwendet.

Fakt ist, ein und derselbe Code liess sich sowohl mit diversen 3er als
auch mit 4er AVR-GCC-Versionen compilieren, ohne Abstürze, und hat
jedesmal ein funktionierendes Hexfile ergeben, auch wenn der
Speicherbedarf immer etwas geschwankt hat.

Wenn das bei dir anders war, musst du uns schon ein
Beispiel-Codefragment zeigen.
Reines "Früher war alles besser"-Gejammer bringt dir nix, und hilft auch
den AVR-GCC-Maintainern nicht weiter, das Problem zu finden.

So, ich habe es nun. Es ist ein echter bug. Da ihr aber ja sooo gut und
erhaben seid, alle anderen von Haus aus erstmal für einen Trottel anseht
und selbst nur blanke Sprüche von euch geben könnt, lasse ich euch
einfach mal selber weiter raten woran es liegt. Wer natürlich nur dumme
Reden schwingen kann oder über eine "Hello world" selbst noch nicht
darüber hinaus gekommen ist, wird's wohl nicht merken. Wer sich
allerdings mit der Materie wirklich beschäftigt der wird es über kurz
oder lang auch entdecken. Alles nur eine Frage des Einsatzes und der
aufzuwendenten Zeit.

Also schwelgt weiter in eurem Hochmut und drescht Phrasen was das Zeug
hält.

Bedanke mich somit für die überaus fachlich kompetenten Wortmeldungen.

Gruß
Willi

Behalt ihn ruhig für dich.  Das ist die beste Garantie, dass der Bug
auch wirklich nie gefixt wird.

Don't feed the Trolls - wahrscheinlich wars nur ein vergessenes
Semikolon, der Rest ist frei erfunden.

Oliver

Das sicher nicht, denn die Syntax hat sich nicht geändert, das wäre
also früher auch schon ein Syntaxfehler gewesen. ;-)

Wilhelm Stejskal wrote:
> So, ich habe es nun. Es ist ein echter bug.

Klar, ein Bug in deinem Programm. Das hätte ich dich auch vorher sagen
können ;)

lol
Mit euch hat man ja wirklich richtig Spass.

Oliver hat scheinbar keine Ahnung von C. Ansonsten würde er nicht meinen
dass ein fehlendes Semikolon den Kontroller ins Nirwana schicken könnte.
Aber immerhin hat er wenigstens neben dummen Sprüchen auch einen Versuch
gewagt. g

Simon ist da ja noch nicht soweit. Er beschränkt sich nur auf's Glauben
und Mutmaßen.

Diese Art wird euch sicher weiter bringen.


@Jörg (dl8dtl)

Keine Sorge, beide Bugs melde ich natürlich. Aber nicht in diesem Forum
sondern direkt beim Team. Wäre hier auch bei solchen Spezialisten
sinnlos. ;-)

Gruß
Willi (oe1msc)

Na, dann bin ich mal gespannt...  Für den GCC 4.3.0 (und dessen
WinAVR-Implementierung mit all den Xmega-Patches) gab's ja nun schon
ein paar Bugs, die Eric teilweise auch repariert haben, aber du
schreibst ja, dass bei dir auch der GCC 4.2.2 (oder 4.2.3, weiß ich
gerade nicht ganz genau, was bei WinAVR 20071224 dabei war) nicht
tut.  Der hat sich eigentlich als ziemlich stabil erwiesen, insofern
würde es mich schon wundern, wenn der tatsächlich für irgendwas, was
früher ging, falschen Code generieren würde.

Schau die doch mal den arroganten Schreibstil von Wilhelm an. Er
schreibt das ganze hier doch nur, weil er unbedingt Recht behalten
möchte.

@Wilhelm: Wir kommen hier auch ganz gut ohne deine Bugmeldung aus.
Insofern, sind wir nicht sonderlich getroffen von deiner Ankündigung,
uns diesen nicht mitzuteilen.

Bei den 2007er Versionen lag die CPU gleich bei der Einschaltmeldung
flach. Das heißt beim ersten P-String. Ich habe dem aber aus Zeitmangel
nicht sonderlich viel Interesse geschenkt und einfach mit der 2006er
weiter gearbeitet. Erst mit dem Vista wurde ich gezwungen auf die 2008er
umzusteigen. Da laufen zwar nun die P-Strings wieder, aber dafür das
EEPROM "nicht". Meine momentane "Lösung" wird wahrscheinlich eine
VirtualBox werden um die 2006er unter XP weiter am laufen zu halten.

Wilhelm Stejskal wrote:

> Oliver hat scheinbar keine Ahnung von C. Ansonsten würde er nicht meinen
> dass ein fehlendes Semikolon den Kontroller ins Nirwana schicken könnte.
> Aber immerhin hat er wenigstens neben dummen Sprüchen auch einen Versuch
> gewagt. *g*

Natürlich kann ein fehlendes Semikolon auch zu falschem Code führen,
wenn das ganze semantisch trotzdem korrekt ist.

while (PINB & _BV(PB0))
PORTA=0xff;

je nachdem ob du hinter dem while ein Semikolon hast oder nicht kommt
anderer Code dabei raus. Beides ist semantisch richtig, funktionell aber
doch nicht das selbe.

Oliver schrieb von einem "VERGESSENEN" Semikolon und nicht von einem das
zuviel wäre. Jörg hat euch auch darauf hingewiesen dass der selbe Kode
ja auf anderen Version läuft. (Bitte immer vor dem Posten lesen und
verstehen!)

Ich glaube aber wir sollten hier einen Schlußstrich ziehen. Das führt
hier nämlich zu nichts und ich habe andere Aufgaben auch noch zu
bewältigen. Wenn wer das gleiche Problem hat oder kennt, dann kann er
mir ja eine PN mit konstruktivem Inhalt senden.

Gruß
Willi

Da du keine einzige Zeile an Code rausgerückt hast, ist es schier
unmöglich herauszufinden, ob ein bestimmtes Problem dasselbe ist wie
deins.

Ich bin auf deine WinAVR-Bugreports gespannt.

Wilhelm Stejskal wrote:
> Oliver schrieb von einem "VERGESSENEN" Semikolon und nicht von einem das
> zuviel wäre. Jörg hat euch auch darauf hingewiesen dass der selbe Kode
> ja auf anderen Version läuft. (Bitte immer vor dem Posten lesen und
> verstehen!)

Ich hab gelesen und verstanden, du aber anscheinend nicht. Es gibt
nunmal Stellen an denen man das Semikolon weglassen kann, der Code
immernoch compiled, aber halt nicht macht was er soll.

Nico Erfurth wrote:

> Ich hab gelesen und verstanden, du aber anscheinend nicht. Es gibt
> nunmal Stellen an denen man das Semikolon weglassen kann, der Code
> immernoch compiled, aber halt nicht macht was er soll.

Nun hör doch mal auf damit.  Das sind zwar prima konstruierte Fälle,
doch aber alles keine, bei denen das Kompilat dann auch früher schon
keine Chance gehabt hätte, lauffähig zu sein.

>Oliver hat scheinbar keine Ahnung von C.

Naja, das mit dem Semikolon ist als einfache Umschreibung irgend eines
dummen Fehlers in deinem Programm gemeint gewesen.

Hättest du Ahnung vom Programmieren, hättest du hier gleich zu Anfang
ein aussagekräftiges und kompilierbares Codebeispiel gepostet, und nicht
nur ein banales "es stürzt ab". Ohne dieses wird auch das "Team"
fröhlich ratlos sein. Aber das weißt du ja alles sicherlich besser.

Oliver

Falls von Wilhelm ein konkreter bug-report mit nachvollziebarem code
kommt, wäre ich durchaus interessiert! Das ist ja nicht unwichtig.

Bitte auf dem laufenden halten. (bin aber skeptisch)

Icke wrote:

> Falls von Wilhelm ein konkreter bug-report mit nachvollziebarem code
> kommt, wäre ich durchaus interessiert! Das ist ja nicht unwichtig.

https://sourceforge.net/tracker/?group_id=68108&am...

Bugs 2009712 und 2009732

Wilhelm Stejskal wrote:
> @Jörg (dl8dtl)
>
> Keine Sorge, beide Bugs melde ich natürlich. Aber nicht in diesem Forum
> sondern direkt beim Team. Wäre hier auch bei solchen Spezialisten
> sinnlos. ;-)

Hehe, Ob du es hier, im avrfreaks-Forum oder als Bugreport einreichst,
Jörg (und die anderen Maintainer natürlich) bekommt ihn so oder so. Sei
also vorsichtig wen du abfällig hier als Spezialist bezeichnest :P

http://savannah.nongnu.org/projects/avr-libc/
Rechts unter "Mitglieder" stehen die Maintainer.

Kann diese Bugs mal jemand nachvollziehen? Das ist ja kaum zu glauben.

Hab mir aus lauter Neugierde den letzten WINAVR installiert.
Normalerweise nutze ich meine eigene Toolchain unter WinXP. Hab mein
Webserver-Projekt (v. U.Radig) damit kompiliert. Das Binärfile wurde um
weitere 400 Byte größer - puh.

"warning: array subscript is above array bounds"
Es trat ein mir bis dato unbekannter Warning auf, der einen Arrayfehler
in einem meiner Module aufdeckte, den ich noch nie gesehen hatte. Das
lob ich mir. Im GCC4.3.0 scheint also was ganz Neues drin zu sein.

Im Gegensatz zum Original-Quellcode von Ulrich Radig mache ich bei
meinem Projekt sehr umfangreichen Gebrauch von EEPROM-Varibalen (div.
Arrays u. Variablen von uint8_t bis uint32_t), deren
Speicherorganisation ich dem Compiler überlasse. Ulrich benutzt diese
Möglichkeiten nicht. Also entspricht das in etwas dem erkannten
EEPROM-Fehler - nur bei mir ist alles in Ordnung. (Atmega128)

Jörg Wunsch wrote:
> https://sourceforge.net/tracker/?group_id=68108&am...
>
> Bugs 2009712 und 2009732

Oh Gott, das solln Bugreport sein?
Kein Wunder, daß er sich nicht traut, den hier zu posten.
Da mache ich mir auch keinerlei Hoffnung, daß sich das jemand näher
ansieht.

Man muß sich also erstmal nen Beispielcode basteln und hoffen, daß der
Fehler auftritt.

Und einen Reset macht die CPU auf keinen Fall, wenn nicht der Watchdog
enabled ist.
Warscheinlich wird der Stack zerschossen, ein Memorydump vor dem
initialisieren des SRAM könnte hilfreich sein.
Bzw. erstmal das Assemblerlisting der Codestellen.


Peter

Neben dem Watchdog kann es auch ein Interrupt ohne ISR sein. Wenn ich
mich richtig erinnere, unterscheiden sich da tatsächlich die älteren
avr-libc-Versionen im Verhalten von den neuen.

Oliver

Nachtrag: Da hab ich mich wohl falsch erinnert, zumindest bis 2005xxxx
rückwärts gibts da immer einen reset.

Oliver

Peter Dannegger wrote:

> Oh Gott, das solln Bugreport sein?

Mach's mal halblang, Peter.  WinAVR hat naturgemäß sehr viele Nutzer,
die bislang nicht mit Opensource und dort üblichen Vorgehensweisen
vertraut sind.  Daher wünscht sich Eric auch, dass WinAVR-Nutzer
primär erst einmal Bugs bei WinAVR selbst aufmachen statt bei den
im Hintergrund benutzten Tools selbst.  Wenn sich dabei Bugs in
den eigentlichen Tools ergeben, kann man auf diese Weise die
notwendigen Details erst einmal beschaffen, um danach dann einen
fundierten Bugreport für das jeweilige Tool daraus zu generieren.

> Kein Wunder, daß er sich nicht traut, den hier zu posten.

Wilhelms Auftreten hier finde ich teilweise auch etwas überheblich,
aber euer Verhalten erinnert auch eher an Rüsseltiere im Porzellan-
laden.  Mit solchen Sprüchen wirst Du Wilhelm kaum dazu bringen,
hier konstruktiver zu agieren.

> Und einen Reset macht die CPU auf keinen Fall, wenn nicht der Watchdog
> enabled ist.

Ein Rücksprung auf Adresse 0 kann aber bei inkorrektem Inline-Asm-Code
schon einmal passieren, und die EEPROM-Funktionen sind in der aktuellen
avr-libc aus diversen Gründen neu geschrieben worden.  Mir wäre ein
nachvollziehbares Beispiel natürlich auch lieber, aber das Mindeste
wäre erst einmal die Angabe des CPU-Typs.

>aber das Mindeste wäre erst einmal die Angabe des CPU-Typs.

Der ist ja inzwischen bekannt, ein Mega128.

Oliver

Oliver wrote:

> Neben dem Watchdog kann es auch ein Interrupt ohne ISR sein.

Naja, nicht als Reset, sondern als Sprung auf Adresse 0, aber der
Unterschied ist nur wahrnehmbar, wenn man sich den Status der
IO-Register ansieht.

> Wenn ich
> mich richtig erinnere, unterscheiden sich da tatsächlich die älteren
> avr-libc-Versionen im Verhalten von den neuen.

Nö, das hat sich nicht geändert.  Es wurde darüber diskutiert, ob man
vielleicht standardmäßig einen RETI machen sollte, aber das würde ja
den Programmierfehler nur kaschieren.  Je nachdem, welche ISR es ist,
würde dadurch der Fehler u. U. unbemerkt bleiben, aber selbst eine
Endlosschleife der CPU ist denkbar (bspw. bei einem UART-Interrupt).

Da das Problem nach wie vor noch ansteht und auch der Bugreport noch
immer nicht behandelt wurde habe ich heute mir mal die Listings
angesehen. Dabei sind mir folgende Sachen unklar aufgefallen.

Also wir sind immer noch beim Thema WinAVR 2006 funktionier und 2008 mit
dem selben Sourccode mit EEPromzugriff nicht.

2006:
00000afc <__eeprom_read_byte_1C1D1E>:
 afc:  e1 99         sbic  0x1c, 1  ; 28
 afe:  fe cf         rjmp  .-4        ; 0xafc
<__eeprom_read_byte_1C1D1E>
 b00:  bf bb         out  0x1f, r27  ; 31
 b02:  ae bb         out  0x1e, r26  ; 30
 b04:  e0 9a         sbi  0x1c, 0  ; 28
 b06:  11 96         adiw  r26, 0x01  ; 1
 b08:  0d b2         in  r0, 0x1d  ; 29
 b0a:  08 95         ret


und 2008:
0000039a <eeprom_read_byte>:

/** \ingroup avr_eeprom
    Read one byte from EEPROM address \a __p.
 */
_ATTR_PURE__ static __inline_ uint8_t eeprom_read_byte (const uint8_t
*__p)
{
     39a:  df 93         push  r29
     39c:  cf 93         push  r28
     39e:  00 d0         rcall  .+0        ; 0x3a0
<eeprom_read_byte+0x6>
     3a0:  cd b7         in  r28, 0x3d  ; 61
     3a2:  de b7         in  r29, 0x3e  ; 62
     3a4:  9a 83         std  Y+2, r25  ; 0x02
     3a6:  89 83         std  Y+1, r24  ; 0x01
    do {} while (!eeprom_is_ready ());
     3a8:  ec e3         ldi  r30, 0x3C  ; 60
     3aa:  f0 e0         ldi  r31, 0x00  ; 0
     3ac:  80 81         ld  r24, Z
     3ae:  88 2f         mov  r24, r24
     3b0:  90 e0         ldi  r25, 0x00  ; 0
     3b2:  82 70         andi  r24, 0x02  ; 2
     3b4:  90 70         andi  r25, 0x00  ; 0
     3b6:  00 97         sbiw  r24, 0x00  ; 0
     3b8:  b9 f7         brne  .-18       ; 0x3a8 <eeprom_read_byte+0xe>
#if  E2END <= 0xFF
    EEARL = (unsigned)__p;
#else
    EEAR = (unsigned)__p;
     3ba:  ee e3         ldi  r30, 0x3E  ; 62
     3bc:  f0 e0         ldi  r31, 0x00  ; 0
     3be:  89 81         ldd  r24, Y+1  ; 0x01
     3c0:  9a 81         ldd  r25, Y+2  ; 0x02
     3c2:  91 83         std  Z+1, r25  ; 0x01
     3c4:  80 83         st  Z, r24
#endif
    EECR |= (1 << EERE);
     3c6:  ac e3         ldi  r26, 0x3C  ; 60
     3c8:  b0 e0         ldi  r27, 0x00  ; 0
     3ca:  ec e3         ldi  r30, 0x3C  ; 60
     3cc:  f0 e0         ldi  r31, 0x00  ; 0
     3ce:  80 81         ld  r24, Z
     3d0:  81 60         ori  r24, 0x01  ; 1
     3d2:  8c 93         st  X, r24
    return EEDR;
     3d4:  ed e3         ldi  r30, 0x3D  ; 61
     3d6:  f0 e0         ldi  r31, 0x00  ; 0
     3d8:  80 81         ld  r24, Z
}
     3da:  0f 90         pop  r0
     3dc:  0f 90         pop  r0
     3de:  cf 91         pop  r28
     3e0:  df 91         pop  r29
     3e2:  08 95         ret


Was mir als erstes auffällt ist die Codegröße. Aber die stört mich
eigentlich nicht wirklich. Vielmehr frage ich mich bereits bei den
ersten zwei Zeilen wer oder was holt die CPU aus der von mir
interpretierten Endlosschleife??? Muss aber dazu sagen dass die
Programme klaglos arbeiten.

Bei der Version WinAVR 2008 (letzte Ausgabe) frage ich mich was die
Zeile mit "3ae:  88 2f         mov  r24, r24" an dieser Stelle für einen
Sinn hat. Des weiteren frage ich mich warum die Register R30 und R31
benutzt werden ohne sie vorher gesavet zu haben. Als Draufgabe frage ich
mich auch noch warum am Ende der Routine zweimal zum Register R0 gepopt
wird. Stimmt denn da danach der Stackpointer noch???

Sofern ich hier nichts falsch verstanden habe, würde ja dies alles mir
Erklären warum es zum Nichtfunktionieren der Programme führt.

> Was mir als erstes auffällt ist die Codegröße.

Das zweite (lange) Beispiel ist ohne Optimierung kompiliert worden. Da
treten dann mitunter "NOPs" wie MOV R24,R24 auf. Das sieht beim
"alten" Compiler auch nicht viel anders aus.

> Vielmehr frage ich mich bereits bei den ersten zwei Zeilen wer oder
> was holt die CPU aus der von mir interpretierten Endlosschleife???

Du meinst die im ersten Beispiel? SBIC ist ein bedingter Sprungbefehl,
der aus der Schleife herausführt.

Ups..., da habe ich mir als Legastheniker selbst ein Ei gelegt. SBCI !=
SBIC. Ganz klar. Allerdings unbegreiflich wie das mir nur passieren
konnte. ;-) Dabei habe ich ja noch dazu 10 Min. (dumm) herumgerätselt
obwohl ja der Kode gut läuft. Naja, war halt ein Bier zuviel.

Aber freut mich dass du dich trotzdem damit beschäftigt hast.
Das eigentliche Problem ist aber dass der selbe Sourccode und auch
jedweder Neue mit Versionen nach 2006 nicht mehr lauffähig ist. Dazu
habe ich auch ein Demo im Bugreport mitangehängt. Also ganz einfach den
Maschinenkode (srec) in einen ATmega128 laden und sehen was passiert.
Auf Wunsch kann ich auch jederzeit den selben Kode mit der 2006er
Version zur Verfügung stellen. Nur damit man eben sieht dass er auch
funktioniert (kann). ;-)

Ps.:
Optimierung ist bei mir immer ausgeschalten. Was ich programmiere möchte
ich ja auch haben und nicht mehr oder weniger.

>Auf Wunsch kann ich auch jederzeit den selben Kode mit der 2006er
>Version zur Verfügung stellen. Nur damit man eben sieht dass er auch
>funktioniert (kann). ;-)

Viel hilfreicher wäre ein Beispiel im Source-Code.

>Optimierung ist bei mir immer ausgeschalten. Was ich programmiere möchte
>ich ja auch haben und nicht mehr oder weniger.

Dann solltest du aber direkt in Assembler programmieren. Da hast du dann
die volle Kontrolle. Das, was der gcc (oder irgend ein anderer
C-Compiler) produziert, ist, egal, ob mit oder ohne Optimierung, selten
das, was man von Hand programmiert hätte. Trotzdem funktioniert es.

Oliver

Das Demo gibt es ja im Bugreport von mir auf der Souceforgseite herunter
zu laden. Mein Zusatzangebot bezieht sich darauf wenn einer ein
lauffähiges 2006er-File haben möchte. Um den Bootloader braucht sich
auch keiner Sorgen zu machen. Im gesamten Projekt sind Source, Listungs,
Hex und Srec-Files vorhanden. Also im Prinzip alles was man zum
Nachvollziehen braucht. Wer ein persöhnliches Demo haben möcht wird
natürlich auch bedient werden. Ich verarbeite so ca. zwischen 1800 und
2500 128er pro Jahr. Da sind rund 30 verschiedene Applikationen. Dass
WINAVR nicht für den kommerziellen Gebrauch vorgesehen ist, mindert
meine "Reklamation" aber sicher auch nicht. Ich bin es vielleicht nur
nicht gewohnt etwas was "open source" ist so abwickeln zu müssen. Da ich
selbst natürlich nicht unfehlbar bin, nehme ich auch Hinweise betreffend
einer etwaigen Fehlnutzung gerne entgegen. Es ist also ohne weiteres
möglich dass bei mir selbst ein Unsinn entsteht. Ob die Versionen nach
2006 funktionieren oder nicht, berührt mich in erster Linie nur deswegen
weil ein Teil meiner Rechner mit VISTA arbeiten und die WINAVR 2006er
Version dort als Entwicklungsumgebung nicht läuft. Aber selbst wenn ich
eine 2007er oder 2008er Version auf XP installiere kommt nur Buggycode
heraus. Also beschränken wir uns bitte darauf dass ein und der selbe
Sourccode der auf 2006 lauffähig ist mit einer 2007er und einer 2008er
Version nicht mehr funktioniert. Bei der 2007er habe ich zB. keine PSTR
verwenden können. Da wurde wild im Speicher herumgelesen. Bei der 2008er
funktionieren die PSTR zwar wieder, aber dafür habe ich das Problem auf
ungerade Adressen im EEProm zuzugreifen.

Heute Mittag habe ich mir nach langer Zeit mal einige Minuten dafür
gewidmet und eben mal einen Kodevergleich durchgeführt. Also Grund genug
hier wieder einen Post abzusetzen.

Wilhelm Stejskal wrote:
> und 2008:
> 0000039a <eeprom_read_byte>:
>
> /** \ingroup avr_eeprom
>     Read one byte from EEPROM address \a __p.
>  */
> _ATTR_PURE__ static __inline_ uint8_t eeprom_read_byte (const uint8_t
> *__p)
> {
>      39a:  df 93         push  r29
>      39c:  cf 93         push  r28
>      39e:  00 d0         rcall  .+0        ; 0x3a0
> <eeprom_read_byte+0x6>
>      3a0:  cd b7         in  r28, 0x3d  ; 61
>      3a2:  de b7         in  r29, 0x3e  ; 62
>      3a4:  9a 83         std  Y+2, r25  ; 0x02
>      3a6:  89 83         std  Y+1, r24  ; 0x01
>     do {} while (!eeprom_is_ready ());
>      3a8:  ec e3         ldi  r30, 0x3C  ; 60
>      3aa:  f0 e0         ldi  r31, 0x00  ; 0
>      3ac:  80 81         ld  r24, Z
>      3ae:  88 2f         mov  r24, r24
>      3b0:  90 e0         ldi  r25, 0x00  ; 0
>      3b2:  82 70         andi  r24, 0x02  ; 2
>      3b4:  90 70         andi  r25, 0x00  ; 0
>      3b6:  00 97         sbiw  r24, 0x00  ; 0
>      3b8:  b9 f7         brne  .-18       ; 0x3a8 <eeprom_read_byte+0xe>
> #if  E2END <= 0xFF
>     EEARL = (unsigned)__p;
> #else
>     EEAR = (unsigned)__p;
>      3ba:  ee e3         ldi  r30, 0x3E  ; 62
>      3bc:  f0 e0         ldi  r31, 0x00  ; 0
>      3be:  89 81         ldd  r24, Y+1  ; 0x01
>      3c0:  9a 81         ldd  r25, Y+2  ; 0x02
>      3c2:  91 83         std  Z+1, r25  ; 0x01
>      3c4:  80 83         st  Z, r24
> #endif
>     EECR |= (1 << EERE);
>      3c6:  ac e3         ldi  r26, 0x3C  ; 60
>      3c8:  b0 e0         ldi  r27, 0x00  ; 0
>      3ca:  ec e3         ldi  r30, 0x3C  ; 60
>      3cc:  f0 e0         ldi  r31, 0x00  ; 0
>      3ce:  80 81         ld  r24, Z
>      3d0:  81 60         ori  r24, 0x01  ; 1
>      3d2:  8c 93         st  X, r24
>     return EEDR;
>      3d4:  ed e3         ldi  r30, 0x3D  ; 61
>      3d6:  f0 e0         ldi  r31, 0x00  ; 0
>      3d8:  80 81         ld  r24, Z
> }
>      3da:  0f 90         pop  r0
>      3dc:  0f 90         pop  r0
>      3de:  cf 91         pop  r28
>      3e0:  df 91         pop  r29
>      3e2:  08 95         ret
>
>

> Bei der Version WinAVR 2008 (letzte Ausgabe) frage ich mich was die
> Zeile mit "3ae:  88 2f         mov  r24, r24" an dieser Stelle für einen
> Sinn hat.

Hier wurde ein trivialer MOV nicht wegoptimiert.
Der MOV mag im asm-Code trivial sein, die Behandlung im Compiler ist es
aber mitunter nicht...

> Des weiteren frage ich mich warum die Register R30 und R31
> benutzt werden ohne sie vorher gesavet zu haben.

R30 und R31 sind call clobbered in der avr-gcc ABI, d.h. der Compiler
darf dieser Register in einer Funktion ändern ohne sie zu sichern/wieder
herzustellen.

> Als Draufgabe frage ich
> mich auch noch warum am Ende der Routine zweimal zum Register R0 gepopt
> wird. Stimmt denn da danach der Stackpointer noch???

Ja. Die zwei POP gehören zum trivialen RCALL .+0, der wohl auf einen
geinlinten indirekten Call zurückgeht.

Der indirekte Call ist auch der Grund für den Codezuwachs im Vergleich
zur 3.4.x.; ist für die avr-libc-Leute aber wohl bequemer...

Die Fehlfunktion des besagten Codes beruht auf Nichtbefolgung der EEPROM
Schreib-Sequenz, siehe Handbuch -> AVR Memories -> EEPROM read/write
access.

Der Zugriff auf die SFRs darf nicht in C implementiert werden, weil das
keinen spezifizierten Code erzeugt. Der Zugriff muss in
(Inline)-Assembler ausgetextet werden.

Danke für deine Antwerten.

Schlüssig zum begreifen sind sie aber teilweise nicht für mich.
Möchte aber auch gleich dazu sagen dass deine kritischen Bemerkungen nur
an die Entwickler der AVR-Lib gerichtet sein können. Denn ich benutze ja
lediglich nur ihre dafür vorgesehenen Funktionen wie eben die
eeprom_read_byte. Also was du da siehst ist rein nur der Kode der aus
der Lib kommt. Die Funktionen zur Nutzung des EEProms sind im Datenblatt
klar erklärt und auch mit einem Beispiel versehen. 2006 hatte man ja
diese auch fast 1:1 übernommen und sie funktionieren. Dass das nun eher
cryptisch abläuft ist halt schon verwunderlich. Noch dazu scheint hier
auch der Grund der Probleme begraben zu sein. Im Gegensatz zu anderen
mCs habe ich bei den 128ern noch keine einzige Zeile, mit Ausnahme eines
InlineNOP, als Assemblerkode geschrieben. Daher bin ich gerade erst
dabei mir den CPU-Kode anzusehen. Um so mehr bin ich geschockt wenn der
Copiler Register benutzt die nicht gesaved wurden. Da stelle ich mir vor
was passiert wenn ich in die C-Source Assemblerteile miteinfüge in denen
ich diverse Register nutze und dazwischen die eeprom_read_byte nutze.
Also bei anderen Toolchains wie zB. für Hitachi, welche teilweise auch
auf Basis von GCC arbeiten, konnte ich immer darauf vertrauen dass alle
Register save sind.

Gibt's da vielleicht eine Doku dazu?
Woher hast du denn das Insiderwissen her?

Wie sieht denn das mit diesen Zeilen aus?

     3a0:  cd b7         in  r28, 0x3d  ; 61
     3a2:  de b7         in  r29, 0x3e  ; 62
     3a4:  9a 83         std  Y+2, r25  ; 0x02
     3a6:  89 83         std  Y+1, r24  ; 0x01

Wird denn da nicht der WERT von 0x3d (EEDR) ins Y-Reglow und der WERT
von 0x3e (EEARL) ins Y-Reghigh geschrieben? Für mich sieht's im Moment
so aus als würde man dann gleich danach je nach Inhalt der Portadresse
wild irgendwo hinein schreiben. Also überall hin nur nicht auf die
EEProm-Adressregister. Aber wer weiß, vielleicht wird der in-Befehl auch
als immediat interpretiert ;-). Ich kann's mir zwar nicht vorstellen,
aber wer weiß?

Die Meinung dass SFR-Register in C nicht genutzt werden dürfen habe ich
einerseits nirgens gelesen und andererseits seit Jahren keine negativen
Erfahrungen gemacht. Gibt ja auch extra Headerdatein dafür. Sollte daher
der preprocessor auch richtig handlen können. Dass Lib-Funktionen
natürlich nur in Assembler zu schreiben sind ist auch klar. Da gebe ich
dir natürlich recht. Aber als Anwender darf mich das nicht berühren
müssen.

Wilhelm Stejskal wrote:
> Die Meinung dass SFR-Register in C nicht genutzt werden dürfen habe ich
> einerseits nirgens gelesen und andererseits seit Jahren keine negativen
> Erfahrungen gemacht.
Hat ja auch gar niemand behauptet ;)

> Gibt ja auch extra Headerdatein dafür.
EBEN. Und diese müssen benutzt werden. Das ist, was Johann meinte.
Sollte daher

> Dass Lib-Funktionen
> natürlich nur in Assembler zu schreiben sind ist auch klar.
Funktionen aus Bibliotheken können entweder in Assembler oder in C (oder
beliebig) geschrieben sein, nur werden diese dann kompiliert und somit
in Binärcode/Maschinencode umgewandelt (und nicht in Assembler. Das ist
was anderes) AKA kompiliert.

Nein, BITTE nicht solche Posts. Das führt zu nichts.
Bleiben wir bitte schlicht beim Problem und polemisieren wir nicht.
Kostruktive Antworten sind gefragt. Sonst nichts.

Ich stehe hier allein gegen den Rest der Welt. Bin mir in dieser
Position also vollkommen i