Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
A legnagyobb bajom az, hogy ezen a héten 0 időm volt és ma sem lesz sok. Emellett lehet, hogy túlbonyolítottam a mód váltogatással. Talán a legjobb megoldást, ahol nem kell a TX INT módot menet közben módosítani, nem próbáltam.
A terv: A megszakítási mód: 01 (Akkor szakít, ha kiürült a FIFO és az SR is.) UART buffer pointer beállítása Adat méret beállítása RS485 irány kimenet TX Interrupt engedélyezése 9 adat betöltése a FIFO-ba, ha van annyi. Ha hamarabb elfogy, kilépés és várakozása megszakításra - ha kiürült a FIFO és az SR, megszakítás: Ha van még adat ugrás az előzőre... Ha nincs több adat, TX int tiltása, RS485 vonal bemenetre váltása, kész... Remélem lesz időm este még kipróbálni. Talán lehetne még variálni, de módot kellene közben váltani. Van a 10-s TX INT mód, ahol akkor szakít meg, ha üres a FIFO (de az SR még nem ment ki). Ezzel nyerhető valamennyi idő, de szerintem az minimális és a végén még is csak váltani kéne, amikor az adat elfogy, mert a legvégén meg kell várni az SR ürülését, mert az RS485 irány vezérlő vonalat nem szabad addig változtatni, míg ki nem ér az utolsó Byte is. Ellenben ez a változtatás akkor történne, amikor a FIFO üres, azaz az ajánlásnak megfelelne. Ezt is kipróbálom majd.  A hozzászólás módosítva: Márc 10, 2016
Egyik sem működik. Olyanokat csinál, hogy csak lesek. Pedig szerintem mindent jól csinálok. Ha a leírások szerint működne a megszakítás jel, akkor jól kéne működnie. Nem olyan bonyolult ez, hogy nagyot lehetne hibázni. Addig szórakozok vele, amíg lesz kedvem, meg időm, aztán hagyom a fenébe, marad a régi mód...
Sziasztok! Lehet felmerült már, de azért felteszem:
PIC-hez akarok készíteni bootloadert, FLASH memória írás segítségével. Azonban egy elég nagy akadályban elakadtam: a hex fájlból lehet-e a FLASH memóriába írandó adatokat kihozni, vagy ,ás fájltípus kell hozzá? A program lényege, hogy leellenőrizz egy flash pontot a PIC-en belül, ha abban szerepel egy adott érték, akkor odaugrik goto paranccsal, ha viszont nem, akkor UARTON várja az adatcsomagot. A kérdés ahhoz fűződne, hogy pontosan milyen adatcsomagot küldjek, hiszen pusztán a hex fájl nem úgy látszik, hogy jó.
javasolnám ha a bootloader a flashben egy ponton ellenőríz
akkor ott álljon tárolt hossz és valamilyen checksum és ha a hosszra nézve nem felel meg a checksum azaz a felírás nem hiteles szintén az Uartot figyelje. Neked a bootloader módban majd bin állományt kell feltölteni ( nem hexa formában ) így gyorsabb lesz a felírás. Amit alul leírtál ott valami nem világos. Ha müködik egy felírt programod, de majd másikat akarsz feltenni, akkor mivel flashben egy pontot figyel és aszerint már GOTO -> de akkor hogy fogsz újból feltölteni ? Javaslom inkább bootolás adjon ki időközönként pár azonos karaktert, akkor ha nem érkezik rá input flash címen ellenőrzés esetleg goto ->./boot vissza. Ha érkezik azonnal leáll a bootjel és flash írás művelet indulhat. E közbeni hiba esetén boot jelek újra. Gondolom bármikor lecserélhető legyen felíráskor a PIC mindíg tudja hova írjon ezért lehetne a beküldés csomagonként [1 felírást jelző karakter][cím érték][hasznos írt hossz][checksumbyte][a byte sor...] nem hiteles esetben jelezze hogy nem stimm és pár ismétlést felajánljon vagy hogy gondoltad ?
A saját gondomból 1 siker született
szabályos5 baudos jel 4 8 16Mhz nél szabálytalan de 2Mhz es órajelnél hibátlan formát vett. Érdekes, hogy ehhez órajelet éppen lefele kellett vinni. Már csak az maradt hogy TXregbe írva folyamatosan lövöldözi ki a karaktert a pinen. 18F26K22. jópár reget ma is változtattam vagy ez vagy síri csend. 1 doktorátusi címet felajánlanék, aki erre ötletet ad. Kössz
Tegnap sikerült pár dolgot kideríteni:
Mód: 01, akkor szakít meg, ha a FIFO kiürült és az SR is kiment. (ilyenkor a TRMT is 1 lesz) első 9 karakter FIFO-ba töltése megszakításjel törlése (debuggerben elenőrizve, sikeres) Ezt követően kilép a megszakítás kezelésből és nem kéne visszalépnie, csak amikor a FIFO kiürült és az SR is kitolta az utolsó karaktert. Ennek ellenére gyakorlatilag azonnal visszatér. A következő 9 karakter rátöltődik a FIFO-ra, ami abból látszik, hogy az első U6TXREG-be való töltéskor a BF (túlcsordulás) bit beáll. A megszakítás jelző bit itt is törlésre kerül Ekkor elmeg az első 9 bájt! A megszakításba betér, de ekkor már az utolsó 4 bájt kivitelére fut a szál, mert az index 18-on áll. (összesen 24bájt kerül kivitelre most) Az utolsó 4 bájt is kimegy, és megszakít. Kérdés, miért nem várja meg az első 9 kiküldését a megszakítási logika? Ami érdekes, ha csak 1-től 4 bájttokkal töltöm fel a FIFO-t, akkor jól működik. Ha már 5-el, akkor 1 bájt lemarad. Ha többel, akkor egyre több bájt marad le az első és az utolsó csomag között. 9 esetén az egész középső csomag lemarad. Ha valakinek van ötlete, nagyon örülnék neki! 
Droot, nincs kedved kipróbálni, amivel küzdök? Elküldeném a megszakítási forrásokat...
Tegnap előtt szétszedtem a kábeldzsungelt, amin be volt minden kötözgetve. Így sajna elég nagy meló lenne összerakni.
 A forrást esetleg küldd át és belenézek.
