Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
STM32F103RC Lento
32 views
Skip to first unread message
Skynet81
Jun 8, 2013, 1:52:45 PM6/8/13
to
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;
}
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;
}
Marco Trapanese
Jun 9, 2013, 5:03:28 AM6/9/13
to
Il 08/06/2013 19:52, Skynet81 ha scritto:
> 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.
> Sto cercando di imparare la programmazione di un uC STM32F103RC, dopo
> che per anni ho usato tranquillamente degli atmega(8-324-128), in quanto
> 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).
Ciao, dovrò anche io utilizzare un micro della stessa famiglia a breve e
> (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).
la cosa mi interessa.
Hai provato a vedere il codice asm generato dal loop infinito?
Marco
Skynet81
Jun 9, 2013, 5:19:13 AM6/9/13
to
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.
filo che ha fatto corto circuito :o). Ora si che funziona :)
Provo nel pomeriggio con l'integrato di riserva.
dalai lamah
Jun 9, 2013, 7:00:08 AM6/9/13
to
Un bel giorno Skynet81 digitò:
> Dopo avere con successo compilato ed effettuato la mia prima
> programmazione del uC (il programma è riportato sotto), mi aspetto che
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.
> Dopo avere con successo compilato ed effettuato la mia prima
> 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
Innanzi tutto vedo che hai inserito dei wait states nella flash, quindi la
> (qualche MHz considerando che il uC lavora a 72MHz).
> Invece mi ritrovo un'onda quadra ad una frequanza di circa 300KHz
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.
Fabio_78
Jun 9, 2013, 2:42:08 PM6/9/13
to
> 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.
> anni ho usato tranquillamente degli atmega(8-324-128), in quanto mi serve una
> 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).
Ciao, a memoria ricordo che "srotolando il loop"
> che il uC lavora a 72MHz).
(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
Skynet81
Jun 10, 2013, 2:47:41 AM6/10/13
to
Fabio_78 ci ha detto :
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.
> verificare" le prestazioni del core
> credo che non sia buon metodo. Se invecde ti serve
> generare dei segnali veloci
Grazie mille per le risposte; il test che ho fatto non era per generare
> credo che non sia buon metodo. Se invecde ti serve
> generare dei segnali veloci
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.
Fabio_78
Jun 10, 2013, 4:25:56 AM6/10/13
to
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.
Skynet81
Jun 10, 2013, 5:25:34 PM6/10/13
to
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 ! :-)
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 ! :-)
blisca
Jun 11, 2013, 4:36:17 PM6/11/13
to
"Skynet81" <Skyne...@hotmail.it> ha scritto nel messaggio
news:mn.557d7dd6a...@hotmail.it...
> Fabio_78 ci ha detto :
>>> Fabio_78 ci ha detto :
>>>> verificare" le prestazioni del core
>>>> credo che non sia buon metodo. Se invecde ti serve
>>>> 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.
>>
avevo letto su un forum in inglese di qualche confronto tra un qualcosa
>>> Fabio_78 ci ha detto :
>>>> verificare" le prestazioni del core
>>>> credo che non sia buon metodo. Se invecde ti serve
>>>> 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.
>>
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,
0 new messages