Newsgroup: it.hobby.elettronica.digitale
Titolo: STM32F103RC Lento

Sto cercando di imparare la programmazione di un uC STM32F103RC, dopo 
che per anni ho usato tranquillamente degli atmega(8-324-128), in 
quanto mi serve una maggiore velocitï¿œ di calcolo.
Dopo avere con successo compilato ed effettuato la mia prima 
programmazione del uC (il programma ï¿œ riportato sotto), mi aspetto che 
sul pin PC9 ci sia un onda quadra con una frequenza abbastanza elevata 
(qualche MHz considerando che il uC lavora a 72MHz).
Invece mi ritrovo un'onda quadra ad una frequanza di circa 300KHz 
(misurata con un oscilloscopio con fmax 20MHz).
Ho utilizzato 2 programmi differenti per compilare il codice riportato 
al termine del messaggio:
-CooCox (senza ottimizzazione)
-Keil uVision4 limitato a 32Kb (provato diverse ottimizzazioni)
 
Programmatore:St-Link
 
Ottengo sempre lo stesso risultato sul pin PC9; mi sapete dire dove sto 
sbagliando?
 
 
int main(void)
{
ErrorStatus HSEStartUpStatus;
 
GPIO_InitTypeDef GPIO_InitStructure;
 
	/* RCC system reset(for debug purpose) */
  RCC_DeInit();
 
  /* Enable HSE */
  RCC_HSEConfig(RCC_HSE_ON);
 
  /* Wait till HSE is ready */
  HSEStartUpStatus = RCC_WaitForHSEStartUp();
 
  if(HSEStartUpStatus == SUCCESS)
  {
    /* Enable Prefetch Buffer */
    FLASH_PrefetchBufferCmd(FLASH_PrefetchBuffer_Enable);
 
    /* Flash 2 wait state */
    FLASH_SetLatency(FLASH_Latency_2);
 
    /* HCLK = SYSCLK */
    RCC_HCLKConfig(RCC_SYSCLK_Div1);
 
    /* PCLK2 = HCLK */
    RCC_PCLK2Config(RCC_HCLK_Div1);
 
    /* PCLK1 = HCLK/2 */
    RCC_PCLK1Config(RCC_HCLK_Div2);
 
    /* PLLCLK = 16/2 MHz * 9 = 72 MHz */ quarzo da 16MHz sui pin osc
    RCC_PLLConfig(RCC_PLLSource_HSE_Div2, RCC_PLLMul_9);
 
    /* Enable PLL */
    RCC_PLLCmd(ENABLE);
 
    /* Wait till PLL is ready */
    while(RCC_GetFlagStatus(RCC_FLAG_PLLRDY) == RESET)
    {
    }
 
    /* Select PLL as system clock source */
    RCC_SYSCLKConfig(RCC_SYSCLKSource_PLLCLK);
 
    /* Wait till PLL is used as system clock source */
    while(RCC_GetSYSCLKSource() != 0x08)
    {
    }
  }
 
 
 
 
  GPIO_InitTypeDef  GPIO_InitStructure;
    /* Initialize LED which connected to PC9, Enable the Clock*/
    RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOC, ENABLE);
    /* Configure the GPIO_LED pin */
    GPIO_InitStructure.GPIO_Pin = GPIO_Pin_9;
    GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP;
    GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz;
    GPIO_Init(GPIOC, &GPIO_InitStructure);
 
 
  while (1)
    {
        GPIOC->ODR ^= GPIO_Pin_9; //loop infinito toggle PC9
    }
    return 0;
}
 
 

 (misurata con un oscilloscopio con fmax 20MHz).
 
 
Ciao, dovrò anche io utilizzare un micro della stessa famiglia a breve e 
la cosa mi interessa.
 
Hai provato a vedere il codice asm generato dal loop infinito?
 
Marco
 
 

Marco Trapanese ha detto questo domenica :

