Microchip C18, umwandeln von WORD auf BYTE

[simon (Gast)]

Hi,


ich dachte da an sowas:

    WORD Reg_Addr;
    BYTE lowbyte = (BYTE) Reg_Addr;
    BYTE highbyte = (BYTE) Reg_Addr >>8;

Da habe ich in der Header Datei aber folgendes gefunden:

typedef union
{
    WORD Val;
    BYTE v[2] __PACKED;
    struct __PACKED
    {
        BYTE LB;
        BYTE HB;
    } byte;
    struct __PACKED
    {
        __EXTENSION BYTE b0:1;
        __EXTENSION BYTE b1:1;
        __EXTENSION BYTE b2:1;
        __EXTENSION BYTE b3:1;
        __EXTENSION BYTE b4:1;
        __EXTENSION BYTE b5:1;
        __EXTENSION BYTE b6:1;
        __EXTENSION BYTE b7:1;
        __EXTENSION BYTE b8:1;
        __EXTENSION BYTE b9:1;
        __EXTENSION BYTE b10:1;
        __EXTENSION BYTE b11:1;
        __EXTENSION BYTE b12:1;
        __EXTENSION BYTE b13:1;
        __EXTENSION BYTE b14:1;
        __EXTENSION BYTE b15:1;
    } bits;
} WORD_VAL, WORD_BITS;

Da steht LB und HB drinne, ich glaube das die genau diesen Fall schon 
vorgesehen haben. wie kann ich mit hilfe der union ein WORD_VAL 
umwandeln auf BYTE?

BYTE high = WORD_VAL.HB?
BYTE low = WORD_VAL.LB?

[Frank K. (fchk)]

WORD_VAL t;
WORD w=0x1234;
BYTE h,l;

// WORD w in die Union reinschreiben
t.Val=w;
// BYTEs h und l rausholen
h=t.byte.HB;
l=t.byte.LB;

[Madeyemike (Gast)]

Temporär auf den Typen casten.

WORD w = 0x1234;
BYTE h, l;

h = ((WORD_VAL)w).HB;
l = ((WORD_VAL)w).LB;

Gruß Mike

[simon (Gast)]

Danke.

[simon (Gast)]

Also so ganz funzt das nicht, und ich verstehe nicht was er daran zu 
meckern hat:

xx.c:97:Error [1146] type mismatch in argument 1

void xx_write_SPI(WORD_VAL Reg_Addr, BYTE nr_bytes, BYTE *data)
{

}

xx_write_SPI(0xEBFF,1,&x);

Da ist doch ein wunderschöner WORD wert den ich da übergebe.

[Frank K. (fchk)]

nein. Du übergibt die Union, nicht das WORD.

So ist es richtig:

void xx_write_SPI(WORD RegAddrW, BYTE nr_bytes, BYTE *data)
{
  WORD_VAL Reg_Addr;
  Reg_Addr.Val=RegAddrW;

}

xx_write_SPI(0xEBFF,1,&x);

[simon (Gast)]

Also irgendwie funzt das nicht Anständig.

Ich habe es mal ohne WORD_VAL gemacht:

    WORD w = 0;
    w = (GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16 );
    bufferX[0] = 'X';
    bufferX[1] = ( (BYTE) (w>>8) );
    bufferX[2] = ( (BYTE) (w) );
    bufferX[3] = 'X';
    bufferX[4] = '\0';
    putsUART((char*)bufferX);

Ergebnis: er verschluckt das zweite X was angezeigt werden soll. und die 
Werte davor passen auch nicht.


Das ganze mal am PC mit gcc ( funzt out of the box):

  unsigned int w = (GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16 );
  char lb = (char) w;
  char hb = (char) (w>>8);

Ausgabe:
 Integer: [337] -> Hex: 0x151 -> Bin: 101010001
 Integer: [1] -> Hex: 0x1 -> Bin: 1
 Integer: [81] -> Hex: 0x51 -> Bin: 1010001


In beiden fällen die defines dazu:

#define GAIN_PGA1_1  (0x0001)
#define GAIN_PGA1_2  (0x0002)
#define GAIN_PGA1_4  (0x0003)
#define GAIN_PGA1_8  (0x0004)
#define GAIN_PGA1_16 (0x0005)

#define GAIN_PGA2_1  (0x0001<<3)
#define GAIN_PGA2_2  (0x0002<<3)
#define GAIN_PGA2_4  (0x0003<<3)
#define GAIN_PGA2_8  (0x0004<<3)
#define GAIN_PGA2_16 (0x0005<<3)

#define GAIN_PGA3_1  (0x0001<<6)
#define GAIN_PGA3_2  (0x0002<<6)
#define GAIN_PGA3_4  (0x0003<<6)
#define GAIN_PGA3_8  (0x0004<<6)
#define GAIN_PGA3_16 (0x0005<<6)



Was ich mich immernoch Frage was die sache mit "char" soll.
Worin unterschiedet sich Char von Byte?

typedef char                    CHAR8;
typedef unsigned char           UCHAR8;
typedef unsigned char           BYTE;

Also scheinbar nur im Vorzeichen, nur wozu brauche ich bei einem char 
ein Vorzeichen?

[Fabian O. (xfr)]

simon schrieb:
> Ergebnis: er verschluckt das zweite X was angezeigt werden soll. und die
> Werte davor passen auch nicht.

Dann schreib doch wenigstens, was er ausgibt. Und poste bitte den ganzen 
Code. Dann spart man sich viel Rätselraten. Man sieht z.B. nicht, 
welchen Typ bufferX hat. Und wenn eines der Bytes 0 ist, hört die 
Ausgabe natürlich an der Stelle auf, weil das Byte dann als 
String-Ende-Zeichen erkannt wird.

simon schrieb:
> Was ich mich immernoch Frage was die sache mit "char" soll.
> Worin unterschiedet sich Char von Byte?
> typedef char                    CHAR8;
> typedef unsigned char           UCHAR8;
> typedef unsigned char           BYTE;
>
> Also scheinbar nur im Vorzeichen, nur wozu brauche ich bei einem char
> ein Vorzeichen?

Wenn Du mit kleinen, vorzeichenbehafteten Werten (-128 bis 127) rechnen 
willst, nimmst Du ein signed char. Wenn Deine Werte von 0 bis 255 gehen, 
nimmst Du ein unsigned char. Wenn Du Buchstaben ausgeben willst, nimmst 
Du ein char. Eigentlich ganz einfach.

Die Typen CHAR8, UCHAR8 und BYTE hat Dein Compilerhersteller definiert, 
weil er sie anscheinend schöner fand. Ich würde die nicht in eigenem 
Code nehmen. Dann lieber <stdint.h> einbinden und Du hast für kleine 
Zahlen diese eindeutigen Typen:

uint8_t = unsigned char
 int8_t = signed char

Entsprechend für 16 Bit:

uint16_t = unsigned short
 int16_t = signed short

etc.

[simon (Gast)]

Der Buffer:

BYTE bufferX[10];

[simon (Gast)]

Also ich habe jetzt mal printf genommen, das auch nix schief gehen kann 
beim umwandeln.

#define GAIN_PGA1_1  (0x0001)
#define GAIN_PGA2_2  (0x0002<<3)
#define GAIN_PGA3_16 (0x0005<<6)

    WORD w = (GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16 );
    x = (BYTE) (w >> 8);
    y = (BYTE) w;
  
    printf("X: %#x\n", x);
    putsUSART( buffer );

    printf("Y: %#x\n", y);
    putsUSART( buffer );

Ergebnis:
X:0x0
Y:0x51


Also ich kann mir nicht erklären wie der auf X: 0x0 kommt.



Mein erwartetes Ergebnis wäre:
 X: 0x1
 Y: 0x51

[simon (Gast)]

