Fórum témák

» Több friss téma
Fórum » ARM - Miértek hogyanok
 
Témaindító: gtk, idő: Jún 26, 2007
Lapozás: OK   155 / 177
(#) don_peter válasza Topi hozzászólására (») Feb 20, 2021 /
 
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.
(#) ha1drp válasza don_peter hozzászólására (») Feb 20, 2021 / 1
 
A CDC emulálja az RTS, DTR stb.. jeleket is. Legalábbis HAL alatt biztosan működik.
(#) Topi válasza don_peter hozzászólására (») Feb 20, 2021 / 1
 
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.
A hozzászólás módosítva: Feb 20, 2021
(#) don_peter válasza Topi hozzászólására (») Feb 21, 2021 /
 
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.
(#) vargham válasza don_peter hozzászólására (») Feb 21, 2021 / 1
 
Azok nem lábak... Virtuálisak. Szóval csak a szoftver által kezelendő flagek.
(#) don_peter válasza vargham hozzászólására (») Feb 21, 2021 /
 
Öhöm, öhhöm..
Utána nézek. Köszi.
(#) ha1drp válasza don_peter hozzászólására (») Feb 21, 2021 / 2
 
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.
(#) don_peter válasza ha1drp hozzászólására (») Feb 22, 2021 /
 
Í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.
(#) ha1drp válasza don_peter hozzászólására (») Feb 22, 2021 /
 
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.
(#) cross51 hozzászólása Feb 23, 2021 /
 
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)
(#) don_peter hozzászólása Feb 25, 2021 /
 
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:
  1. bajtok = 0x01, 0x02, 0x03, 0x04...stb
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:
  1. bajtok = 0x01, 0x00, 0x03, 0x04
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.
(#) Pethical válasza don_peter hozzászólására (») Feb 25, 2021 /
 
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?
(#) don_peter válasza Pethical hozzászólására (») Feb 26, 2021 /
 
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.
A hozzászólás módosítva: Feb 26, 2021
(#) Pethical válasza don_peter hozzászólására (») Feb 26, 2021 /
 
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.
(#) don_peter válasza Pethical hozzászólására (») Feb 26, 2021 /
 
Néhány perc és mutatom. Köszi előre is.
(#) don_peter válasza Pethical hozzászólására (») Feb 26, 2021 /
 
PC oldal:
  1. byte[] WriteBuf = new byte[3];
  2. WriteBuf[0] = 0xAA;
  3. WriteBuf[1] =  Convert.ToByte(rom_count);
  4. serialPort1.Write(WriteBuf, 0, 2);
  5. try
  6. {
  7.     serialPort1.Read(ReadBuf, 0, 1);
  8. }
  9. catch (TimeoutException)
  10. {
  11.     textBox1.Text += "\r\nKártya nem válaszol..";
  12.  
  13. }
  14. if (ReadBuf[0] == 0x0F)
  15. {
  16.      textBox1.Text += "\r\nKártya készen áll..";
  17. }
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.:
  1. WriteBuf[0] = 0x02;
  2. WriteBuf[1] = 0x00;
  3. WriteBuf[2] = 0x09;
  4. serialPort1.Write(WriteBuf, 0, 3);
  5. // try catch párost ezúttal nem illesztem be
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:
  1. static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)
  2. {
  3.     /* USER CODE BEGIN 6 */
  4.     USBD_CDC_SetRxBuffer(&hUsbDeviceFS, &Buf[0]);
  5.     USBD_CDC_ReceivePacket(&hUsbDeviceFS);
  6.     CDC_ReceiveCallBack(Buf, *Len);
  7.     return (USBD_OK);
  8.     /* USER CODE END 6 */
  9. }
  10. // CallBack eljárás
  11. /* USER CODE BEGIN 4 */
  12. void CDC_ReceiveCallBack(uint8_t* buf, uint16_t len)
  13. {
  14.         strncpy((char*)BuffRX, (char*)buf, len);
  15.         //CDC_Transmit_FS(buf, len);
  16. }
  17. /* USER CODE END 4 */

Ennyi az egész, és ezért is vagyok kicsit tanácstalan..
(#) vagnerjazon válasza don_peter hozzászólására (») Feb 26, 2021 / 2
 
És így mi kerül a 3. bájtba? 0x00?
Gondolom, igen, mert az strncpy elvileg így működik.
Idézet:
„If, after copying the terminating null character from src, count is not reached, additional null characters are written to dest until the total of count characters have been written.”

Próbáld ki memcpy-val.
(#) Pethical válasza vagnerjazon hozzászólására (») Feb 26, 2021 / 1
 
Bizony, az egy string művelet, a 0-nál azt hiszi, hogy vége van a szövegnek.
(#) don_peter válasza vagnerjazon hozzászólására (») Feb 26, 2021 /
 
Azt a pikuláját, hogy ezt nem vettem észre..
Köszi.
Már is minden a helyére került..
(#) Pethical válasza don_peter hozzászólására (») Feb 26, 2021 /
 
Gyanús volt, hogy stringkezelés van a dologban.
(#) vagnerjazon válasza don_peter hozzászólására (») Feb 26, 2021 /
 
Ö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.
(#) ha1drp válasza don_peter hozzászólására (») Feb 26, 2021 / 1
 
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.
(#) Pethical válasza vagnerjazon hozzászólására (») Feb 26, 2021 /
 
Ezért jó a fórum, lehetőség van a csapatmunkára.
(#) cross51 hozzászólása Márc 10, 2021 /
 
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?
(#) vargham válasza cross51 hozzászólására (») Márc 11, 2021 /
 
Idézet:
„STM32L451-es controller ami egy feladatot kicsit lassan csinál”

Mit csinál lassan?

Idézet:
„egy ilyen controller mennyire melegszik”

Nem nagyon. Sosem volt rá szükségem, hogy megmérjem. Kézzel éppenhogy langyosnak tűnik.
(#) cross51 válasza vargham hozzászólására (») Márc 11, 2021 /
 
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.

midi.png
    
(#) ha1drp válasza cross51 hozzászólására (») Márc 11, 2021 / 1
 
É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.
(#) Jonni hozzászólása Márc 13, 2021 /
 
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
(#) csatti2 válasza Jonni hozzászólására (») Márc 13, 2021 /
 
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
(#) Jonni válasza csatti2 hozzászólására (») Márc 13, 2021 /
 
Köszi. Tudsz olyat ahova nem elég ez a 32 bit?
Mondjuk nekem tuti elég lessz
Következő: »»   155 / 177
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem