mikrocontroller.net

Forum: Compiler & IDEs Kompatibilitaet von structs an absoluten Positionen


Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe hier den C-Compiler von Renesas fuer SH. Fuer den liefert 
Renesas ein File fuer die Registerdefinitionen der CPUs mit.

Das sieht in etwa so aus:

struct st_iic3 {                                /* struct IIC3  */
       union {                                  /* ICCR1        */
             _UBYTE BYTE;                       /*  Byte Access */
             struct {                           /*  Bit Access  */
                    _UBYTE ICE:1;               /*   ICE        */
                    _UBYTE RCVD:1;              /*   RCVD       */
                    _UBYTE MST:1;               /*   MST        */
                    _UBYTE TRS:1;               /*   TRS        */
                    _UBYTE CKS:4;               /*   CKS        */
                    } BIT;                      /*              */
             } ICCR1;                           /*              */
[einiges gekuerzt]
      union {                                  /* NF2CYC       */
             _UBYTE BYTE;                       /*  Byte Access */
             struct {                           /*  Bit Access  */
                    _UBYTE :6;                  /*              */
                    _UBYTE PRS:1;               /*   PRS        */
                    _UBYTE NF2CYC:1;            /*   NF2CYC     */
                    } BIT;                      /*              */
             } NF2CYC;                          /*              */
};                                              /*              */

#define IIC3_1 (  *(volatile struct st_iic3 *) 0xFFFEE400 ) /* IIC3_1 
Address */

Ein Zugriff auf ein Bit ist dann zum Beispiel einfach so moeglich:

IIC3_1.ICCR1.BIT.ICE = 1;

Ich wuerde gerne dieses File auch unter dem gcc nutzen. Der Prozessor 
hat eine ganze Menge Register und das File ist 600kbyte gross. Das 
schreibt man nicht mal eben so neu.

Es ist auch kein Problem das einzubinden und ich habe damit auch schon 
einiges programmiert. Es sollte also funktionieren. Allerdings habe ich 
hier auch einen relativ schlichten Programmteil (i2c-bus) der mit dem 
Compiler von Renesas funktioniert, mit dem gcc aber nicht.

Daher meine Frage ob soetwas portabel ist, oder ob es sein kann das der 
gcc die Reihenfolge der Bits oder anderer Elemente umsortiert?

Olaf

Autor: Μαtthias W. (matthias) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

die Anordnung der Bits in einem Bitfeld ist vom C Standard nicht 
vorgeschrieben -> "Implementation defined". Du kannst dich also nicht 
darauf verlassen wir der Compiler die Bits anordnet.

Matthias

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>  Du kannst dich also nicht
> darauf verlassen wir der Compiler die Bits anordnet.

Hm..gut, oder auch schlimm.

Allerdings habe ich mittlerweile herausgefunden das auch soetwas
nicht funktioniert:

   pointer = (void*) 0xfffee402;  //Adress of ICMR_1
   vari1 = *pointer;

Ich lese hier ein Register indem laut Datenblatt des Controllers 
bestimmte Bits immer 1 sein muessen, aber bekomme trotzdem null raus. 
Woran es auch immer liegt, der vom gcc erzeugten Assemblercode sieht 
unauffaellig aus, es liegt jedenfalls erstmal nicht an den structs.

Der zugriff ueber structs:

   vari1 = IIC3_1.ICMR.BYTE;

fuehrt zum selben falschen Ergebnis. Die structs sind also unschuldig.

Olaf

Autor: Martin Thomas (mthomas) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>...
>pointer = (void*) 0xfffee402;  //Adress of ICMR_1
>vari1 = *pointer;
>...
Typ von pointer und vari1? Adresse impliziert 
"16-bit"-Zugriffsmöglichkeit. So etwas ausprobiert?:
#define TESTREG (*((volatile unsigned short*) 0xfffee402))
volatile unsigned short val;
int main(void) { val = TESTREG; while(1) {;} return 0;}
val sollte so im Debugger "watchbar" sein, zumindest sollte ein 
Core-Register den Wert von TESTREG enthalten.

Aktuelle Version der KPIT GNU tools im Einsatz? Falls nicht, könnte sich 
ein Update lohnen. Denn wenn richtig erinnert, ist im mitgelieferten GNU 
Compiler die Funktionalität von -fstrict-volatile-bitfields enthalten 
und per default aktiviert. Damit sind die Aussichten auf Funktion des 
"struct/union/Bitfelder über Hardwareregistern"-Ansatzes besser.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Typ von pointer und vari1? Adresse impliziert
> "16-bit"-Zugriffsmöglichkeit. So etwas ausprobiert?

Daran lag es nicht. Das Register ICMR soll zwar immer 0x38 liefern,
aber macht das wohl erst wenn das gesamte I2C-Modul eingeschaltet ist.

Allerdings hatte ich I2C eingeschaltet. Und zwar so:

 CPG.STBCR5.BIT.MSTP56 =       0;

Das funktioniert aber nicht. Schalte ich es dagegen so
ein:

  pointer = (void*) 0xfffe0410;  //STBCR5 Register
  *pointer &= ~0x40;             //MSTP56 ist Bit6

Dann bekomme ich meine 0x38.

Schaue mir jetzt mal an was der Compiler aus

   CPG.STBCR5.BIT.MSTP56 =       0;

macht:
  37                            .loc 1 37 0
  38 0004 02E00010              movi20  #-131056,r2  //0xfffe0010
  39 0008 01000400              movi20  #1024,r1     //0x00000400
  40 000c 312C                  add     r2,r1        //r1=STBCR5
  41 000e 6311                  mov.w   @r1,r3       //Inhalt holen
  42 0010 02F0BFFF              movi20  #-16385,r2   //0xbfff ARGH!
  43 0014 2239                  and     r3,r2
  44 0016 2121                  mov.w   r2,@r1

