Azért nem akarok nagyon vitába szállni a Visual Studios témában, mert kb. 5 éve próbáltam a VS + VisualGDB párost, nagyon mélyen akkor sem veséztem ki a funkcióit. Akkor nekem úgy tűnt, hogy a VS nem ad több mindent hozzá a dologhoz, mint egy nagyra nőtt szövegszerkesztőt némi Intellisense képességgel. Ha tévedtem, akkor bocs.

A VisualGDB szerintem szuper. Az pedig CSAK Visual Studiohoz létezik. Ami pedig nem rossz IDE. Úgyhogy, én elvagyok ezzel a kombinációval.

Munkaeszközöd?

Igen.

A klón Jlink-el csak óvatosan, mert a CubeIDE-vel nem biztos hogy fog menni (tudom nem is írtál erre vonatkozó szándékot). Nálam a klón Jlink a 6.3 verziós programjával hajlandó csak működni, a későbbi verzióknak nem tetszik a klón mivolta. A CubeIDE meg nem hajlandó a régi Jlink szoftverekkel együtt dolgozni. Én úgy oldottam meg, hogy a régi 9.3.0 verziós truestudiot használom, mert az hajlandó kommunikálni a 6.3-as Jlink programokkal. Szerencsére ez a régi truestudio is képes a mostani verziós 'Makefile' toolchain beállítással generált CubeMX projecteket beimportálni magának, bár első alkalommal kicsit nehézkes a dolog, mert a Symbols és az 'include directory' beállításokat kézzel kell hozzáadni.

A CubeIDE-ben még a saját maga által generált projektet sem tudtam hiba nélkül átvinni másik gépre. ST-linken kívül szerintem nem is kompatibilis más probe hardverrel. Az MCSDK (motor control SDK) projekt generálás/importálás pedig rémálom, csak igazi hardcore mazochistáknak ajánlom.

A J-link nagy előnye az RTT (Real-time transfer), ami a futás közben (debug megállítása nélkül) biztosít memória írás/olvasást, így pl. live variables-t, csak sajnos iszonyat drága. Ráadásul állandóan frissíteni akarja a firmware-t, ami persze állítólag jó eséllyel téglásítja a klónokat.

Azonban van egy ingyenes alternatívája, a probe-rs (Rustban íródott), amely nem GDB szervert használ, hanem saját megoldást. Ez támogatja az ST-linket, J-linket (szerintem a klónokat is), DAP-linket, Black Magic Probe-ot... Jól hangzik, de még nem sikerült kipróbálnom.
Ha van valakinek ezzel tapasztalata, kérem ne tartsa magában!

CubeMX generálta CMake projektekkel dolgozunk a munkahelyemen. Többen, több számítógépen is dolgozunk ugyanazon. Ide az kinél mi, VScode, VS+VGDB, CubeIDE, CLion. Mindegyik teljesen jól kezeli a projekteket.
A MCSDK az tényleg borzalom. Sajnos ott az ST saját dolgozói nem tartották magukat a más dolgozók által készített CubeMX követelményeihez.
CubeIDE jól működik J-Linkkel is.
Ha van STM32 devboardod, akkor van J-Linked is. A Segger ugyanis ad egy szoftvert (reflash), ami J-Linket csinál egy onboard ST-Linkből.
Minden Cortex-M CPU beépített debug szolgáltatása, hogy a debugger hozzáfér a memóriához a CPU leállítása nélkül. Így a target halt nélküli, élő memórianézet elérhető CubeIDE-ben ST-Link használatával is. Ha jól tudom, a J-Link adatátvitele gyorsabb.

Az MX szerintem nem annyira rossz, mint a CubeIDE és az MCSDK. Már gondolkodtam azon, hogy nálam lehet, hogy egy láthatatlan gonosz kis manó mindig elront valamit, mert a CubeIDE magától nem lehet ennyire sz@r.
A CubeIDE-ben már tényleg van J-link beállítási lehetőség, rosszul tudtam! Butított j-link firmware-t rá lehet tölteni ST dev. boardokra, amin van -talán- ST-linkV1-es hardver, de ott a licenc csak annak a boardnak a debugját engedi, más boardot nem enged, és azt is csak lassan: J-link 15-50MHz, ST-link V1 talán 4 MHz, persze ettől még használható.
A Cortex-M engedi ugyan futás közben a memória kiolvasását, de a GDB ezt nem használja. Ezért a GDB-s (pl. OpenOCD) debug szoftveres megoldások nem tudnak pl. live variables-t, ott mindig léptetgetni kell, ha a változó értékét akarod folyamatosan figyelni, de akkor lőttek a megszakításoknak. Mások (pl. VisualGDB, Segger J-link, EBlink) nem, vagy nem teljesen a GDB-t használják, ott működnek az emelt szintű debug szolgáltatások.
Az ST saját GDB alapú szervert használ. Igazából a fejlesztésüknek köszönhetően sikerült lassítani rajta, és egy kissé sánta Live variables-t bevezetni. Tudtommal nem használ RTT-t, ami folyamatos és gyors adatátvitelt tenne lehetővé pl. a memória futás közbeni kiolvasásához, hanem helyette meg-megszakítják a futást, és ekkor olvassák a változók értékeit.
Azt nem tudom, hogy ez mennyire üzembiztos, de tegnap CubeIDE-ben még egy megszakításban lévő breakpointot sem sikerült vele megtalálnom. Bár lehet, hogy csak azt a kis manót kéne fülöncsípnem!