kleiner Fehler, so:

    char buffer[20];
    WORD w = (GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16 );
    BYTE x = (BYTE) (w >> 8);
    BYTE y = (BYTE) w;
  
    sprintf(buffer, "X: %#x\n", x);
    putsUSART( buffer );

    sprintf(buffer, "Y: %#x\n", y);
    putsUSART( buffer );

Denoch gleiches Ergebnis.

[Karl H. (kbuchegg)]

simon schrieb:

> Denoch gleiches Ergebnis.

Und welchen Wert hat w?

[simon (Gast)]

#define GAIN_PGA1_1  (0x0001)
#define GAIN_PGA2_2  (0x0002<<3)
#define GAIN_PGA3_16 (0x0005<<6)

WORD w = (GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16 );

[Karl H. (kbuchegg)]

simon schrieb:
> #define GAIN_PGA1_1  (0x0001)
> #define GAIN_PGA2_2  (0x0002<<3)
> #define GAIN_PGA3_16 (0x0005<<6)
>
> WORD w = (GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16 );


Nein.
Ich meine an der Ausgabe. Lass es dir mal mit einem printf ausgeben. Die 
0 für x muss ja irgendwo herkommen. Wenn das High-Byte in w schon 0 ist, 
dann geht die Suche weiter, warum das High-Byte 0 ist und nicht warum 
bei der Zerlegung was schief geht.

Daher sollte man mal klären, ob die 0 schon im w drinnen steckt oder 
nicht.

[simon (Gast)]

sprintf(buffer, "W: %#i\n", w);
    putsUSART( buffer );

    W: 81

da müsste Eigentlich 337 erscheinen.

 Integer: [337] -> Hex: 0x151 -> Bin: 101010001
 Integer: [81] -> Hex: 0x51 -> Bin: 1010001
 Integer: [1] -> Hex: 0x1 -> Bin: 1

[simon (Gast)]

Also ich komme zum verrecken nicht drauf was hieran falsch sein soll?

Es funktioniert ja mit gcc am PC wunderbar.

Was macht der Microchip XC16 anders?

[Fabian O. (xfr)]

Probier mal

#define GAIN_PGA3_16 (0x0140)

und

#define GAIN_PGA3_16 (0x0005UL<<6)

und

#define GAIN_PGA3_16 ((WORD)0x0005<<6)

[simon (Gast)]

> #define GAIN_PGA3_16 (0x0140)

Funzt Perfekt.

Mal so zum verstehen, was ist hier den genau schief gelaufen?

Der Preprozessor hat das als größere oder kleinere Variable gesehen?

[simon (Gast)]

Gibt es hier eine Einfache Möglichkeit das WORD in w dieser Funktion zu 
übergeben?

Die Funktion erwartet (Gain addresse, anzahl bytes, pointer auf byte)

w = (WORD) (GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16 );

xx_write_SPI((WORD)GAIN,2,(BYTE*)&w); // Ist es auch ok hier ein WORD zu nehmen?

void xx_write_SPI(WORD Reg_Addr, BYTE nr_bytes, BYTE *data)
   BYTE i;
    for(i=0;i<nr_bytes;i++) {     // Write Data
        spi(*data);
        data++;
    }

[Karl H. (kbuchegg)]

simon schrieb:
>> #define GAIN_PGA3_16 (0x0140)
>
> Funzt Perfekt.
>
> Mal so zum verstehen, was ist hier den genau schief gelaufen?

Ist das wieder so ein Müll, dass der Compiler entgegen dem C-Standard 
ein

    5 << 6

als 8-Bit Operation implementiert, anstatt wie es richtig wäre als int 
Operation? Bzw. der eigentliche Scheiss besteht darin, dass der COmpiler 
einen int mit 8 Bit zulässt, obwohl des gegen jeden C-Standard 
verstösst?

Ich frage deshalb, weil in einem anderen Thread genau dieser Müll mit 
dem CSS Compiler auf einem Pic aufgetreten ist.

Das solltest du unbedingt abklären, denn das ist eine wichtige 
Information für dich. Was ergibt

  int i = 5 << 6;
  sprintf(buffer, "T: %#d\n", i);
  putsUSART( buffer );

