C > Struct > Pointer - Adresszuweisung

[Jan H. (janiiix3)]

Hallo Bit Freunde,

ich möchte gerne weiter meine C Kenntnisse auffrischen..

Dieser Variable möchte ich gerne die Adresse zuordnen, jedoch zeigt der 
Online Compiler ein Fehler an (was vermutlich auch richtig ist..)

Was mache ich falsch?

  //GPIO->OutReg       = (uint32_t*)((0x0554 + (4 * 8)));

/******************************************************************************

                            Online C Compiler.
                Code, Compile, Run and Debug C program online.
Write your code in this editor and press "Run" button to compile and execute it.

*******************************************************************************/

#include <stdio.h>
#include <stdint.h>

#define GPIO_BASE 0x60004000ul

typedef struct
{
  volatile uint32_t *FuncOutCnfg;
  volatile uint32_t *OutReg;
  volatile uint32_t *EnableReg;
}sGPIO;

volatile sGPIO *GPIO;



int main()
{
  //GPIO->FuncOutCnfg  = (uint32_t*)(GPIO_BASE + 0x0004);
  //GPIO->EnableReg    = (uint32_t*)(GPIO_BASE + 0x0020);
  GPIO->OutReg       = (uint32_t*)(GPIO_BASE + (0x0554 + (4 * 8)));
  
  //GPIO->OutReg       = (uint32_t*)((0x0554 + (4 * 8)));
    
    
  printf( "%p", GPIO->OutReg);

    return 0;
}

[Ada J. Quiroz (inschnier)]

*GPIO gibt es nicht. *GPIO zeigt ins Nichts.

[Bruno V. (bruno_v)]

Warum soll GPIO ein Pointer sein?

Falls zwingend Pointer:

volatile sGPIO GPIO[1];

sonst . statt ->

