Tudnál adni linkeket hogyan lehet VsCode-ot beállítani stm32-rei?

Itt egy korábbi hozzászólásom a témában. Mivel a linkek azóta elévültek itt vannak újak (szintén időzárasak).

Minta projekt, telepítési leírással.
Toolchain-em. Elég nagy, az internetről már frissebb verziók is let... kell.
Egy korábbi projektem, amit Atollic-ról átvittem VSCode-ra. Ezt ne nagyon osszátok tovább, mert lehetnek benne olyan könyvtárak stb., amit elméletileg csak a weblapjukról szabadna tovább terjeszteni. Egyébként fent van githubon csak nem ilyen teljes formában. Git-et is telepíteni kell a fordításához. A win32-es szimulátort elméletileg bárki lefordíthatja belőle, az vas nélkül is működik (vezérlés billentyűzettel 1-5-ig gombok [1 piros, 2 fehér, 3 zöld], enter, fel/le). Ez elég jól bemutatja a platformfüggetlen lehetőségeit a VSCode-nak.

Köszönöm szépen, áttanulmányozom.

Szia!
A VSCode-hoz írtak már kiegészítőt, amivel alkalmassá tehető STM32-vel történő munkára: PlatformIO, a VSCode-ból telepíthető.
Van benne debug is, de amikor én néhány hónapja próbáltam, akkor ez nálam még nem működött tökéletesen. Persze lehet, hogy azóta javítottak rajta.
Az ST-link-et is ismeri.
Egy próbát megér. Példaprogramok is vannak benne.

Tetszőleges STM32 MCU-t tudok PlatformIOval használni? CubeMX generálta projektet? Tudok választani a HAL és az LL driverek között?

Nem használom aktívan, így nem ismerem mélyebben. Ezért is írtam, hogy egy próbát megér.

A példa programok között van HAL, LL, libopencm3, mbed, stm32cube, zephyr. Külön viszont nem lehet kiválasztani ilyeneket egy projekt-wizard keretében, szóval szerintem némileg kézzel is kell kalapálni egy-egy projektet. Ráadásul nem MCU-t, hanem board-ot választhatsz egy projekthez.

Ezek miatt nem zártam a szívembe a VSCode+PlatformIO-t, és mert json és ini file-okkal operál, amiket meg kell ismerni. Azonban azt nem gondolnám, hogy egy kis munkával ne lehetne bármelyik STM32 MCU-t alkalmazni.
Az viszont vitathatatlan, hogy rövid telepítés után már fordítja és ST-linken keresztül fel is tölti a programot (és elvileg debugolni is tud)
Szóval ízlések és pofonok...

Én a CubeMX által generált projektet Visual Studioban használom VisualGDB pluginnal. Makefile alapú a projekt, simán lefordítja a Linuxos build server.
Csak most felmerült, hogy jó lenne a debug meg a trace Linux alatt is. Elkezdtem nézelődni, hogy mivel lehetne.

A JSON az szinte megkerulhetetlen manapsag es eleg egyszeru, erdemes atnezni.
A (VS)code es a platformio eleg gyorsan fejlodik, mar egesz elfogadhato. En mondjuk tobbnyire AVR-hez hasznalom linux alatt.

Uraim, fel tudna valaki világosítani, hogy ez a várakozó ciklus miért nem jó?PIC esetében ezt használom, UART vagy USB CDC adat várakozáshoz és működik rendesen, de az ARM (STM32F103) nem szereti, beragad a ciklusba. Előre is köszi a segítséget.

Szia,
RXCount értéke mitől változik? Mennyiről indul?
Szerintem így kéne:

1. Ha IRQ-ban módosítod az RXCount értékét, akkor volatile legyen.
2. Nézd meg az lss/list fájlt, hogy hogyan néz ki ASM-ben a kigenerált kód.
3. Ha rosszul fordítja, akkor előbb -Os próba
4. Ha úgy sem, akkor:

Az olvasás rutin implementálja..

Köszi, szerintem ez volt gond, mármint a volatile lemaradt. azt hittem az extern elég, de nem volt elég. Köszi.

Srácok, újabb agybajban vagyok. STM32F103-as MCU-t használok és nyilván már a friss STM32CubeMX-ben generáltam le az alapot. USB CDC-t használnék és nagyobb mint 64bájtos csomagokat küldenék át. Konkrétan 256byte-os csomagokat. Az adatátvitelre a gyári rutinokat használom, de nem értem mi ez a 64byte-os csomag határ. esetleg tudnátok segíteni, hogy ezt meg e lehet kerülni vagy az USB ezen 64byte-os csomagokkal dolgozik és ez behatárolja nekem az átvitelt?

