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 / 112
(#) 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 (») Kedd, 18:53 /
 
A könyvet én is megvettem, nagyon szuper.
Köszönöm szépen az ajánlást!
(#) cimopata hozzászólása Sze, 1:11 /
 
Ü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: Sze, 1:12
(#) cimopata hozzászólása Sze, 1:20 /
 
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 Sze, 9:22 /
 
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: Sze, 9:22
(#) vargham válasza Attis92 hozzászólására (») Sze, 12:55 /
 
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: Sze, 12:56
(#) Attis92 válasza vargham hozzászólására (») Sze, 13:06 /
 
Bocsi, de hol érem el a minta projekteket?
(#) kapu48 válasza Attis92 hozzászólására (») Sze, 13:37 /
 
(#) Attis92 válasza kapu48 hozzászólására (») Sze, 14:06 /
 
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 (») Sze, 14:20 /
 
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 (») Sze, 14:42 /
 
Ahová a CubeMX letölti a csomagokat.
(#) cimopata válasza cimopata hozzászólására (») Sze, 16:32 /
 
Esetleg valakinek valami ötlet?
(#) Attis92 válasza vargham hozzászólására (») Sze, 16:39 /
 
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 (») Sze, 16:41 /
 
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 (») Sze, 16:51 /
 
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 (») Sze, 18:00 /
 
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 (») Sze, 18:02 /
 
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 (») Sze, 18:08 /
 
É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 (») Sze, 18:28 /
 
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 (») Sze, 19:17 /
 
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 (») Sze, 21:23 /
 
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 (») Sze, 21:42 /
 
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 (») Sze, 22:29 /
 
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 (») Sze, 22:30 /
 
Ü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 Sze, 22:48 /
 
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 (») Csü, 8:15 /
 
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 Csü, 14:47 /
 
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 Pé, 9:44 /
 
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.
Következő: »»   112 / 112
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu