AVR-CC

[Niki Hammler (Gast)]

Hallo,

1.) Mein AVR geht wieder, es war doch der XTAL kaputt...jetzt hab ich 
halt zwei CPUs zu Hause
2.) Was produziert avr-gcc für ein Ausgabeformat?? Ich erhalte eine 
*.rom Datei die viel zu gross ist (>350Bytes).
Wie kann ich so ein Programm mit isp_avr überspielen? hexbin2.exe nimmt 
nur die ersten 255 Bytes und ich weiss nicht ob das wirklich so richtig 
ist
3.) Kennt jemand ein Tutorial für den Start? Ich hab ja nur ein LED 
und einen Schalter dran (PB0 und PB1) möchte aber trotzdem ein wenig 
experimentieren.
4.) Sollte mein LED, das an Port PB0 angeschlossen ist, jede Sekunde 
leuchten wenn ich folgendes Programm schreibe? (ok, vielleicht keine 
Sekunde aber so dass ich es sehen kann)

#include <io.h>

void delay(void)
{
  int i = 0;
  for(i=0;i<60000;i++) { }
}

int main(void)
{
  char status = 0;
  outp(0xFF, DDRB);
  for(;;)
  {
    switch(status)
    {
      case 0: outp(0x80, PORTB); status = 1; break;
      case 1: outp(0x00, PORTB); status = 0; break;
    }
    delay();
    delay();
  }
}

Niki

[Jonas Diemer (Gast)]

Hi!

1) wie, xtal kaputt. meinste den quarz?

2) also bei mir ist die rom datei bei gcctest1 genau 394 bytes (nicht 
kbytes!) groß und im ihex format. kann also problemlos von ponyprog 
gelesen werden

3) schau dir die gcctest programme an.

4) nun ja, wenn du die optimierung einschaltest, wird der compiler deine 
schleife wegoptimieren, weil dort nix gemacht wird... kannst ein nop 
oder sonstwas einfügen.

jonas

[Andreas (Gast)]

4) Siehe http://www.mikrocontroller.net/avr-gcc-faq.htm

Andreas

[Christian Fuchs (Gast)]

Hallo,

zu 4:
Ich würde jetzt mal sagen, dass das mit dem <60'000 nicht geht, da int 
meines Wissens nach so breit ist, wie der Bus des Prozessors, da diese 
Variablen am schnellsten verarbeitet werden können. Wären beim AVR also 
8 Bit. Und in 8 Bit passen diese 60000 halt nicht rein...

Mit uint16_t (?weiß nicht genau) sollte das gehen.(0-65535)

Bitte um Rückmeldung, wenn das beim AVR mit der breite von int's anders 
gehandhabt wird...


ciao

      Christian

[Jonas Diemer (Gast)]

aus include/inttypes.h:

typedef signed char int8_t;
typedef unsigned char uint8_t;

typedef int int16_t;
typedef unsigned int uint16_t;

typedef long int32_t;
typedef unsigned long uint32_t;

typedef long long int64_t;
typedef unsigned long long uint64_t;

typedef int16_t intptr_t;
typedef uint16_t uintptr_t;


int ist also (bei avr-gcc) 16 bit breit, aber geht von -32768 bis 
+32767. Das müsste also ein unsigned int sein.

[Christian Fuchs (Gast)]

Hallo,

interessant, da hat mich das C-Tutorial, wo ich das herhab, angelogen 
;-)

Aber auf moderneren PC's stimmt das tatsächlich, denke ich, also bei NT: 
int=32bit


ciao

      Christian

[Jonas Diemer (Gast)]

Ja, das stimmt. hängt aber i.d.R. nicht vom betriebsystem, sondern von 
der prozessorarchitektur ab... bei einem 32bit prozessor (pentium 
klasse) sind ints 32bit lang, beim alpha glaub ich 64bit.

in normalem c sollte man deshalb short int (16 bit) und long int (32/64 
bit) benutzen (bzw deren unsinigned pendants).

bei avr-gcc bieten sich die typen nach dem format int<bit-anzahl>_t bzw. 
uint<bit-zahl>_t an.