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   112 / 175
(#) Ivan93 válasza icserny hozzászólására (») Feb 10, 2018 /
 
Átfutottam a tartalomjegyzéket és elolvastam pár oldalt a GPIO fejezetből. Ezek alapján szerintem ez megfelelő könyv mind az alapok, az STM32 és a HAL megismeréséhez is. Köszönöm szépen!
(#) vargham válasza roleez hozzászólására (») Feb 10, 2018 /
 
Csak feltöltés nincs, de könnyen hozzáadhatod magad.
Tools menü
Configure tools...

  1. Name: Flash with ST-Link
  2. Executable: C:\Program Files (x86)\STMicroelectronics\STM32 ST-LINK Utility\ST-LINK Utility\ST-LINK_CLI.exe
  3. Parameters: -NoPrompt -c SWD -P "${TARGET_OUTPUT_DIR}${TARGET_OUTPUT_BASENAME}.hex" 0x08000000 -Q -V -Rst -Run
  4. Working directory: ${PROJECT_DIR}


Variálhatod a paramétereket, ahogy neked megfelelő. Lásd az ST-Link CLI dokumentációját.
(#) Lardy válasza icserny hozzászólására (») Feb 13, 2018 /
 
A könyvet én is megvettem, nagyon szuper.
Köszönöm szépen az ajánlást!
(#) cimopata hozzászólása Feb 14, 2018 /
 
Üdv.

Belefutottam egy elég idegesítő problémába és nem tudom mit kezdjek vele.
Szokásos STM32F030, USART 9600 as baudra va beállítva de tudnám állítani 38400-ra is.
9600-on ment minden jól de azt vettem észre ha átállítom 38400-ra akkor mindig lefagy az mcu.

Odáig tudtam leszűkíteni a problémát hogy elegendő annyi a fagyáshoz hogy 9600-as beállítással küldök a processzornak egy olyan csomagot ami magasabb sebességű pl 38400. De ekkor sem mindig van hogy csak a 8-10-dik csomagra fagy le. Szkópon nézem hogy mi csinál amikor lefagy és annyit látok hogy érdekes módon fagyás után is belép az USART megszakításba újabb és újabb üzenet küldök neki de ezen kívül semmi mást nem csinál pl, futott PWM stb, minden megáll. De az USART megszakításba továbbra is be-belépked ha üzenetet küldök neki.

Találkozott valaki ilyesmivel?
A hozzászólás módosítva: Feb 14, 2018
(#) cimopata hozzászólása Feb 14, 2018 /
 
Még annyival kiegészíteném hogy akkor is lefagy ha egy pillanatra a földre zárom az USART-ot.
(#) Attis92 hozzászólása Feb 14, 2018 /
 
Sziasztok!

Valaki foglalkozott már esetleg STM32F3 kontrolleren az USB felélesztésével CubeMX segítségével? Nálam még egy FreeRTOS is generálódik, de ez nem olyan lényeges.
Van esetleg valakinek egy minta projektje CDC üzemben, amiben a HAL kezelések jól felfoghatóak?
Előre is köszönöm.
A hozzászólás módosítva: Feb 14, 2018
(#) vargham válasza Attis92 hozzászólására (») Feb 14, 2018 /
 
Nem bonyolult. F2 és F1 sorozattal próbáltam, de van kéznél F3 is. Hol akadtál el?
Minta projektek pedig vannak a CubeMX-hez. Azokat nézted?
A hozzászólás módosítva: Feb 14, 2018
(#) Attis92 válasza vargham hozzászólására (») Feb 14, 2018 /
 
Bocsi, de hol érem el a minta projekteket?
(#) kapu48 válasza Attis92 hozzászólására (») Feb 14, 2018 /
 
(#) Attis92 válasza kapu48 hozzászólására (») Feb 14, 2018 /
 
Most, hogy nézem az STM32F3-Discovery kapcsolását, ott fel van húzva az USB_DP tápra 1,5k-val. Hát nálam viszont nincs. Valahol azt olvastam, hogy nem kell mert az USB periféria intéz minden ilyen HW dolgot. Na mindegy felpatkolok egyet és megnézem mit reagál!
(#) Attis92 válasza Attis92 hozzászólására (») Feb 14, 2018 /
 
Igen, ez határozottan segít. Legalább már a Windows látja a VCOM-ot! Köszi a rávezetést, küzdök vele tovább!
(#) vargham válasza Attis92 hozzászólására (») Feb 14, 2018 /
 
Ahová a CubeMX letölti a csomagokat.
(#) cimopata válasza cimopata hozzászólására (») Feb 14, 2018 /
 
Esetleg valakinek valami ötlet?
(#) Attis92 válasza vargham hozzászólására (») Feb 14, 2018 /
 
Köszi, megtaláltam. Sikerült feléleszteni.
Ha jól értem, akkor a
  1. static int8_t CDC_Receive_FS(uint8_t* Buf, uint32_t *Len)
és a
  1. uint8_t CDC_Transmit_FS(uint8_t* Buf, uint16_t Len)
függvények, amit használni kellene a küldéshez és a fogadáshoz és ezeket közvetlenül érdemes hívogatni?
(#) Attis92 válasza cimopata hozzászólására (») Feb 14, 2018 /
 
Szia!

Nem igazán értem, amit leírtál. Beállítasz az MCU-n egy baudrate-et és szándékosan másik baud-al küldesz neki valamit és akkor lefagy?
(#) icserny válasza cimopata hozzászólására (») Feb 14, 2018 /
 
Ebben a könyvben a 8.4 és 8.5 fejezet foglalkozik a témával. Feltételezem, hogy valami hiba (ráfutás vagy keretezési) nincs rendesen lekezelve.
(#) cimopata válasza Attis92 hozzászólására (») Feb 14, 2018 /
 
Igazából már annyiról lefagy ha egy pillanatra rövidre zárom az RX bemenetét. Rövidrezáráskor valószínűleg nem felismerhető karaktert kap vagy olvas.
(#) cimopata válasza icserny hozzászólására (») Feb 14, 2018 /
 
Látok ilyen regisztert hogy:
FE: Framing error
PE: Parity error
NF: START bit Noise detection flag
ORE: Overrun error

Esetleg kapcsoljam be ezeket a megszakításokat is és ha ilyen jön elő akkor reseteljem a flag-eket?
(#) icserny válasza cimopata hozzászólására (») Feb 14, 2018 /
 
Én nem foglalkoztam még behatóan az STM32 mikrovezérlőkkel, tehát nem tudom.
1. Ha CubeMX által generált, HAL fügvényekkel tűzdelt alkalmazásról van szó, akkor a föntebb ajánlott könyv 8.5 fejezetében írtak szerint ezek le vannak/lesznek kezelve.
2. Ha a CubeMX nélkül írt saját programról van szó, akkor nézd meg, hogy mit csinál egy CubeMX mintaprogram a hibák lekezelése érdekében!
(#) cimopata válasza icserny hozzászólására (») Feb 14, 2018 /
 
Nem igazán használom a HAL-os cuccokat mert eléggé lassítja a dolgokat. Regiszte szinten próbálom kezelgetni a dolgokat.

A ref mnual szerint ezeket az error megszagításokat be tudom kapcsolni az EIE bittel a UART1->CR1 regiszterben viszont nem látok pont ilyen bitet nem lenne ilyen funkció ezen?

Bővebben: Link

625.oldal
(#) cimopata válasza icserny hozzászólására (») Feb 14, 2018 /
 
Betettem, végül ezt:
  1. void USART1_IRQHandler(void)
  2. {
  3.         if(USART1->ISR &= 0xF)
  4.         {
  5.                 usart_error = USART1->ISR;
  6.                 USART1->ICR = 0xF;
  7.         }
  8.         else //ha nincs hiba
  9.         {
  10.         }
  11.   /* USER CODE END USART1_IRQn 0 */
  12.   HAL_UART_IRQHandler(&huart1);
  13.   /* USER CODE BEGIN USART1_IRQn 1 */
  14.  
  15.   /* USER CODE END USART1_IRQn 1 */
  16. }


Így már nem fagy le semmilyen esetben sem viszont ha 38400-ra állítom a fogadó sebességet akkor sajnos elég sokszor nem válaszol az eszköz pl 10-ből csak 4 szer. Kiolvastam mi volt a hiba és a Framing error illetve az overrun error bitek áltak be azon akad fenn.

Mi miatt adódhat ennyiszer keret probléma? Az lehet baj hogy optokapun keresztül meg a kommunikáció és a felfutó jelnél kicsit késik a jel? Pl egy byte adat az 230us és bitenként ahol felfutó él kell legyen ott 15usec-et késik a felfutó él, optokapu sajnos csak ennyit tud.
(#) csatti2 válasza cimopata hozzászólására (») Feb 14, 2018 /
 
Hmmm, és mennyi ideig tart a jel fel, illetve lefutása? A legtöbb digitális elektronika érzékeny (értsd meghülyül) ha túl lassú a jelváltás. Lehet egyébként ilyen célra tervezett optókat kapni (nagy-sebességű adatátvitel).
(#) Attis92 válasza cimopata hozzászólására (») Feb 14, 2018 /
 
Szerintem inkább az overrun lehet a probléma. Ha jól tudom, akkor nincs valami sok tárhely az RX FIFO-ban (az is lehet, hogy csak 1), így ha nem tudod garantálni a gyors kiolvasást akkor ez okozhatja ezt a hibát és magyarázhatja, hogy csak nagyobb sebességnél jön elő. Amikor mi ezzel szórakoztunk csak DMA-val volt stabil. Egyébként ha jól emlékszem akkor HAL_UART_IRQHandler-ben többféle callback is van, amivel akár több infót is kaphatsz, hogy mi okozza a megszakítást (és nem kell a bitek közt túrkálni).
(#) cimopata válasza csatti2 hozzászólására (») Feb 14, 2018 /
 
A fel lefutás nem vészes 1usec körül csupán a késés nagyobb. Lehetne akár 6N137 is csak nem annyi helyem a panelen így marad az SOP4 HCPL-181-00DE, csak az a fura hogy nagyon messze van attól amit az adatlap ír. ts-re 1usec alatt írja a kikapcsolás késleltetést 220Ohm felhúzóm van 3,3v tápra és kell vagy 10-13usec mire megindul magasba a jel. direkt emiatt választottam ezt az optót.
(#) cimopata válasza Attis92 hozzászólására (») Feb 14, 2018 /
 
Üres első indításra küldök 1 csomagot és arra sem reagál mindig ott pedig üresen van még minden tárhely.
(#) cimopata hozzászólása Feb 14, 2018 /
 
Szinte biztos hogy a lassú optó miatt késés a baj mert leveszem a sebességet 38400 ról 19200-ra és itt már stabilan mindig jön a válasz. Lehetséges hogy a 15us késés miatt lecsúszik a stop bitről a vevő.
(#) icserny válasza cimopata hozzászólására (») Feb 15, 2018 /
 
Idézet:
„UART1->CR1 regiszterben viszont nem látok pont ilyen bitet”

UART->CR3 0. bitjét nézd meg!
(#) gtk hozzászólása Feb 15, 2018 /
 
Sziasztok !

Eppen most neztem hogy a CMSIS / DSP lib M7-re is hasznalhato.
De, 32H7 eseteben hogy tudja ez kihasznalni a DP-FPU-t ha az adat float ?
(#) roleez hozzászólása Feb 16, 2018 /
 
Az stm32f103 mcu-nál az USART-on megjelenő IDLE megszakítás megjelenésekor már a DMA
az összes fogadott bájtot "elkapta"? Az IDLE figyelésével csinálom a(z RX) változó darabszámú byte vételt.
Köszönöm.
(#) gtk hozzászólása Feb 20, 2018 /
 
Sziasztok,

Valaki probalkozott HAL -t hasznlva ilyesmivel ? DMA: Periph to Memory / circular / double buffer.
En korabban az SPL-lel ezt megcsinaltam, de most az uj procira a HALal fel nap olvasgatas es keresgeles utan sem latom hogy hogyan lehetne megvalositani.
Ha jol latom a H7-nek mar nincs SPL tamogatasa, tehat a korabbi kodomat nem tudom ra alkalmazni.

Az SPL-lel az erre vonatkozo resz kb ennyi volt:
  1. ...
  2.     DMA_InitStructure.DMA_Mode = DMA_Mode_Circular;
  3.     DMA_InitStructure.DMA_Memory0BaseAddr = (uint32_t) addr0;  // 0.vpuffer cime
  4.     DMA_DoubleBufferModeConfig(DMA1_Stream3, (uint32_t) addr1 /*ezzel folytatja*/, DMA_Memory_0);


Esetleg lehet hogy regiszter szinten ki tudnam egesziteni a HAL ide vonatkozo eljarasat, de az elegge szomoru egy ut lenne.
A hozzászólás módosítva: Feb 20, 2018
Következő: »»   112 / 175
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.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