volatile sGPIO GPIO;
... 
    GPIO.OutReg = (uint32_t*)(GPIO_BASE + (0x0554 + (4 * 8)))

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jan H. schrieb:
> jedoch zeigt der Online Compiler ein Fehler an (was
Sollen wir jetzt raten, welcher Compiler welchen Fehler anzeigt?

> ich möchte gerne weiter meine C Kenntnisse auffrischen..
Wozu einen neuen Thread für das exakt selbe Problem? Reicht der 
Beitrag "Mit dem ESP32C3 laufen lernen" nicht?

Jan H. schrieb:
> Dann bin ich mal auf deine Erklärung gespannt..
Denk mal da drüber nach:
- https://onlinegdb.com/HZ-zbCPMXY

#include <stdio.h>

#define GPIO_BASE 0x60004000ul

typedef struct
{
  volatile unsigned long *FuncOutCnfg;
  volatile unsigned long *OutReg;
  volatile unsigned long *EnableReg;
} sGPIO;

volatile sGPIO GPIO;
volatile sGPIO *pGPIO;

int main()
{
  pGPIO = (sGPIO*)(&GPIO);

  GPIO.OutReg    = (unsigned long*)(GPIO_BASE + 4);
  printf( "%p\n",  pGPIO->OutReg);
  printf( "%p\n\n", GPIO.OutReg);  
  
  pGPIO->OutReg  = (unsigned long*)(GPIO_BASE) + 4;
  printf( "%p\n",  pGPIO->OutReg);
  printf( "%p\n\n", GPIO.OutReg);  
    return 0;
}

[Jan H. (janiiix3)]

Und so würde ich dann dem "Register" (0x60004004) einen Wert zuweisen?

  GPIO.OutReg    = (unsigned long*)(GPIO_BASE + 4); // Reg.Addr: 0x60004004
  *GPIO.OutReg   = 0x80; << zugewiesener Wert

[Jan H. (janiiix3)]

Ich versuche es mal wie folgt zu lösen..

//Mapping Address
//GPIO 0x6000_4000 to 0x6000_4FFF 

#define GPIO_BASE 0x60004000ul

typedef struct
{
  struct 
  {
    // mapped @GPIO_BASE
    uint32_t Bt_Select_Reg;
    uint32_t Out_Reg;
    uint32_t Out_W1TS_Reg;
    uint32_t Out_W1TC_Reg;
    uint32_t Enable_Reg;
    uint32_t Enable_W1TS_Reg;
    uint32_t Enable_W1TC_Reg;
    uint32_t Strap_Reg;
    uint32_t In_Reg;
    uint32_t Status_Reg;
    uint32_t Status_W1TS_Reg;
    uint32_t Status_W1TC_Reg;
    uint32_t PCPU_Int_Reg;
    uint32_t Status_Next_Reg;    
  }Cnfg_Reg;
  


  //mapped @GPIO_BASE + 0x554
  struct 
  {
    uint32_t Func0_Out_Sel_Cnfg;
    uint32_t Func1_Out_Sel_Cnfg;
    uint32_t Func2_Out_Sel_Cnfg;
    uint32_t Func3_Out_Sel_Cnfg;
    uint32_t Func4_Out_Sel_Cnfg;
    uint32_t Func5_Out_Sel_Cnfg;
    uint32_t Func6_Out_Sel_Cnfg;
    uint32_t Func7_Out_Sel_Cnfg;
    uint32_t Func8_Out_Sel_Cnfg;
  }Out_Func_Reg;

}GPIO_struct;
 
volatile GPIO_struct*    const sGPIO = (GPIO_struct*)GPIO_BASE;

Gibt es eine Möglichkeit die Struktur "Out_Func_Reg" an die Adresse 
"GPIO_BASE + 0x554" zu mappen also quasi das direkt schon bei der 
definition des Structs? Wie würde man sowas lösen?

[Bruno V. (bruno_v)]

Jan H. schrieb:
> Gibt es eine Möglichkeit die Struktur "Out_Func_Reg" an die Adresse
> "GPIO_BASE + 0x554" zu mappen also quasi das direkt schon bei der
> definition des Structs?
Nein.

> Wie würde man sowas lösen?
mit einem Datenfeld entsprechender Größe dazwischen. unsigned char 
_dummy[0x554-4*14]; oder so

Oder 2 Structs. Wenn es zwei Bereiche sind, warum dann nicht auch zwei 
Strukturen?

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Jan H. schrieb:
> Wie würde man sowas lösen?
Nachdem du zum Glück nicht der erste bist, der solche 
Registerdefinitionen in seinem C-Programmen verwednen will, wäre es 
sicher sinnvoll, mal zu schauen, wie seit vielen Jahren andere derartige 
Probleme lösen.

Bruno V. schrieb:
> mit einem Datenfeld entsprechender Größe dazwischen. unsigned char
> _dummy[0x554-4*14]; oder so
Ich finde diese verschachtelten Structs ungünstig, weil die jeder 
Compiler so interpretieren kann, wie es ihm gerade gefällt. Oder 
andersrum: es ist im Grunde Zufall wie diese Structs im Speicher 
abgelegt werden. Es kann sein, dass das mit den Dummy-Bytes zwischen den 
structs heute funktioniert. Es kann aber auch sein, dass es nach einem 
Compilerupdate oder nach dem Einschalten von Optimierungen nicht mehr 
funktioniert.

[Jan H. (janiiix3)]

Kann ich denn irgendwie sehen was der Compiler für Adressen als 
"Endergbnis" liefert?

Ich bin gerade dabei bei einem Board eine LED zum Leben zu erwecken aber 
ich habe das Gefühl das irgendwas mit den Adressen nicht ganz so 
hinhaut..

//Mapping Address
//GPIO 0x6000_4000 to 0x6000_4FFF 

#define GPIO_BASE 0x60004000ul

typedef struct 
{
    // mapped @GPIO_BASE
    uint32_t Bt_Select_Reg;
    uint32_t Out_Reg;
    uint32_t Out_W1TS_Reg;
    uint32_t Out_W1TC_Reg;
    uint32_t Enable_Reg;
    uint32_t Enable_W1TS_Reg;
    uint32_t Enable_W1TC_Reg;
    uint32_t Strap_Reg;
    uint32_t In_Reg;
    uint32_t Status_Reg;
    uint32_t Status_W1TS_Reg;
    uint32_t Status_W1TC_Reg;
    uint32_t PCPU_Int_Reg;
    uint32_t Status_Next_Reg;    

}GPIO_Cnfg_Reg_t;
 
typedef struct
{
  //mapped @GPIO_BASE + 0x554
    uint32_t Func0_Out_Sel_Cnfg;
    uint32_t Func1_Out_Sel_Cnfg;
    uint32_t Func2_Out_Sel_Cnfg;
    uint32_t Func3_Out_Sel_Cnfg;
    uint32_t Func4_Out_Sel_Cnfg;
    uint32_t Func5_Out_Sel_Cnfg;
    uint32_t Func6_Out_Sel_Cnfg;
    uint32_t Func7_Out_Sel_Cnfg;
    uint32_t Func8_Out_Sel_Cnfg;

}GPIO_Func_Sel_Reg_t;

volatile GPIO_Func_Sel_Reg_t*     const sGPIO_Func_Sel_Reg  = (GPIO_Func_Sel_Reg_t*)(GPIO_BASE + 0x0554);
volatile GPIO_Cnfg_Reg_t*         const sGPIO_Cnfg_Reg      = (GPIO_Cnfg_Reg_t*)GPIO_BASE;

void setup() 
{
  sGPIO_Func_Sel_Reg->Func8_Out_Sel_Cnfg |= 0x80;
  sGPIO_Cnfg_Reg->Enable_Reg |= 1<<8;

  // gpio8 auf low setzen
  sGPIO_Cnfg_Reg->Out_Reg &= ~(1<<8);
}

[Bruno V. (bruno_v)]

Jan H. schrieb:
> sGPIO_Func_Sel_Reg->Func8_Out_Sel_Cnfg |= 0x80;
>   sGPIO_Cnfg_Reg->Enable_Reg |= 1<<8;
>   // gpio8 auf low setzen
>   sGPIO_Cnfg_Reg->Out_Reg &= ~(1<<8);

sollen die alle das gleiche bit beschreiben? Mal 0x80, mal 0x100.

[Bruno V. (bruno_v)]

Lothar M. schrieb:
> Ich finde diese verschachtelten Structs ungünstig,
Ich auch. Deshalb war meine Antwort auch lakonisch

Bruno V. schrieb:
> Jan H. schrieb:
>> Gibt es eine Möglichkeit ...
> Nein.

[Jan H. (janiiix3)]

Bruno V. schrieb:
> Jan H. schrieb:
>> sGPIO_Func_Sel_Reg->Func8_Out_Sel_Cnfg |= 0x80;
>>   sGPIO_Cnfg_Reg->Enable_Reg |= 1<<8;
>>   // gpio8 auf low setzen
>>   sGPIO_Cnfg_Reg->Out_Reg &= ~(1<<8);
>
> sollen die alle das gleiche bit beschreiben? Mal 0x80, mal 0x100.

Nein natürlich nicht.
Habe mich hier an dieses Beispiel gehalten (mit der Struktur und den 
ganzen Registern)

https://blog.feabhas.com/2019/01/peripheral-register-access-using-c-structs-part-1/

[Dergute W. (derguteweka)]

Moin,

Jan H. schrieb:
> Kann ich denn irgendwie sehen was der Compiler für Adressen als
> "Endergbnis" liefert?

Fuer die Mutigen mit gcc/binutils toolchain, die sich durch den 
Assembler lesen wollen:
entweder gcc -save-temps ....
und dann im .s File stoebern
oder objdump -D bla.o | less
und dann g'schwind lesen.

Gruss
WK

[Jan H. (janiiix3)]

Jan H. schrieb:
> Bruno V. schrieb:
>> Jan H. schrieb:
>>> sGPIO_Func_Sel_Reg->Func8_Out_Sel_Cnfg |= 0x80;
>>>   sGPIO_Cnfg_Reg->Enable_Reg |= 1<<8;
>>>   // gpio8 auf low setzen
>>>   sGPIO_Cnfg_Reg->Out_Reg &= ~(1<<8);
>>
>> sollen die alle das gleiche bit beschreiben? Mal 0x80, mal 0x100.
>
> Nein natürlich nicht.
> Habe mich hier an dieses Beispiel gehalten (mit der Struktur und den
> ganzen Registern)
>
> 
https://blog.feabhas.com/2019/01/peripheral-register-access-using-c-structs-part-1/

Ich verstehe deine Antwort nicht.
Die Register haben jeweils unterschiedliche Werte.

[Bruno V. (bruno_v)]

Jan H. schrieb:
> Ich verstehe deine Antwort nicht.
> Die Register haben jeweils unterschiedliche Werte.

Ich kenne Dein System nicht. Du schreibst nur

Jan H. schrieb:
> Ich bin gerade dabei bei einem Board eine LED zum Leben zu erwecken aber
> ich habe das Gefühl das irgendwas mit den Adressen nicht ganz so
> hinhaut..

aber nicht, was nicht funktioniert oder (noch wichtiger) was 
funktioniert.

Wenn Du Angst hast, dass die Adresse falsch sein könnte ... dann schreib 
sie direkt hin, probier es aus und wenn es funktioniert, dann nimm den 
Struct-Weg und probier erneut. Das brauchst Du ja nur ein Mal 
exemplarisch zu machen.

Oder Du hast einen Debugger am laufen, dann setze den Brakepoint davor, 
schaue Dir das Register an und geh im Singlestep drüber.

Ohne Debugger scheitert es an den unmöglichsten Dingen, angefangen von 
Konfigurationsbits und der Quarz läuft gar nicht los. Oder das Signal 
toggelt so schnell, dass Du es nicht siehst. Hast Du Debugger, LSA oder 
Oszi?

Die Struct-Adressfrage ist ja genügend beleuchtet. Das ist aber Kür wenn 
der direkte Weg funktioniert.

[Jan H. (janiiix3)]

Bruno V. schrieb:
> Ohne Debugger scheitert es an den unmöglichsten Dingen, angefangen von
> Konfigurationsbits und der Quarz läuft gar nicht los. Oder das Signal
> toggelt so schnell, dass Du es nicht siehst. Hast Du Debugger, LSA oder
> Oszi?

Für ATMEL habe ich alles da, ja. Oszi. habe ich auch. Bringt mir jetzt 
gerade nur nichts.

Es muss an meiner Initalisierung von dem Struct liegen bzw. der 
Adressen.
Leider kann ich mir nicht erklären was genau das Problem ist.

Wenn ich es mit fester Adresse teste, funktioniert es:

volatile uint32_t* Func_Reg = (uint32_t*)(GPIO_BASE + 0x0574);
volatile uint32_t* Enable_Reg = (uint32_t*)(GPIO_BASE + 0x0020);
volatile uint32_t* Out_Reg = (uint32_t*)(GPIO_BASE + 0x0004);

void setup() {

 *Func_Reg = 0x80; // set special index
 *Enable_Reg = 1<<8; // enable gpio 8
 *Out_Reg = 0; // set all @low level

}

Mache ich es mit der Struktur haut es aufeinmal nicht mehr hin..
Ich vermute mal das der Compiler? Da andere Adressen interpretiert als 
ich mir das vorstelle?!

Hier ist mein Zeiger auf die Basis Adresse des GPIO´s

volatile GPIO_Cnfg_Reg_t*         const sGPIO_Cnfg_Reg      = (GPIO_Cnfg_Reg_t*)GPIO_BASE;

So wie ich mir das jetzt vorstelle. Meine Struktur mit den ganzen 
Konfigurations Register:

typedef struct 
{
    // mapped @GPIO_BASE
    uint32_t Bt_Select_Reg;
    uint32_t Out_Reg;
    uint32_t Out_W1TS_Reg;
    uint32_t Out_W1TC_Reg;
    uint32_t Enable_Reg;
    uint32_t Enable_W1TS_Reg;
    uint32_t Enable_W1TC_Reg;
    uint32_t Strap_Reg;
    uint32_t In_Reg;
    uint32_t Status_Reg;
    uint32_t Status_W1TS_Reg;
    uint32_t Status_W1TC_Reg;
    uint32_t PCPU_Int_Reg;
    uint32_t Status_Next_Reg;    

}GPIO_Cnfg_Reg_t;

Halte ich mit der Maus jetzt auf den ersten Member so erhalte ich 
folgendes Bild (siehe Anhang).
Dort zeigt mir die Arduino IDE an das "Bt_Select_Reg" einen Offset von 0 
hat. Gehe ich mit der Maus jetzt auf den letzten Eintrag 
"Status_Next_Reg" sagt die IDE mir das es sich um einen Offset von 52 
Bytes handelt.
Das würde dann dem letzten Register (Adresse) vom Datenblatt entsprechen 
oder verstehe ich das falsch?

[Harald K. (kirnbichler)]

Jan H. schrieb:
> Dort zeigt mir die Arduino IDE an das "Bt_Select_Reg" einen Offset von 0
> hat. Gehe ich mit der Maus jetzt auf den letzten Eintrag
> "Status_Next_Reg" sagt die IDE mir das es sich um einen Offset von 52
> Bytes handelt.

Das sind die Offsets der Strukturelemente relativ zum Beginn der 
Struktur.
Mit Deinen Registeradressen hat das, wenn überhaupt, nur rein zufällig 
zu tun.

Wozu soll bei Deinem Projekt eigentlich die Struktur dienen? Welches 
Problem meinst Du, damit lösen zu können?

Ich sehe hier nur eine zusätzliche Abstraktionsebene, die Du einziehst, 
und die Dich heftigst herausfordert.

[Jan H. (janiiix3)]

Harald K. schrieb:
> Wozu soll bei Deinem Projekt eigentlich die Struktur dienen? Welches
> Problem meinst Du, damit lösen zu können?


Damit möchte ich einfach vermeiden das ich die ganzen Register Adressen 
von Hand in den Code tippen muss..
So wie hier..

volatile uint32_t* Func_Reg = (uint32_t*)(GPIO_BASE + 0x0574);

[Harald K. (kirnbichler)]

Jan H. schrieb:
> Damit möchte ich einfach vermeiden das ich die ganzen Register Adressen
> von Hand in den Code tippen muss..

Musst Du ja auch nicht. Du machst an einer Stelle ein #define, und das 
war's dann.

So arbeitet der Rest der Welt, und so sind i.d.R. auch die von 
Controllerherstellern gelieferten Headerdateien für ihre µCs aufgebaut.

Und man kann so ein Macro auch so definieren, daß man es direkt als 
"Pseudovariable" verwenden kann.

#define Func_Reg (*((uint32_t *) (GPIO_BASE + 0x0574)))

Das dereferenziert die I/O-Adresse, so daß Du im Code einfach so etwas 
schreiben kannst:

Func_Reg = 4;

int x = Func_Reg;

Eine Struktur ist da nicht erforderlich, sondern höchstens ein besseres 
Namensschema (ich würde das Ding GPIO_FUNC_REG nennen, auch um zu 
zeigen, daß das ein Macro/#define ist).

[Jan H. (janiiix3)]

Danke für den Vorschlag.
Meinen Ansatz hatte ich mal in einen Online C Compiler gehauen und da 
hatte es komischerweise gepasst mit den Adressen von daher bin ich 
ausgegangen das es so funktionieren kann. Auf einigen Webseiten wird es 
für diverse Atmels auch so praktiziert.

[Harald K. (kirnbichler)]

Jan H. schrieb:
> Auf einigen Webseiten wird es
> für diverse Atmels auch so praktiziert.

Auf Webseiten wird viel praktiziert.

Es gibt im Zusammenhang mit HAL-Abstraktionen verschiedener 
µC-Hersteller  die Tendenz, statt einzelner Registerdefinitionen (wie 
oben) Pseudostrukturen zu definieren, die ein Peripherieobjekt abbilden.


Wenn bei einem Peripheriebaustein die zusammengehörenden Register 
monoton aufsteigend angeordnet sind, dann kann das so aussehen, wie hier 
diskutiert:
Beitrag "Ich verstehe diesen Code nicht"

Die Registerstruktur im ESP32, um den es Dir ja letztendlich geht, ist 
für diese Herangehensweise nicht geeignet, da die Register recht 
willkürliche Adressen haben (wie Dein Offset von 0x574 ja schon zeigt).

Da müsste man die Struktur mit sehr, sehr vielen "Füllregistern" für 
unbenutzte Registeradressen definieren):

typedef struct
{
    __IO uint32_t GPIO_BT_SELECT_REG; // 0x0000
    __IO uint32_t GPIO_OUT_REG;       // 0x0004
    __IO uint32_t GPIO_OUT_W1TS_REG;  // 0x0008
    __IO uint32_t GPIO_OUT_W1TC_REG;  // 0x000C
    __IO uint32_t UNUSED_BLOCK_0[4];
    __IO uint32_t GPIO_ENABLE_REG;    // 0x0020
   ... etc.
    __IO uint32_t GPIO_PIN21_REG      // 0x00C8
    __IO uint32_t UNUSED_BLOCK_x[35];
    __IO uint32_t GPIO_FUNC0_IN_SEL_CFG_REG // 0x0154
   ... etc.


} ESP32_GPIO_T;

(bezogen auf das Datenblatt, Seite 171, Tabelle mit GPIO-Registern)

Du siehst, daß das sehr unhandlich und vor allem fehlerträchtig wird.

[Johann L. (gjlayde)]

Lothar M. schrieb:
> Oder andersrum: es ist im Grunde Zufall wie diese Structs
> im Speicher abgelegt werden.

Natürlich ist es kein Zufall, sondern es wird im [E]ABI (Applicaton 
Binary Interface) festgelegt / beschrieben.

Nicht alle Features von C/C++ werden im Sprachstandard festgelegt; es 
gibt auch Dinge, die sind Implementation Defined.  Einige davon werden 
von der C/C++ Implmemtation festgelegt, für GCC etwa:

https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html
https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Implementation.html

andere werden im ABI festgelegt, welches idR Hardware- und OS-abhängig 
ist.  Und auch Eigenschaften des Binärformats (z.B. welche RELOCs im ELF 
wie festgelegt sind) sind Sache des ABIs.

[Jan H. (janiiix3)]

Wieso funktioniert das mit den Registern dann bei z.B einem Xmega von 
ATMEL bzw. Microchip?

/* I/O Ports */
typedef struct PORT_struct
{
    register8_t DIR;  /* I/O Port Data Direction */
    register8_t DIRSET;  /* I/O Port Data Direction Set */
    register8_t DIRCLR;  /* I/O Port Data Direction Clear */
    register8_t DIRTGL;  /* I/O Port Data Direction Toggle */
    register8_t OUT;  /* I/O Port Output */
    register8_t OUTSET;  /* I/O Port Output Set */
    register8_t OUTCLR;  /* I/O Port Output Clear */
    register8_t OUTTGL;  /* I/O Port Output Toggle */
    register8_t IN;  /* I/O port Input */
    register8_t INTCTRL;  /* Interrupt Control Register */
    register8_t INT0MASK;  /* Port Interrupt 0 Mask */
    register8_t INT1MASK;  /* Port Interrupt 1 Mask */
    register8_t INTFLAGS;  /* Interrupt Flag Register */
    register8_t reserved_0x0D;
    register8_t REMAP;  /* I/O Port Pin Remap Register */
    register8_t reserved_0x0F;
    register8_t PIN0CTRL;  /* Pin 0 Control Register */
    register8_t PIN1CTRL;  /* Pin 1 Control Register */
    register8_t PIN2CTRL;  /* Pin 2 Control Register */
    register8_t PIN3CTRL;  /* Pin 3 Control Register */
    register8_t PIN4CTRL;  /* Pin 4 Control Register */
    register8_t PIN5CTRL;  /* Pin 5 Control Register */
    register8_t PIN6CTRL;  /* Pin 6 Control Register */
    register8_t PIN7CTRL;  /* Pin 7 Control Register */
} PORT_t;
.
.
.
.
.
#define PORTA    (*(PORT_t *) 0x0600)  /* Port A */
#define PORTB    (*(PORT_t *) 0x0620)  /* Port B */
#define PORTC    (*(PORT_t *) 0x0640)  /* Port C */
#define PORTD    (*(PORT_t *) 0x0660)  /* Port D */
#define PORTE    (*(PORT_t *) 0x0680)  /* Port E */
#define PORTF    (*(PORT_t *) 0x06A0)  /* Port F */
#define PORTH    (*(PORT_t *) 0x06E0)  /* Port H */
#define PORTJ    (*(PORT_t *) 0x0700)  /* Port J */
#define PORTK    (*(PORT_t *) 0x0720)  /* Port K */
#define PORTQ    (*(PORT_t *) 0x07C0)  /* Port Q */
#define PORTR    (*(PORT_t *) 0x07E0)  /* Port R */

[Bruno V. (bruno_v)]

Jan H. schrieb:
> volatile uint32_t* Enable_Reg = (uint32_t*)(GPIO_BASE + 0x0020);

das ist ein offset von 32, also das 9te Element.

Jan H. schrieb:
> typedef struct
> {
>     // mapped @GPIO_BASE
>     uint32_t Bt_Select_Reg;
>     uint32_t Out_Reg;
>     uint32_t Out_W1TS_Reg;
>     uint32_t Out_W1TC_Reg;
>     uint32_t Enable_Reg;
>     uint32_t Enable_W1TS_Reg;
>     uint32_t Enable_W1TC_Reg;

Hier ist es das 5te Element.

Ein Problem ist, dass Du zwar mehrere Beispiele hast, aber niemals dabei 
sagst, ob es das gleiche oder was verschiedenes zeigt.

[Jan H. (janiiix3)]

Ich werde

Bruno V. schrieb:
> Jan H. schrieb:
>> volatile uint32_t* Enable_Reg = (uint32_t*)(GPIO_BASE + 0x0020);
>
> das ist ein offset von 32, also das 9te Element.
>
> Jan H. schrieb:
>> typedef struct
>> {
>>     // mapped @GPIO_BASE
>>     uint32_t Bt_Select_Reg;
>>     uint32_t Out_Reg;
>>     uint32_t Out_W1TS_Reg;
>>     uint32_t Out_W1TC_Reg;
>>     uint32_t Enable_Reg;
>>     uint32_t Enable_W1TS_Reg;
>>     uint32_t Enable_W1TC_Reg;
>
> Hier ist es das 5te Element.
>
> Ein Problem ist, dass Du zwar mehrere Beispiele hast, aber niemals dabei
> sagst, ob es das gleiche oder was verschiedenes zeigt.

Ich werde leider nicht wirklich aus deinen Kommentaren schlau.
Was genau meinst Du? Es ist immer noch das gleiche Projekt was ich vor 
mir habe.

[Bruno V. (bruno_v)]

Jan H. schrieb:
> Damit möchte ich einfach vermeiden das ich die ganzen Register Adressen
> von Hand in den Code tippen muss..
> So wie hier..volatile uint32_t* Func_Reg = (uint32_t*)(GPIO_BASE +
> 0x0574);

Ist zwar O.T., aber wenn die Adressen sowieso ungeordnet bzw. 
fragmentiert vorliegen, ist die Tipparbeit selbst mit Editoren aus dem 
letzten Jahrhundert in Summe geringer.

Du schreibst Die Namen und Adressen runter

Func_Reg      0x0574
Dings_Reg     0x0588
...

und machst den Pre- ("volatile uint32t* ")  Mid- (" = 
(uint32_t*)(GPIO_BASE +
 ") und Postfix (");") in wenigen Sekunden für alle.

Der Vorteil: Du siehst später sofort den echten Wert und musst ihn nicht 
abzählen. Hat zwar auch ein paar Nachteile, aber vorerst reicht das.

[Bruno V. (bruno_v)]

Jan H. schrieb:
> Ich werde leider nicht wirklich aus deinen Kommentaren schlau.
> Was genau meinst Du? Es ist immer noch das gleiche Projekt was ich vor
> mir habe.

Du sagst

Jan H. schrieb:
> wenn ich es mit fester Adresse teste, funktioniert es:
> ...
> volatile uint32_t* Enable_Reg = (uint32_t*)(GPIO_BASE + 0x0020);

hast bei der "Struktur-Version" Enable_Reg aber an einer ganz anderen 
Adresse (GPIO_BASE + 20 statt +0x20)

Mag sein, dass das ein Tippfehler ist (0x20 statt 20), mag sein, dass 
Füll-Elemente fehlen.

[Jan H. (janiiix3)]

Okay.
Also laut Datenblatt sind die Konfigurations Register 32 Bit lang, also 
4 Bytes und fangen bei der Adresse "0x0000".
Das "Enable" - Register liegt bei Adresse "0x0020".
Wenn ich jetzt eine Struktur habe wo alle Elemente 32 Bit lang sind also 
4 Bytes und das "Enable" Register an der richtigen Stelle steht, müsste 
es doch von der Adresse passen?!

[Bruno V. (bruno_v)]

Jan H. schrieb:
> Wenn ich jetzt eine Struktur habe wo alle Elemente 32 Bit lang sind also
> 4 Bytes und das "Enable" Register an der richtigen Stelle steht, müsste
> es doch von der Adresse passen?!

Ja. Dann sähe dein Struct aber so aus. Mit, wie

Harald K. schrieb:
> sehr vielen "Füllregistern" für unbenutzte Registeradressen [..]
> typedef struct
>

> {
>     __IO uint32_t GPIO_BT_SELECT_REG; // 0x0000
>     __IO uint32_t GPIO_OUT_REG;       // 0x0004
>     __IO uint32_t GPIO_OUT_W1TS_REG;  // 0x0008
>     __IO uint32_t GPIO_OUT_W1TC_REG;  // 0x000C
>     __IO uint32_t UNUSED_BLOCK_0[4];
>     __IO uint32_t GPIO_ENABLE_REG;    // 0x0020
>    ... etc.

In Deinem Beispiel fehlen die Füllregister, hier UNUSED_BLOCK_0

[Bruno V. (bruno_v)]

Oder, falls Du wirklich den Unterschied zwischen 0x20 und 20 nicht 
kennst: Das wievielte Element soll es ein? Das 5te oder das 9te?

[Jan H. (janiiix3)]

Bruno V. schrieb:
> Oder, falls Du wirklich den Unterschied zwischen 0x20 und 20 nicht
> kennst: Das wievielte Element soll es ein? Das 5te oder das 9te?

Du hast natürlich vollkommen Recht! Ich habe den Wald voller Bäume nicht 
gesehen.
Habe gar nicht bemerkt das nach 0x000C nicht 0x0010 kommt^^

[Klaus (feelfree)]

Jan H. schrieb:
> Habe gar nicht bemerkt das nach 0x000C nicht 0x0010 kommt

Erneuter Vertipper oder immer noch Verständnisschwierigkeiten?

[Jan H. (janiiix3)]

Klaus schrieb:
> Jan H. schrieb:
>> Habe gar nicht bemerkt das nach 0x000C nicht 0x0010 kommt
>
> Erneuter Vertipper oder immer noch Verständnisschwierigkeiten?

Habe gerade im Datenblatt gesehen das es ab dem "GPIO_OUT_W1TC_REG" 
nicht mehr der Reihe nach geht. Das war mir vorher nicht bewusst.

[Harald (hasanus)]

Bruno V. schrieb:
>> volatile uint32_t* Enable_Reg = (uint32_t*)(GPIO_BASE + 0x0020

Das ist wohl ein Tippfehler. Es sollte + 0x10 lauten, dann bist du 
wirklich am fünften Element.

[Harald (hasanus)]

Jan H. schrieb:
> Mache ich es mit der Struktur haut es aufeinmal nicht mehr hin..

Ich war genauso blind, hab den Fehler einfach übersehen.
In solchen Fällen sind assertions überaus hilfreich. Dass und auch wo im 
code der Unterschied herkommt hat mir

    assert(&sGPIO_Cnfg_Reg->Out_Reg == Out_Reg);
    assert(&sGPIO_Cnfg_Reg->Enable_Reg == Enable_Reg);
    assert(&sGPIO_Func_Sel_Reg->Func8_Out_Sel_Cnfg == Func_Reg);

gezeigt.

[Jan H. (janiiix3)]

Harald schrieb:
> Jan H. schrieb:
>> Mache ich es mit der Struktur haut es aufeinmal nicht mehr hin..
>
> Ich war genauso blind, hab den Fehler einfach übersehen.
> In solchen Fällen sind assertions überaus hilfreich. Dass und auch wo im
> code der Unterschied herkommt hat mir
>
>     assert(&sGPIO_Cnfg_Reg->Out_Reg == Out_Reg);
>     assert(&sGPIO_Cnfg_Reg->Enable_Reg == Enable_Reg);
>     assert(&sGPIO_Func_Sel_Reg->Func8_Out_Sel_Cnfg == Func_Reg);
>
> gezeigt.

Mit assert habe ich noch nicht gearbeitet. Muss ich mir mal anschauen.
Danke für deine Hilfe Harald! Einer von wenigen der nicht nur "ironisch" 
helfen will.

So funktioniert es ;)

//Mapping Address
//GPIO 0x6000_4000 to 0x6000_4FFF 

#define GPIO_BASE 0x60004000

/* Configuration Registers @DB Page 171 */
#define GPIO_BT_SELECT_REG      (*(volatile uint32_t*)(GPIO_BASE))
#define GPIO_OUT_REG            (*(volatile uint32_t*)(GPIO_BASE + 0x0004))
#define GPIO_OUT_W1TS_REG       (*(volatile uint32_t*)(GPIO_BASE + 0x0008))
#define GPIO_OUT_W1TC_REG       (*(volatile uint32_t*)(GPIO_BASE + 0x000C)) 
#define GPIO_ENABLE_REG         (*(volatile uint32_t*)(GPIO_BASE + 0x0020))
#define GPIO_ENABLE_W1TS_REG    (*(volatile uint32_t*)(GPIO_BASE + 0x0024))
#define GPIO_ENABLE_W1TC_REG    (*(volatile uint32_t*)(GPIO_BASE + 0x0028))
#define GPIO_STRAP_REG          (*(volatile uint32_t*)(GPIO_BASE + 0x0038))
#define GPIO_IN_REG             (*(volatile uint32_t*)(GPIO_BASE + 0x003C))
#define GPIO_STATUS_REG         (*(volatile uint32_t*)(GPIO_BASE + 0x0044))
#define GPIO_STATUS_W1TS_REG    (*(volatile uint32_t*)(GPIO_BASE + 0x0048))
#define GPIO_STATUS_W1TC_REG    (*(volatile uint32_t*)(GPIO_BASE + 0x004C)) 
#define GPIO_PCPU_INT_REG       (*(volatile uint32_t*)(GPIO_BASE + 0x005C))
#define GPIO_STATUS_NEXT_REG    (*(volatile uint32_t*)(GPIO_BASE + 0x014C))

#define GPIO_FUNC0_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0554)) 
#define GPIO_FUNC1_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0558)) 
#define GPIO_FUNC2_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x055C)) 
#define GPIO_FUNC3_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0560)) 
#define GPIO_FUNC4_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0564)) 
#define GPIO_FUNC5_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0568)) 
#define GPIO_FUNC6_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x056C)) 
#define GPIO_FUNC7_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0570)) 
#define GPIO_FUNC8_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0574)) 
#define GPIO_FUNC9_OUT_SEL_CFG_REG      (*(volatile uint32_t*)(GPIO_BASE + 0x0578)) 
#define GPIO_FUNC10_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x057C))  
#define GPIO_FUNC11_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x0580)) 
#define GPIO_FUNC12_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x0584)) 
#define GPIO_FUNC13_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x0588)) 
#define GPIO_FUNC14_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x058C)) 
#define GPIO_FUNC15_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x0590)) 
#define GPIO_FUNC16_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x0594)) 
#define GPIO_FUNC17_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x0598)) 
#define GPIO_FUNC18_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x059C)) 
#define GPIO_FUNC19_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x05A0)) 
#define GPIO_FUNC20_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x05A4)) 
#define GPIO_FUNC21_OUT_SEL_CFG_REG     (*(volatile uint32_t*)(GPIO_BASE + 0x05A8))

[Harald (hasanus)]

Johann L. schrieb:
> Lothar M. schrieb:
>> Oder andersrum: es ist im Grunde Zufall wie diese Structs
>> im Speicher abgelegt werden.
>
> Natürlich ist es kein Zufall, sondern es wird im [E]ABI (Applicaton
> Binary Interface) festgelegt / beschrieben.

Zudem gibt es auch in C static_assert, sizeof() und Direktiven zum 
Ausrichten und Packen von structs. Damit kann man sicherstellen dass 
(oder zumindest prüfen ob) Daten z.B. auf einem avr genauso abgebildet 
werden wie auf x64.

[Jan H. (janiiix3)]

ich habe da nochmal eine Frage:

#define SPI_LL_GET_HW(ID) (((ID)==1) ? &GPSPI2 : NULL)

SPI_LL_GET_HW bekommt die Adresse von "GPSPI2", richtig?

/**
 * Initialize SPI peripheral (master).
 *
 * @param hw Beginning address of the peripheral registers.
 */
static inline void spi_ll_master_init(spi_dev_t *hw)
{
    //Reset timing
    hw->user1.cs_setup_time = 0;
    hw->user1.cs_hold_time = 0;

    //use all 64 bytes of the buffer
    hw->user.usr_miso_highpart = 0;
    hw->user.usr_mosi_highpart = 0;

    //Disable unneeded ints
    hw->slave.val = 0;
    hw->user.val = 0;

    hw->clk_gate.mst_clk_active = 1;
    hw->clk_gate.mst_clk_sel = 1;

    hw->dma_conf.val = 0;
    hw->dma_conf.tx_seg_trans_clr_en = 1;
    hw->dma_conf.rx_seg_trans_clr_en = 1;
    hw->dma_conf.dma_seg_trans_en = 0;
}

Hier wird mit (vermutlich) schon den Hardware Registern gearbeitet, sehe 
ich das richtig? Zumindest sehe ich sonst keine Funktion mehr die die 
Register behandelt.

Wo bekommt "*hw" bzw. "GPSPI2" die Basisadresse von der SPI Einheit her?
Die muss doch irgendwo zugewiesen werden?

Die "spi_struct.h" die sich im Anfang befindet definiert "GPSPI2" stellt 
jedoch noch keine "Basis Adresse" da, lediglich evtl. die Offsets für 
die einzelnen Register?

[Bruno V. (bruno_v)]

Jan H. schrieb:
> SPI_LL_GET_HW bekommt die Adresse von "GPSPI2", richtig?

Das Makro wählt mittels ID zwischen verschiedenen Instanzen aus. Hier 
allerdings ist nur GPSPI2 für ID==1 vorhanden.

Solche Wrapper sollte man nur verwenden, wenn man sie braucht, also wenn 
der Code  mehrere Instanzen händelt.

Jan H. schrieb:
> Wo bekommt "*hw" bzw. "GPSPI2" die Basisadresse von der SPI Einheit her?

hw bekommt die Adresse beim Aufruf.
GPSPI2 beim Beispiel vorher ist bei seiner Definition an die richtige 
Adresse gelegt worden.

Es gibt eine ähnliche Zeile wie

> extern spi_dev_t GPSPI2;

Die heißt dann z.B.

> spi_dev_t GPSPI2 @0x10000;

wobei das @xxx, also die Adresszuweisung, compilerspezifisch ist.

[Jan H. (janiiix3)]

Bruno V. schrieb:
>> spi_dev_t GPSPI2 @0x10000;
>
> wobei das @xxx, also die Adresszuweisung, compilerspezifisch ist.

Das wird dann aber ganz normal in einer .c oder .h gemacht oder im 
Linker?