Még annyival egészíteném ki az előző hozzászólásomat, hogy J-linkre átflashelt ST-link szerintem nem tudja a legjobb feature-t, az RTT-t. Így marad a nagyobb stabilitású, de alap J-link szolgáltatás.

Én úgy tudom, nem állítja meg. Használjuk egy csomó időkritikus (HW-t működtető, megszakításokat használó) kód globális változóinak figyelésére, és működik jól. Tudtommal a globális változókat képes target halt nélkül olvasni/írni.
Az ST-Link V3 24 MHz működésre is képes.
Mindezt csak kiegészítésként írom. Nem vitatom, hogy a Segger J-Link szuper debugger. Talán a legjobb.

A build log alapján benne kellene lennie a debug symboloknak. Lövésem sincs miért nem működik.

Elnézést a kései válaszért, elég sűrű volt a hét.

Köszi mindenesetre. Én már feladtam. Saját projektekhez az Embitz simán használható továbbra is, az ST lib-es projekteket pedig igyekszem kerülni, ha lehet.
Vargham: lehet, hogy én tévedek, és a GDB-t jobban átvariálták, mint hittem. Próbálom ezt az STCube rendszer-szörnyeteget megszokni, mert egy projekthez használnom kell, és a fórumon olvasott vélemények azt mutatják, hogy van remény. Bár az ST marketinges gyomrosával, amelyben szétreklámozzák a ZeST funkciót (MCSDK kellék), aztán közlik, hogy csak kiválasztottaknak biztosítják, eléggé lejáratták magukat előttem.
Apropó, CubeIDE dark módban hol kell a függőleges folder fehér csík színét (amiben összecsukhatók az egyes függvények) valami kevésbé világosra változtatni. A Preferences->Appearence-ben már mindent átszíneztem, de még mindig beleég a retinámba a fehér csík, mint plazma TV-be a TV2 logo.

Megjelent az Embitz 2.65-ös verziója az EBlink 6.21-gyel, tehát mindkettő új verziót kapott.
"
Nem tudom igazából, hogy a debug gondom kapcsán mi változott, de most megy a debug -dwarf-4 kapcsolóval és a beépített GCC15.2-vel.

Milyen debuggert STM32-re?

Eddig AVR-t használtam az otthoni projekteken, viszont szeretnék váltani ARM-ra.

Találtam egy jó oldalt, ahol jól körüljárják milyen is az egyes vendor terméke:Bővebben: Link Ez alapján az STM-re esett a választás.

Milyen debuggert javasoltok?

Ezt néztem ki: STLINK-V3SET

Személy szerint annak vagyok a híve, hogy érdemes egyszer venni egy jót, így ha van esetleg jobb debugger, amire érdemes lehet beruházni arra abszolút nyitott vagyok. Nyilván nem több százezresre gondolok.

Nem akarlak lebeszélni téged a V3-as vételéről..., csak megjegyzem gondolkodásképpen, mióta kb 6-7 éve áttértem az ST-kre, kezdettől fogva egy filléres V2-es kínai klónnal használom. És még soha nem éreztem, hogy feltétlenül több kellene... A 3-as persze gyorsabb és többet is tud...de kérdés, kell e az neked...?!

Valószínűleg fogsz devboardokat használni. Úgy a leggyorsabb a különböző MCUk megismerése, a prototipizálás. A legkisebb méretűek kivételével az összes STM32 devboaron, mint Nucleo, Discovery, stb. van debugger. A régebbieken V2, az újabbakon V3. Ezzel pedig nem csak az onboard targetet tudod programozni, hanem bármelyiket.
V2 és V3 között amúgy főleg sebességben van különbség, illetve a V3nak van egy halom, PCről elérhető perifériája, mint GPIO, CAN, SPI, I²C, stb. HIL teszteknél jól tud jönni, de általában nincs rá szükség.