wenn da nicht 320 rauskommt, dann such nach dem Compilerschalter, wie du 
diesen Dreck abdrehen kannst. Wenn ein int nicht mehr garantiert 
mindestens 16 Bit hat, und der Compiler das auch in arithmetischen 
Ausdrücken mit den Promotionrules berücksichtigt, dann ist das keine 
Hilfe für den Programmierer sondern dann haben sie dem Compilerbauer ins 
Hirn gesch.... (wie Mundl Sackbauer sagen würde)

[Fabian O. (xfr)]

simon schrieb:
> Funzt Perfekt.
>
> Mal so zum verstehen, was ist hier den genau schief gelaufen?
>
> Der Preprozessor hat das als größere oder kleinere Variable gesehen?

Was ist denn mit den anderen beiden Möglichkeiten? Funktionieren die 
auch? Wenn ja, dann hält sich Dein Compiler nicht an den C-Standard, 
weil ein int für ihn nur 8 statt mindestens 16 Bit breit ist.

Der Compiler hat also die Zahl 0x0005 als 8-Bit-Wert genommen (die 
führenden Nullen interessieren nicht) und den Linksshift um 6 Stellen 
auch nur mit 8 Bit gerechnet. Dann ist das oberste Bit rausgeflogen, 
weil es nicht mehr in 8 Bit gepasst hat.

Wie gesagt verstößt das aber gegen den C-Standard. Wenn das der Fall 
ist, solltest Du mal schauen, ob man das nicht ändern kann (per Option 
beim Aufruf des Compilers).

simon schrieb:

xx_write_SPI((WORD)GAIN,2,(BYTE*)&w); // Ist es auch ok hier ein WORD zu nehmen?

Das wäre sinnlos, denn die Funktion erwartete einen Zeiger auf ein BYTE. 
Das kannst Du als Aufrufer der Funktion nicht ändern. Du musst ihr das 
geben, was sie haben will. In dem Fall will sie einen Zeiger auf ein 
BYTE. &w ist aber ein Zeiger auf ein WORD. Also musst Du den BYTE* in 
einen WORD* umwandeln. Der Compiler würde das auch ohne expliziten Cast 
automatisch machen (er hat ja keine andere Wahl), aber das gibt dann 
eine Warnung.

Den ersten Cast (WORD)GAIN kannst Du Dir dagegen sparen. Die Funktion 
erwartetet ein WORD, also wird ihr der Compiler ein WORD übergeben. Auch 
wenn GAIN vielleicht kein WORD ist. Bei Integern gehen solche impliziten 
Casts ohne Warnung, da sie ständig vorkommen.

[simon (Gast)]

Vielen Dank für die Tips.

xx_write_SPI((WORD)GAIN,2,(BYTE*)&w);

Das hier funktioniert wunderbar, nur ob das jetzt Zufall ist weisz ich 
nicht.

Mein Problem ist das ich die Funktion nicht ändern kann/sollte weil ich 
manchmal nur 1 byte schicke und manchmal auch 2, 3 oder 4 byte.

Gibt es hier den kein Trick wie ich aus dem Pointer auf mein word ein 
byte pointer machen kann?



Zu den Fragen:
Alle drei der genannten Möglichkeiten Funktionieren und bringen das 
richtige Ergebnis.

#define GAIN_PGA3_16 (0x0140)
#define GAIN_PGA3_16 (0x0005UL<<6)
#define GAIN_PGA3_16 ((WORD)0x0005<<6)

// Frage 2:
  int i = 5 << 6;
  sprintf(buffer, "T: %#d\n", i);
  putsUSART( buffer );  // Ausgabe T: 64

[Fabian O. (xfr)]

Ich sehe gerade, ich habe mich in meinem Beitrag verschrieben:

> In dem Fall will sie einen Zeiger auf ein
> BYTE. &w ist aber ein Zeiger auf ein WORD. Also musst Du den BYTE* in
> einen WORD* umwandeln.

