Wie lauten diese Codezeilen (Keil-Compiler) für GCC?

Schmierlappen schrieb:
> DraconiX schrieb:
> Bitte sehr:
> http://bfy.tw/COSl
>
> Was für ein Schmierlappen bist Du doch!

Warum?! Es ist absolute Grundlage! Die unsigned char sollte völlig 
selbstklärend sein. Das sbit ist eben ein Bit (Bit 7 in dem Fall) in 
eben diesem uchar.

Und richtig:

Nop schrieb:
> Typen mit define zu definieren, sollte man generell lassen. Dafür gibt's
> typedef.

Das gehört sich einfach nicht. Oder man sollte verstehen lernen was das 
define darüber überhaupt macht.

W.S. schrieb:
> Nop schrieb:
>> Typen mit define zu definieren, sollte man generell lassen. Dafür gibt's
>> typedef.
>
> Ach wo. Eigentlich ist das egal, ob die Ersetzung beim Präprozessor oder
> etwas weiter hinten erfolgt.
>
> Dieses Wort "typedef" suggeriert einem, daß man damit Typen definieren
> könnte, aber das ist FALSCH. Mit typedef kann man lediglich einem
> bereits vorhandenen Typ einen zweiten Namen geben.
>
> Ob man sowas wirklich gut findet, ist Geschmackssache. Ich halte typedef
> für herzlich überflüssig. Da wären zuvor ganz andere Dinge in C
> verbesserungswürdig.
>
> W.S.

Falsch:

1

#define defined_type_t unsigned char*

2

typedef unsigned char *typdef_type_t;

3

4

int main(void) {

5

  unsigned char c;

6

7

  typdef_type_t  t_a, t_b;

8

  defined_type_t d_a, d_b;

9

10

  t_a = &c; /* kein problem */

11

  t_b = &c; /* kein problem */

12

  d_a = &c; /* kein problem */

13

  d_b = &c; /* Fehler! */

14

15

  return 0;

16

}

liefert natürlich

1

13:8: error: assigning to 'unsigned char' from incompatible type 'unsigned char *'; remove &

2

        d_b = &c; /* Fehler! */

3

              ^~

Wenn du jetzt sagst, dass man so etwas nicht macht: doch, es gibt Leute, 
die das genau so schreiben.
Natürlich gibt es auch häufig typedefs auf Pointer, wenn man zum 
Beispiel den Inhalt einer Struct verbergen will.
Typedef macht also sehrwohl Sinn.

Mit freundlichen Grüßen,
N.G.

N. G. schrieb:
> W.S. schrieb:
>> Ob man sowas wirklich gut findet, ist Geschmackssache. Ich halte typedef
>> für herzlich überflüssig. Da wären zuvor ganz andere Dinge in C
>> verbesserungswürdig.
>>
>> W.S.
.
> Falsch:
> #define defined_type_t unsigned char*
>   unsigned char c;
>
>   defined_type_t d_a, d_b;
>
>   d_b = &c; /* Fehler! */
>
> liefert natürlich
> 13:8: error: assigning to 'unsigned char' from incompatible type
> 'unsigned char *'; remove &
>         d_b = &c; /* Fehler! */
>               ^~
> Wenn du jetzt sagst, dass man so etwas nicht macht: doch, es gibt Leute,
> die das genau so schreiben.

Ja, so ist das eben wenn man den Unterschied "Typ" und "Textersatz" 
100%tig verstanden hat


;-)

Lars schrieb:
> uchar bdata transdata;

Da fehlt ein Komma. Richtig wäre hier:

1

uchar bdata, transdata;

bleibt noch die Zeile für den Typ sbit. Dazu gab es ja schon 
hinreichende Hinweise.

Frank M. schrieb:
> Lars schrieb:
>> uchar bdata transdata;
>
> Da fehlt ein Komma. Richtig wäre hier:
>

1

> uchar bdata, transdata;

2

>

>
> bleibt noch die Zeile für den Typ sbit. Dazu gab es ja schon
> hinreichende Hinweise.

Lars schrieb:
> uchar bdata transdata;
> sbit transbit = transdata^7;
Alles x51-spezifisch.
  bdata: bitaddressierbares RAM
  sbit:  Bit 7 in der bdata-Variable (Standard-c hat da das Bitfield)

1

  struct transdate_t {

2

    uint8t transbit:1;

3

  };

4

5

  transdata_t transdata;

6

7

8

  transdata.transbit = 1;

9

10

  if(transdata.transbit) {

11

    // ...

12

  }

Bit By Bit schrieb:
> Carl D. schrieb:
>> sbit:  Bit 7 in der bdata-Variable (Standard-c hat da das Bitfield)
>> struct transdate_t {
>>     uint8t transbit:1;
>>   };
>
> Welches Bit vom uint8_t wird hier angesprochen???
>
> Die Anordnung der Bitfelder ist dem Compiler überlassen. Beim sbit
> übernimmst du das. ;-)

Das interessiert doch bei reinen Software-Flags Überhaupt nicht.
Wenn ich die bitaddressierbarene x51-Special-Function-Register 
definieren muß, dann ist das was anderes. Da ist die Bit-Position ins 
Silizium gebrannt.

Bit By Bit schrieb:
> Carl D. schrieb:
>> Das interessiert doch bei reinen Software-Flags Überhaupt nicht.
>
> Ist es das hier?
>
> Lars schrieb:
>> for ...
>>   SDA  = transbit;        // To Start transfer From Highest bit
> ...
>>   transdata = transdata<<1;      // One bit left shift
>
> Ich denke, die Bit-Position ist hier nicht unwichtig.
>
> Und generell, wenn der µC einen BIT-adressierbaren RAM-Bereich hat, ist
> das von entscheidender Bedeutung!
> Wie wird auf ein C 'Bit-Feld' zugegriffen? Und wie macht der µC das wohl
> im Keilschen bdata? Warum hat der µC wohl ein 'bdata' Bereich?
> Geschwindigkeit ist keine Hexerei ...

Also braucht man gar keine Bitvariable sondern einfach nur:

1

SDA = (transdata&0x80)?1:0;

Da der GCC übersetzen soll: welcher der von ihm unterstützten μC hat 
"bdata"?