Es sieht also so aus als wenn der Compiler das Register wirklich
an der falschen Stelle im Struct verortet. Oder er macht einen 16Bit 
Zugriff obwohl er nur 8Bit darf. Muss ich noch weiter pruefen.

> Aktuelle Version der KPIT GNU tools im Einsatz?

Aber aber, mein gcc stammt aus eigenem Ansatz:
/home/olaf/sources/SH2A/test1: sh2a-gcc --version
sh2a-gcc (GCC) 4.5.1

> val sollte so im Debugger "watchbar" sein, zumindest sollte ein
> Core-Register den Wert von TESTREG enthalten.

Waer schoen, dafuer muesste ich aber erstmal den gdb-stub vollstaendig 
laufen haben. Soweit bin ich noch nicht.

> ist im mitgelieferten GNU
> Compiler die Funktionalität von -fstrict-volatile-bitfields enthalten
> und per default aktiviert.

Hm..interessant. Werde ich gleich mal testen ob mein original gcc das 
auch kann und ob es das Problem loest.

BTW: Wenn ich mal den Code vergleich den der gcc erzeugt und den der 
Renesas compiler erzeugt dann schneidet gcc aber ziemlich schlecht ab. 
Ich glaub der gcc erzeugt etwa Faktor 2-3 mehr code. Ausserdem 
verschachtelt der Renesas-Compiler Instruktionen von verschiedenen 
C-Befehlen lustig ineinander. Das macht zwar das debuggen etwas nervig, 
aber ich nehme mal an das macht er nicht ohne Grund. Ich vermute er 
sortiert den Code so um damit der Prozessor wirklich zwei Befehle 
gleichzeitig ausfuehren kann.

Olaf

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm..interessant...

Ich nutze auch ein RS232 Modul und schalte das so ein:

CPG.STBCR4.BIT.MSTP44 = 0;

  63                            .loc 1 66 0
  64 000c 02E00010              movi20  #-131056,r2
  65 0010 010003FC              movi20  #1020,r1
  66 0014 312C                  add     r2,r1
  67 0016 6311                  mov.w   @r1,r3
  68 0018 02F0EFFF              movi20  #-4097,r2
  69 001c 2239                  and     r3,r2
  70 001e 2121                  mov.w   r2,@r1

Das sieht identisch aus zu obigen Problem, aber es funktioniert!

Ich vermute mal das Problem ist der 16Bit-Zugriff auf das Register. Im 
Datenblatt steht naemlich nur was von 8Bit-Zugriff. Das geht vielleicht 
bei manchen Registern gut und bei manchen nicht.

Allerdings frage ich mich wieso der Compiler auf die Idee kommt 16bit 
weise zuzugreifen. Definiert ist das struct naemlich so:

       union {                                  /* STBCR5       */
             _UBYTE BYTE;                       /*  Byte Access */
             struct {                           /*  Bit Access  */
                    _UBYTE MSTP57:1;            /*   MSTP57     */
                    _UBYTE MSTP56:1;            /*   MSTP56     */
                    _UBYTE MSTP55:1;            /*   MSTP55     */
                    _UBYTE :1;                  /*              */
                    _UBYTE MSTP53:1;            /*   MSTP53     */
                    _UBYTE MSTP52:1;            /*   MSTP52     */
                    _UBYTE MSTP51:1;            /*   MSTP51     */
                    _UBYTE MSTP50:1;            /*   MSTP50     */
                    } BIT;                      /*              */
             } STBCR5;                          /*              */
       _UBYTE wk7[3];                           /*              */

Olaf

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, das hier funktioniert:

 37:i2c.c         ****   CPG.STBCR5.BYTE &= ~0x40;
  37                            .loc 1 38 0
  38 0004 01E00010              movi20  #-131056,r1
  39 0008 02E00010              movi20  #-131056,r2
  40 000c 32214400              mov.b   @(1024,r2),r2
  41 0010 632C                  extu.b  r2,r3
  42 0012 E2BF                  mov     #-65,r2
  43 0014 2239                  and     r3,r2
  44 0016 622C                  extu.b  r2,r2
  45 0018 31210400              mov.b   r2,@(1024,r1)

Wie man sieht liegt es wohl wirklich am verbotenem wordweisen Zugriff.

Olaf

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Denn wenn richtig erinnert, ist im mitgelieferten GNU
> Compiler die Funktionalität von -fstrict-volatile-bitfields enthalten
> und per default aktiviert.

djdelorie hat mir gerade dasselbe erzaehlt. Dieser switch ist aber erst 
im neuen 4.6er enthalten. Das hat man davon wenn man einmal einen total 
modernen und voll coolen Controller verwendet. :-)
Da werde ich wohl mal updaten muessen...

Olaf

Autor: Entwickler (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Das hat man davon wenn man einmal einen total
>modernen und voll coolen Controller verwendet. :-)

... und kein Geld für einen modernen und voll coolen Compiler ausgeben 
möchte. Mit falschem Code läuft da nichts :-)

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... und kein Geld für einen modernen und voll coolen Compiler ausgeben
> möchte. Mit falschem Code läuft da nichts :-)

Ich verwende diesen voll coolen Compiler ja auch. Aber leider laeuft der 
nicht unter meinem voll coolen Betriebssystemen und das nervt etwas wenn 
ich jedesmal um was zu testen erstmal ein voll uncooles Windows booten 
muss. .-)

Olaf

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.