Én 3+1 dolgot csinálnék.
1: Priorizáld a megszakításokat.
2: Használj egymásba ágyazott megszakításokat.
3: Ne használd (ott) a CUBEMX-et.

Még valami: Nem tudom mit kell osztani mennyivel de én:
Ha pl mérek valamit sokszor, akkor a mérések száma kettő hatványa.
Ezután az átlagolás az osztás szintén kettő hatványa.
Ez így valójában azt jelenti, hogy szorzok kettővel-néggyel stb (léptek balra), osztáskor jobbra. Azaz segítem a processzort.

A kettő hatványaival való mérésre még gondoltam én is. Most nekiálltam írogatni a programot cubemx-nélkül ami kissé megnehezíti a dolgot mivel a cube azért sok miden beállítás legenerál.
Ha a cube-al generált programba akarok bele írni akkor meg egyszerűen nem hajlandó menni a program így kicsit bele ásom magam a részletekbe.

Rögtön meg is akadtam az elején leszedtem az STM-es clock generátort ami megcsinálja a system_stm32f0xx.c fájlt, hogy legalább az órajellel ne kelljen bajlódni.

Az a durva hogy összehasonlítottam a sima kimenet billegtetését amit a cube generált azzal amit a xls. generált és a cube-os 2x gyorsabb 300ns a másik meg 600ns.

Ennyi a kód:[code=c][#include "stm32f0xx.h"



int main(void)
{
volatile uint32_t dly;

RCC->AHBENR |= RCC_AHBENR_GPIOBEN;
GPIOB->MODER |= GPIO_MODER_MODER6_0;

GPIOB->OSPEEDR |= GPIO_OSPEEDR_OSPEEDR6;
//GPIOB->PUPDR |= GPIO_PUPDR_PUPDR6_0;
while (1)
{

GPIOB->ODR = GPIOB->ODR | 0x40; // PB6 bekapcsol

GPIOB->ODR = GPIOB->ODR & 0xFFBF; // PB6 kikapcsol
}
/code]

A cube-osnál sok egyéb van de a main-ben ugyan ez.
Miért lehet gyorsaságban különbség? A Mhz- beállítások ugyan azok. Bár az excelben a bekarikázott rész nem állítható a cube-ban igen és az 48Mhz.

A cubeMX-hez nem értek, de ha a regisztereket közvetlenül írogatod, akkor az ODR regiszter olvasás-bitműveletek-írás módszertől van gyorsabb is egy láb billengetésére:

Tudom, hogy az gyorsabb azzal az eredmény 75ns vs 220ns-lett a Cube MX javára.

Nem tudom miből adódhat ekkora különbség.

Mit gondoltok, 8MHz-vel túl lehet húzni 1 STM32F103-ast?
Károsodás nélkül?

Mert lehet állítani 3 féle GPIO sebességet.

És utána kellene nézned mire állította neked?

Már 1 órája megy 10* szorzóval 80MHz-vel.

Hiba nélkül semmi langyosodás.
Azt hiszem így hagyom!

Mások is kipróbálták, mindjárt 128MHz-ig húzták.

Ez a kimenetek slew rate sebessége. Nem a meredekséggel van baj hanem hogy tovább tart neki elvégeznie.

Na, ez jó! A magok általában nagyon bírják a túlhúzást de a perifériák szoktak téveszteni, leginkább az EEPROM írás, de lehet, hogy az is megy... Megy közben timer-ed vagy USART vagy valami élérzékeny periféria? (pl. I2C).

Ennek utána mértem!

És igazad lett, a GPIO_Speed_2MHz vagy GPIO_Speed_50MHz beállításnál.
Ugyanazt az impulzus szélességet mértem, ezzel a rutinnal:




Ezért csak az első mérésről teszem ide a képet:


Most már ezt is tudom!

ui,: Elég gyenge a kép, de kinagyítva látszik a 2db, 41ns impulzus.

Igen Megy közben Systick int 10KHz-n, 2 timer 4KHZ-n, USART 115200 baud hibátlanul!

Most olvasom, hogy az USB nem mükszik emelt órajellel!

Aki botloadert használ az ne kísérletezzen!

2-10 vagy 50Mhz ennek ott van értelme ahol szeretnénk csökkenteni a nagy dU/dt-t ami esetlegesen áramköri zavarokat okozhat hosszabb vezetékekben.

Csak ők GD32-est huztak 128Mhz-re, az alapból tud 108MHz-t!

Bővebben: Link

Hát ez, "bluepill" stm32 szerintem , de én is kíváncsi vagyok kipróbálom.

Egy gyors SPI (ILI9341 TFT ) és i2c tesztre futotta 128MHz-en. Eddig úgy tűnik minden rendben fut.

Olvasom, hogy a Kínából jött STM32-ők, hamisítottak.
Valójában GD32-esek vannak a címke alatt.

Ezért bírják a csúcs hajtást!

Ez igen, amit az LCD-vel produkál!!

Köszi az infót, akkor lehet megpróbálkozom az USB résszel is, akkor kiderül mi a típusa valójában.

Az USB az reménytelen!
ADC még mükxik: PLL 14* és ADC Presc/ 8 beállítással!
Az Timerk-nél, DMA-nál 112MHz …
Mikor USB-t akarsz használni vissza veszed a PLL szorzót!

Itt (1)egy arduinos példa rá:
Bővebben: Link

Egyébként lehetséges, hogy a Kínai ARM-okban van nagyobb USB elő osztó is?
De mire azokat a dokumentációkat lefordítják legalább angolra!?
(Csak találgatok!)

Azért ne essünk már hanyatt attól. Ez is F103-on fut (csak nem hajtom túl): videó

TFT test, ARM 72MHz, 8bit databus??

Az előző SPI-n teljesített hasonlóan!

A kettő rendszer külön súlycsoport!

A kínai GD32-es példányokban 0 wait state-es flash van. Már az órajel emelése nélkül is el lehet érni néhány százalékos gyorsulást (állítólag akár 10%-ost is) ennek a beállításával.
Egyébként nem biztos, hogy hamisat veszel. Olyan F103-ast is normális áron vettem, amiből nincs is GD32-es kivitel. A GD32 pedig állítólag hivatalos ST partner, lehet licenszelik az F1-es sorozatot.

Az megvan, hogy én teljes képernyőt írok és SD kártyát is olvasok közben? Mind1, ne vitatkozzunk ezen.

Ez jó hír!
Pláne ha még az USB Prescale osztót is hozzá állítják az emelt órajelhez!

Csak nem értem! Miért STM logót szitáznak rá, ha a magja GD gyártmány?

Próbáld meg levenni a flash latency-t 0-ra az inicializáláskor. Ha rendesen fut a programod, akkor valszeg GD32 a cucc.

Távol áll tőlem a vitatkozás!
Te valószínűleg sokat dolgoztál, mire összejött ez a teljesítmény!

A másik meg csak megemelte az órajel szorzót!

Annyira sokat azért itt még nem dolgoztam rajta, csak portoltam némi kódot ATXMega-ról ARM-ra és kíváncsi voltam mit bír a vas.

Igen, van: 1, 1.5, 2 és 2.5-es szorzó. Utóbbi kettővel 48 x 2 = 96 Mhz vagy 48 x 2.5 = 120 MHz frekvencián lehet az USB működését remélni. A 120 MHz kicsit fölötte van a GD32 specifikációjának, de szobahőmérséklet környékén ez nem okozhat gondot. Bővebben: Roger Clark - GD32F103: A STM32F103 on steroids!