Mi is próbálkoztunk a munkahelyemen legolcsóbb, pendrive formájúakkal (~50 darab). Valamennyire használhatóak, de annyira nem jók. A megfelelő funkcionalitáshoz át kell építeni őket.
1. Teljesen véletlenszerűen fel szoktak forrósodni, és meghalnak. Van amelyik azonnal, van amelyik néhány használat után, és van amelyik már évek óta bírja. Szétszedve kiderült, hogy STM32F103 helyett STM32F100 MCU van bennük. Amiben hivatalosan nincs is USB periféria. Nyilván ugyanaz a belseje mindnek, és amelyik átmegy a gyártónál a teszten, az USBs, amelyik nem, az lesz az olcsóbb. A kínai ezt tudja, és az olcsóbbal szereli. Aztán az eszköz vagy működik, vagy nem.
2. Nem lehet állítani a cél MCUnak megfelelő IO feszültséget, fixen 3.3 voltról működik. A legtöbbször mondjuk ez elég.
3. Nincs kivezetve a reset. Ami a tüskesoron látszik, az az STM8-hoz való reset, nem az STM32-höz. Így low power targetet nem lehet debuggolni, mert reset nélkül nem tudja felébreszteni.
4. Nincs kivezetve a SWO. Így elestél a target nagysebességű, MCU-t alig terhelő monitorozásától.
5. Nincs UART. Köthetsz a cél MCUra egy plusz USB/UART adapter.
6. Nincs USB mass storage. Engem ez nem zavar, de sokan szeretik a drag and drop programozás lehetőségét.

Van klónja a teljes méretű ST-Link V2-nek is. Arra nem vonatkoznak a fentiek, teljesen jól használható. Csak éppen ugyanannyiba kerül, mint itthon az eredeti.

A legpraktikusabb venn pár Nucleo-t, és használni a ráépített debuggert. Olcsó, azonnal működik, használható külső targethez is.

Nekem két egyforma(vagy annak tűnő), különböző helyről vásárolt példányom van, semmit sem kellett vele tennem, évek óta megy gond nélkül mind a kettő(STM32F101 van legalábbis az egyikben)! Nem is értem, normál használatot feltételezve, hogyan lehet elrontani egy ilyet...?!
Általában van saját tápja minden készüléknek. Ha kikötöd a debuger tápvonalát, mehet kisebb feszültséggel is..., mondjuk elég ritkán lehet erre szükség. Nekem még egyszer sem kellett...
A reset-et sose értettem. Van benne soft reset, mikor kell ennél több?
Az swo, uart, mass storage, mind-mind kényelmi funkciók, amiknek a valódi értéke a 0 felé konvergál, inkább marketing okokból születtek szerintem, semmint valós, létfontosságú igényből. Valamivel el kell adni az újabb típusokat is...
Nekem személy szerint a debuger annyit jelent, meg tudom állítani a programot ahol szeretném, látom a változók értékeit, resetelni tudom.... Ennél többre csak ritkán van szükség! Ha eljut odáig egy projekt, hogy kellene egy soros port, az nyilván azért van, mert eleve annak használatát terveztem bele, akkor fogok egy usb-uart átalakítót, és bekötöm! Nem a debugertől várom ezt el...
Van itthon kb két db eredeti Nucleo panelem is, amikről használhatnám a rajtuk lévő st-linket, valamint vagy egy eredeti jlink debugerem is. Még a dobozából sem vettem ki...., sokkal kényelmesebb a filléres st-link használata....

Köszönöm a válaszokat!

Személy szerint nem vagyok a klónok híve. Nincs meg a bizadalmam, hogy minden feature úgy működik ahogy kell. Ettől függetlenül lehet, hogy a valóságban más a helyzet, de valahogy a gyártói megoldás mindig bonyolultabb NYÁK-t eredményez, aminek szerintem oka van.

Az árról azt gondolom, hogy ha maradok az STM vonalon a jövőben, akkor a jövőből nézve a kb 10k HUF difi nem tűnik akkora nagy költségnek.

Még nagyon régen az NXP tetszett és vettem egy ilyet: LPCXpresso Baseboard (pofátlanul olcsó volt amikor még lehetett kapni és van hozzá 1-1 hozzávaló NXP-s modul) és erre tervezek most éppen egy STM-es modult. Nem terveztem Nucleo-t venni, bár kétségtelen hogy jó cucc és jó árban van.

Én azért ránéznék a CH32-re is, ha csak hobbiproject eléggé pénztárca barát.

