Normális lehet...
Startup fájlt mindkettő IDE maga szolgáltatja, és ebben vannak az órajel beállítások.

Vagy a késleltetést is kioptimalizálhatja a fordító, ki kell próbálni egy extra nop paranccsal.

Ebbol a kodbol egy -Os opcioval a gcc a ket for ciklust ugy kivagja, mint a sicc, ha az i nem volatile. Ebben az esetben ez szemmel nem latjato villogast kell eredmenyezzen..
De ettol fuggetlenul ugy tartjak, hogy a Keil-nek jobb a C forditoja, mint a gcc. A gcc egy baromi jo fordito, ingyenes, fut mindenen, de neha nagyon erthetetlen dolgokat muvel. AVR-en irtozatosan katasztrofalis kodot kepes generalni, de neha ARM-en is..

volatile az i

hali,

köszi kipróbáltam,
az extra nop paranccsal is sokkal gyorsabb..., de lassabb, mint nop nélkül...
kemény dolgok ezek.

Keil-ben milyen szintu optimalizacio van beallitva, es GCC-ben ?
Most latom elkestem, na nem baj Bocsi.

Lehet meglesz a különbség.
Most, hogy bütykölöm.tanulom az időzítést,
meghívva a SystemCoreClockUpdate(); függvényt és debuggerrel belemászva látszik, hogy Keilban

tmp = RCC->CFGR & RCC_CFGR_SWS;

switch (tmp)
{
case 0x00: /* HSI used as system clock source */
SystemCoreClock = HSI_VALUE;
break;
case 0x04: /* HSE used as system clock source */
SystemCoreClock = HSE_VALUE;
break;
case 0x08: /* PLL used as system clock source */

/* PLL_VCO = (HSE_VALUE or HSI_VALUE / PLL_M) * PLL_N
SYSCLK = PLL_VCO / PLL_P
*/

0x08 az érték, mígy CoIDE-ben pedig 0x00.
ezáltal Keilban 168MHz, a másikban pedig 16000000 (160MHz?)

Ez és a fordítók különbségei magyarázatot adhatnak a különbségre.
Systickkel mostmár persze egyforma...

Már csak azt kellene kitalálnom, honnan is szedi végül az órajel forrás beállítást...:-O

Köszi mindenkinek az együttgondolkodást.!

A Startup fájlból.

Amúgy én annyira nem bízom a SystemCoreClock értékében. Már olvastam ki hülyeségeket onnan, de lehet csak valamit elbénáztam.

Nos, sikerült összegányolnom a dolgot.

Arra jutottam, hogy Coocox alatt nem fut le SystemInit()... a startup során... a startup_stm32f4xx.c fájlban....
Kicsit bugos szagú a dolog... nekem.

A Default_Reset_Handler simán kis mókolás után hívja a main()-t...
__asm(" ldr r0, =_sbss"
" ldr r1, =_ebss"
" mov r2, #0"
" .thumb_func"
"zero_loop:"
" cmp r0, r1"
" it lt"
" strlt r2, [r0], #4"
" blt zero_loop");
#ifdef __FPU_USED
/* Enable FPU.*/
__asm(" LDR.W R0, =0xE000ED88"
" LDR R1, [R0]"
" ORR R1, R1, #(0xF << 20)"
" STR R1, [R0]");
#endif

/* Call the application's entry point.*/
main();
}

Holott a startup leírása ezt tartalmazza:

This module performs:
* - Set the initial SP
* - Set the initial PC == Reset_Handler,
* - Set the vector table entries with the exceptions ISR address
* - Configure the clock system and the external SRAM mounted on
* STM324xG-EVAL board to be used as data memory (optional,
* to be enabled by user)
* - Branches to main in the C library (which eventually
* calls main()).

Hát ezt nem nagyon tudtam itt tettenérni...

Kézzel explicit a main()-ban meghívva a SystemInit()-et sikerült ugyanolyan ledvillogtatási sebességet elérni a for-ciklussal.
Szóval siker, félsiker. Persze lehet, hogy rosszul gondolom ezt a startupos dolgot...

Kicsit félrebeszéltem...

Tehát az órajeleket nem a startup fájlban, hanem a system_stm32f4xx.c fájlban állítja be.
De ezt még meg kell előznie pár dolognak.

Az stm32f4xx.h fájlban van egy ilyen rész:

Tehát a meffelelő procit definiálni kell, legjobb lenne a fordítóban, mert az órajeleket is e szerint állítja a system_stm32f4xx.c.

Még az stm32f4xx.h fájlban van ez is:

Ezzel adod meg a külső órajelet.

A SystemCoreClock csak egy változó ami alapban kap értéket:

Tehát simán kiolvasva semmi köze a valódi órajelhez.

Hogy aktualizálódjon a SystemCoreClock értéke, meg kell hívni a SystemCoreClockUpdate(); függvényt.
És megfelelően be kell állítani a HSI_VALUE vagy HSE_VALUE értéket.

Hali,

ezek a lépések mind megvoltak sajnos. Pont ezért nem értettem, hogy miért nem jó, amikor minden a helyén volt.... ráadásul a Keil-ban is ezek a HSE értékek vannak, csak ugye ott más a startup menete egy kicsit...

Egyszerűen mintha a coocox-ban nem hívódott volna fel... passz.
Mostmár így jó... ha nem elegáns is.
Lehet ezek után megnézem az itt ajánlott másik free toolchaint is...

Megnéztem az EM::Blocks-al is, ott is frankón megtörténik a startup belenyúlás nélkül is...
Mondjuk ennél meg debuggolni nem tudtam, mert a GDB server el sem indul.
(lehet a vpn miatt?)

Az érdekes, mert nekem szépen megy a debug is minden extra beállítás nélkül.

Mi is pontosan a hardvered?

Én is kinlódtam a debuggerrel Em:Blocks-ban. Nem tudom, hogy milyen programozó/debugger hardvert használsz, én ST-link V1 és ST-link V2-vel próbáltam.
V1-gyel sehogy sem sikerült, pedig a spéci drivert is kipróbáltam, amit a fórumon írnak (azzal már a programozás sem működött).
A V2-vel végül sikerült életre keltenem a debugger funkciót: az Em:Blocks-ot Run as Administrator-ral indítva végre működött az SVD repository plugin, az ott lementett file-t beállítva pedig rendesen elindult a GDB server.
Elég láma dolog, hogy nem jutott eszembe adminisztrátorként indítani a progit, de minden más működött normál indítással is, és semmi erre utaló hibaüzenetet nem dobott a program.
A fórumokon még azt is írták, hogy az USB3-mal vannak problémái a debuggernek, ha régi USB3 driver van a gépen.

Azt azért ne felejtsük el hogy a PLL osztóit /szorzóit a user-nek kell állítgatni, és szerintem az se egy rossz dolog, ha azoknak megfelelően a SystemCoreClock változót is átállítja, az osztókból számolt és kívánt értékre.
Vzolee. Nem vagyok gép előtt, ahol az osztók értékeit kell beállítani, azt tedd már még neki ide szerintem, mert úgy teljes a kép.

ST-LINK/V2 ISOL.

