Nem jövök rá, hogyan tudok egy db karaktert elküldeni PIC32MZ UART-al. A FIFO-ja 8 mély, csak akkor kezdi elküldeni egyenként a karaktereket, ha megtelt, azaz a 9. beérkezésekor elküldi az elsőt. De egy karaktert is el kellene tudnia küldeni, de nem jövök rá hogyan. Megszakításból a 24 karakterből elkült 15-öt. Nem találok olyan beállítást, hogy FIFO kikapcsolása. MX-en ez simán ment, persze FIFO nélkül...

Pedig nincs különbség az MX és az MZ UART-ja között, és a FIFO nem tiltható le egyiküknél sem. Alap esetben az adásnak meg kell kezdődnie közvetlenül a TX tárba való írás után (FIFO ide vagy oda). Ha viszont használod a Flow Control módot, akkor az adás csak a /CTS jelre indul meg. Szerintem nézd át az /RTS és /CTS lábak beállítását!

A vezérlő lábakat kikapcsoltam(illetve nem kapcsoltam be.). Biztosan valami beállítás, de nem jöttem rá eddig.
Azt írod, mindenképpen meg kell kezdődnie? Break-el hajtottam végre a megszakítást, amiben egyenként küldöm el a bájtokat egy tömbből. A 9. beírásakor került ki az első. Ha ezt akarnád, hogyan oldanád meg?

Találtam különbséget. Azon kívül, hogy az MX-nek 4 mélységű, az MZ-nek 8, eltérés van a megszakítás jel generálódásában is. Nem pontosan értem, csak sejtem, hogy mi az eltérés, ha tudtok segítsetek megérteni!

Adások előtt a TRMT bitet ellenőrizted?

Azt hiszem arra már rájöttem, hogy miért tűnik úgy, hogy csak a 9. karakter után viszi ki az első karaktert. Azért, mert a megszakítás jel csak akkor törlődik, ha tele a puffer 8 mélyen, 00-s beállítás esetén. A puffert olyan gyorsan tölti, hogy a debuggolás közbeni betérések alatt nem ér ki egy bit sem a soros vonalon. Ezt követően már csak akkor tér be a megszakításba, ha kiment egy adat, mert akkor már legalább egy puffer üres, azaz megvárja, míg kimegy egy karakter.

Azt még nem értem, hogyan maradhat bent a pufferben az utolsó 9 adat...

De rájöttem! Ez egy RS485 illesztővel ellátott vonal. Amikor kiért a beállított számosságú karakter, letiltom a TX megszakítást és a kimenetet bemenetté fordítom. Hiába küldi az UART a maradékot, nem jut ki a vonal illesztőn. Meg kell várjam, míg teljesen kiürül a puffer, azaz menet közben módosítanom kell a megszakítás mód jelzőt és ha kiürült minden, akkor szabad vételre váltanom! Félek nem lesz sok időm délután, de beszámolok, ha sikerült! Köszi az eddigieket!

Megszakításban kezelt TX-nél nem szükséges szerintem, mert a megszakítás jelek helyettesítik.

4-szintű FIFO UART modulnál:
11 = X
10 = Megszakítás keletkezik amikor a TX tár kiürül
01 = Megszakítás keletkezik amikor minden adat el lett küldve (TX tár és SR kiürült)
00 = Megszakítás keletkezik amikor a TX tárnak lesz legalább egy üres helye

8-szintű FIFO UART modulnál:
11 = X
10 = Megszakítás keletkezik és addig fenn is marad amíg a TX tár üres
01 = Megszakítás keletkezik amikor minden adat el lett küldve (TX tár és SR kiürült)
00 = Megszakítás keletkezik és addig fenn is marad amíg a TX tárnak van legalább egy üres helye

Az én értelmezésem szerint:
4-szintű FIFO-nál a megfelelő esemény bekövetkeztekor a megszakításjelző bit bebillen, de utána programból törölhető.
8-szintű FIFO-nál viszont törlés után a bit visszabillen újra mindaddig amíg az eseményt kiváltó állapot fennáll. (Tehát előbb meg kell szüntetni az okot, majd törölni a bitet!)

Sziasztok!

A Cast-olással akadt problémám!



Adott ez a sor:

Néha 0 lesz az értéke, és úgy látom, nagyon nem pontos. Túl nagy lépésközzel jön a backlight_set-be eredmény, biztos, hogy nem számol mindig rendesen tizedesekkel.
Lehet, hogy float helyett double kellene?
Mindig is voltak gondjaim a cast-olással.
Valaki helyre tudná ezt tenni?
A backlight_set-be egész számok kerülhetnek, egy PWM generátorba megy. Tulajdonképpen ez az egész egy kijelző fényerejét szabályozza automatikusan.

Köszönöm! Szimulációban csodálkoztam, hogy nem törlődik a bit, azt hittem bugos, ezek szerint csak okos.

Ha úgyis egész eredmény kell, akkor felejtsd el a float és double típust! Az egész osztás csonkítása miatt azonban meg kellene cserélni a szorzás és az osztás sorrendjét. Emiatt long típusú átmeneti tárolásra lesz szükséged.

Le tudnád írni esetleg egy példában, hogy hogyan gondolod ezt?
A számlálóba vigyem fel az avg_lux szorzást?

Igen.

Így is butaságokat mér sajna:

Valószínű, hogy a szorzás eredménye nem fér bele a vélhetően 16, vagy 32bites változókba. Ha netán nem így lenne most, deklarálj long long változókat, vagy több lépésben hajtsd végre a műveleteket, sok esetben még gyorsabb is lesz, mint így egybe nyomorgatva. A C szép dolog, de ára van.

Most azon agyalok, ha a main-ben végzem ezt el, akkor működik. 1ms-os megszakítsában csináltam, mint most kiderült, nincs elég ideje elvégezni. Úgyhogy kell a main-embe egy flag.

Jut eszembe, az MZ EF sorozatnak van hardveres float és double támogatása. Tedd át doublébe és számoltasd ki ugyanezt, lehet, hogy gyorsabb lesz! (Azt nem tudom, hogyan kell rávenni a fordítót, hogy ezt használja, talán tudja magától, ha a legújabb XC32-t használod.))

A legújabbat használom!
Végülis nem kell lebegőpontos számolás.
Ez lett a vége a main-ben egy flag-el:

Elég látványosan működik, frankó lett. De pl 200-as kitöltési tényezőről 100-ra ugrás elég hirtelen a kijelző fényerejét illetően, úgy csinálom meg, hogy ms-onként vegyen vissza egyet a kitöltési tényezőből.

Nem biztos, hogy lineáris öszefüggés lesz a fényerő és a kitöltés között.

Nem izgat, hogy az FPU-val hogyan menne? Ha jól láttam pár órajel alatt kiszámolja az eredményeket, még gyökvonás is van, ha jól látom. Az adatlap(60001320B.pdf) 3.1.4 részénél nézd meg miket tud!

Mindjárt átnézem.

A prg induláskor minden beállítás majd
-egyik teszten 1 byte kiküldés
-másik teszten 2 byte kiküldés
és üres pörgés NOP sorozaton.
Ennyinél miért kellene küldés előtt TRMT vel torődnöm ?
UART1 és 2 ugyanaz a helyzet.

TRMT...
mivel 1 byte nál még nem tellik meg és nem lesz a TRMT full
és ennél is ismétlődik a kiküldés ebből gondolom nem TRMT
miatt történik az ismétlődő TXd.
Úgy néztem 2 byte nál lesz full a TRMT
és ezt e PIR3 configban is lehet ellenőrizni mármint hogy üres vagy tele a TXbuff.
Érdekes hogy ennyit kell görcsölni.
a jel szabálytalan és nem áll le.

A leírás szerint így kellene lennie:

A TRMT üres/tele különbözik a TX1IF üres/tele lekérdezéstől.
2 byte-ot lehet a bufferbe küldeni.
A TRMT akkor lesz üres jelzésű, ha buffer utolsó byteja is ki lett küldve és a stopbit nél tart
A TX1IF pedig 1 byte TXREG be küldésekor ad egy picic LOGIC-0 jelet, de LOGIC-1re visszatér
és amikor már beküldtük a 2. byte-ot és tele van a buffer úgy, hogy az első byte
küldése nem fejeződött be tartós LOGIC-0 lesz a legelső STOPbitig.

A problémám is tesztelve TRMT LOGIC-1 ekkor küldök 1 byte-ot ki LOGIC-0 lesz
és a következő csapda, ami LOGIC-1 re várakozik már nem jut túl rajta a stopbit
látván sem, mert köpködi ki a byte-ot. Asynchronra módon vagyok.

Tegnap kevés időm volt(ma is az lesz), addig jutottam, hogy 8nál több karaktert tudok küldeni megszakításból. 8-nál kevesebb nem megy ki. Az U6TXREG-be beteszem az adatot és nem történik semmi. Egyelőre nem értem, ilyennel még nem találkoztam, pedig 12F-től minden PIC családdal dolgoztam...

Tehát ha bepakolsz a CPU-val manuálisan (Nem DMA-val vagy megszakítással) pl. 5db adatot az U6TXREG-be, nem kezd el adni? Szkóppal mérve nem jön ki semmi? Az U6STA regiszterben történik változás?
Hogyan inicializálod az UART-ot, és hogyan küldesz?

De! Manuálisan megy, TRMT-t figyelve.
Próbálom elmondani mi van, de nem egyszerű, mert nehezen tudom megfogalmazni, hogy érthető legyen. Talán azzal kezdeném, ahogy most már működik. Cél, hogy megszakításban legyenek elküldve a karakterek egy pufferből. Átadásra kerül az elküldendő karakterek száma és engedélyezésre kerül a TX megszakítás a folyamat megindításához.
Ahogy most működik:
Megszakítás mód beállítás:

Ebben a módban az történik, hogy betöltöm a karaktert a FIFO-ba (U6TXREG-be), elküldésre kerül, amikor kiért megszakít, újra betöltöm, egyesével, mindezt addig, amíg el nem fogynak a karakterek.
Ez a működés megfelel a régi hagyományos FIFO nélküli módnak, mert a FIFO-ba mindig csak egy karakter lesz letéve.

Természetesen szeretném kihasználni a FIFO-t, megszakításban, de eddig nem sikerült. Ha az U6STAbits.UTXISEL=0b00, ami akkor szakít meg, ha van legalább egy szabad hely a pufferben, akkor addig belepörög a megszakításba, amíg nem telik meg a FIFO. Amikor ez megvan, akkor elvileg csak akkor tér be, ha a FIFO legalább egy karakterrel ürül, azaz innen azonos a működés lenne a fent leírtakkal. Meg kéne oldani, hogy amikor elfogynak a karakterek, de még a FIFO félig tele, várja meg, míg kiürül, de eközben folyamatosan megszakítás történik a 00-s módban, mert a FIFO nincs már tele. Itt nem lenne szép elkezdeni vizsgálni a TRMT-t, mert az már nem megszakításban való kezelés, még ha ott is pörög a szál. Tehát át kéne váltani a U6STAbits.UTXISEL=0b01; módra és várni, míg kiér az utolsó karakter és akkor jön a megszakítás. Ekkor lehetne törölni a megszakítás engedélyt és visszaváltani 0b00 módra, valamint bemenetre váltani az RS485 vonalat.
Ez elvileg jónak tűnik(lehetne finomítani ez elején a FIFO első feltöltésén ciklusban, hogy itt is csak egy megszakítás legyen, de ez most mindegy), de az adatlap azt írja, hogy a U6STAbits.UTXISEL bitet nem javasolt módosítani, csak akkor, ha a FIFO üres. Na szép! Ezzel meg vagyok lőve, mert nem értem minek a FIFO, ha nem tudom használni.

Ha van ötleted a használatára, szívesen venném!

Egy komplett library-t elküldtem neked erre ma délután emailben.

Nemrég értem haza, nem láttam még. Megnézem, köszi!

Nálam most ez működik, gyakorlatilag ugyanabban a módban, amit küldtél. Eddig ezt használtam, de most gondoltam jó lenne kihasználni a FIFO-t, de csak küzdök vele.

Azért küldtem, mert ezt az utat már egyszer végigjártam! Annyit lehet rajta javítani, hogy double buffering-et használjon. Egy másik buffernek átadod a memóriacímet, ami ugye gyorsabb, mint a másolás.

Ez nem ugyanaz, amit írok. De köszönöm hogy segíteni próbálsz! A FIFO 8 mélységű és az MX-hez képest másképpen működnek a megszakítás jelek is. Emellett amit felraktam kódot, egyenértékű a tiéddel: beteszem a TX6_DataPointer mutatóba puffer címét, amiben az adatok vannak, engedélyezem a megszakítást és elküldi egyenként, egy-egy megszakításban feltöltve a TXREG-et(bemegy, feltölt, kijön...).
A FIFO kezelése csökkentené a megszakítások számát, így erőforrás szabadulna fel (nem sok, de tény). Bemegy, feltölti a FIFO-t max 9 karakterrel, mert egy rögtön lecsúszik a léptető regiszterbe és a küldés megkezdődik, de még a start jel sem megy ki, mire a FIFO feltöltődik és kilép a megszakításból.
Az nem fér a fejembe, hogy ha nem javasolt menet közben módosítani a megszakítás módokat, akkor hogy gondolták a FIFO használatát a MC-nél?