Ha szeretsz forrasztgatni, egy kis zsugorcső, néhány vezeték, és teljes értékű V3-at kapsz:V3mods
Az ára kb. 4ezer Ft. Én most ezt használom. Azokat a kínai "Dupont" csatlakozókat raktam rá, ami rámegy minden 2,54-es tördelhető tüskesorra.
Korábban több klón V2-őt használtam, használok néha most is. Kettő tönkrement az évek során, szerintem ESD miatt. Vigyázni kell velük, a 3,3V-os csatlakozás nem teljesen kompatibilis a gyáriakkal, de ez csak egy kis odafigyelést igényel.
Azt nem tudom, hogy az STMCubeIDE mennyire szereti a klónokat, de a VSCode-os extension-öknek (pl. Cortex Debug) nincs gondja a klónokkal.
ARM vonalon létezik még a CMSIS DAP debug probe. Ez is filléres cucc. Előnye, hogy nem STM specifikus, viszont még csak most van terjedőben, kevés IDE támogatja.

Vagy ez.

Szia,

Vegyél ilyet,
STLINK-V3MINIE vagy STLINK-V3MODS olcsó és ugyanazt tudja mint a V3SET.
Kapásból vegyél 3db-ot, akkor is felel árban kijössz.
Én ki kábeleztem egy sima 2.54es tüskesorra.

STM32 vs NXP

Sziasztok!
STM32 után ismerkednék az NXP mikrokontrollereivel is. Kicsit elegem lett az STM dokumentáció minőségével (pl. az ST MCU adatlapok nem mások, mint regiszter szótárak, de hogyan kellene azokat használni, arról majdnem semmi), vagy pl. a periféria kötöttségek: egy perifériának van max. egy remap, és kész. Ugyanígy a DMA hozzárendelés is elég kötött. Ha kisebb projektet raksz össze, ez fel sem tűnik, de amikor már komolyabb cuccot kell építeni, akkor már jönnek a fájdalmas felszisszenések - legalábbis nálam.
Olvasgatva az NXP-ről, rugalmasabbnak tűnik. Hogy konkrétabb is legyek, használt már valaki MCXN családot, vagy a PowerQuad nevű beépített koprocesszort (mátrix és vektorműveletek, nemcsak CORDIC). A HAL túlzott absztrakciója helyett inkább assemblyben optimalizált library-k. Az iparban talán jobban elterjedt, mint az STM cuccai pl. sensorless FOC vezérlésnél.
Tudom, hogy időről-időre felvetődnek ilyen kérdések, és nehéz összehasonlítani, de folyamatosan jelennek meg új családok, és én kíváncsi vagyok NXP-ben jártasabbak véleményére.
A 2 dolláros bluepill klón talán még nincs náluk, de mintha nyitnának a hobbisták felé, 10ezerért már vannak új dev.boardok.

Szia!
Stm32 nél ne csak a datasheetet nézd hanem a reference manualt. Ott van részletesen leírva.

Köszi, de a kb. 10 év alatt mióta STM32-vel foglalkozom nézem a reference, programming manual-okat, az errata-t és az application notes-okat is. Mindezzel együtt a dokumentáció minősége nem győzött meg. Ennél a francia-olasz cégnél kiváló a marketing, kevésbé jó szerintem a hardver-tervezés, és kritikán aluli a szoftver-tervezés. Ettől még persze használok STM gyártmányú mikrokontrollereket a jövőben is, mert óriási a választék, de most egy kicsit megfáradtam a küzdelemben.

Melyik családot nézted ki az NXP-ből? Úgy emlékszem, hogy az LPC a saját sorozata és van a néhány éve megvett Freescale vagy gyártói termékei.

Az új STM32 sorozatoknál - mint pl. G0 - is szembesültél ezekkel a problémákkal?

Az LPC-ket valamikor a Philips készítette és voltak apró, olcsó, népszerű kártyái (pl. az Olimex-től LPC2138-cal, bootloaderrel, a SparkFun is forgalmazta). Csak annak már bő két évtizede. : -) Nem tudom, azóta mi a helyzet.

Leszámítva persze azt az apróságot, hogy Philips a régi formájában már nem létezik --> NXP.

Az NXP-től az MCXN947-et választottam, vettem belőle egy gyári dev.board-ot ( csak még nem érkezett meg a mousertől az amerikai hóhelyzet miatt).
Két MCU (M33) mag - ha már lúd, legyen kövér! Van mellette egy PowerQuad nevű matematikai blokk, mint a CORDIC az STM-nél, csak ez többet tud.
Ez állítólag egy viszonylag új család, a régi LPC-s vonalat olvasztja egybe a Freescale-es vonallal.
Sajnos az NXP-nek is van Eclipse-es IDE-je, de használhatóbbnak tűnik, mint a CubeIDE dupla menüje, és van neki is VSCode-os extension-je.