Úgy kell megírni a linker szkriptet, hogy arra a területre ne generáljon.

"Tudja valaki, hogy mi történt az Embitz.org-gal? "
Néhány napja megjelent az EmBitz 2.0 és a jelek szerint a forum is működik.
Mivel én a korábbi verziót sem használtam (meg a mostanit sem) így többet nem tudok róla mondani.

Már feltelepítettem, de még nem teszteltem az új funkciókat. Kívülről semmi nem látszik, ugyanúgy néz ki. Debug-ban erősödött a leírás szerint.
Most VSCode-ot használok, de ha ez jobb debugban, visszatérek az avitt kinézet ellenére is.

Nekem a VisualGDB debug funkcionalitása jön be a legjobban.

A VisualGDB kb. 40eFt 1 éves időszakra. Az egy év letelte után még használható, csak nem jön rá frissítés, vagy mindenképp évente kell vásárolni rá licencet? - ami ha jól tudom kb. fele annyi az induló árnak.

Használható, csak nem frissül.

Kipróbáltam a 2.0-t. Meglepően gyors. A fordítás is, a debuggolás pedig különösen. Az ST-Linkhez egyedi, Eblink nevű debug programot használ. Ez gyors, és tud mindent: live variables, data breakpoints, EBmonitor. Utóbbi egy a Printf()-et átirányító monitor, amely soros hw nélkül magán az stlinken keresztül fogad és küld üzeneteket. Olyasmi, mint a Segger RTT.
A debugger single step módban gyorsabban reagál, mint pl a Keil&jlink páros, amivel dolgozom.
Én tipikusan STM uC-ket programozok C-ben. Egyelőre nincs CubeMX import, a szerző szerint nemsokára elkészül. Kézzel pár perc importálni a fájlokat.

Én elsősorban Keil-lel dolgozom, néha PlatformIO-val, ha Arduino-val játszom. Debuggolni Keil-ben. néha Ozone-ban szoktam, az Eblink meglepő módon mindkettőnél gyorsabb.

A kinézete elavult, mondjuk a Keil se valami modern. Ha kívánságműsor lenne, hobby célra a VSCode-hoz szeretnék Eblink-et, de úgy, hogy a live variables is működjön. (anélkül simán be lehet tenni)

Sziasztok!
STM32F103C8 72Mhz. Legegyszerűbb port billegtetés. EmBitz2.0 STLinkV2.0 programozó.
Kérdésem: miért csak 972kHz a kimeneti frekvencia ?
Ettől többet kellene tudnia, nem?
Órajel beállítás kellene neki valami?
Itt a kód:

Másold ide a clock init kódrészt is!

Ennyi van a programban. Honnan tudom előszedni a clock init részt ?

Megírod.

Nézd meg, hogy mi van a GPIO_SetBits és GPIO_ResetBits függvényekben. Lehet hogy több sor is van, ezért lassú a végrehajtás+függvény hívás és visszatérés. Ha gyorsabbat szeretnél, írd át úgy, hogy a GPIO regisztereket kezeled közvetlenül.

A reset meg ugyanez csak BRR-el.

Ez alapján állítottam be: (csak a Main Clock Setup részt vedd figyelembe)
Bővebben: Link

Ha a 72Mhz-s rész átállítom 36Mhz-re, akkor tényleg feleződik a kimenő frekvencia. Tehát elméletileg tényleg 72MHz-en fut.
De nekem kevés a 910kHz-es kimenő jel. Gyorsabb kell. Hogyan ?

Ha csak a szükséges sorokat írod be, függvény hívás nélkül, akkor lényegesen gyorsabb:

While(1){
GPIOC->BRR = GPIO_PIN_13;
GPIOC->BSRR = GPIO_PIN_13;
}

Megnéztem, nálam 292nsec, 3.425MHz a fenti kóddal.
A uC 72MHz-re van állítva a HAL függvényekkel.

Érdemes használni a HAL könyvtárat és az STM32CubeMX-et, sokkal kényelmesebb, mint kézzel kitöltögetni mindent.

Assemblyben még lehet faragni ezen is.

Az assembly használata mellett tovább lehet gyorsítani úgy is, hogy RAM területre lehet másolni a kódot, és ott futtatni. A RAM elérés gyorsabb, mint a flash, nincs wait state.

További gyorsításra DMA használata ad lehetőséget, vagy timer kimenet.