Fullspeed (FS) USB esetén a bulk endpoint csomagmérete maximum 64 bájt lehet "default"-ban (wMaxPacketSize). Ha nagyobb adatot akarsz küldeni, akkor szét kell szedni chunkokra, és külön-külön küldeni.
USB2.0 specifikáció szerint 64, 32, 16, 8 bájt lehet a packet size.

Ha el akarsz térni a szokványos USB CDC-től, arra is van lehetőséged, de a descriptort is át kell írnod, közölnöd kell a host-tal, hogy nálad wMaxPacketSize az mondjuk 256 bájt.

Azért mondom, hogy "default", mert adódhat, hogy a host controller nem tudja kezelni a nagyobb csomagméretet, mert nincs elég FIFO-ja hozzá. Tehát mindig hordoz kompatibilitási rizikót a nagyobb / jóval nagyobb packet size.

Szerk: Ha nagyon muszáj a 256 bájt, akkor lépj át High-speed USB-be a Full-speedről, de az már nem fog menni FS-USB hardverrel.

Tehát ha jelenleg 256byte-ot küldök ki egyszerre , akkor a az FS CDC 64byte-ot fogad és a többi kuka?

Ez a CubeMX drivertől is függ, nem nagyon ismerem, mert nem használom ezt a fajta egybegyúrt mókát, meg kell nézni az SDK forrását, mit csinál a bejövő adattal. Elképzelhető, hogy már alapból felszeleteli, de erről bővebben az tudna nyilatkozni, aki ismeri a CubeMX által generált kódokat.

Most már azon agyalok, hogyan tudok összetenni egy nagyobb tömböt a 64byte-os csomagokból. Van esetleg olyan változata a strncpy() rutinnak, amely megoldja a másolást mondjuk a tömb megadott pozíciójától? Meg tudom írni, de hátha van jobb megoldás, ami már kész is van. A 64byte-os csomag feldolgozása marha sok időt venne igénybe ugyan is 1MB adatokat akarok USB CDC-vel küldeni, majd ezt az adatot egy SPI memóriába kiírni.

Uraim, osztottam egy képet, tud esetleg valaki erre valamit mondani? Találkozott már valaki ezzel a hibával?

A hiba amit látunk, hogy az SPI (HAL) kommunikációval használt memória kiolvasásnál valamiért 1 byte-ot, tételesen a legelső vagy is a nulladik byte-ot nem használja fel, hanem egyel lejjebb tolja az adatokat. Miért lehet ez?
A memória a nulladik címtől 255-ig feltöltve 0-től 255-ig adattal, a képek buffer feltöltését mutatják.
Az SPI transzfer rutin gyári, nem piszkáltam bele.. Még...
Előre is köszi.

ui: stm32f103rf

Első körben legyél óvatos ezzel a fajta debug módszerrel. Kódon állsz meg, optimalizált fordítás esetén, gyári HAL libekkel, esetenként DMA-kkal.

Töréspontot haszontalan / direkt erre a célra létrehozott pontra tegyél, mert lehet hogy a debugger teljesen más adatokat lát, illetve Te látsz más adatokat még.

asm volatile("nop"); sort szúrj be, arra tedd a breakpointot, azt nem fogja kioptimalizálni, jobb eséllyel fogsz látni jó adatokat.

Másodsorban ellenőrizd le, hogy a sizeof(...) tényleg adott fordítási mód esetén biztosan 64 bájtot ad-e vissza. Akár úgy is, hogy beírod most tesztnek, hogy 64 hosszon töröljön.

Harmadsorban a memsethez (mivel void * ptr), add meg neki, hogy mi az a ptr amit adsz neki, ne kényszerítsd soha a fordítót automatikus pointerképzésre, arm-gcc és IAR is sokszor elvérzik benne.

vagy


Kisebb ARM-okat (M0, M3) főleg DMA és IRQ-k használata esetén LED-del (is) debugolj. Főleg ha rendellenességet tapasztalsz, akkor írj egy teszt rutint is, ami akkor kapcsol fel ha, akkor kapcsol le ha...

Nagyon fontos a jó debugolás, mert megtéveszted magad. Az IDE azt mutatja, hogy már a 164 sorban van, de közben az optimalizálás miatt egyáltalán nem ott vagy még. (B eset, hogy -O0-val dolgozz, de ott meg egy rakat cucc nem fog rendesen menni)

