Datentyp OCRx (AVR)?

[Thomas K. (thkusch)]

Hallo!

Welchen Datentyp haben die OCRxx-Register eines 16-bit Timers bei einem 
ATMega?

Hier kriege ich die Warnung "initialization from incompatible pointer 
type":

volatile unsigned short *pusPWMReg;
pusPWMReg=&OCR1A;

Das hier funktioniert:
volatile unsigned char *pucPort;
pucPort=&PORTA;

Danke im Vorraus,

Gruss
Thomas

[g457 (Gast)]

#define pusPWMReg OCR1A

Falls Du wissen willst, wie so ein OCR1A genau aussieht, dann schau in 
die IO-Header vom betreffenden Chip :-)

HTH

[Johann L. (gjlayde)]

Thomas K. schrieb:

> Hier kriege ich die Warnung "initialization from incompatible pointer
> type":
>
> volatile unsigned short *pusPWMReg;
> pusPWMReg=&OCR1A;

volatile uint16_t * pusPWMreg;

[Chris L. (kingkernel)]

wenn es sich um einen 16bit Register handelt dann sind die Register auch 
16 bit breit. Sowas steht aber auch immer im Datenblatt!

[Thomas K. (thkusch)]

Hallo!

@g457: define ist nicht das was ich will. Der Variablen soll ein OCR zur 
Laufzeit zugewiesen werden. Wie der OCR1A aussieht, weiss ich. Die Frage 
war (genauer ausformuliert), welchen Datentyp, wenn nicht "volatile 
unsigned short*" haben unter WinAVR die 16-bit OCRs. Jede Zuweisung 
eines OCRs möchte ich nicht explizit casten.

@Johann: uint16_t ist die Abbildung von unsigned short. Das macht keinen 
Unterschied. "volatile unsigned char *pucPort;" funktioniert ja auch 
(ohne Compilerwarnung), obwohl es streng genommen "volatile uint8_t 
*pucPort;" heissen müsste.

@Christian: ich kann mit Deiner Aussage nicht wirklich was anfangen..

Der Code, der die Warnung bringt, sieht so aus:

typedef struct
{
  volatile unsigned char *pucPort;
  unsigned char ucPin;
  volatile unsigned short *pusPWMReg;
  unsigned char ucSPWMID;
} LIGHTIO;

static const LIGHTIO lightIO[25]={
  {&PORTB,_BV(PB5),&OCR1A, 0},
  {&PORTB,_BV(PB6),&OCR1B, 0},
  {&PORTB,_BV(PB7),&OCR3C, 0},
        ......};

Jedes OCR generiert die Warnung "initialization from incompatible 
pointer type".

Gruss
Thomas

[Floh (Gast)]

OCR ist doch definiert als sfr(adresse).
Theoretisch musst du die Adresse übergeben, und den Zugriff der Variable 
als special function deklarieren.

[Stefan E. (sternst)]

> uint16_t ist die Abbildung von unsigned short. Das macht keinen
> Unterschied.

Doch, es macht einen Unterschied. Warum probierst du es nicht einfach 
erst mal, bevor du dagegen argumentierst?

Ein uint16_t geht auf ein unsigned int zurück. Und auch wenn es die 
gleiche Größe wie ein unsigned short hat, ist es aus Sicht des Compilers 
eben doch ein anderer Typ.