(Közben rákerestem a googliban: coocox SystemInit()... majd otthon elolvasom a sok találatot a problémáról... Meg is van: "In Coocox you must calling SystemInit() by your self and I call it in the main();
" de így még nagyobb a sikerélmény, hogy erre a közreműködésetekkel végül rájöttem magam...)

Ezzel ellentétben, a keil-féle Startup file végén megtalálod a SystemInit() hívást.

Elvileg a DefaultResetHandler() végén, közvetlenül a main() függvény meghívása előtt kellene automatikusan meghívnia a SystemInit() függvényt. Most nézem a Joseph Yiu: The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors (3rd Edition) könyv mintapéldáit, s a ch_18_hello_world_5_CoIDE mintapéldában ezt a kommentben is így írja és valójában is így van (lásd startup_stm32f4xx.c):


Ezek szerint CoIDE és CoIDE között is különbség lehet...

Kösz, meg is csináltam így.

Szerintem a system_stm32f4xx.c -re gondoltál:



Illetve a project beállításoknál, a projectoptions->target->XTAL érték, illetve a projectoptions->c/c++/preprocessor symbols/define sorban beállított értékek is befolyásolják az órajelet, ráadásul tudtommal felül is bírálja a kódban beállított paramétereket.

Aha. Arra. Csak gép nélkül nehéz.
Én ezekkel az adatokkal szoktam kiszámolni a SysClk-t, illetve a további osztókkal az fAHB1, fAHB2 frekiket ezeket a változókat még külön én definiálom. Így a perifériák fel tudják használni a saját maguk konfigurálására, úgy mint USART Baud Rate, vagy ECAN.

Nekem ez a gyári órajel beállítás nem nyerte el a tetszésemet... ezért inkább egy sajátot csináltam.

Nálad még sosem láttam olyat, hogy egy kód elnyerte tetszésedet!

Sziasztok!
Segítséget kérek, mert kezdek beleőrülni: Em::Blocks-ban nem működik a debugger.
ST-link V2-vel próbálom, korábban már működött, ezért nem értem. Ugyanazzal az STM32F100RB-vel próbálom, mint korábban, de az STlinkGDB kapcsolódásakor mindig megáll a "Listening at *:4242..." üzenetnél. Másik gépre is feltelepítettem, ott ismét működik ugyanezzel a hardverrel. Újratelepítettem az Em::Blocks-ot, újratelepítettem az STlink drivert is, amivel egyébként a programozás szépen megy. Csak a debugger nem. Mi lehet a gebasz?

Végül megtaláltam: a Comodo tűzfalam berakta a GDB-arm.exe-t a Sandboxba, így - gondolom - az innen érkező üzeneteket szépen lenyelte, így a GDB server nem kapta meg. Csak azt nem értem, hogy korábban amikor a tűzfalat kikapcsoltam, akkor miért nem működött. Na mindegy, egy csomó időt elb@sztam, de hátha valakinek segítség.

Korábban hülyeséget írtam, az STlink V1-gyel mégiscsak működik az Em::Blocks debugger, ha az alábbi módszer szerint kicseréljük a drivert:
EM::Blocks debugger ST-link V1-gyel hogyan
Arra számítsunk, hogy a cserélt driverrel a programozás nem működik.

Üdv!

vzolee!

Úgy hallottam Itt, hogy neked van 429i discovery-hez expansion boardod, amivel külső kijelzőt is tudok kapcsolni a discovery-re.
Hogyan tudnék egy ilyenhez hozzájutni?

Valaki STM32CubeMX-el generált kódot probálkozott lefordítani gcc-vel?
Cocoox-ban nekem vagy 0-bájtot generál (assemby nélkül) vagy hibaüzneneteket ad a fordító...

Sziasztok! Már többször kaptam segítséget ezen a fórumon, ezért fordulok ismét hozzátok. A szakdolgozatnak a következő témát kaptam: Intelligens szenzor megvalósítása SNMP alapon. Kaptam egy Olimex STM32-P103 boardot, amin STM32F103RBT6 Cortex M3 proci van. Elsőnek nagy segítség lenne tőletek, ha segítenétek abban, hogy milyen RTOS-t ajánlotok erre a feladatra. Illetve, hogy milyen fejlesztőeszközt ajánlotok (most feltettem a uVision 5-t és a demo blinket megcsináltam és villog a led), de RTOS-t nem tudom, hogy kell rávarázsolni.

A Keil/ARM/Boards/ST könyvtárban biztosan találsz olyan mintapéldát, ami a kártyádhoz könnyen adaptálható. Az RTX_Blinky mintapélda az RTX RTOS-t használó demó. Az RTX már telepítve van a Keil/ERM/RL/RTX könyvtárban.

A másik egyszerű lehetőség a FreeRTOS. Ezen az oldalon keress a tiedhez hasonló kártyára/CPU-ra készített demót!

Hi!

Szerintem Intelligens szenzorhoz fölösleges az RTOS.
Én úgy csinálnám, hogy csoportosítanám a mérendő jeleket mit hogyan akarsz mérni (AD, PWM számlálás, SPI, USART I2C) ezeket Timer-el időzítve periódikusan olvasnám egy tömbbe.
Az adott tömböt, tömböket pedig a másik oldalról RS485, vagy CAN buszon kérném magától a szenzortól. az STM32F103-tól.
A fent említett perifériák itt rengeteg embernek ki vannak dolgozva, a CAN busz igaz hogy 207-re de nekem (is) pl meg van.
A CAN buszon egy MCU teljes távvezérlését megoldottam anno (igaz PIC-en) az eszköz cím, regiszter, regiszter-adat, R/W formában, így gyakorlatilag CAN buszon írtam az MCU bármely regiszterét. Én ezt tudnám neked ajánlani, nagyon gyors eredmény lehet, a szenzor protokolján nem kellene gondolkodni, az adott hardverek initje meg ugyebár rendelkezésre áll.