Lehet hogy nem egészen értem mit akarsz mondani nekem.
Header?
Minden 64 byte eleje legyen header?
Ettől még nem lesz szinkronban a hardver a PC-vel.
Ilyenre gondolok pl.:
Küld egy adat bájtot a PC, amelyet fogad hardver nyugtáz és beáll a következő adatok fogadására.
PC megkapja a nyugtázást vagy is HW kész a következő adatok fogadására, kiküldi a fájl infókat, mondjuk a várható pontos hosszt.
HW fogadja, fel dolgozza majd nyugtázza és várja az adatokat.
PC megkezdi a küldést és 64 byte-os csomagokkal küldeni kezdi, persze minden kiküldött csomag után vár HW nyugtázására.

Na most van itt egy olyan gondom, hogy miszerint figyeljem mondjuk a HW-ban, hogy megérkezett a x adat. Hogy a feldolgozás csak akkor menjen végbe, ha beért az összes adat a csomagban. Nem szeretnék saját változót használni.
A natur USB CDC-t használom, de nincs olyan rutin vagy eljárás, amely azt figyeli hogy beérkezett egy megadott adat.. Itt tudni kell, hogy olyan is van, hogy csak pár bájtot várok, pl a fájl hosszát. Ilyenkor meg kellene adnom, hogy 3byte adat beérkezéséig várjon a HW, majd után ha beérkezett dolgozza fel és mehet a nyugtázás.
Nem tudom érthető e, a szinkronizáció miatt hamar szét csúszhat minden.

A CDC emulálja az RTS, DTR stb.. jeleket is. Legalábbis HAL alatt biztosan működik.

A handshake metódus ettől független. Csinálhatod szoftveresen, vagy CDC által emulált flow-control flagekkel is (DTR, RTS, ...).
De ha biztosra akarsz menni, akkor minden chunkot elláthatsz CRC-vel is, és a küldő oldal egyszerűen meg tudja ismételni a chunkot, ha nem jó a CRC, és a CRC visszaküldés maga az ACK.

Érdemes egy állapotgépet készíteni, hogy egyszerre (kvázi blockingként) legkevesebb CPU időt egye.

Sajnos DTR és RTS lábakat nem használom, így azok kiestek már a meglévő hardveren. Talán következőre. Most csak HAL van és szoftver.

Azok nem lábak... Virtuálisak. Szóval csak a szoftver által kezelendő flagek.

Öhöm, öhhöm..
Utána nézek. Köszi.

Ha HAL-t használsz akkor mi a problémád? Ha adat jött az "usbd_cdc_if.c" fájl tartalmazza a CDC_Receive_FS függvényt, amit neked kell bővíteni mi legyen, ha adat jött. Ha adatot küldesz azt a CDC_Transmit_FS meghívásával teheted. Minden mást a HAL megold.

Így kezelem, de jó lenne az USB saját változót használni csak nincs olyan ami pl. a be érkezett aktuális hoszt figyelné, amik vannak pedig nem működnek. Sajáttal is próbáltam úgy meg csúszás van, sokszor elég komoly amit nem értek. Mint ha akkor is számolnia mikor küldök vagy valami automatikus duma van.

Nem igazán értelek. A CDC_Receive_FS második paramétere (len) a beérkezett byte-ok száma. Ez lehet minimum egy, elletve a maximális érték (64, 128, stb.. amit a CUBEMX-nél beállítottál). Miután lekezelted a bejövő adatokat, nullázni kell az inputbuffert majd engedélyezni a következő csomagot. (Ezen utóbbiak bent vannak a template - ben, nem kell beírnod.) Az hogy hány byte érkezett az tulajdonképpen a "len"-ek összege.

Sziasztok!

don_peter:
Csinálsz egy header-t mint Topi írta, a header tartalmazhat bármit de legyen benne egy length tartalom a sizeof(Header) mindig ismert lesz 'IDLE'-ben vársz mindig egy header berkezését utána a header tartalma szerint átlép következő állapotba az állapotgép és olvasol addig amíg a length változó nem nulla, ha ez bekövetkezett megint vársz egy header-t.
A nyugtázásra két opciód van, vagy használod a handshake-et és addig a host nem küld adatot amíg foglalt a program vagy minden 64 byte után visszaküldesz egy 'OK' jelet és a host csak ez után küld új adatot, itt nem tudom, hogy a Topi által írt CRC miért fontos, hisz az USB is csinálja.
A második opciónak emlékeim szerint az a hátránya, hogy lehet, hogy te csak 2 byte-ot küldesz vissza de az az USB-n minimum 64 byte méretű lesz így a nyugtázással "sok" idő elmehet.

