Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Valami mással lesz a gond, mert LATx-be be kell kerülnie az adatnak minden egyébtől függetlenül. Jó regisztert nézel? A LATA az F89h címen kell, hogy legyen.
Azt minimum csináld meg, hogy egy szóközt vagy egy tabot beteszel az utasítások elé. A bal szélen csak címke lehet, utasítás nem (k1d1, k1d1k azok címkék). Van is egy csomó "Found directive in column 1" meg "Found opcode in column 1" üzeneted. Érd el, hogy ilyen ne legyen (és nem azzal, hogy kikapcsolod az üzenet megjelenítését), és nézd meg akkor újra a szimulátort.
Még néhány észrevétel: ne írj a címkével egy sorba utasítást, hanem a következő sorba írd, hogy áttekinthetőbb legyen. Kerüld az ékezetes betűk használatát a változóneveknél. Jó eséllyel nem okoz gondot, de inkább ne kisértsd a sorsot, a programozáshoz az angol ABC jeleit használd mind változóneveknél, mind fájlneveknél, mind mappaneveknél. Jó, ha ezeket már az elején megszokod.
Így sem jó sajnos. Amúgy nem szoktam a bal szélen hagyni utasítást csak addig, amíg nem vagyok benne biztos hogy működik (így könnyebb átlátni hogy melyek a még kérdéses kódrészletek).
Itt van az asm: (A LATA, LATC-be nem akarok én b'00000100'-át írni. Csak a szimuláció miatt írtam be ezt a három sort, mert a programom sem tudta változtatni a LATA-t.)
Ne használj ékezetes karaktereket a deklarálásnál, definiálásnál sem. Egyszer én is belefutottam hasonlóba és utána megoldódott a "hiba".
Átírtam az összes ékezetet, de így sem jó. :no:
Digitálissá tetted a PORT -ot ? POR után az RA5 és RA3 analóg bemenet.
Tiltsd le a lábakról az analóg bemeneteket, akkor jó lesz szimulátor szerint. Abból jöttem rá, hogy 0xFF-et töltöttem a W-be, majd utána a LATA-ban csak 11010000 jelent meg, és ahol nullák vannak, azokon a lábakon van AD konverter bemenet. Itt egy hiba van az adatlapban, mert a PORTA leírásánál azt mondja, hogy 0x07-et kell az ADCON1-be tölteni ahhoz, hogy az RAx lábak mind digitális bemenetek legyenek, viszont ha megnézed az ADCON1 leírását, akkor pont ennek hatására maradnak az RAx lábak analógok. Tehát 0x0F-et tölts az ADCON1-be.
Ami viszont a szimulátorban lesz szerintem a hiba, hogy akármi van a lábon, a LATx-ben meg kell jelennie annak, ami oda írva lett. Én kipróbálnám a kódodat ezen módosítások nélkül a PIC-ben, szerintem a lábaknak billenniük kell. De ha nem, az se tragédia, sőt talán jobb ha nem, mert akkor ebből megtanulod, hogy mindig be kell állítani azt a néhány dolgot, amit használni szeretnél. Itt konkrétan ha digitális célra akarod használni a lábat, akkor le kell tiltani róla az analóg funkciókat. Idézet: „Én kipróbálnám a kódodat ezen módosítások nélkül a PIC-ben, szerintem a lábaknak billenniük kell.” Igen, a PIC-ben kikerül így a LATA-ra.  Idézet: „De ha nem, az se tragédia, sőt talán jobb ha nem, mert akkor ebből megtanulod, hogy mindig be kell állítani azt a néhány dolgot, amit használni szeretnél. Itt konkrétan ha digitális célra akarod használni a lábat, akkor le kell tiltani róla az analóg funkciókat.” Én úgy tudtam hogy alapból digitális és ha analóggá akarom tenni akkor kell átállítanom.  A másik dolog pedig, hogy ugyan ezekkel a konfigurációs beállításokkal egy másik programom tudta vezérelni a LATA-t... Vagy azt mondod hogy annál nem néztem a szimulátorban olyan portot amin van analóg láb?! Az könnyen lehet. Idézet: „Én úgy tudtam hogy alapból digitális és ha analóggá akarom tenni akkor kell átállítanom.” Minden láb úgy indul, hogy áramkörbe helyezve a lehető legkevesebb galibát okozza. Ezért indulnak a csak digitális lábak bemenetként, hogy ne fordulhasson elő két kimenet szembekapcsolódása. Az analóg lábak pedig azért analógként indulnak, hogy ha pl. 2,5V kerülne a digitális bemenetre, akkor az állandó áramfolyást jelentene a bemeneti puffer mosfetjein, ami akár tönkre is tehetné, de felesleges fogyasztást biztosan okozna. Ezért alapból a digitális puffer le van választva és nullára van húzva, a bemenet pedig analógként lebeghet bárhol. Idézet: „Vagy azt mondod hogy annál nem néztem a szimulátorban olyan portot amin van analóg láb?! Az könnyen lehet.” Vagy pedig tényleg hiba van az MPLAB SIM-ben ennél a tipusnál. Én még nem próbálgattam ilyet, mert mindig letiltom először az analóg funkciókat, ha nem kellenek.
Bővebben: itt
A fönti weboldalon van egy mondat, amit szeretném, ha elmagyaráznátok: Idézet: „RLF PORTD,F ;Balra forgatja a biteket (F most egyenlő a PORTD-vel)” A parancsban az F betű miért egyenlő ez esetben a PORTD-vel? Azt értem, hogy RLF balra forgatja PORTD filereguszter 8 bitjét a C jelzőbiten keresztül. Értem az Idézet: szintakszist is, csak éppen nem megy a fejembe a fönti mondat értelme. „RLF f,d”  Megmagyarázná ezt nekem valaki?
Azért, mert a PORTD-t elforgatjuk és az eredményt visszaírjuk a regiszterbe, tehát a PORTD-be.
F van beírva, mint a művelet célregisztere.
Tehát nem a W-be kerül az eredmény, hanem ezzel jelezzük, hogy a művelet eredménye az aktuálisan piszkált regiszterbe visszaíródik, jelen esetben a PORTD-be.
Sziasztok
Soros vezérlést szeretnék USART al, max 9 bájtot szeretnék egyszerre fogadni és egy tömbben tárolni. Műkodik is minden, de a hibakezelésre nincs ötletem. Jelenleg úgy oldottam meg, hogy a tömb futóindexe a 0x00 bájtra nullázodik, és dolgozza fel a parancsot a PIC, de szüségem lenne azért a 0 ra is  Hogy lehet úgy megoldani, hogy esetleges hiba esetén,(mondjuk véletelen fogad 1 bájtot valami külső zavar folytán) nem csúszik el nekem az egész. Jelenleg ez a primitív megoldás van:
de ezt ugye a 0 "szinkronizálja" Üdv
Szia!
Az üzenet elejét mindenképen meg kell jelölni, mert különben az elcsúszás után az adatokat félreértelmezheti az algoritmus. A megjelölés olyan karakterrel történhet, ami a többi adatban nem fordulhat elő. Egy másik hibajelenségre is fel kell készülni: a vett adat hibás. Az uart a keretezési és egymásra futási hibákat jelzőbitek segítségével mutatja. A jól vett, de nem megengedett karaktereket a programmal kell kiszűrni. Ehhez valamilyen ellenőrző összeget szoktak használni. (Kis távolságokra, laboratóriumi vagy otthoni körülmények esetén az ellenőrző összeg elhagyható.) Egyes hibák csak az uart letiltásával és újra engedélyezésével törölhetők. Minden hibás vétel esetén is ki kell olvasni az RCREG regisztert, mert a kiolvasás törni a megszakítási okot (programból nem kell, de nem is lehet). Egy karakter vételéhez csak egyszer szabad kiolvasni az RCSTA ill. RCREG regisztereket, mert az uartban egy fifo memória van, a kiolvasás után a következő karakter kerül az RCREG-be, illetve az RCSTA-regiszteben a következő karakter jelzőbitjei állnak be. Szia
Az USART tud olyat, hogy kilenc biten fogad, és a kilencedik bittel tudod jelezni, hogy most kezdődik az adatátvitel. Csak a számítógép nembiztos, hogy tud 9 biten adni, tehát ez nem biztos, hogy járható. De pl. csinálhatsz olyant, hogy amikor megjön egy bájt, akkor nullázod egy futó timer értékét. Így amikor egy csomag jön, akkor az mindig nullázza a timert. Ha megszakad valamiért az adatfogadás, akkor a csomag ugyan elveszik, de a timer túlcsordul, és amikor túlcsordult, akkor nullázod a tömb indexét. Itt lehet még finomítani, hogy két csomag között mi történjen, akkor is fusson a timer, vagy csak az első bájt indítsa, stb.
Egyszerű ellenőrzőösszeget tudsz csinálni, ha XOR műveletet végzel a vett bájtokon, és azt is elküldöd az adattal együtt, a másik oldalon meg kiszámolod és ellenőrzöd. Bonyolultabb megoldás valamilyen CRC használata, watt honlapján találsz róla információt. Idézet: „Az üzenet elejét mindenképen meg kell jelölni” Ez nem juttott eszembe. Az első fogadott karakter úgyis a parancs lesz abból nemlesz 256.Ezekszerint elég az "ertekel()" függvénybe annyit írni ha ismeretlen a parancs akkor nulláza a futót, kiolvassa a regisztereket, és el van intézve(?) Köszönöm a helpet
A timerre énis gondoltam csak túl folyamatos lesz az átvitel, és ha közbe megcsúszik akkor már mind1.
A 9 bittel meg nem akarom megbonyolítani. Ezen a CRCn viszont elgondolkozok, vagy legalábbis az XOR os dolgon. Köszönöm
Összevissza beszélek. Most esik el... az ertekel() mar önnmagában nullázza a futót.
Az a baj sehogy sem tudom megjelölni az elejét, mert bármi előfordulhat mint helyes adat. Marad az XOR. "Najó nem írkalok hülyeségeket, előbb gondolkodok"
Üdvözlök mindenkit!
Bár találtam problémámra illő topicot, de 2 éve nem írt bele senki. Szeretnék 8 bites adatot gyűjteni (napi 300 adat analóg ) van erre pic-em 16f84a és pic16f872 , programozni és beégetni is tudom. A pic paneljába kellene beledugni egy flash memória kártyát, és a pic által felírt adatokat kellene számítógépre vinni .(Nincs lehetőség vezetékes kapcsolatra, illetve nem azzal szeretném megoldani) c++- ban szintén tudok programozni ( pl printer port) vagy egy kártyaolvasót beleteszek. Ennek megvalósítására kérnék némi segítséget. tervezésben, panelgyártásban smd szinten otthon vagyok. lehetőleg érdemi hozzászólást kérnék. üdv.: Foxi
igen, ha megoldható. addig nincs fesz alatt a pices áramkör, amíg cserélem, persze ehhez be kell építeni egy foglalatot is.Még mindenféle dolog szóba jöhet...
Szia!
Ha az adatban egy bájton mind a 256 féle kombináció előfordul, akkor vagy a 9 bites adatátvitel, vagy az üzenet másképeni kódolása lehet a megoldás. A 9. bit adásával - vételével a pic oldalon nincs gond (Vételnél az RCSTA regiszter értékét előbb kell kiolvasni és eltárolni egy átmeneti változóban, aztán az RCREG-et, adásnál a 9. bitet a TXSTA regiszter 0. bitjébe beállítani, utána beírni a TSREG-et.) PC-ről történő adásnál a Line Control Regiszter 5. bitjével lehet a kiadott paritás bitet állítani. 16C450 adatlap Átkódolás: Ha az adatokat mondjuk nem binárisan küldöd, hanem átalakítod két karakteres hexadecimális formára (0,..9,A,..F) karaktereket küldöd, akkor a többi karakterből választhatsz kezdőkaraktert, vagy a kezdő karakter 7. bitjét bebillented, a többiét nem. Sokféle megoldás elképzelhető. Nem jó, ha a feldolgozás és a vétel közvetlenül egymás változóit állítja. Egy 16 bájtos körforgó vételi buffert ajánlok, amibe a vevő rutin beírja a vett karaktereket, a dekódoló rutin pedig akkor olvassa ki, ha a feldolgozásban elért a soron következő karakterig és a bufferben van vett karakter. Szia
Most nekem is keresnem kéne, de létezik FAT tábla kezeléséről példa SD-re a microchip oldalán. Ebből lehetne kiindulni.
A napi 300 adatra való tekintettel esetleg valami egyszerűbb megoldás (pl. I2C illesztésű EEPROM) is használható.
Köszönöm
Megpróbálok valami összefésülni ebből a sok-sok megoldásból  Másik kérdés: Valaki tud mutatni egy 93c86 os epprom író C kódot? Kezdek bekattanni, hogy minden parancs megy, olvasás, engedélyezések, még a write all is, de a sima írás nem... A pickit2 szoftver tudja írni, szóval nem az alaktrész hibás Thx
Szia!
A PicKit2 egy három csatornás logikai analizátor is egyben. A PGD és PCLK bemenetei 4k7 ellenállással a földre vannak húzva. Ha az AUX bemenetet használod az EEProm DO jelére, a másik kettőt a pic álta kiadott DI és CLK jelekre, és így felveszed az írás folyamatát, sok mindenre fény derülhet. Szia
Megírtam az első, kicsit bonyolultabb programomat:
Bővebben: KÉP1 A fényképről talán érthető a dolog. A nullakioltást is megoldottam: Bővebben: KÉP2 A 13 bites számot négy decimális számjeggyé konvertálni nem volt egyszerű. A nullakioltás és a multiplexelés már könnyebb volt. A két kijelző két A/D konverter eredményét fogja kiírni egyébként. Ismételten megköszönöm az eddigi segítségeteket mindannyitoknak! Mint látjátok volt értelme.
PIC16F877A -hoz kötném a DIP121A7212L szilárdtestrelét.
A relé adatlapja itt is elérhető. Azonban ebből az adatlapból sehogyan sem értem, hogyan kellene a mikrovezérlőhöz kötnöm, mert nem értem, melyik lábának mi a szerepe. Megmagyaráznátok-e nekem? 
Ez nem szilárdtestrelé, hanem csak mini relé. Ott van az adatlapban a rajzon, hogy melyik lábnak mi a szerepe. Mi nem világos rajta?
|
Bejelentkezés
Hirdetés |
