system_stm32f10x.c: 2 C-Verständnisfragen

Tobias Gast #1755759
Lesenswert?
• ▲
▼ 
Hallo,
mal 2 C-Verständnisfragen zum untenstehenden Code aus der 
system_stm32f10x.c:
1. Warum ist die (großgeschriebene???) Variable HSEStatus auch vom Typ 
uint32_t? uint8_t hätte hier doch eigentlich voll gelangt, somit 3 byte 
verschwendet?
2. Warum ist bei RCC->CR |= ((uint32_t)RCC_CR_HSEON); noch ein cast auf 
uint32_t? RCC_CR_HSEON ist doch im define schon als uint32_t definiert. 
Ich weiß, es schadet wohl auch nicht, nur wenn es einen Grund hat, würde 
ich es gerne wissen.

1
static void SetSysClockToHSE(void)

2
{

3
  __IO uint32_t StartUpCounter = 0, HSEStatus = 0;

4
  

5
  /* SYSCLK, HCLK, PCLK2 and PCLK1 configuration ---------------------------*/    

6
  /* Enable HSE */    

7
  RCC->CR |= ((uint32_t)RCC_CR_HSEON);

8
 

9
  /* Wait till HSE is ready and if Time out is reached exit */

10
  do

11
  {

12
    HSEStatus = RCC->CR & RCC_CR_HSERDY;

13
    StartUpCounter++;  

14
  } while((HSEStatus == 0) && (StartUpCounter != HSEStartUp_TimeOut));

15
.

16
.

17
.
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
(prx) A. K. #1755766
Lesenswert?
• ▲
▼ 
Zu 1: Bei einem ARM - wie bei vielen anderen 32-Bit Architekturen - 
verbrät eine lokale 8- oder 16-Bit Variable mehr Platz als eine 32-Bit 
Variable. Es läuft so oder so auf ein Register raus dessen ggf. 
verbleibender Rest nicht anderweitig verendet wird, aber bei weniger als 
32 Bits kommen Konvertierungen hinzu, die bei 32 Bits entfallen.

Optimierungsstrategien können also bei AVR und ARM sehr gegenläufig 
verlaufen. Weshalb es in stdint.h sowas wie int_fast8_t gibt, was bei 
ARM 32 Bits und bei AVR 8 Bits breit sein kann.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Robert T. #1755951
Lesenswert?
• ▲
▼ 
Nochmals so einfach es geht. Der STM32 "spricht 32-bit", der AVR 
"spricht 8-bit". Fuer 16-bit bruahcne beide einen Dolmetscher, doch 
abwaerts geht's leichter.
Programme, die stark ueberwiegend 8-bit Verarbeitung machen werden 
wachsen wenn man sie auf 32-bit protiert. Programme, die viele 32-bit 
variablen oder Arithmetik benuetzen werden viel groesser, wenn man sie 
von 32-bit auch 8-bit portiert. Beide brauche Dolmetscher, Libraries, 
type-casting.....
Der Einfachheit halber bei STM32 die 32-bit variable benuetzen wenn's 
nicht total eng ist im Speicher

Gruss, Robert
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Lutz Gast #1756340
Lesenswert?
• ▲
▼ 
Wieder was gelernt. Denn im Hitex Guide auf Seite 16 unter 2.3.6 
Unaligned Memory Accesses steht groß als dolles CM3-Feature, daß sich 
die 8-, 16- und 32 bit Variablen im Gegensatz zu z.B. "alten" Kernen 
lückenlos aneinanderschmiegen und so bis zu ca. 25 % SRAM sparen.
Oder ist das wieder der ewige Spagat: Laufzeit- oder 
Resourcenvorteilhaft programmieren, eine XOR-Verknüpfung ...?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
(prx) A. K. #1756355
Lesenswert?
• ▲
▼ 
In deinem Beispiel stehen die Variablen nicht im Speicher, sondern in 
Registern. Und genau das macht den Unterschied aus. Wenn man eine 
Variable aus dem Speicher ins Register läd macht es bei ARM praktisch 
keinen Unterschied im Code, ob 8/16/32-Bit. Wenn sie jedoch vom Compiler 
von vorneherein im Register gehalten werden, dann sind sie bei unter 32 
Bits ineffizient.

Wobei dabei zwischen Cortex-M3 und klassischem ARM wenig Unterschied 
besteht, ausser dass Cortex-M3 Variablen im Speicher auch unaligned 
verarbeiten und somit Füllbytes einsparen kann. Darauf bezieht sich die 
Aussage von Hitex. Gratis ist das aber nicht, denn es kostet Zeit, daher 
wird man das eher selten finden, man muss es im Compiler extra 
hinschreiben.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren