STM32L4 HAL USART problem

[Jaroslav Buchta]

Ono je to slozitejsi, da se snad cekat, ze HAL knihovna to ma nejak 
osetrene a skutecne zda se ma a celkem rozumne. Nicmene v dusledku 
nejake casove souhry obcas asi dojde k tomu, ze misto aby se to spravilo 
samo tak to udela asi Abort prijmu a dalsi znaky uz se neprijimaji dokud 
se zase nezavola fce HAL_UART_Receive_IT. Asi je resenim vyvolat tuto 
funkci v callback fci od RxAbort. Ale cekam az se to zase stane abych si 
hypotezu potvrdil. Ono se to totiz v 99.9999 pripadech pri ORE zachova 
spravne... Jeste budu badat dal, samozrejme primarne to pak upravim, aby 
k ORE vubec nedochazelo. Ale radsi nejdriv zkusim zjistit, pricinu 
problemu, at tam neni nadale kostlivec.

Dne 24.07.2019 v 16:27 Miroslav Mraz napsal(a):
> Jasně, to je ta druhá možnost. Já jen, že ten owerflow je default 
> zapnutý, takže pokud se s tím nechci zabývat, musím ho při 
> inicializaci vypnout. Tenkrát jsem to tak udělal zřejmě proto, že by 
> mi to komplikovalo rozhraní a protokol co běží nad tím umožňuje 
> detekovat chybějící nebo vadné znaky o vrstvu výš pomocí CRC. A to 
> bylo prostě jednodušší pro implementaci.
>
> Mrazík
>
> Dne 24. 07. 19 v 15:02 Jan Waclawek napsal(a):
>>> (dělá to jen problémy)
>>
>> No preto, lebo ho treba detekovat a poriadne osetrit... ;-)
>>
>> ORE sam osebe aj bez RXNE sposobuje prerusenie povolene len pre RXNE. 
>> Zdalo
>> by sa, ze to nemoze nastat, no ale nastava to prave nasledkom toho, ako
>> presne sa tie flagy nuluju.
>>
>> wek
> _______________________________________________
> HW-list mailing list  -  sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list