frage zu diesen Zeichen @

Das ist eine compilerspezifische Erweiterung.
Da musst du dir ansehen, wer die Library gemacht hat, welchen COmpiler 
er verwendet hat und rausfinden was das macht.

Standard-C hat nichts darüber zu sagen.

das hab ich gefunden nur hab noch immer keine ahnung

 volatile unsigned short ccpr1 @ 0xFBE; //declare a 16 bit variable that 
is located at address 0xFBE, just where CCPR1 registers start
 //Now this variable can be used in C cone
 ccpr1 = 0x2400; //for example assign 0x2400 to it what writes 0x00 into 
CCPR1L and 0x24 into CCPR1H

Ah nur wie schreib ich jetzt diesen befehl
volatile bit output @ RA2_bit;

ist das so zu sehen das RA2_bit in output gespeichert wird

Michael Schulz schrieb:
> Ah nur wie schreib ich jetzt diesen befehl
> volatile bit output @ RA2_bit;
>
> ist das so zu sehen das RA2_bit in output gespeichert wird

Das nächste Problem:
Den Datentyp bit gibt es so nicht in C.
Du musst rausfinden was da wieder dahintersteckt

Könnte ein #define oder ein typedef sein
Könnte aber auch wieder mal eine compilerspezifische Erweiterung sein

also bei microC pro gibt es ihn schon und das schreiben sie in der hilfe

bit type
The mikroC PRO for PIC compiler provides a bit data type that may be 
used for variable declarations. It can not be used for argument lists, 
and function-return values.

bit bf;    // bit variableThere are no pointers to bit variables:

bit *ptr;    // invalidAn array of type bit is not valid:

bit arr [5];     // invalidNote :
Bit variables can not be initialized.
Bit variables can not be members of structures and unions.
Bit variables do not have addresses, therefore unary operator & (address 
of) is not applicable to these variables.

Sven P. schrieb:
>>

1

>> volatile unsigned short *ccpr1 = (unsigned short *)0xFBE;

2

>> *ccpr1 = 0x2400;

3

>>

>
> Nein, in normalem C wäre das undefiniert. Das ist im Übrigen genau der
> Unterschied zwischen Zeigern und Adressen, den ich jedes Mal aufs Neue
> predige, und für den man mich jedes Mal aufs Neue verschreit.

Sorry, ich stehe anscheinend hier auf dem Schlauch. Ich finde den obigen 
C-code vollkommen OK. Uebersehe ich da was?

Oder willst du darauf hinaus dass die @-Schreibweise etwas aehnliches 
wie eine reference variable in C++ ist und es kein Pendant dazu in C 
gibt?

Thomas

Im Prinzip hast du damit ja recht.

Aber faktisch ist das egal, weil jede Konstruktion, die
eine Variable an eine bestimmte Adresse legt, niemals
portierbar sein wird.
Es geht also nur noch darum, ob es auf dem konkreten Rechner
damit klappt.

Bei microC gibtes das zeichen @ nicht ich kann nur schreiben
volatile bit output;
und wenn ichdann schreibe output=RA5_bit; dann mag er das auch nicht

@haku:
Ok, du hast natuerlich recht, und jetzt verstehe ich auch deinen Zusatz 
"und für den man mich jedes Mal aufs Neue verschreit". ;-) Wenn jemand 
mit festen Adressen arbeitet, dann ist demjenigen hoffentlich bewusst, 
dass das nicht mehr portabel ist.

Wie und wo wird den 'output' verwendet.

Vielleicht kann man das mit einem Makro irgendwie kaschieren.
Wer oder was ist denn RA2_bit?

Wenn du eh erst mit dem Programmieren anfängst:

Schnapp dir ein Sample-File für DEINEN Compiler, und versuch nicht 
(als allererstes Projekt) mit den Interna von ZWEI verschiedenen 
Compilern zu Kämpfen bei dem Versuch ein Programm zu portieren.

Klaus Wachtler schrieb:
> Aber faktisch ist das egal, weil jede Konstruktion, die
> eine Variable an eine bestimmte Adresse legt, niemals
> portierbar sein wird.

Genau.  Im zitierten C99-Stückchen steht ja auch nicht, dass das
Verhalten "undefined" sei, sonder "implementation-defined".  Damit
steht es der Implementierung frei zu dokumentieren, was passiert,
wenn man eine Zahl in einen Zeiger umformt und worauf man dabei
achten muss.  Finde ich allemal aber sinnvoller, als deshalb nun
gleich noch die Syntax zu erweitern, wie das bei dem @-Hack ja
erfolgt ist.