Saját kérdés:
Ha van egy int változó ami Mutex-al van zárolva a setterben, ha ennek az értékére írok egy gettert akkor ez az int változó atomikusnak számít vagy lockolni kell a getterben is?
És ugyanez az elképzelés csak IT-vel tehát IT piszkálja a változót a ciklus peddig csak getter-el fér hozzá akkor a getterben tiltani kell az IT-t vagy nem?
Továbbá ha a 32 bites atomikus akkor 8,16,64 az vagy nem?
(a 64 gondolom nem, de itt főleg a kisebb méretűkre szól a kérédés)

Köszi, srácok, elkezdtem megírni, de belefutottam egy ilyenbe és nem tudom, hogy a beállításaim hibásak ami CubeMX alapértelmezett USB CDC vagy valami nem kerek a driver-be vagy még valamit nekem külön be kell állítanom. Hozzáteszem, hogy ez régebben nem volt vagy nem tűnt fel mert a program jól kezelte.

PC-n írom a küldő programot és azt vettem észre vagy 1 hetes keresgélés és agyalás után, hogy a kiküldött byte-okat, rosszul kezeli az STM fogadó rész. (itt értsd úgy, hogy vagy én nem állottam be valamit) , mutatok egy példát: Ha mondjuk ezt így elküldöm, akkor fogadja az STM32F103RF, de ha így küldöm el, mert ügye az adat lehet simán ilyen is: akkor a megérkezik az első bájt és utána már nem érkezik több mert a 0x00-val azt hiszi lezárul az adat, vagy legalább is nem tölti fel a többi adatot a bufferbe.

Mi lehet az oka? Találkozott már valaki ilyennel?
Köszi előre is.

Valahol nem konvertálódik véletlen, vagy akarattal az adat stringgé, amit 0 terminál? Esetleg nem szövegként próbálod fogadni/küldeni?

PC oldalon byte tömbből a byte küldő rutinnal küldöm az adatokat. STM oldalról pedig a CDC alap funkcióját használom. Ha string ként küldök adatot az mind megjön, gondolom mert egyik sem az abszolút nulla vagy is le záró karakter. Egyelőre nem találom hogy mitől van ez.

Azt a pár sor kódot ami a küldést és fogadást csinálja meg tudod osztani velünk? Hátha abban látszik valami.

Néhány perc és mutatom. Köszi előre is.

PC oldal:
Ez máködik mert mind kettő bájt valamilyen értéket vesz fel, de nem véglezáró nullt.
A következő viszont már a fentebb említett hibát hozza.:Ez utóbbi az 1.-es index értékével lezárja az adatsorozatot. (lehet csak konfigurációs hiba, nem tudom)

STM felőli oldal meg az alap kicsit kiegészítve:
Ennyi az egész, és ezért is vagyok kicsit tanácstalan..

És így mi kerül a 3. bájtba? 0x00?
Gondolom, igen, mert az strncpy elvileg így működik.

Próbáld ki memcpy-val.

Bizony, az egy string művelet, a 0-nál azt hiszi, hogy vége van a szövegnek.

Azt a pikuláját, hogy ezt nem vettem észre..
Köszi.
Már is minden a helyére került..

Gyanús volt, hogy stringkezelés van a dologban.

Örülök, hogy működik. A jó irányba gyanakodás Pethical érdeme, én csak megláttam a kódot, és feltűnt.

Esetleg annyit még, hogy először a "CDC_ReceiveCallBack" legyen az első lépés (4 sorban). Mert jelen esetben előbb engedélyezed a következő csomagot, mielőtt kimásolnád az adatokat. Így az simán felülíródhat.

Ezért jó a fórum, lehetőség van a csapatmunkára.

Sziasztok!

Van egy STM32L451-es controller ami egy feladatot kicsit lassan csinál persze ebbe benne van, hogy még nem jó a kód rengetek optimalizálási lehetőséget vettem észre, de mivel az ár nem túlzottan lényeg így körbenéztem milyen controller van nagyobb frekin.

És találtam H7/F7-est 550 Mhz ami a 80 MHz-es képest már egy kicsit az ágyúval veréb kategória fölött van és inkább nyálcsorgatás, de ha ki lehet próbálni miért ne. A H730-as még olcsóbb is mint az L4-es néztem doksit és ha cache nélkül használom elvileg az összes perifériát bekapcsolva 170mA az áramfelvétele.

Melegedés szinten Θ_JA=43.8, ha Ta-nak mondjuk 30 °C feltételezek és Imax mondjuk 200 mA akkor TJ=Ta+(P*Θ_JA)~=60 °C ami nekem így elsőre kevésnek hangzik valakinek van tapasztalata, hogy egy ilyen controller mennyire melegszik és az a 60°C környéke valid?

Mit csinál lassan?


Nem nagyon. Sosem volt rá szükségem, hogy megmérjem. Kézzel éppenhogy langyosnak tűnik.

Egy MIDI vezérlőt csinálok ami enkódereket figyel és ledeket hajt meg (ez elképzelés könnyedsége véget csatoltam egy képet). A LED lényeg igazándiból 17 db SPI-s LED driver van (DM13A) ami 17*16 bit információt jelent.

