Forum: Mikrocontroller und Digitale Elektronik frage zu diesen Zeichen @


von Michael S. (mihadongle)


Lesenswert?

Hallo, hab mir ein Samel file gezogen, jedoch mein Compiler (MicroC)
Will diesen befehl nicht weiss nicht mal was er bedeutet
volatile bit output @ RA2_bit;
Vielleicht könnt ihr mir da weiter helfen.

MfG Michael

von Karl H. (kbuchegg)


Lesenswert?

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.

von Michael S. (mihadongle)


Lesenswert?

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

von Sebastian B. (Gast)


Lesenswert?

Michael Schulz schrieb:
> volatile unsigned short ccpr1 @ 0xFBE; //declare a 16 bit variable that
> is located at address 0xFBE, just where CCPR1 registers start

In normalem C wäre das ein Zeiger:
1
volatile unsigned short *ccpr1 = (unsigned short *)0xFBE;
2
*ccpr1 = 0x2400;

Du kannst dir aber auch z.B. die avr-libc angucken, da werden Register 
auch ohne die *-Zeigerschreibweise gesetzt. Kann Aus dem Kopf aber nicht 
sagen wie das geht.

von Sven P. (Gast)


Lesenswert?

Sebastian B. schrieb:
> Michael Schulz schrieb:
>> volatile unsigned short ccpr1 @ 0xFBE; //declare a 16 bit variable that
>> is located at address 0xFBE, just where CCPR1 registers start
>
> In normalem C wäre das ein Zeiger:
>
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.

Der '@'-Operator wurde vermutlich genau aus diesem Grund eingeführt, 
eben um es definiert zu haben. Der funktioniert vermutlich auch noch bei 
bitadressiertem Speicher usw.

Die AVR-Libc (bei der man sich vorher drauf geeinigt hat, dass die 
Adressen zu den Zeigern korrespondieren) macht man lvalues, etwa so:
1
#define  REGISTER     (*( (char *) 123 ))

von Michael S. (mihadongle)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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

von Sven P. (Gast)


Lesenswert?

Wegen 'bit' tippe ich halt mal, dass es sich um bitadressierbaren 
Speicher handelt...

von erwieder (Gast)


Lesenswert?

Output ist im Prinzip nur ein alias fuer RA2_bit.

von Michael S. (mihadongle)


Lesenswert?

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.

von Thomas P. (tpircher) Benutzerseite


Lesenswert?

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

von Tätäterätätä (Gast)


Lesenswert?

Hallo Michael,

Standarddefinition der Portpindeclaration beim
CC5X-Compiler (goggel KNUDSEN compiler PIC)
für die schmuddeligen, kleinen PICs.
Das musst Du zurechtbasteln für den mikroC.

Dietmar

von Sven P. (Gast)


Lesenswert?

Thomas Pircher schrieb:
> 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?

Das Problem bei deiner Schreibweise ist: Nirgendwo steht auch nur ein 
Wort darüber geschrieben,
(1) wie Zeiger intern dargestellt werden und
(2) wie die Umwandlung zwischen Zeiger und Ganzzahl zu erfolgen hat.

Bezüglich der Umwandlung ist nur festgelegt:
1
 The mapping functions for converting a pointer to an integer or an integer to a pointer are intended to
2
 be consistent with the addressing structure of the execution environment.
Nur die Adressstruktur der Laufzeitumgebung kann halt eben alles sein 
(PAE und schon gehts in die Hose). Strenggenommen könnte ein Compiler 
intern auch eine Tabelle verwalten, in denen er linearen Zeigern einfach 
Zufallswerte zuordnet, wenn denn das zur Adressierung in der 
Laufzeitumgebung passt.

von Sven P. (Gast)


Lesenswert?

Noch deutlicher, C99-Draft, §6.3.2.3:
1
An integer may be converted to any pointer type. Except as previously
2
specified [da wurde der NULL-Zeiger eingeführt], the result is
3
implementation-defined, might not be correctly aligned, might not point
4
to an entity of the referenced type, and might be a trap representation. 
5
56) [die Fußnote, die ich oben bereits zitiert habe]

von Klaus W. (mfgkw)


Lesenswert?

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.

von Michael S. (mihadongle)


Lesenswert?

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

von Thomas P. (tpircher) Benutzerseite


Lesenswert?

@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.

von Karl H. (kbuchegg)


Lesenswert?

Wie und wo wird den 'output' verwendet.

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

von Εrnst B. (ernst)


Lesenswert?

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.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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.

von Tätäterätätä (Gast)


Lesenswert?

!!
11.02.2010 15:02
!!
Hast Du einmal nachgeschaut?? ok
die Antwort ist "nein".

volatile bit output @ RA2_bit;

in den controllerspez. Headerdateien, z.B.

#pragma bit  GPIO0   @ GPIO.0 // general purpose IO 0

In den ganzen Headerdateien gibt es aber kein
RA2_bit !

Merkwürdig, das die Frage noch nicht kam:
Welcher Controller ?? Was soll passieren ??
Warum ??

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.