von avr-gcc nach WinAVR andere Bibo?

[Jörg H. (joh)]

Hallo,
2 Jahre habe ich mit avr-gcc (GCC) 3.4.4 unter Linux kompiliert und
UART-Kommunikationsroutinen aus/ähnlich avr-glibc (siehe Anhang)
verwendet.Bislang ohne Probleme.
Nun soll das ganze wegen Wechsel auf AVRStudio4 das Ganze
mit WinAVR-20060421 kompiliert werden. Sollte doch das gleiche Ergebnis
produzieren? Tut es aber nicht, die routine q_pressed() (siehe Anhang) ,
die ein über RS232 gesendetes 'q' erkennt liefert jetzt !=0 wenn es kein 
'q'
ist.

Gruß
joh

[Jörg W. (dl8dtl) (Moderator)]

Schalt doch mal die Compiler-Warnungen an (oder guck auf diese, wenn
sie schon eingeschaltet sind).  Der sollte dir irgendwas sagen, dass
diese Funktion ggf. einen undefinierten Wert zurückgibt -- immer
dann, wenn uart1RxDataLength_grn gleich 0 ist.

Btw.:

> if (uc_rt==0x71)

besser:

if (uc_rt == 'q')

[SiO2 (Gast)]

Ist es auch die gleibe (selbe?) libc unter win?

[chrisg (Gast)]

Kein Wunder, wenn uart1RxDataLength_grn==0, dann wird kein Returnwert 
festgelegt. Es ist also dem Zufall überlassen, was das entsprechende 
Register zu diesem Zeitpunkt enthielt.

Ich würde das so ändern:

u08 q_pressed(void) {
  u08 uc_rt;

  if (uart1RxDataLength_grn!=0) {  //(nur) wenn etwas von UART kam...
    uc_rt=uart1Get();      //dann Zeichen holen
    if (uc_rt==0x71) {      //wenn 'q' dann...
      uart1FlushRxBuffer();    //
      return 1;        //true liefern
    }
  }
  return 0;        //sonst false
}

So wird in beiden False-Fällen 0 zurückgeliefert.

[Jörg H. (joh)]

@Jörg: die einzigen Warnungen die ich bekommen (wenn man nicht gerade
den C99 compat. Mode einschaltet) beziehen sich auf
...
fdevopen(uart1Put, uart_getchar_JW);
...

warning: passing arg 1 of `fdevopen' from incompatible pointer type
warning: passing arg 2 of `fdevopen' from incompatible pointer type

if(var == 'ASCIIzeichen') ist viel informativer, ok :)




@SiO2 ((ist das nicht Sand?  :))
auf der WinAVR Seite ist es avr-libc 1.4.4 auf der liux-Seite sicher 
älter




@chrisg
da hast Du wohl recht, heute abend folgt der Targettest

if(daranhatsgelegen==TRUE) {
  Asche_auf_mein_Haupt();
}
else ...

[Jörg W. (dl8dtl) (Moderator)]

Jörg Haas wrote:

> @Jörg: die einzigen Warnungen die ich bekommen (wenn man nicht
> gerade den C99 compat. Mode einschaltet) beziehen sich auf

> warning: passing arg 1 of `fdevopen' from incompatible pointer type
> warning: passing arg 2 of `fdevopen' from incompatible pointer type

OK, du solltest die Argumente für die backend-Funktionen mal anpassen,
das hat sich mit avr-libc 1.4 geändert (die bekommen jetzt noch ein
FILE * mit übergeben).  Die Interrupthandler kannst du bei der
Gelegenheit gleich noch von SIGNAL() auf ISR() und auf die neuen
Vektornamen umbauen.

Wäre übrigens schön, wenn du solche Beispiele einigermaßen
compilierfähig anbieten würdest, so musste ich mir selbst die Arbeit
machen (include-Dateien, privater u08-Typ, rausfinden, welcher
Prozessor gemeint ist, ...).

Das sind wirklich deine einzigen Warnungen?  Ich bekomme:

Anhang.c: In function 'uart_putstr':
Anhang.c:213: warning: pointer targets in initialization differ in signedness
Anhang.c: In function 'main':
Anhang.c:342: warning: passing argument 1 of 'fdevopen' from incompatible pointer type
Anhang.c:342: warning: passing argument 2 of 'fdevopen' from incompatible pointer type
Anhang.c:351: warning: control reaches end of non-void function
Anhang.c: In function 'q_pressed':
Anhang.c:333: warning: control reaches end of non-void function

Das erste ist ein char * vs. uint8_t *.  Diese Warnung hat der GCC 3.x
möglicherweise wirklich noch nicht gebracht.

Das zweite kennst du schon.  Das "reaches end of non-void function"
ist dein verkürztes main(), OK.

Die dritte Warnung ist genau die, die ich meinte.  Du fällst in
q_pressed() ,,unten durch'', und das ist dem Compiler sehr wohl eine
Warnung wert (meiner Meinung nach auch bereits dem GCC 3.x, aber ich
kann hier nur noch 4.x testen).

[Jörg H. (joh)]

....ja, das war's wohl. Zukünftig sind mir
Kompilerwarnungen einen Blick mehr wert.

Sieht der Idealfall also nun so aus, daß ich ein unter
Linux compilierbares Projekt 1:1 unter WinAVR(AVRStudio)
übersetzen kann?

Gruß
joh

[Jörg W. (dl8dtl) (Moderator)]

Jörg Haas wrote:

> ....ja, das war's wohl. Zukünftig sind mir
> Kompilerwarnungen einen Blick mehr wert.

Das ist immer ein guter Vorsatz. ;-)

> Sieht der Idealfall also nun so aus, daß ich ein unter
> Linux compilierbares Projekt 1:1 unter WinAVR(AVRStudio)
> übersetzen kann?

Ja, allerdings sollte zumindest die minor version der
Bibliothek sinnvollerweise zwischen beiden gleich sein,
also avr-libc 1.4.x auf beiden.  Wenn du auf Kompatibilität
zwischen 1.2.x achten musst, wird's aufwändiger.

[Jörg H. (joh)]

Mal noch eine Greengornfrage dazu:
Wie bekomme ich denn die Versionsnummer
auf beiden Sytemen heraus?

Gruß
joh

[Jörg W. (dl8dtl) (Moderator)]

Jörg Haas wrote:

> Wie bekomme ich denn die Versionsnummer
> auf beiden Sytemen heraus?

Auf avr-libc >= 1.4.0 gibt's ein <avr/version.h>.  Die Versionen bis
1.2.x hatten sowas noch nicht.