XMEGA64A3U - Prodsig-Bytes lesen

[wendelsberg (Gast)]

Beim Lesen der Bytes zur Korrektur des internen Temperatursensors bin 
ich auf etwas fuer mich Unerklaerliches gestossen. Nach dem Umschalten 
des NVM-Controllers soll mit

  dummy0 = pgm_read_byte( 0x2e );

das Byte 0x2e gelesen werden, das erzeugt richtig (0x2e = 46d):

  ldi r30,lo8(46)
  ldi r31,0
/* #APP */
 ;  31 "read_prodsig.c" 1
  lpm r30, Z

Dagegen erzeugt

  dummy2 = pgm_read_byte( PRODSIGNATURES_TEMPSENSE0 );

(in iox64a3u.h: #define PRODSIGNATURES_TEMPSENSE0  _SFR_MEM8(0x002E))
zum Lesen desselben Bytes falsch

  in r30,0x2e
  ldi r31,0
/* #APP */
 ;  40 "read_prodsig.c" 1
  lpm r30, Z

und gibt dann fuer beliebige Adressen im Bereich Prodsignatures immer 
0x0b zurueck.
Kompiliert wird mit

avr-gcc -save-temps -c -Os -mmcu=atxmega64a3u read_prodsig.c

Was mache ich eventuell falsch?

wendelsberg

[Stefan (Gast)]

tByte           ReadCalibration       (unsigned char index ) {
tByte result;

NVM_CMD = NVM_CMD_READ_CALIB_ROW_gc;
result  = pgm_read_byte (index);
NVM_CMD = NVM_CMD_NO_OPERATION_gc;
return result;
}

ReadCalibration (offsetof(NVM_PROD_SIGNATURES_t,TEMPSENSE0));
ReadCalibration (offsetof(NVM_PROD_SIGNATURES_t,TEMPSENSE1));

[Stefan (Gast)]

ups ... bevor hier wieder die Post ab geht ...

typedef   unsigned char       tByte;

[N. G. (newgeneration)]

Hallo,

was machst du da mit _SFR_MEM8()?

Damit werden eigentlich Register im internen Adressraum beschrieben.
Also so was wie

#define PORTL _SFR_MEM8(0x42)

was dann auf

(*(volatile uint8_t*)0x42)

abgebildet wird.

Somit hast du dir das gebastelt:

dummy2 = pgm_read_byte(PRODSIGNATURES_TEMPSENSE0);
=> pgm_read_byte(_SFR_MEM8(0x002E))
=> pgm_read_byte(*(volatile uint8_t*)0x002E);

Damit liest du zuerst das Register an der Stelle 0x2E, also eben 
PRODSIGNATURES_TEMPSENSE0 aus und übergibst dessen aktuellen Wert (und 
eben nicht die Adresse) an die Funktion pgm_read_byte().

Was du wahrscheinlich willst dürfte sein:

pgm_read_byte(&PRODSIGNATURES_TEMPSENSE0);

Ich hoffe ich habe dein Anliegen richtig verstanden ;-)

Mit freundlichen Grüßen,
N.G.

PS: warum muss isch jeder eigenen Datentypen definieren, anstatt die aus 
<stdint.h> zu nehmen?

[Rufus Τ. F. (rufus)]

N. G. schrieb:
> warum muss isch jeder eigenen Datentypen definieren

Vermutlich, damit man sie zur Belustigung mit anderen mischen kann:


Stefan schrieb:
> tByte           ReadCalibration       (unsigned char index ) {

> typedef   unsigned char       tByte;


Ich liebe so etwas.

[Stefan (Gast)]

Stefan schrieb:
> ups ... bevor hier wieder die Post ab geht ...

N. G. schrieb:
> PS: warum muss isch jeder eigenen Datentypen definieren, anstatt die aus
> <stdint.h> zu nehmen?

Vielleicht weil man es sich nicht aussuchen kann, vielleicht weil man 
damit etwas ausrdücken kann, vielleicht nur aus Spaß.
Die neue Generation benutzt ja bevorzugt auto oder var.

Rufus Τ. F. schrieb:
> Vermutlich, damit man sie zur Belustigung mit anderen mischen kann:
> Ich liebe so etwas.

Aber Du weißt nicht!
Von der neuen Generation erwarte man ja nix anderes.
Aber ... Auch Du mein Freund rufus?

[wendelsberg (Gast)]

N. G. schrieb:
> was machst du da mit _SFR_MEM8()?

Das

#define PRODSIGNATURES_TEMPSENSE0 _SFR_MEM8(0x002E)

 stammt, wie geschrieben aus der iox64a3u.h, die mit dem Paket avr-libc 
installiert wurde, in diesem Fall mit der 
avr-libc_1%3a1.8.0+Atmel3.5.0-1_all.deb.
Wobei es sich mir nicht erschliesst, warum das dort nicht mit

#define PRODSIGNATURES_TEMPSENSE0 0x2e

 definiert wird.

N. G. schrieb:
> Was du wahrscheinlich willst dürfte
> sein:pgm_read_byte(&PRODSIGNATURES_TEMPSENSE0);
Ja, das war mein Fehler. Danke.

N. G. schrieb:
> PS: warum muss isch jeder eigenen Datentypen definieren, anstatt die aus
> <stdint.h> zu nehmen?
Mach ich nicht, ich schwoere! s.o. ;-)

wendelsberg