-0O optimalizáció, berakva és javítva az említettek, semmi sajna. Ugyan az a hiba. Mint ha a tömb első elemét nem venné figyelembe. Nem értem igazából miért van ez, pedig már kidebugoltam végig lépésről lépésre, egy bár látom, hol következik be a hiba, de annak okát nem látom és nem is értem.

100% biztos vagyok benne hogy ez valami gyári gyarlóság lesz. Csak nem értem mi a francért tolja el egyel lejeb a vett adatokat. Persze emiatt hiányzik az utolsó elem, majd a következő olvasásnál ugyan ez megismétlődik. Használhatatlan ebben a formában.

Még nincs benne, hogy [0], legalábbis amit feltettél kódrészletet, ott nincs.

De az miért kell? Az egész tömböt akarom törölni, vagy ezzel csak a tömb memória kezdőcímét akarod átadni? Megnézem, de szerintem nem lesz rá hatással mert az a törlés, és nekem az olvasásnál van gondom..

Semmi.. Tettem fel képet.

Ránézésre mindkét "memset" jó megoldás , függően az #include <stdio.h> -tól
A debugger a sor elejére mutat, lehet butaság, de léptesd tovább eggyel a sor végrehajtásához, hátha.

Ezt nem értem. Végig léptettem már 100szor, sőt kielemeztem minden gyári rutint és megtaláltam azt a részt ahol a hibát produkálja, tételesen azt a részt ahol pakolja befelé a bufferbe az vett adatokat. Csak azt nem tudom miért van a hiba, mert erre utaló rész nincs, csak egyszerűen átugorja az első elemet, passz hogy miért és hogy hol. Ami még érdekes számomra, hogy nem inkrementálással számolja a lépéseket, hanem dekrementálással. Vagy is 64-1 egészen gondolom nulláig. Viszont a buffer pedig 1-től tölti 63-ig. Érthetetlen egyelőre. Keresem továbbra is a hibát.

A fastmemread-es függvényt kellene látni,mert így a visszajövő adatokból nem fog menni,hogy mi is a gubanc.

Más nem jó lesz helyette a "for" ciklus is.

Az SPI flash olvasása, írása relatíve lassú az USB sebességéhez képest. Ott is lehet probléma, ráadásul a ráfutást még debuggolni is nehéz.

DE én is jártam már így egy H7-tel, a D2 SRAM tartományban. Ott próbaképpen lefoglaltam egy 256 byte hosszú tömböt a semmire (dummy), és megjavult. Ennek ellenére nem gondolom, hogy fordító hiba lenne.

Winbond SPI flashez én ezt használom: w25qxx
Fura, hogy a page, sector, block címzéhez nem címet, hanem sorszámot kell megadni, de nekem tökéletesen, hiba nélkül működik.

Ezzel sikerült akkor az összes környező problémát kiszűrni, most kell belemélyedni a függvényekbe. Fastmem read, stb.

Köszi srácok az ötletelést. Egy hiba volt még pedig az, hogy az olvasásnál mikor kiadjuk a parancsot aztán a 24bit-es címet, az ügye 3szor 1byte, után még + 1byte olvasást kell csinálni és csak azt követően jönnek a helyes adatok. Ez a dummy byte olvasás nekem nem volt a kódomban, pótolva azonnal a helyére került minden. Nesze neked 1 hét..

Örülök / örülünk hogy meglett a probléma

Annyi apró kis tanácsot adnék a jövőre nézve, hogy tudasd majd a tagokkal, hogy kódodnak mely része az ami hibakeresendő. Félreviheti az ötletelést, ha kiderül, hogy nem a mellékelt kódban "kell" hibát keresni, hanem tartalmaz teszteletlen alfüggvényeket, libeket.
Sokunk ha egyszer megír és tesztel egy libet valamihez, onnantól használja még sok más helyen is ugyan azt, ilyenkor ha valami nem megy, nem a legmélyéről kezdjük a hibakeresést, mert készpénznek vesszük, hogy az a függvény már tesztelt.

Illetve nagyon hasznos ilyenkor ráaggatni egy logikai analizátort, a Saleae analizátor program például nagyon hasznos. Ha másról nem, megbizonyosodsz róla, hogy nem memóriakezelési gondod van, hanem tényleg az közlekedik az SPI-on. Azonnal rátaláltál volna valószínűleg, hogy nem memóriakezelési probléma van