A kínai gyártás, fejlesztés pörög ezerrel..., egy újabb, perspektivikus mikrovezérlő(gyártó) Kínából - ARTERY

Van neki több mikrovezérlő típusa is, hajazva kicsit az STM típusokra, de nem, vagy csak részlegesen fedve le azokat, illetve jóval nagyobb RAM, Flash, órajel mellett kínál portékát.
Pl az egyik nagyon jó paraméterekkel rendelkező vezérlő az AT32F403A

A dokumentáció ami elérhető, angol nyelvű(Datasheet, Reference maual), teljesen korrekt, semmivel sem rosszabb minőség, mint pl egy STM támogatás.

Az oroszoknál valakik még röntgennel is megnézték a belsejét, és elégedettek voltak az ott látottakkal...

A WeAct studio, AT32F403ACGU7 procival szerelt BlackPill-t készített belőle, igen baráti áron!!

Van hozzá eclipse alapú IDE, és elérhető KEIL, IAR, SEGGER támogatás is.

Saját AT-Link nevezetű letöltő/debugger-e van, de legalábbis a KEIL tudja az ST-Link -et is használni hozzá zökkenőmentesen.

Mindent összevetve, szerintem egy egész jó alternatíva, STM helyett, minden szempontból....

Szerintem van nekem otthon egy ilyen BlackPill-em, valami nevetséges áron vettem (2-3eFT közt), de még nem programoztam rá semmit!

Ez egy viszonylag új cucc! Feltehetően ami neked van, az az azonos néven futó, egy ideje már létező STM32F401/411 BlackPill, ami nem azonos ezzel a termékkel, paramétereit tekintve sem.

CubeMX-et merre találok hozzá?

Igen, azt hiányolom. Ahogy a HAL-t is.
Egy kezdetleges clock configurator van hozzá.

Gondolom sehol..., mivel ez nem STM gyártmány!

Nem ugyanazt a szoftver hiányoljuk. Hanem valami olyat, ami hasonló szolgáltatást, kényelmet nyújt.

Hát akkor úgy kell kérdezni!
Én nem futottam bele hasonló konfigulátorba, de attól még előfordulhat, hogy van hozzá...esetleg lesz később. De személy szerint engem az ilyesmi különösebben nem is érdekel, ahogy az LL, HAL könyvtárak sem. A konfigurálást kb egyszer kell megcsinálni(néha esetleg futás közben is módosulhat), nem egy nagy kaland jellemzően..., de mindenképpen eltörpül egy kicsit is komolyabb program megírásának ideje mellett az egész! Számomra bőven megéri ezért a "kényelmetlenségért" cserébe a sokkal nagyobb memória és sebesség...

Az stm32-hez sem létezett CubeMX, HAL, LL amikor megjelent. Valószínűleg legelőször a CMSIS-t csinálták meg hozzá (nyilván a periféria regisztereinek elnevezése nélkül semmilyen épkézláb programot nem lehet rá írni), aztán (vagy vele együtt?) jött az azóta süllyesztőbe került "standard peripheral library". A HAL, LL, CubeMX csak később készült.
A kérdés, hogy a gyártó mennyit szán majd a fejlesztői környezet tovább okosítására. Mindenesetre egy darabot én is rendeltem ebből az alternatív blackpill-ből, ha megérkezik, majd letesztelem.

Eddig amit próbáltam aszerint lefelé teljesen kompatibilis az STM32F103xx verziókkal. (A HAL verzióval is!) Kis munkával az STM header file-ja átírható, hogy bekapcsolja az FPU-t, módosítsa a PLL regisztereket, az M3 helyett a "core_CM4.h"-t használja, na meg persze a fordítónál is engedélyezni kell a hard FPU-t. (Ennek még nem jutottam a végére, majd egyszer talán ...)
E mellett szinte egyezik a GD32F303CG típussal, csak a PLL regiszterben pár bit különbözik. (Nekem a GD is futott 240MHz-en)
Arduino könyvtára még fejlesztésre vár, bár már az is használható.

Próbálta már valaki használni a DMA vezérlőjét?
Én most tesztelem, és azt mérem, hogy kb 9 órajelbe kerül neki egy mem->periféria(IO portra) írása! Nekem ez nagyon lassúnak tűnik, szemben pl az STM32F407-es vezérlővel, ahol is 4 órajelbe került mindez.
Vajon én rontok el valamit, vagy tényleg ilyen kicsi a DMA hatékonysága ezen a procin??!

Ennyire nem mentem bele, azonban azonos órajel mellett az STM32F4xx nekem is gyorsabb, és nem csak a perifériáknál.
Viszont közben kíváncsiságképpen egy AT32F435RG-t is felraktam egy üres STM boardra. Ez már jobban muzsikált.
A RAM-ból futó (flash shadow) GD32F303 volt a leggyorsabb, de csak addig amíg az STM32F4 nem a CCM-ből vette az adatokat.