Non ancora, tuttavia pochi minuti fa mi è esploso il uP a causa di un 
filo che ha fatto corto circuito :o). Ora si che funziona :)
Provo nel pomeriggio con l'integrato di riserva.
 
 

 Invece mi ritrovo un'onda quadra ad una frequanza di circa 300KHz 
 
Innanzi tutto vedo che hai inserito dei wait states nella flash, quindi la
velocità di esecuzione del codice ne risente di conseguenza. Esaminando il
disassemblato puoi trovare il numero di istruzioni richiesto dal tuo loop
infinito, e moltiplicando questo nomero per WS+1 puoi grossolanamente
stimare il numero di cicli di clock necessari.
 
Inoltre spesso anche i periferici (GPIO inclusi) hanno dei wait states
"impliciti" dovuti principalmente al fatto che condividono i bus
dati/indirizzi interni con altri periferici.
 
Però effettivamente anche così 300 kHz sembrano pochi.
 
-- 
Fletto i muscoli e sono nel vuoto.

 che il uC lavora a 72MHz).
 
Ciao, a memoria ricordo che "srotolando il loop"
(lunga sequenza di set/reset) e accedendo direttamente
ai registri la frequenza di uscita era superiore a 10MHz,
non ricordo esattamente quanto. Il limite credo siano i
waitstates della flash e l'accesso al bus che non è
istantaneo. Quindi molto + veloce di 300kHz ma non
paragonabile alla frequenza di clock, comunque se
ti interessa per "verificare" le prestazioni del core
credo che non sia buon metodo. Se invecde ti serve
generare dei segnali veloci, studiati i suoi timers, e
di studio da fare ce ne sta parecchio :)
Su google "STM32 pin toggle speed" dovrebbe restituirti
alcuni esempi di programmi di test.
 
-- 
Muvideo altrove
Fabio Eboli nella vita reale...
fabioebChiocciolAquipo.it
 
 

 generare dei segnali veloci
 
Grazie mille per le risposte; il test che ho fatto non era per generare 
forme d'onda PWM o altro bensì quello di comparare la velocità del uP 
ad effettuare il toggle di PC9 rispetto a quello dell'atmega128 
(effettuando lo stesso test) che sto usando per pilotare un LCD 
320x240. (Oscilloscopio 25MSPS)
L'intenzione era quella di sostituire l'atmega128 con qualcosa di più 
veloce in modo da aumentare il refresh del display.
 
 


Se il display ha una interfaccia parallela tipo 6800 o 8080
allora potresti usare il FSMC (mi pare che c'e' solo nelle
versioni high density da più di 100 pin). C'e' una appnote
al riguardo. Io ho usato un stm32F103rb per un display touch
320x240 senza FSMC, quindi pilotando le porte direttamente,
e il refresh era abbastanza veloce, ma non ci potevo visualizzare
filmati. I dettagli non li ricordo è passato un po' di tempo.


Fabio_78 ci ha detto :

Ho riprovato il test seguendo il tuo consiglio di cercare su Google 
alcuni esempi da cui potevo prendere spunto.
Il risultato ottenuto è più che soddisfacente, ora riesco ad ottenere 
una freq. di circa 15MHz, sempre utilizzando codice in C e compilato 
con uVision (sembra che coocox crei troppo codice asm).
Non mi resta che convertire il listato dell'oscilloscopio in modo da 
sostituire l'atmega128L con questo STM32.
Sono sicuro che almeno le routine grafiche saranno eseguite più 
velocemente (erano il collo di bottiglia di tutto il software anche se 
erano totalmente scritte in assembler).
 
Grazie mille ! :-)
 
 

>
avevo letto su un forum in inglese  di qualche confronto tra un qualcosa 
simile a un ATMEGA e Cortex M0,con velocitàclock comparabili, e qualcuno 
diceva che il primo eseguiva un toggle a velocità superiore,
ma non appena c'era da svolgere del codice che comparava dei valori o faceva 
qualche operazione condizionale. il Cortex dimostrava l'efficienza 
dell'ottimizzazione del codice per le istruzioni  ARM,