ESP32, LoRa SX1272, TFT LCD

[epto]

Zdravim,

Mam ku ESP32 pripojeny LoRa modul cez SPI zbernicu. Na tu istu zbernicu je pripojeny aj TFT display.
Komunikacia je bezproblemova s obisvoma zariadeniami. LoRa modul prijime paket, obsluhu riesim cez prerusenie. Obcas sa vsak stane, ze text/grafiku na displeji mi vykresli uplne inde ako je urcene. Vykresli ju spravne, aj text je neslkomoleny akurat je na inom mieste (namiesto vlavo hore je vpravo hore alebo vpravo dole a podobne). Je to iba obcasne a neviem kvoli comu.
Je mozne, ze pocas komunikacie s TFT ked sa odosielaju potrebne data pre neho (text, grafika na vykreslenie) dojde prerusenie, procesor nedokonci celu sekvenciu dat pre TFT, zacne komunikovat s LoRa modulom a po dokonceni obsluhy prerusenia pokracuje v komunikacii s TFT. Nemoze dojst vtedy ku chybnemu vykresleniu?
Rozmyslam, ze pocas prace s TFT zakazem prerusenie.Ale ked mi v tom case pridu data na LoRa modul, ten mi to nijako neoznami lebo mu zakazem prerusenie. Bude si ESPcko nejako pamatat, ze nastalo prerusenie a ked ho povolim tak aj nastane? Popripade je mozne prerusenie spracovat v inom case ako nastane?
V samotnom preruseni iba prijimem prijaty balik dat (8bajtov), ulozim si ho do buffra a nastavim si priznak prijatia dat. Nasledne v hlavnej slucke prijate data ulozene v buffri spracujem.

Podobne som mal predtym a MEGA a inym komunikacnym modulom a tam sa mi podobna vec nikdy nestala.

Dik za kazdu radu

[mato3000]

prvá rada , neotváraj tému 3x

-- Spojený príspevok 18 Feb 2019, 11:14 --

tak a máme tu znova tú istú tému ... takže 4x

som zvedavý kolko krát ich tu bude , kým prídem z obeda

[epto]

Sorac za duplicitnu temu, zamrzol prehliadac, poprosim admina aby zmazal tie prebytocne kopie
Zmazal som ich sam.

[peterple]

A čo si čakal že sa ti ten konflikt vyrieši sám? Jasne že nemôžes uprostred rozbehnutej komunikácie s TFT displejom obslúžiť cez tú istú zmernicu aj ten komunikačný modul. Veď má v tom okamihu to TFT povolený CS a tak všetky tie byte pre modul berie tiež. A a kedže tieto veci sú na sebe nezávislé (asynchrónne) tak to dopadne ako čert chce.
A to dúfam že si to tvoje prerušenie kontroluje aspoň dovysiealnie byte na SPI a nerachne tam tie svoje rovno do vysielacích registrov.
Rieši sa to synchronizáciou semafórmi. Alebo použi jazyk čo to rieši za teba sám. I keď neviem s ktorým z módnych jazýčkov (JAVA, Go, Python, Javascript) dokážeš písať obsluhy prerušení.

Možno je problém práve v tomto. Jedno zariadenie (MEGA) tie knižnice má synchronizované a tie druhé písal nejaký iný majster čo sa k tomuto ešte neprepracoval.

Chceš pracovať s prerušeniami a pritom ani nevieš kedy a ako ich Core spracuje. Najvyšší čas si to poriadne naštudovať pre ten MCU čo práve hodláš používať. Každý to má totiž inak.

[epto]

Dobra pripomienka s CS signalmi, danu vec som si kontroloval, funkcie pre obsluhu TFT aj modulu poctivo nahadzuju aj zhadzuju CS signal, ale iba svoj. Skusim doplnit do obsluhy prerusenia zhodenie CSka pre TFT.
Kontrolu dovysielania byte si pozriem, ci to autor kniznice nejako riesi.
Dik za nasmerovanie.

[peterple]

Ale veď nemožeš zhodiť CS TFT keď je uprostred nejakého datového prenosu. Ako by si v ňom po návrate z prerušenia pokračoval?
Najjednoduchšie by bolo zmeniť tvoju stratégiu obsluhy prerušenia. A to tak že iba nastavíš priznak že bolo. Vyčítanie dát z modulu potom urobíš v hlavnej slučke. Teda vždy sa vykoná kompletná obsluha TFT a potom komplet modul, alebo opačne.
Ak toto riešenie nie je možné lebo obsluha TFT trvá dlho a možu prísť medzi tým iné data ktoré nahradia tie prvé tak potom pomocou semafórov ako som písal. Hľadaj také pojmy ako race condition.

Ešte ohľadom tých prerušení všeobecne platné býva naprieč MCU že externý prerušovaí vstup ktorý má nastavené spúštanie hranou tak ten sa zapamätáva. Ten čo je aktivovaný úrovňou (jedno číi 0 alebo 1) tak ten nie. Ale všade sú všelijaké špécie a detaily na ktorých znalosti či neznalosti stojí a padá spoľahlivé fungovanie systému postaveného na prerušení. Stačí že niekde nieje niečo reentrantné alebo máš problém s atomickostou a potom sa ti môže stať že raz za život stupíš na brzdu a ono to miesto toho pridá plyn.

[epto]

Ked mi pride prerusenie pocas komunikacie s TFT a za predpokladu, ze dokoncilo prenos byte, mozem zhodit CSko, len musim zistit ci bolo nahodene, ci vdanej chvili prebiehala komunikacia s TFT, prenos po dokonceni prerusenia by mal pokracovat normalne. Ale musim to vyskusat.
Kazdopadne musim to osetrit, dorobil som k tomu vsetkemu aj posielanie dat cez WiFi pripojenie na server na sieti. Funguje to vsetko dokopy prekvapivo dobre az na tie obcasne chybne vykreslenia. Niekedy 2 dni nic, inokedy aj 2-3 krat za den. Ale ked dana chyba nastane je viditelna.
Posielanie dat na server je casovo narocnejsie, ale nastane raz za +é minut, tam by som na danu chvilu ozelel prerusenie.
Aeste by islo zakazat prerusenie ked sa kresli na display ale ten by som musel optimalizovat aby sa prekreslovalo iba to to skutocne treba, nie cele prvky/texty.
Idem pozriet tie semafory

[peterple]

Pre to tvrdenie v prvej vete máš aj nejaký argument podopretý datasheetom radiča toho displeja, alebo si to len myslíš? Low level komunikáciu s displejom si si písal sám alebo si použil nejaký hotový výtvor?
Ak formát komunikácie s displejom je taký že na začiatku je command a potom data tak to tvoje tvrdenie neplatí, lebo prechod CS z H do L označuje práve začiatok prenosu a slúži to na reštart komunikácie, aby sa vedelo kedy príde command. Potom to už len záleží od toho kam sa ti podarí prerušením trafiť a prípadne ten príkaz nabúrať. Takže ak to vyskúšaš tak všetko bude OK lebo okno do ktorého sa treba trafiť je povedzme pár desiatok či stoviek mikrosekund. Pri periode povedzme 1 sekuna (záleží ako často komunikuješ s displejom). Ale ono sa to niekedy stane. Čert nikdy nespí, a veci sa dejú tak aby spôsobili čo najviac zle, čo však pri testovaní na stole nehrozí. Takže vtedy takáto výnimočná situácia takmer určite nenastane.

[epto]

Zatial som nemal cas vyskusat vsetky napady ale aj taketo teoreticke uvazovania je prospesne. Kniznica pre obsluhu displeja nie je moj vytvor. Naviac je to kolos pripraveny pre x druhov arduina a x druhov displejov. Vyextrahovat z toho iba moju kombinaciu dosky + radica je na dlhe zimne vecere
Prerusenie nastava niekolkokrat za minutu (prijem dat cez 433MHz z niekolkych stanic). Vykreslovanie na display mam ihned po prijati dat a odosielanie cez net na server bude raz za 10 minut.
Napadlo ma uplne zakazat prerusenia pocas prace s displejom a pocas kominikacie so servrom. Taktiez vykreslovat na display budem raz za minutu kedy aktualizujem co bude potrebne. Kedze ide iba o zber dat, pripadne neprijatie baliku dat z jednej stanice to az tak nevadi.
Je to skor take obidenie problemu ako vyriesenie ale pre vyriesenie mmi chhybaju hlbsie znalosti programovani. Cele to mam ako hobby obcas po veceroch ked mam cas. Avsak mam v plane z toho celeho urobit clanok kde sa podelim o moje riesenie a ziskane skusenosti.

[peterple]

A s čím máš problém? Jedno riešenie som ti navrhol. V prerušení nastavíš príznak že treba vyčítať správu a v hlavnej slučke to urobíš keď nepíšeš do displeja. Ak máš niektoré úlohy (ako komunikácia so serverom) napísané blokujúco tak to nieje to pravé vhodné riešenie.

Druhé riešenie je máličko komplikovanejšie. Potrebuješ ešte do toho zapliesť časovač a nejaký semafor - obyčajný príznak 0-1
Scenár obsluhy je teraz takýto:

1. nastalo prerušenie, test či je CS displeja aktívny
2. nie - môžem okamžite vykonať čítanie modulu - vybavené
3. áno - nemôžem čítať modul, Nastavím na semafore pre obsluhu displeja červenú. Zároveň je to príznak že nemám obslúžené čítanie modulu. Týmto som požiadal obsluhu displeja, aby sa nová nezačala dokiaľ nebude na semafore zelená. Prerušenie vybavené.
4. V prerušení časovača kontrolujem či je na semafore červená. Ak áno, znamená to neobslúžené čítanie komunikačného modulu. Ak je červená a CS je neaktívny (obsluha displeja medzičasom ukončila komunikáciu) vybavím čítanie modulu a semafor pre displej dám na zelenú.
5. Ak nie tak nerobím nič sa končím obsluhu časovača.
6. Komunikáciu s displejom upravím tak, že si vždy pred začatím komunikácie najprv pozriem semafor. Ak je tam červená čakám až mi ju časovač prepne na zelenú.
7. Ak je zelená tak si spustím a vybavím komunikáciu s displejom. Samozrejme je vhodné rozdeliť prekreslenie displeja na niekoľko komunikácií aby to malo zmysel

Práve si si týmto implementoval OS s multitaskingom. Ten najjednoduchší s jednou bežiacou úlohou na popredí a druhou na pozadí.
Dá sa to aj bez toho timera. Vtedy v prípade že je semafor na červenej vyčítaš najprv komunikačný modul dáš ho na zelenú a pokračuješ v obsluhe displeja. Funkčné to bude ale už sa ti tam stráca ten zárodok multitaskového systému.