Cortex M3 I/O Peripherie Adressen

[Janvi (Gast)]

schaue mir gerade einen STM32F103 an. Wenn ich das richtig sehe, kann 
man auf die IO Pins über folgende Arten zugreifen

1) das normale IO Register
2) das set reset Register
3) das reset Register
  (was offensichtlich eingeführt wurde um einen Wort Swap zu sparen?)
4) über die gespiegelte Adressierung auf D0

GPIO Port A liegt laut STM32 Ref Manual auf 0x4001 0800 bis ... 0xBFF. 
Belegt also insgesamt füt 16 IO Bit ein volles Kilobyte 
(0xbff-0x800=0x3ff). Die GPIOA Register CRL, CRH, IDR, ODR, BSRR, BRR, 
LCKR  machen zusammen 7 Langworte aber nur 4 Byte = 28 Byte. Habe ich da 
etwas übersehen, bzw. was ist mit den restlichen Adressen ? Die 
Einzelbitzugriffe liegen doch erst oberhalb 0x42000000 ?

[Marcus H. (mharnisch)]

Janvi schrieb:
> 4) über die gespiegelte Adressierung auf D0

Was meinst Du mit D0?

> GPIO Port A liegt laut STM32 Ref Manual auf 0x4001 0800 bis ... 0xBFF.
> Belegt also insgesamt füt 16 IO Bit ein volles Kilobyte
> (0xbff-0x800=0x3ff). Die GPIOA Register CRL, CRH, IDR, ODR, BSRR, BRR,
> LCKR  machen zusammen 7 Langworte aber nur 4 Byte = 28 Byte. Habe ich da
> etwas übersehen, bzw. was ist mit den restlichen Adressen ?

Das liegt an der internen Busarchitektur. Der AMBA Standard sagt, dass 
jedes Device mindestens 1KB belegen muss. Das liegt wiederum daran, dass 
eine solche Einschränkung das Dekodieren der Adressen erheblich 
einfacher macht.

Gruß
Marcus
http://www.doulos.com/arm/

[J. V. (janvi)]

Mit D0 habe ich die Datenleitung Nummer Null gemeint, weil nur die im 
Bitbereich maßgebend scheint.

Bei AMBA habe ich natürlich noch nicht nachgelesen. Klar, es scheint 
dann als ob die Peripherieregister dann innerhalb 1k jeweils vielfach 
gespiegelt sind um Dekodierlogik zu sparen.

Eigentlich muß man das auch gar nicht so genau wissen, aber bei einem 
ersten  Blick in ein älteres Hitex Beispiel für das Keil MCBSTM Board 
habe ich mich wegen der Code Komplexität ziemlich gewundert und die 
Ärmel hochgekrempelt um was einfacheres eigenes zu schreiben. Nachdem 
ich die Portadressen selbst definiert habe, habe ich mich durch die 
Header Hierarchie der STM Lib von 2008 durchgewühlt. Wie ich das 
verstanden habe bin ich heute über CMSIS gestolpert wo alle Datentypen 
wieder umbenannt sind. Mal sehen ob ich aus den CMSIS Beispielen den 
GPIO Toggle mit dem GCC auf einem unpassenden Keil Board zum laufen 
kriege. Der Code ist jedenfalls ähnlich umständlich wie das Hitex 
Beispiel das ich vorgestern weggeschmissen habe - blos daß jetzt etwas 
klarer ist warum er so aufgeblasen ist ...

[Random .. (thorstendb)]

Hi,

> Wie ich das
> verstanden habe bin ich heute über CMSIS gestolpert wo alle Datentypen
> wieder umbenannt sind.

das ist so nicht ganz richtig.

Für die CMSIS wird von der ST Library im Grunde nur die stm32f10x_map.h 
verwendet. Die stm32f10x.h aus der CMSIS ist eine leicht erweiterte Form 
der _map, wo z.B. die Interrupts in einer enum ausdefiniert sind.

Der einzige Programmiertechnische Unterschied liegt in der Breite des 
Interrupt Priority Registers, welches original von ST als 32 Bit mit der 
Bezeichnung IPR[], und in der CMSIS als 8Bit mit der Bezeichnung IP[] 
dargestellt wird, da der Cortex-M3 byteaccess unterstützt.

Definitiv reicht immer die _map zum vollständigen Programmieren der 
Register a'la

Peripheral->Register = 0x55;
x = Peripheral->Register;

Schau mal in die CMSIS, da wird genau dieses Prinzip umgesetzt, und noch 
ein paar inline - Helferlein u.a. zum NVIC / SysTick angeboten.


Zu den Datentypen:
Mit der CMSIS wurden nur andere Bezeichner für die Datentypen eingeführt 
(uint32_t), um sich an den C standard anzulehnen, da dies über die 
verschiedenen Implementierungen der ARMs bisher immer "wie Kraut & 
Rüben" durcheinander ging (auch, wenn es auf die gleichen Datentypen 
hinauslief).


VG,
/th.