Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Sziasztok!
Óra IC-t szeretnék használni időmérésre és kijelzésre. Már többször rákérdeztem a fórumban de sajnos senki nem tudott használható tanáccsal ellátni. A problémám az, hogy egy idő után ledöglik a program. Az órára rá van kötve egy elem, miután elindítom, bármikor lekérdezem megy. Tehát valami más a baj. Lehet, hogy az I2C kommunikációnál rontok el valamit? Ott nem csordulhat túl valami? Nem kell valamit resetelnem időnként ??? Létszi segítsetek!!! Köszi
Ne gondold, hogy azért nem válaszolunk, mert kivételezünk veled, egyszerűen nem tudjuk(bár én csak a saját nevemben beszélhetek).
Láttam korábban a beszúrt forrásrészletet is, abból csak az derült ki, hogy egy jeled nem jön vissza, ezért nem lép ki az ellenőrző ciklusból a program. Hogy ez a jel miért nem jön vissza, azt kéne kideríteni. Hibakezelést is beiktathatsz, hogy ha n-szer nem jön a jel, akkor hibával lépjen ki, jelezve azt, hogy elakadt. Esetleg ha a jelet újra lehet kérni, azt is megkísérelheti. Remélem jól értelmezem, hogy a jel az órától kéne jöjjön. Ha érdekes esetleg, nekem is van ezzel az órával alkalmazásom(három is működik, nem volt velük gond évek óta, pedig folyamatosan mennek...) csak 16F876-al megy és assemblerben írtam, ezért C-ben nem nagyon tudok segíteni.
Hali!
Köszi a gyors választ! Azért zavarodtam össze, mert ha elindítom a progit és mondjuk az óra olvasást rárakom egy gombra, amelyet időnként megnyomok, akkor napestig is elketyeg. Időzítési gondra már nem nagyon tudok gondolni, mert így is túl nagy késleltetéseket hagytam néhol. Ezért tippelnék arra, hogy valami túlcsordul az órával való kommunikáció során! Bármilyen tippet szívesen fogadnék! Köszi
Hi!
Van itt még egy apróság. Ha nem a 16F877-es próbapanelen nézem, hanem egy PICDEM2-es panelen, akkor jóval több ideig fut a progi. Több, mint egy óráig! Esetleg az órajel, vagy valamilyen konfigurációs bitek nem zavarhatnak be? Az F877-esen 20Mhz-s kvarc van, annál az SSPDA=49 megfelelő, nem? Üdv
Hali!!
nos további tesztelésnek vetettem alá a kapcsolásomat, és beszereztem egy frekvenciamérőt az eredmény: a kvarc szépen ketyeg 4MHz-n tehát a baj nem ezzel van viszont rájöttem hogy ha az egyébként levegöben logo (mert még nem raktam össze teljesen) rb3 lábhoz hozzáérek a program futása azonnal leáll. ha elengedem előfordul, hogy kell egy perc is mire ujra elindul ezen felbuzdulva gondolván hogy kontakt hiba azonnal szédszedtem az egészet és ujra összeraktam egy másik panelen... nem nyert, a hiba ugyanaz a b portot az lcd adat csatornájának használom asm kodot mellékelem hátha ez segit ja és ha fix potenciálra teszem (0) akkor persze szépen ketyeg
Hali!
Lenne még egy kérdésem! C-ben vagy az MPLAB-ban mit kell beállítani ahhoz, hogy a RESET gomb hatására elinduljon a programom? Eddig ezeket állítottam be: WDT = OFF LVP = OFF ODC = HS köszi
Szerintem úgy kellene, hogy meg kell vizsgálni a portot. majd utána call foprogram szerintem.
Nem valami #pragma cucc kellene?
Mert ha nem indul el fejlesztő nélkül a kártyán, akkor hiába írok bele plussz sorokat, nem??? Vagy nem egyre gondolunk? Köszi
Meg mondom még nem nagyon tudok én se progizni) De nem szeretnék rossz tanácsot, rosz útra vezetni Téged. inkább csendben figyelek Ha valamit tudok akkor szólok.
Idézet: „Azért zavarodtam össze, mert ha elindítom a progit és mondjuk az óra olvasást rárakom egy gombra, amelyet időnként megnyomok, akkor napestig is elketyeg.” Akkor az a ciklus amiben beragad nem más, mint ami érzékelné, hogy jön egy megszakításjel az óra IC-től? Amikor jön a megszakításkérés, akkor kiolvasod az óra tartalmát ugye? És az egyik ilyennél belefagy? Megszakításban kezeled a kérést?
Ez van a konfigodban: "_LVP_ON"
Ezt írd át OFF-ra, mert az RB3 láb a PGM, azaz az alacsony feszültségű programozást bekapcsoló láb.
Nem használtam megszakításokat.
Csak a while-ba beraktam egy if-et, hogy ha klikk volt, akkor Ora_Olvasas(), egyébként meg csak print!
Furcsa kérdés! A reset gomb hatására mindig újra indul a programod. Ha a programodat egy gomb megnyomására akarod indítani, az nem RESET gomb lesz!
Ha nem titok, felteszed a kódot? Nem vagyok egy nagy C guru, de hátha meglátok valami... :merges2:
Előre is köszi!
Már fel raktam, ezért nem rakom fel mégegyszer, mert le leszek szidva: Bővebben: Link
Hello!
Hogy lehet PIC16f84-re véletlen számot generálni? Nincs valakinek ilyen programja véletlenül?
Előkerestem a régebben beszúrt kódodat. A szerint a Buffer Full Status bit -et vizsgálod, ami akkor jelez, ha az I2C buffer tele van.
Kérdésem: Az óra IC mikor küld adatot?
Ezt most találtam ki:
Deklarálsz egy változót 8 bitest. Ezt minden megszakításban növeled egyel. (Ha nem használsz megszakítást semmire, akkor csak ezért is érdemes. Az sem gond, ha pl. a timer 1-et másra használod, mert nem zavar be semmit, ha túlcsordulásakor megszakítást okoz, amikor is lépteted a számlálódat.) Mikor szükséged van egy számra, csak kiolvasod. Nagy a valószínűsége, hogy két egyforma számot nem sűrűn olvasol ki belőle egymás után. Minél gyorsabban változik az értéke két kiolvasás között, annál jobb véletlenszámot kapsz.
Igazad lehet!
Ott akad meg a debug is. Csak azt nem értem, hogyan lehet ez! A debug a ReadI2C függvényre hivatkozik, amit én nem is használok. Ha csak a getcI2C nem azt használja. Hogy lehetne kiküszönölni a hibát? Van ötleted? Thx.
Berakom a prtScr-t. Hátha így egyértelműbb a dolog.
Ezek szerint akkor a getsI2C hibás ??? Vagy az SSPBUF-ot valamikor ürítenem kéne?
Nagyon sok dolgot nem értek még rendesen a C-ben, és a programodban sem.
1. Nem értem, hogy mikor küld adatot az óra. Kéred a programból? Mikor és milyen sűrűn? A kódrészlet amit régebben belinkeltél: Idézet: „unsigned char ReadI2C( void ) { SSPCON2bits.RCEN = 1; // enable master for 1 byte reception while ( !SSPSTATbits.BF ); // wait until byte received return ( SSPBUF ); // return with read byte }” Ez ha jól látom(ClockLibTest projectben nyílik fel) a C18 saját i2c_read.c rutinja, amit valamelyik könyvtárrutin hív meg(na itt sem tiszta a kép, még a fogalmakkal sem). Naszóval az egyik gyári rutinhívásban akad el a programod, hogy miért nem tudom egyelőre. Hátha egy C18 guru tud segyíteni!
Nem. Egyszerűen nem érkezik "I2C buffer tele" jeled, ezért a "while-ciklus" soha nem ér véget.
Ha előfordulhat, hogy azután törlöd a SSPSTATbits.BF bitet, hogy beérkezett egy bájt, de nem olvastad még ki, akkor örökre bennt marad a legutoljára kiolvasott adat a bufferben, és soha nem fog a SSPSTATbits.BF beállítódni. Megjegyzem ,hogy a gyári rutin, elég fapados, mert amint látszik simán beragadhat. Valami számlálást végezhetne és hibát jelezhetne, mondjuk a (nemlétező) híváskor megadható számosságú ciklus után. Na de nem lehet minden tökéletes.. Idézet: „asm kodot mellékelem hátha ez segit” Látod ezt megtehetted volna előbb is, és akkor már megis lenne az egyik hibaforrás: _LVP_ON helyett _LVP_OFF kell. Ezért fagyott meg, ha az RB3 lábhoz hozzáérsz. De egyébként amikor az ilyet észrevesszük, akkor azt kellene csinálni, hogy elővesszük az adatlapot, és megnézzük, hogy milyen funkciói vannak az adott lábnak. Na ha ezt megtetted volna, akkor láttad volna azt is, hogy ott áll mellette, hogy "programming pin in LVP mode."
Bocs a dupla válaszért, nekem nem jelentek meg ezek a hozzászólások.
Hű megszakításokat még nem csináltam. De hogy nézne ki mondjuk egy olyan program, ahol 1 és 6 között akarnék egy számot generálni?
Kerestem neten pseudo-random programra, de nem találtam használhatót.
Hogy nézne ki? Csak leírni tudom, de szerintem egyszerű, csak a megszakításokat kell megérteni, ami nem bonyi.
Mondjuk Timer0 okoz megszakításokat 100Hz-el. A megszakításban egy regisztert(változót) növelünk 1-6-ig(ha 7 lenne beleírunk 1-et). Ezzel kész a véletlenszám, mert a főprogram és a megszakítás szála soha, ill. csak nagyon spéci esetben fut szinkronban, ezért a kiolvasás pillanatában a számunk teljesen véletlenül lesz annyi amennyi, mert a kiolvasás sokkal ritkábban történik, mint ahányszor a számunk túlcsordul. Én legalább is nem hiszem, hogy másodpercenként 100 véletlenszám kell... vagy mégis? Még annyi eszembe jutott, hogy természetesen ezt a megszakítást más egyéb időzítési célra is fel lehet használni, akár egy stoppernek, vagy billentyűzet lekérdezésnek, LED villogtatás ütemének stb-stb.
köszi, kipróbálom igaz, előbb a megszakításokba kell beleásnom magam
gondoltam csinálok egy dobókocka szimulálást ledekkel, persze majd másra kéne a véletlenszám generálása
A megszakítás egy olyan szubrutinhívás, aminek a belépési címe rögzített, és nem egy program parancs(CALL) hívja, hanem egy periféria(pl. Timer0) megszakítás jele(T0IF). Nézd meg az INTCON regisztert, ill. az adatlap interrupt fejezetét.
A Microchip matematikai APP_ok közt van radom number generáló kód PIC-re.
Kíváncsi lennék hogyan oldják meg. Nem akarom fényezni a megoldásomat, de szerintem egyrészt nagyon tömör(kevés programlépésből áll), valamint valós véletlenszámot generál(nem valami számoltat), ha nem szinkronizált időközönként olvassuk ki a számunkat(ez egy elágazásos feltételekkel teli programban legtöbbször megoldott), . Megnézem az APP-okat, de lehet, hogy egy link segítene, ha már Te megtaláltad!
|
Bejelentkezés
Hirdetés |