Köszi.
Csak a fenti módosítással 3x lett a frekvencia.
Így 2,87MHz lett a kimenő freki.
Az órajelet a fenti Link Main Clock Setup szerint lett beállítva.

Érdekes, hogy nem pont annyi, mint az enyém. A lehetséges okok:
- nem ugyanakkora nálad az órajel (az enyém 72MHz-re van állítva
- más típusú hamisítványaink vannak
Az utóbbi években gyakorlatilag lehetetlen volt valódi ST gyártmányú uC-vel BluePill boardot venni. Én egy olyanon futtattam, amelyre STM van írva, de biztosan hamis, mivel a chip ID nem egyezik, és emiatt az STLinkv3 nem is hajlandó szóba állni vele. JLinkkel vagy Stlinkv2-vel tudom debuggolni.

Kíváncsiságból kipróbáltam egy eredeti STM32-n is, 2.877MHz, pont mint a tiéd.

Némelyik klón, pl. a GD32 alapból ram-ban futtat, megspórolja a flash wait state-eket. Érdekes cucc, két chip van a tokban, egy külön flash tartalmazza a kódot, és ezt reset után átmásolja RAM-ba, majd ott fut.

Bekapcsolt -o3 optimalizálással 11.99MHz az eredetin.
A klónon 9.59MHz, és ami meglepő, egy rövid - egy hosszabb impulzus. Valószínűleg pre-fetch van a magban, és nem jól jön ki az optimalizált kóddal.

Játszottam egy kicsit az Embitz 2-vel. Nem tapasztaltam hibát, szépen működik. Az EBMonitor ügyes szolgáltatás, külön vezeték és soros port nélkül lehet üzeneteket kiírni. A stringeket \n -nel le kell zárni, különben nem megy át azonnal az üzenet, összevárja amíg megtelik valami puffer. Kb. ugyanaz, mint a Segger RTT, csak ez stlink-kel dolgozik. Két irányú, teszteléshez lehet vele CLI-t írni.
Sajnos a kinézete nagyon avítt, a kód szerkesztő elég egyszerű (vagy nem jöttem rá mindenre), a debuggere viszont kiváló.

Akkor ma is tanultunk valamit.
Úgy döntöttem, hogy mivel saját magamnak fogok csinálni. Egy darabos cucc, visszatérek a jó öreg ASM-ez és ATMega16 illetve 32-höz a kódméret miatt. Ott pontosan ki tudom számolni, hogy mikor mit csinál, nincs ilyen olyan optimalizáció,prefetch, stb... JTAG-on debugolom és programozom.

Nagyon komoly előnyei vannak az ARM-oknak, nem biztos hogy érdemes visszalépni. Más világ, sokkal jobban kell támaszkodni kész kód szegmensekre, de a lehetőségek is összehasonlíthatatlanul jobbak, olcsón. Sokoldalúbb, kidolgozottabb perifériák, nagyobb sebesség, több ram, több flash. Nem gond, ha floating point-ban kell valós időben adattömeget darálni, vagy sok szálat futtatni.
Én sokat programoztam assemblyben 8 biteseket, de ma már a legegyszerűbb feladat esetén se venném elő őket.

Az ARM és a C nem bitbangelésre való... Mivel nem írtad mi a feladat, így nem tudunk segíteni.

Ezt én egy kicsit túlzásnak tartom! Nem baj ha te nem veszed elő, de azért a 8 biteseknek is megvan a maguk helye a világban!
Nekem van olyan projektem ami ATinyre épül, oda az való, bőven elegendő, és már egy Mega sem nagyon férne el azon 1,5 cm2 nyákon...

Van 8 lábú ARM is...
Árkülönbség még van egy kicsi, de az már csak milliós gyártásnál számít.
Kisebb szériánál sokkal többet számít a fejlesztési, továbbfejlesztési és hibakeresési idő.

Egy 640x240 LCD vezérlése lenne a feladat. 8 bit és vezérlő jelek.

Egy évig kapsz új verziót, igazándiból ez nem is lenne gond, ha az összes VS-hez használható lenne, de ha jön ki új VS akkor ahhoz kell új verzió.

Ha van egyetemista ismerősöd rajza keresztül van 50% discount valamint ha folytatod a licence-t akkor is van 50% discount.

Vargham-al mindig egyetértünk ebben, jobb IDE nincs szerintem controller-hez, talán a uVision-ban van néhány funkció ami csak ott érhető el, de amúgy ezt leszámítva szerintem az uVision használhatatlan.