Adatot is fogadsz közben?
Az errata a 8. Pontjában említ egy RX FIFO szinkronizációs hibát.
Előtte fogadok adatot, adás közben nem(Az RS485 half-duplex). Az RX FIFO külön hardver a TX FIFO-tól, remélem nem szólhatnak egymás dolgába, de itt bármi előfordulhat. A legnagyobb bajom az, hogy alig van még PIC32MZ-vel foglalkozó fórum, úgy tűnik kevesen használják.
A forrást ide is fel tudom majd tenni délután, nem titok, egyébként se működik , pedig kéne neki. Két dolog lehet, vagy eltolok valamit, vagy hibás a megszakítás kezelés, de még nem jelezték a microcip-nek. Sajnos a FIFO-t nem látom az MPLAB X-ben és az U6TXREG is mindig 0, bizonyára az ICD3 nem kezeli, vagy eleve nem hozzáférhető memóriahely, ezért nagyon nehéz hibát keresni. A hozzászólás módosítva: Márc 11, 2016
Azért szedted szét, hogy panelre tedd? Gondolom amíg megjön a log analizátor, addig úgy is van időd rá? (Nekem egyébként már kedden megjött, nagyon frankó...).
Tedd fel a forrást és belenézek.
A megszakításokat kirpóbáltad külön külön? Pl az Rx-nél egy lLED-en nyom egy toggle-t. A tx-ben pedig csak egy változót számlálsz és összehasonlítod annyi-e mint ahány karaktert küldtél? Most nem emlékszem fejből, higy FIFO nélkül lehet-e használni. A logikai analizátor már nem kell, mert jó lett az I2C. Az ack-nál i2c1 volt a regiszter neve, de az i2c2-t használtam. Most azért szedtem szét, mert mással kell foglalkoznom. Rakd fel a progit és megnézem szívesen. Jut eszembe, én a Microchip fórumon kérdezősködtem már párszor az MZ-ről. Ott eléggé vágják a dolgokat. Végső esetben érdemes oda feltenni. A regisztráció viszont időbe telik, amíg egy admin jóváhagyja.
Jelen esetben nincs köze az adásnak a vételhez, csak annyi, hogy a bejövő csomag indítja az adást. Adásban egy előre feltöltött tömb adatait küldöm el. A tömbbe 1...200 számokat teszek, így nagyon jól látható, hogy melyik bájt nem ért át. (Az elküldött számokat a brayterminallal nézem a PC-n.) Délután felteszem...
De be van kötve (panelen van kettő illesztő a 4 és a 6 UART-on). Tudod, írtam, hogy ha 1-től 4 mélységig töltöm fel a FIFO-t, akkor hibátlan (az 1 mélység felel meg a régi módnak, ahogy te is használod), ezért nem lehet külső hiba.
Kicsit olvasgattam az adatlapját.
A 8 level deep azt jelenti, hogy 8 bájt? Ha a FIFO ki van kapcsolva, az nem felel meg a célnak? Ha megszakításból kezeled, úgy jól tud működni.
Majdnem igen, 8+1bit széles a FIFO, 8 mélységben.
Nem lehet a FIFO-t kikapcsolni (ha tévedek, akkor javítsatok ki). Célnak? A célom az, hogy megismerjem és kihasználjam az MZ lehetőségeit. Sokat gondolkodtam a dolgon, lehetséges, hogy a megszakítási logika 4 mélységnél többet nem tud kezelni, azaz bugos? Az MX-eken csak 4 mély a FIFO... A hozzászólás módosítva: Márc 11, 2016
Lehet, hogy valamilyen bug-ról van szó. Szerintem a Microchip fórumban kérdezz rá. De ide is tedd fel a forrást, azért belekukkantok. Bár fifo-t nem használtam még, amit a forrásban láttál abban egy bájtot küldözgetek.
Igen, de végül is nem tudod nem használni a FIFO-t, csak ha minden egyes TXREG-be írás után kijössz a megszakításból, akkor csak egy mélységben használod. Ezt tudom feltornászni 4-re, eddig. Sajnos annyira nem tudok angolul, hogy ilyen bonyolult dolgokról tudjak társalogni velük.
A FIFO_Deep 1 és 4 közötti, akkor kimegy 121-ig minden bájt
Ha a FIFO_Deep x: kimenő bájtok 9 után elnyelődnek al alábbi módon. 5: 1-9, 11-121 6: 1-9, 13-121 7: 1-9, 15-121 8: 1-9, 17-121 9: 1-9, 19-121
A hozzászólás módosítva: Márc 11, 2016
Szia!
Egy tipp. Belenéztél már abba a hex file-ba, hogy mi is van benne (klikk ide) ? Csak mert egy sima szöveg, egyszerű szerkezettel. Akár notepaddal is átszerkesztheted.
Sziasztok!
Próbálkozom a PIC programozás tanulásával, de nehezen megy. Megköszönném, ha lenne valakinek ideje és leírná nekem, hogy hogyan működik az időzítés az alábbi programban, mert nagyon nem értem. A neten találtam szoftveres időzítésre példát,ott CBLOCK 0x20 T1 T2 T3 ENDC majd T1,T2,T3 kap egy értéket és DECFSZ, ez így érthető, de az alábbi programban pl. a D_500mS időzítésnél csak temp3 kap értéket.
Akármi is volt a T1 és T2 értéke,a D_500mS másodszori meghívásakor már 0 értékűek lesznek, hiszen a decfsz utasítás 0 értéket hagy bennük.
A hozzászólás módosítva: Márc 13, 2016
Sziasztok,
Számomra meglepő dologgal találkoztam, mégpedig egy új asm utasítással, 18F szériánál. Illetve már nagyon régóta jelen van ez az utasítás, de valahogy eddig nem használtam/elkerülte a figyelmemet. Ez a "DAW" utasítás, ami annyit csinál, hogy felbontja a WREG-et alsó és felső bájtra (nibble), majd megvizsgálja az alsót és felsőt is: ha a nibble értéke nagyobb mint 9, akkor hozzáad 6-ot, és az eredmény kerül vissza (mármint értelemszerűen az alsó 4 bite). BCD kódolgatásoknál jól jöhet. Ja, és 1 cycle alatt megcsinálja. Idézet: Igen, mert arra valo. Ezt a z80 processzor mar 1976-ban tudta... Csak ott DAA volt a neve (Decimal Adjust Accumulator) „BCD kódolgatásoknál jól jöhet.”
Van egy ilyen UART hibakezelőm megszakításban.
Kommunikáció során többször betér ide, amit a LED és a hiba számláló villogása illetve növekedése mutat. Ellenben egyetlen egyszer sem fut be a szál a három lehetséges kiváltó ok vizsgálatába. Breakpontot tettem mindháromra, nem fut bele. Kérdésem, mi okozhat még megszakítást? Vagy létezik, hogy a kiváltó ok megszűnik, mire beér a megszakításba? Az RX megszakítás kezelése gyors, elvileg minden adatot el tudok kapni, majdnem kizárt, hogy a 8 mélységű FIFO megteljen. FERR előfordulhat, de még nem tudtam elcsípni a fenti módon, lehet nem is lehet így... A hozzászólás módosítva: Márc 15, 2016
Azt elfelejtettem, hogy 9bites módban van az UART. (és PIC32MZ EF) Nincs engedélyezve az auto cím detektálás mód.
A hozzászólás módosítva: Márc 15, 2016
Nekem az UARTra 1x TXREGbe írt adat állandó ismétlődő kiküldésének meglett a miértje.
A goto és bra gépi kódú számítása nem volt jó. Ezeket javítottam és TX üzemmód remek. Most jön a RECEIVED művelet félek itt se lesz egyszerű az élet.
Sziasztok!
Egy 65k szinu 7"-es TFT-n szeretnek egy menut megjeleniteni, illetve egy par adatot. Szuksegem lenne gombokra, csuszkakra. Nagyon rossz vagyok grafikaban. Letezik olyan program, amiben vannak elore megtervezett csuszkak, checkbox-ok es gombok? Hasonloan, mint a Visual Studio-ban amikor ablakos windows alkalmazast keszitek. Probaltam parat, a mikro TFT-t, a CrankSoftware tervezojet, de szerintem elegge hasznalhatatlanok es idejetmult programok. Windows-ra es Linux-ra is johet.
A win / linux dolog kicsit zavaros. Ez egy pic topic.
|
Bejelentkezés
Hirdetés |
