Fórum témák
» Több friss téma |
Nem , ez csak az ADC-nek kell leosztani. Jó lesz igazad van , köszönöm.
Hali!
18F-es PIC-en lévő DACOUT kimenettel lehetne direktbe (műveleti erősítő stb. nélkül) állítani egy karakteres kijelző kontrasztját? Még nem használtam ezt a kimenetet.  További kérdésem, hogy viszonylag pontos, a program futása alatt változtatható késleltetésekhez mit ajánlanátok? Olyan 100us (de inkább 10us) - 500ms-os tartományban kellene változtatnom a késleltetést. Jelenleg a timer2 modult használom (1:4 és 1:1-es osztókkal) és a PR2 regisztert feltöltöm 100-zal, így 100us-onként kapok egy TMR2IF flag bitet (16Mhz-es órajel esetén) amit while ciklusban figyelek, majd ezt a függvényt hívom meg többször attól függően, hogy hány ms kell. Ez mind működik csak 10ms helyett 12ms-os késleltetést kapok. Ha külső 16MHz-ről ketyegne a PIC akkor mennyivel lenne pontosabb? Vagy a SOSCI-SOSCO bemenetekre tegyek pl. egy 3,2768MHz-es kvarcot és használjak más timer-t?  Kinek mi vállt be?
Helló!
Miért írja ki mindig ezt a fordítóm : 158 317 Operator '' is not applicable to these operands '' lcd.c Szerintetek mi lehet itt a hiba ?(A display_v egy változó. )
MikroC a fordító. A hozzászólás módosítva: Okt 25, 2015
No de milyen típusú és "látszik -e" onnan, ahol ez a sor van?
A hozzászólás módosítva: Okt 25, 2015
A > művelet nem értelmezett karakterfüzérre...
A hozzászólás módosítva: Okt 25, 2015
Előbb a karakterfüzért kell álalakítani egész (signed vagy unsigned)(int vagy char) esetleg float típusba.
A hozzászólás módosítva: Okt 25, 2015
De mikor létrehoztam , már meg van adva :
Idézet: „char *display_v = "0.000";” Így nem értem miért kellene még egyszer. A hozzászólás módosítva: Okt 25, 2015
Ez a fordító egy sime C fordító. Nem értelmezi a karakterfüzér (char*) és az egész (singed vagy unsigned)(int vagy char) között a nagyobb műveletet.
Két megoldás van: - a (char*) -ot konvertálod egyészre vagy float-ra. - megírod az összehasonlítást: f (display_v[0] >= 49)... A hozzászólás módosítva: Okt 26, 2015
Szia!
A 100usec megszakítás jó. A megszakítás rendre figyel egy int változót (időzítő). Ha ennek értéke 0 nem foglalkozik vele. Ha van benne valamilyen érték akkor minden megszakításkor csökkenti. Ha elérte a 0-t akkor bebillent egy jelzőbitet és kész. A főprogramban csak ezt a bitet kell figyelni ha 1 törülni kell és végrehajtani az adott feladatot. rendkívül rugalmas 100us és 6,5531 s között bármilyen időzítésre jó (és pontos). 16MHz esetén PR2=199 T2post=2. A PR2 regiszterbe mindig 1 -el kisebb számot kell írni. indítás: a változóba csak be kell írni a számot és figyelni a jelzőbitet. Ha egészen pontos idő kell TMR2-őt nullázni kell. Hosszabb időknél nem fontos... üdv.: Foxi A hozzászólás módosítva: Okt 25, 2015
Helló!
Nekem most nem szükséges a megszakítás, tehát blokkoló függvény is lehet. Viszont arra tényleg nem gondoltam, hogy eggyel kevesebbet kellene beírni a PR2 regiszterbe. Ki fogom próbálni köszi a tippet! Szerintem annyit fogok még csinálni ha mégse jönne be, hogy bekapcsolom a PLL-t (azaz Fosc = 64MHz), hogy az utasítási idők végrehajtási ideje is csökkenjen.
Ha hivatalosan egy PIC 16MHz-es kvarcot támogat maximum, de van belső négyszerezője (PLL), akkor kikapcsolt PLL-lel tehetek rá mondjuk egy 32,768MHz-es kvarcot? Másik kérdés, hogy bekapcsolt PLL-lel a 16,384MHz-es kvarcot bírnia kellene még?
A válasz nem elfogadható okfejtés nélkül! Szakmai fórumon szakmai választ várok! A 16 és 16,384 nincs olyan messze egymástól, hogy nagyon beleszóljon a működésbe. Ha valami más van a háttérben, akkor kéretik azt leírni. Még belső tunningra is van lehetőség a pic-ekben órajel kalibrálás céljából, ezért kételkedem a második nemleges válaszodban.
A belso primer oszci ennyivel birkozik meg csak HIVATALOSAN, magyaran a gyarto ezt garantalja MINDEN darab eseten. Ergo rateheted, csak lehet hogy egyaltalan nem megy es az is lehet, hogy siman akar tiz darab is megy vele, az utolso meg mar nem. Es akkor nem fogod tudni, mi a baj....
A masodik kerdesre ugyanez a valasz, annyival megspekelve, hogy itt az elteres 4x-es lesz, tehat meg valoszinubb valami problema. Tehat ez a zona incerta lesz innentol. (Szerintem felesleges bizonytalansagot vinni a rendszerbe, nincs akkora kulonbseg a 16 es a 16.384 kozott, hogy ez megerje. Irjal hatekonyabb kodot inkabb  )
Köszi a választ.
Nem is húzni akarom. Csak azért vetődött fel bennem az ötlet, hogy megspóroljak két lábat amire menne egy olyan értékű kvarc aminek kettő hatványa a pontos időzítések végett. Pontosabban másra kell az a két láb. Bár így is megspórolható ha beérem alacsonyabb órajellel is, azaz nem 16,384MHz-eset teszek rá, hanem pl. csak a felét és azt négyszerezem. Ez így már járható út, nem? Vagy az is elő van írva, hogy csak 4;8;16 és 20MHz-es lehet az órajel?
Szia! A timer2 -vel pontos másodperc alapú időzítéseket tudsz csinálni, és nem kell semmiféle hókusz-pókusz. pl 16MHz esetén PR2 regisztert beállítod 199-re a TMR2 utó osztóját 2-re, és máris van 0,001sec pontos megszakításod. ebből igen egyszerű akár másodperces órajelet előállítani.
Csak elméleti kérdés volt
A panelt most tervezem a pic-hez ami több projekthez is fel lesz használva, és a későbbiekben jól jöhet a még pontosabb időzítés. De ha nem muszáj akkor nem pazarolnék el még két lábat egy másik kvarcra. Ezért volt a poszt.
Kedves fórumtársak! Ti vagytok az utolsó reményeim... A bajom a következő: rádiófrekvencián szeretnék adatot továbbítani. Adott egy 16f88 PIC , mely a bemeneteinek függvényében generál egy kódot, melyet USART kódként tovább küld egy RF adó bemenetére (plussz kiírja az LCD-re a küldött adatot). A kód sugárzása folyamatos, míg a tápfeszültség megvan. A másik oldalt van egy RF vevő, melynek a kimenete megy egy másik 16f88 PIC rx lábára, mely próbálja értelmezni a kapott kódot. Na most itt van a baj. Az átküldött kód sok hamis karaktert tartalmaz a vevő oldalán. Irtam egy progit, ami folyamatosan írja az LCD-re az olvasott adatot. Hébe-hóba van közte helyesnek tűnő karakter is, de több a valótlan. A kérdésem az lenne, mi okozhatja ezt? A rádiófrekvenciás zavart( más adó által okozott) kizárnám, mivel az saját adó kikapcsolása után már-már teljesen megáll az új fogadott karakterek kijelzése. Az adó vevő távolsága 10-20cm. Arra gondoltam, hogy az nem lehet baj, hogy az adó oldalon külső kvarc az órajel(16Mhz), míg a vevő oldalon pedig a belső RC az ütemadója a PIC-nek 8Mhz-en. Azért kell a belső oszcillátort használni, mert tapasztalataim szerint az lcd-t nem lehet a B portra rakni , ha az usart modult akarom használni, mert az Usart init() parancs után az lcd kijelzés leáll. Hiába configolom az lcd, úgy hogy a rx láb szabad legyen, valahogy az eredmény ugyanaz, az lcd nem frissül(kifagy).Ha viszont az LCD az A porton van, működik az usart modul, viszont a külső osc. alkalmazása nem lehet. Végül a két kód:
Adó oldal
Vevő oldal:
Szkóppal nézve az RF adó bemenete és az RF vevő kimenete nagyon hasonló jeleket produkál. Pontosan nem összehasonlítható, mert a szkóp nem tárolós. A kijelzett helyen azonos a két jel futása. Van valami ötlete valakinek, hogy mi lehet a rossz? A hozzászólás módosítva: Okt 28, 2015
Az UART-ra vonatkozó megszakítás jelzők hardveresen törlődnek, nem kell őket szoftveresen piszkálni.
Nálam ez okozott olyan hibát, hogy hol működött hol nem.
Egy logikai analizátorral kb. egy perc lenne megnézni, hogy az RF vevő mit küld a PIC felé. Nem drága eszköz, érdemes beszerezni. Ez viszont:
Idézet: Ha az adást lekapcsolod, akkor a vételnek is meg kell(ene) szűnnie azonnal, nem? „A rádiófrekvenciás zavart( más adó által okozott) kizárnám, mivel az saját adó kikapcsolása után már-már teljesen megáll az új fogadott karakterek kijelzése.”
Eloszor kosd ossze az adot a vevovel droton, hogy lasd, az biztosan jo-e. Ha igen, akkor lehet a radiokban keresni a hibat.
Köszönöm válaszod. PIR1.RCIF = 0; utasításra gondolsz az interrupt-ba? Kínomban írtam bele, hogy RCIF regiszter biztos üres legyen az új karakter fogadása előtt. De kiveszem a progiból, biztos ami biztos.
Ien arra gondoltam, de azt elfelejtettem kérdezni, hogy milyen PIC mert azt nem tudom, hogy minden PIC-nél hardveres-e.
Köszönök minden segítséget. Ha az adót lekapcsolod, a környezetből szedhet össze valamilyen haszontalan jelet a vevő. A drótós összekötés nem rossz ötlet, csak akkor valahogy az egészet egy tápról kell hajtani.Próbálkozom, majd jelentkezem.
cross51: Most éppen ezekkel játszadozom. Próbálom a sebességeket állítani, mind adó, mind vevő oldalon, de csak rosszabb. Az Rf modulom, 4800 sebességnél már nem is működik. Az általad írt regiszter nullázásának kivétele a megszakításból is hatástalan (vagyis feleslegesen van a progiba). Esetleg valami más ötlet? Egyébként a 16f88-nak van hardveres UART modulja. A hozzászólás módosítva: Okt 28, 2015
Szia!
Ugyanezzel küzdöttem a múlt héten. Egy olcsó, egyszerű adó-vevő párt használtam, amiben semmi kódolás nincs. Gyakorlatilag közel ugyanez volt a gondom. Nekem most úgy működik, hogy minden egyes byte után újabb szinkronizáló jelet küld. És még így sem tökéletes. Az adó-vevő elvi távolsága 25-30m. Tiszta átsugárzás esetén 5-6m-ig hibátlanul mennek az adatok, majd egyre több lessz a hibás karakter. A vevő beállításai
Nem kell egy taprol hajtani - eleg, ha a foldeket osszekotod (feltetelezve, hogy azonos feszultsegen mukodik mindket PIC).
Ötletek:
1 - Valóban nem kell törölni az RCIF és TXIF biteket. Ha nem akarsz adni a TXIE -t 0 -ra kell állítani. 2 - Okozhatja a hibás vételt a karakterek egymásrafutása. Minden karakter után van egy kiíratás... 3 - Nincs lekezelve a vételi hiba (FERR és OERR) Válaszd ketté a funkciót. Vegyél fel egy buffert, amibe a vett karakterek kerülnek. A mérete legyen vagyobb, mint a leghosszabb táviratod. Hozzá három adat kell még: A bufferbenn levő karatkarak száma, a beírási és kiolvasási index. A vételi megszakítási rutin feladata: - RCIF bit vizsgálata, csak akkor hajtsa végre az alábbiakat, ha valóban vételi megszakítás volt - RCSTA kiolvasása (csak egyszer) és eltárolása - A tárolt értéken a FERR és OERR jelzőbitek vizsgálata - Ha FERR == 0 és OERR == 0: RCREG kiolvasása, a vett adatot írja be a bufferbe, a vételi indexet növelje (ha a buffer végére ért, nullázza) és növelje a bufferben levő karakteker számát. - Ha FERR != 0 vagy OERR != 0: Tiltsa le a vevvőt, olvassa ki a RCREG -et (dobja el a vett értéket), engedélyezze a vevőt. A kiírató rutin feladatai: - Figyelje, hogy hány adat van a bufferben. - Ha van adat, vegye ki a soron következőt, növelje a kiolvasási indexet (ha a buffer végére ért, nullázza), primitív művelettel csökkentse (megszakítás nem juthat érvényre a kezdetétől a végéig) a bufferben levő karakterek számát. - Dolgozza fel az adatot - írja ki. A hozzászólás módosítva: Okt 29, 2015
|
Bejelentkezés
Hirdetés |