FIR (float32) teszt futási idő: (sajnos nem mindenhol azonos az órajel )

STM32F405 (168MHz, CCM) : 239ms
STM32F405 (168MHz) : 290 ms
GD32F303 (168MHz): 264 ms

GD32F303 (240MHz): 142 ms
AT32F403A (240MHz): 203ms
AT32F435 (240MHz): 185ms

AT32F403A (288MHz): 169ms
AT32F435 (288MHz): 154ms

AT32F435 (360MHz): 123ms

Eddig csak az SPI-t próbáltam DMA-val, ott nyilván nem lesz jelentős sebesség eltérés, mert az SPI fogja meghatározni a sebességet. A GPIO-hoz itt még nem próbáltam a DMA-t, csak az STM-en. A flexibilis DMA csatorna - periféria összerendelési lehetőség viszont tetszik, így nem fordulhat elő, hogy két periféria ütközne a DMA csatornán.
Ti milyen fejlesztőeszközben próbáltátok ki? Én az at32ide-ben jlink-et használva próbáltam. Ebben jól megy a debugger funkció is, bár lenne még mit fejleszteni a keretrendszeren.

Először az arduino felületet használtam, nem akartam telepíteni új programot. De sajnos az arduino támogatása még nagyon gyerekcipőben jár, alapjaiban is meg kellene változtatni. Igazából az eclipse platformokat mind próbáltam, de végül felraktam az at32ide-t én is.

Valójában a DMA sebessége és a programkód végrehajtási sebesség két külön világ! Az egyik az tisztán hardveres adottságok halmaza, a másiknál sok függ a körülményektől is jellemzően.
Pl lásd a felsorolt prociknál legjobb esetben is kb 4 órajel(FIFO-s lehetőségnél kicsit kevesebb is) kell a DMA-nak..., míg pl a Raspberry pi pico-nál a DMA-nak elég 1 órajel ugyanahhoz a művelethez!

Igen, SPI-nél egyértelmű, legalábbis a simánál, hogy ő fogja bekorlátozni a lehetőségeket, a néhány tucat Mbit sebesség nem gond egyik DMA-nak sem.
Nekem nagy meglepetés, hogy kb ugyanolyan M4-es mag esetén ilyen nagy különbséget tapasztaltam az STM és AT között DMA-nál...

Én VS19+VisualGDB -ben kezdtem vele az ismerkedést..., aztán pár hónap szünet után elővettem, és most KEIL környezetre akarok áttérni, így az alatt játszadozok. Egyelőre eléggé tetszik a kissé fapadosnak ható, de egyébként nagyon kényelmes környezet! Mindkét környezetben ST-Link-et használok....

Mivel mind a RAM, a FLASH, illetve a perifériák BUS-a közös ezért egyszerre nem férhet hozzá a DMA illetve a CPU magja. Ezt valamilyen módszerrel orvosolni kell. Ezért van hogy például a DMA használata csökkenti a mag végrehajtás sebességét is.
Persze mindez nem segít a problémádon, csak jeleztem, hogy nálam is hosszabbak a futási idők, amellett, hogy itt még a FLASH sem lassítja a folyamatot.

Bevallom, nem nézegettem a belső perifériák busz kiosztását, csak egy gyors teszt volt a cél.
Nyilván a teszt kedvéért akár azt is megtehetném, hogy altatom a vezérlőt, és akkor nem csak hogy nincs lassú flash-ből futtatás, de még a gyorsabb ram-ból történő is kimarad! Na de mire lenne jó egy ilyen értelmetlen teszt, hiszen nem az a cél, hogy a DMA perifériát kizárólagosan használva, mik a paraméterei, hanem azért lenne feladata is, amihez kell hogy fusson a mag is.
Adott esetben a RAM-ból futtatás lehet hogy gyorsíthat rajta..., ezt még kipróbálom, hogy a (most)"üres" main függvényt átpakolom RAM-ba, és megnézem ad e valami értékelhető különbséget?!
Azt viszont megköszönném, ha te is elvégeznél, saját beállításokkal, egy mem->port DMA átvitelt, lemérve, mennyi idő alatt végzi el?! Hátha csak én bénáztam el valamit....

Ezek a kínai vezérlők (AT32, GD32) nem FLASH-ből futtatják a programot, hanem a tartalmát induláskor átmásolja egy egyedi RAM területre. A program onnan fut. Ennek a mérete adott, jellemzően 256k. E felett valóban FLASH-ből fut a program, de ezt biztosan nem lépted át. Kérésedet max hétvégén tudom tesztelni, de szerintem hasonló eredményt fogok kapni.