Fórum témák
» Több friss téma |
Fórum » PIC - Miértek, hogyanok haladóknak
Biztos, hogy jó a baudrate? A mintaprogi működik?
Tuti a megfelelő kódot küldöd ki a terminallal(a mintaprogram válasza hexában kiértékelve megfelelő értéket mutat?)? Próbáltad más kóddal is(nem vezérlő karakterrel)?
Szia watt,
Hat igen, a bank valtas az mindig is korulmenyes egy dolog, nehez jol megoldani. Ketsegkivul a BANK0/BANK1 makroidnak megvan az az elonye, hogy amennyiben tudod csak ezt a ket bankot hasznalod akkor csak ki kell venni az RP1 bitek billegteteset es maris rovidebb a program De jobb lenne egy hatekonyabb makro gyujtemeny. Valaki itt mar elkezdett ezzel foglalkozni es voltak jo otletek. Pl. hogy egy forditas ideju valtozoban el kell tarolni mi az aktualis bank, es ha nem szukseges akkor nincs bank valtas - hiaba van kiadva a bankvalto makro. Az egyetlen problema, hogy ilyekor a cimkek utan nem lehetunk biztosak benne mi az aktualis bank, igy cimke utan elso memoria hozzafereskor mindenkeppen inicializalni kell a bank szelekciot. Ezt manualisan a legegyszerubb megadni egy speci makroval, de az a baj, hogy ezzel a finomabb optimalizaciokat nem lehet vele megoldani - csak kezzel. Tehat pl honnan fogja tudni a makrom, hogy egy masik rutint meghivok az milyen bank beallitasokkal terhet vissza? De forditva is: honnan tudja a rutin elejen, hogy az osszes hely ahonnan meghivodik csak es kizarolag X bankkal fogja a rutint meghvni? Na mindegy, szoval tokeletes optimalizacio nincs hacsak nem epit az ember fel ra egy forditot Idézet: „Ha majd túl leszek annak a megfejtésén hogy miért nem megy ez soros vétel, a string küldő algoritmus érdekelne...Hogyan működik ez a dolog?” nezd majd meg a help-ben a DT direktivat. Azonkivul az adatlapban a kiszmitott goto -t (computed goto). Vegulis ha teoretikailag tokeletesre akarod csinalni akkor bonyolult az algoritmus (mondjuk en inkabb ugy fogalmaznek osszetett), de ha kezdetben nem foglalkozol laphatarokkal akkor az alapjait ennek a technikanak konnyeden elsajatithatod. Majd ha oda ersz akkor segitunk.
Igen. Igazából nem is értem, miért nem oldották meg ezt rendesen a fejlesztők! Lehet, hogy nem is olyan egyszerű, pont ahogy fejtegeted?
És a dolog pikantériája, hogy még a 18F-eknél sem szabadul meg teljesen az ember a bankoktól, de legalább a funció regeknél nem kell váltogatni és néhány trükkel a váltogatást is minimumra lehet csökkenteni a user RAM területen is(Biztos ismered, hogy az 1-es bankra váltasz(256bájt) és az Access részt innen is el lehet értni(+128bájt). Ez elég szokott lenni...).
A GSM modulnál van "auto baud rate" opció, ez van kiválasztva, de ha manuálisan beállítom 9600 ra akkor sem megy. Az adás pedig működik. Olyan eset gondolom nem lehetséges hogy az adás megy a vétel pedig nem. Vagy mégis? Próbálkoztam más karakterrel is ( "R" - Ring) , de azzal sem ment. Azért a CR t erőltettem mert ez az első karakter a válasz során. Hogy a te programod működik e ezen a herdveren...? Jó kérdés, és még jobb ötlet. Átirkálom a programot és kipróbálom. A baj az hogy nem látom mit küld vissza a modul, hogy küld e egyáltalán valamit. Attól hogy a modul össze van kötve a PIC el, párhuzamosan rácsatlakozhatok az RX/TX lábaira egy RS232 illesztővel PC felé? Akkor látnám a Bray Terminálon mit is csinálok, ez lenne a tökéletes megoldás.
Azt meg lehet oldani, hogy a digitális jelszintű RX/TX lábakra lehet tenni egy MAX232-t, de mindkét vonalra a meghajtó egységet (transmitter). Így majd két PC-s soros portba lehet becsatlakozni a jelekkel, az egyiken a TX-et tudod megfigyelni, a másikon az RX-et.
Én azt javaslom, hogy először ne a GSM modulon próbáld a programod, hanem a PC-n(MAX232 kell). A Terminalból küld ki a karaktert(bármilyet), és nézd meg úgy jó-e! Ha igen, akkor már ne a programban keresd a hibát...
Elég egy MAX is, mert két egység van bennük. De amit mondasz működik.
Én sem írtam kettőről Csak soros portból kell kettő a PC-re, ha mindkét irányt debugolni akarja az ember.
Elnézést, tényleg! Kicsit összetett volt a mondatod, belekavarodtam!
Ok, köszönöm. Összerakok egy illesztőt és kipróbálom, de szerintem a program biztos hogy működik. Mert ahogy írtam, ha a nem az RCREG ből kiolvasott adatot hasonlítom össze hanem helyette én töltöm fel a regisztert a helyes értékkel akkor működik a program, világít a PORTB,3 ra kötött led. Ha a két regiszter értéke egyezik akkor a Z bit 1, a btfss feltétel miatt pedig átugorja a goto - t és bebillenti a PORTB,3 at. De biztos ami biztos kipróbálom az illesztővel.
Úgy van, biztos, ami biztos! Nem szabad elmenni ilyen mellett, ha a hiba kizárására van egyszerű lehetőség! Utána ráérsz loggolni a vonalakat a már úgy is illesztett MAX-al. Egyébként felváltva is lehet vizsgálódni, akkor elég egy COM port is.
Ezt örömmel hallom mert csak 1 COM portom van... Nekiállok és meglátjuk mi az eredmény. De ha a terminal programmal működni fog akkor egyszerűen kifogytam az ötletekből. A modul és az F628A láb lábbal direktben (RX-TX / TX - RX) össze van kötve, nem lehet elszúrni. (vagy mégis?) Akkor mi lehet még a gond?
Igen, meg ugye sokan a MOVFF utasitast hasznaljak ha nem fernek el a ram-ban, ami annyibol jobb, mintha bankot valtogatnanak, hogy igy ket kulonbozo bankon levo ram teruletrol lehet dolgozni. (Ugye hagyomanyosan ez eleg maceras is lehet akar, tehat
(MOVLB - re cserelodik le a BANKSEL, tehat erdemesebb BANKSEL var1 -et irni...) Sot a BSR pl bank 0-ra van allitva, de a bank1-en levo valtozot at akarjuk atmasolni a bank 2-re, akkor is mukodik a MOVFF es utana meg mindig lehet a bank0-rol dolgozni a 'szinpla' utasitasokkal, pl:
Szoval 18F-nel azert mar sokkal jobbak a lehetosegek azert. Nyilvan meg azzal is el lehet jatszadozni, hogy az access bankot 'regiszternek' hasznalja az ember, azaz oda at lehet emelni a gyakran hasznalt valtozokat vagy permanensen, vagy ugy, hogy mikor a valtozot egy rutin sokat hasznalja akkor atemeli oda, majd mikor mar nem kell neki vissza masolja a tartalmat az 'igazi helyre'. Tehat kb mint ahogy AVR-eknel szokas vagy akar az x86-osoknal a regiszter hasznalat. De az a baj ezek mar olyan szintu muveletek ahol mar jol johet a magas szintu nyelv optimalizacios kepessege - nyilvan kezzel is meg lehet ezeket csinlni csak egy nagyobb feladatnal mar macerasabb lehet kiszmolni meg minden valtoztatasnal figyelni arra, hogy mindig a legoptimalisabb maradjon a ram nyulkalas.
Én a soros portok első hardveres tesztjének azt szoktam alkalmazni, hogy az egységből (itt ez most a PIC a programoddal) kimenő TX és RX lábakat összekötöm, ezzel csinálok egy fizikai "visszahurkot".
Ebben az esetben a TX-en keresztül kiküldött adatnak be kell esnie az RX lábon, amit utána ellenőrizni lehet, hogy tényleg megjött-e, tényleg az-e, aminek kell lennie. Ha ez a hardveres loopback teszt működik, csak utána lépek tovább a külső egységgel történő összekötésre. Ilyen jellegű tesztet Te csináltál a PIC-kel?
Ha a nagyobb feladat alatt azt érted, hogy matematikai műveletek sora, akkor igen, oda már kell a magasabb szintű nyelv. Bevallom talán még a gyökvonást sem hiszem, hogy lekódolnám asm-ban, inkább keresnék egy rutint, de akkor inkább a C.
Ezzel kapcsolatban van "rossz" élményem is, mikor arcsinust és arctangenst próbáltam használni egy 18F2321-ben, és 10 ilyen utasítás + némi kapcsolódó kód telenyomta a memóriát(4kWord)! Ekkor döntöttem úgy, hogy inkább a nyers adatokat áttolom a PC-be, majd az elszámolgat vele. De ez már más történet.
Ezt én még soha nem próbáltam így, de nagyon ötletes, legközelebb eszembe fog jutni!
A legtöbb esetben PC-vel van összekötve a PIC és a PC azért elég megbízható. Így kézenfekvő, hogy elhiggyük neki amit küld be kell érkezzen, ha jó a baud rate. A PIC visszacsatolós próba csak a program működését tesztelheti, mert bármilyen bauddal működik, amit a PIC-ben kiválasztasz és az nem biztos, hogy a külső eszközzel is együt tud működni. Ettől függetlenül magát a soros port lekezelő rutinjait tényleg nagyon jól le lehet próbálni, akár menyus mostani helyzetében is!
Nem ezt nem próbáltam le így hurokba kötve. És most már nincs is lehetőségem mert be van ülteve a GSM modul is. A PIC RX / TX lábai alatti PAD ről közvetlenül átmegy a TOP ról a vezetősáv a BUTTON oldalra tehát bele sem tudok nyúlni utólag. A teljes BUTTON oldalt takarja a GSM modul aminek a szélein vannak a PAD jei. A GSM modul egy 40 lábú SMD kivitel, nem szívesen forrasztgatná ki. De nekem csak a vétellel van bajom, az adást le tudom próbálni úgy hogy kiadok egy olyan AT parancsot a GSM modulnak ami gyárilag nincs felprogramozva. Ha ezt végrehajtja akkor az adás megy, márpedig megy. A csengetési számot hangerőt...stb mindet tudom változtatni ha a PIC el beküldöm a modulba. De hogy visszafelé miért nem jön adat, vagy éppen mi jön azt nem tudom. Ezért próbáltam meg egy biztosan ismert karaktert azonosítani a vétel során. És itt el is akadtam...
Talán ha gány módon felemelem a PIC lábait a PAD ekről és összekötöm őket...Van még SSOP F628A m ha ezzel esetleg kinyírom. Ki is próbálom, köszi az ötletet.
Idézet: „bármilyen bauddal működik, amit a PIC-ben kiválasztasz és az nem biztos, hogy a külső eszközzel is együt tud működni” Igen, szerintem pont ez a jó benne. Ha véletlenül a baud rate felprogramozásánál elront valamit az ember, de amúgy jól működik az adás és a vétel is, akkor csak szenved, hogy hol a hiba, miért nem érkezik meg, amire várt. A local loopback esetén a baud rate mindegy, ellenben ha itt nem jön meg a várt adat, akkor ott a küldésnél vagy a fogadásnál biztosan van még javítani való. Amennyiben a soros adási és vételi rutinok jók, akkor érdemes még egy tesztet elvégezni: egy végtelen ciklusban nyomni kifelé a TX lábon az 'U' karaktereket (0x55 kód), és rámérni egy frekimérővel a TX vezetékre. Az általában használatos formátumnál (8N1=8 adatbit, nincs paritás, 1 stopbit) az 'U' karakterek kiküldése gyakorlatilag minden bitnél invertálja a TX vonalat, így a frekimérővel a kommunikáció bitsebességének felét fogjuk mérni. Ezzel a teszttel kiszűrhető, ha rosszul programoztuk fel a baud rate generátort.
Sziasztok!
Van egy olyan kérdésem, hogy egy 16F877-es mikroproc. lehet e nagyon pontos (úgy értem, egy másodperc az egy másodperc) Válaszotokat előre is köszi!
Lehet, ha pontos kvarcról járatod. Ha órát akarsz építeni, akkor javaslom, hogy a timer1-hez tartozó kristályoszcillátort járasd egy 32768 Hz-es órakvarccal és a timer1-gyel mérd az időt.
Ha nem vagy túl ügyes programozó, akkor 2 hatványa frekvenciájú quartz-ot használva órajelnek, egyszerűen megoldható az időmérés. A pontosságot a quartz pontossága határozza meg. Ha picit gondolkozol a megoldáson, akkor akár 20MHz -es órajel esetén is tudsz pontosan időt mérni.
Idézet: „Van egy olyan kérdésem, hogy egy 16F877-es mikroproc. lehet e nagyon pontos (úgy értem, egy másodperc az egy másodperc)” Ket fogalmat had tisztazzunk - tenyleg nem kotekedeskeppen, de segit megerteni a problemat en szerintem. Az elso, hogy a PIC az nem mikroprocesszor, hanem mikrokontroller. Van sajat memoriaja nem ugy mint egy mikroprocesszornak, ugyanakkor a mikroprocesszor elsosorban elektronikai alkatresz, masodsorban csak olyan eszkoz amire programot lehet irni. A masodik, hogy a "nagyon pontos" kifejezes az nem mernoki megfogalmazas. A nagyon pontos az kozgazdasz vagy politikusi kifejezes Definialni kellene mi az a nagyon pontos... Hany masodpercet tevedhet -- 1)naponta, 2)hetente, 3)havonta es igy tovabb... Nekem mar a belso RC oszcillator is 'eleg pontos' szobahomersekleten... Neked lehet meg a DCF77-tel szinkronizalo ketyere sem elegge az -128C fokos tartomanyban... es igy tovabb. Azonkivul az elektronikaban minden nagyon fugg a homerseklettol es a paratartalomtol is -- tul a bemeno feszultsegen stb... Tehat azt sem art tisztazni milyen korulmnenyek kozott kell elerni egy bizonyos pontossagot. Pl. Allando szobahomerseklet mellett egy hangolt kristallyal be lehet egeszen precizre loni a dolgot. Vagy lehet szoftveresen is kompenzalni a pontatlansagokat. Altalaban amiket lehet kapni kristalyok azok olyan 10-20ppm -esek. Ezt lehet meg finomabban hangolni varicappal -- datasheetben benne kell legyen, vagy ha nem a mid-range reference manualban benne van. Hasznalhatsz kesz RTC-ket is, azoknak a datasheetjeben is benne kell legyen mennyire pontosak.
Hello
Segítenétek terveztem egy áramkört de nem tudom pontosan hogy jól terveztem meg? vagy valamelyik alkatrészt kikel cserélni? A pic programot kell még megírnom. Elektromos kaput fogja vezérelni két reed relé lesz a végállásnál, ettől félek egy kicsit, mert hogy 1,5-2 métere lesznek az elektronikától. Távirányító foglya működésbe hozni az egészet, ami egy gyári elektronika.
Szia
A 470K-s felhúzó ellenállásokat kicsit sokallom. Szerintem zavarvédettebb lesz ha 1...4,7K-t használsz. (Honnan jöttek az osztó értékei?) A kvarcot meg kár belerakni, van belső 4MHz-es oszcija a PIC-nek.
Ne gonoszkodj, mert még a végén ebből indul ki egy ál-szakmai vita, hogy elég-e a 4MHz...?
Még eddig egyáltalán nem terveztem kapcsolásokat csak mindig módosítgattam, de ez eddig saját tervezésem. Felhúzó ellenállást módosítom 4,7k –ra, és a kvarcotis dobom.
Sziasztok!
Lenne egy egyszerű kérdésem, mégpedig, hogy egy adott oszcillátor frekvenciánál, hogyan tudom meghatározni egy utasítás végrehajtási idejét? |
Bejelentkezés
Hirdetés |