Az első lépés az volt, hogy összeraktam az enkóder figyelést (TIMx_IT) egy enkóder körül 15 db LED van amit, ha csak 15 diszkrét érték van nehéz 127-ra felosztani úgyhogy azt találtam ki, hogy legyen SPI-n keresztül PWM, x buffer ki van töltve kitöltés adatokkal és DMAx_Channely_IT-re mikor kimegy a 17*16 bit akkor megy egy LATCH.

1. Na ez eddig szép és jó, megcsináltam a fényerőszabályzós részt működött, de a MIDI UART-ja már nem akart menni, mivel a DMA folyamatosan fogta a buszt és pörgette ki az adatokat ja és ráadásul 20 MHz-en megy az SPI úgyhogy a procinak sűrűn kell a LATCH-al foglalkoznia.
Erre az volt a megolds, hogy az SPI megkapta az SRAM2-őt és akkor ő busz foglalás nélkül tud menni a prociidőre meg az volt a megoldás kisebb beuffer majd ha az kimenet 10x ms delay egy majd egy TIM_IT visszakapcsolta a DMA-t.

2. A másik gond, hogy az a buffer amit a DMA kűld teljesen újra van mindig számolva, ha nagy a "felbontása" akkor sokat számol.

1. Sokkal effektívebb kihasználást érnék el ha pl 500µs-enéknt indítok el egy átvitelt, mivel ez 500µ*2^5=16ms így ez még tűrhető és így kisebb lenne a buffer mint amit eddig használtam és jóval elosztottabb lenne az időkihasználás

2. Egyrész jelenleg "nagy" bufferek vannak másrészt ez sem a legoptimálisabb lett, mivel double buffering van így mindig mindent újraszámol a controller ami "sok" idő lehet ezt fogom átírni, úgy ha az egyik buffer cserélődik akkor a másik értékei bemásolódnak és csak az lesz újra számolva ami mondjuk egy enkóder megtekerésére szükséges (másolni gyorsabb, mint számolni)

Jelenleg amúgy, hogy 0 optimalizáció felé van állítva a fordító akkor működik szépen csak azt elég nehéz debuggolni.
De alapvetően ezen két rész okozta a gondot, csak nyálcsorgatás miatt néztem az "ágyút" és azért elvárás magam felé is,hogy ezt nem egy akkora hűha, illenék tudni 80x MHz-en megoldani csak mondom rossz a HW kihasználás.

Melegedés:
Jó kicsit túl érdeklődően írtam, ha kézzel megfogható hűtés nélkül akkor tök jó.
Csak azért kérdeztem mert PIC32MZ-vel (200 MHz) kicsit jobban melegedett mint kellet volna.

Én is egy kicsit nehezen értelmeztem amit leírtál, így konkrétan segíteni szerintem nem fogunk tudni, azonban a programkódoddal lehet a gond, mert ilyen kontrollerrel 40MHz-es SPI TFT kijelzőkön játékot lehet futtatni. Gondolom a LATCH aggaszt, az is megoldható egyébként processzoridő nélkül is, (interrupt, timer , comparator akár ) habár a kb. 50nS nem tűnik akkora gondnak.
Ha jól tudom ebben a vezérlőben is több DMA van, érdemes azt kihasználni. E mellett meglepő, hogy egy DMA ennyire fogná a buszt.
Elsőre úgy tűnik, hogy valamit nem jól csinálsz, vagy rossz az órajel, nincs engedélyezve az FP (ha egyáltalán használod). Valamelyik kódrészlet feleslegesen foglalja a processzort stb...

Az -o0 optimalizálást debuggoláshoz használjuk inkább, a kész programot már illik optimalizálni.

A F7/H7 szerintem is teljesen rendben van, de az F4-hez képest komoly eltérések vannak, (pl CACHE , MPU) ami miatt sok minden dolgot meg kell hozzá tanulni.

Sziasztok.

Volna egy mikrovezérlővel kapcsolatos kérdésem. Igaz-e , hogy az arm cortex M0 csipp a leg kisebb fogyaztású? Mondjuk ha olyan helyen van használva ahol minden milliwatt számít

Ennél azért bonyolultabb a dolog. A modern mikrokontrollerekben szoktak lenni az energiagazdálkodást segítő funkciók (a nem használt perifériák lekapcsolása, a CPU mag altatása), ezeken kívül pedig a fogyasztás jelentősen csökkenthető alacsonyabb működési frekvencia megválasztásával is.
Ezeken túl azonban érdemes valamely alacsony energiafogyasztásra optimalizált mikrokontrollert választani ha a fogyasztás kritikus fontosságú. Pl. STMikrónál az STM32L típusszámmal kezdődő mikrokontrollerek mind ilyenek. STM mikrokontrollerek áttekintése

Köszi. Tudsz olyat ahova nem elég ez a 32 bit?
Mondjuk nekem tuti elég lessz