Das muss richtig heißen:
In dem Fall will sie einen Zeiger auf ein BYTE. &w ist aber ein Zeiger 
auf ein WORD. Also musst Du den WORD* in einen BYTE* umwandeln.

Genau das machst Du bei dem Funktionsaufruf ja mit dem Cast:

(BYTE*)&w

Das ist also so gesehen schon in Ordnung. Es ist aber nicht die beste 
Methode, das zu machen. Denn es ist tatsächlich gewissermaßen "Zufall", 
dass es funktioniert. Denn diese Methode verlässt sich darauf, dass die 
beiden Bytes in der richtigen Reihenfolge (in der sie der Empfänger 
erwartet) im Speicher des WORDs stehen. Das mag bei Deinem 
Mikrocontrollertyp der Fall sein, kann auf anderen Prozessoren aber auch 
genau andersrum sein.

Deshalb wäre es besser, einen Sendepuffer anzulegen, in den Du die Bytes 
an die richtige Stelle legst:

WORD w = GAIN_PGA1_1 | GAIN_PGA2_2 | GAIN_PGA3_16;

BYTE buffer[2];
buffer[0] = w >> 8;
buffer[1] = w;

xx_write_SPI(GAIN, sizeof(buffer), buffer);

Falls Du die xx_write_SPI()-Funktion selber geschrieben hast, würde ich 
übrigens die Reihenfolge der Parameter nr_bytes und data umdrehen. Denn 
es ist allgemein üblich, zuerst den Zeiger und dann die Länge anzugeben. 
Alle Funktionen in der C-Standardbibliothek erwarten das so. Es ist 
irritierend, wenn das plötzlich anders ist.

[simon (Gast)]

Fabian O. schrieb:
> Falls Du die xx_write_SPI()-Funktion selber geschrieben hast, würde ich
> übrigens die Reihenfolge der Parameter nr_bytes und data umdrehen. Denn
> es ist allgemein üblich, zuerst den Zeiger und dann die Länge anzugeben.
> Alle Funktionen in der C-Standardbibliothek erwarten das so. Es ist
> irritierend, wenn das plötzlich anders ist.

ok, Das Beispiel was ich hatte war auch ursprünglich mal so.



Also irgendwo steckt doch da echt der wurm drinne..

    UINT32 x;
    BYTE obuf[4];
   char buffer[20];

    x = (UINT32) 831870;
    sprintf(buffer, "VL: %d \n", x); // gibt 12  aus??
    putsUSART( buffer );

    obuf[0] = 0;
    obuf[1] = ((BYTE) (x >>16));
    obuf[2] = ((BYTE) (x >>8));
    obuf[3] = ((BYTE) x);

    xx_write_SPI((WORD)VLEVEL,4,(BYTE*) &obuf[0]); // ins Register schreiben
    x = 0;
    xx_read_SPI((WORD)VLEVEL,4,(BYTE *)&x); // Zurück lesen

    sprintf(buffer, "VLEVELx: %#x\n", x); // Gibt 0x7eb1 aus, wo ict das 0C ?
    putsUSART( buffer );

obuf wird genau mit der spi Funktion ausgegeben, ich sehe dann auch die 
richtigen Werte am SPI.

0x00 0x0C 0xB1 0x7E = 831870;

Nur wie kann es sein das sprintf nur 12 Anzeigt?

[Josef D. (jogedua)]

> sprintf(buffer, "VL: %d \n", x); // gibt 12  aus??
das %d bedeutet: betrachte x als int.

[simon (Gast)]

Was sagt dann aus das x als UINT32 angesehen wird?
%i? %u?
ich kann im C18 manual nur noch x und X finden für den hex wert.

Aber selbst beim zweiten hex wert fehlt mir ein 0x0C

[Josef D. (jogedua)]

Wo das für Deinen Compiler steht, weiß ich nicht.
Für GCC:
http://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html#gaa3b98c0d17b35642c0f3e4649092b9f1

[Josef D. (jogedua)]

Versuch's mal mit %ld, %lx