Hát ezt én is néztem, tényleg egyszerűnek tűnik, de mivel csak a demóm van meg, még egy ok, hogy meglegyen az új PARSIC.

Mondjuk érdekes a lefordított forrás:
BCF INTCON,T0IF
; add 9 to timer0, so the interrupt occures after 250 ticks, instead 256
MOVLW 9
ADDWF TMR0,F ; W + f -> f
Ha 9-ről indul, akkor nem 250-et számol túlcsordulásig, hanem 247-et. Mivel előosztó az inicializálásnál nincs hozzárendelve és 4MHz a kvarc, a megszakítás 0.000247sec-onként érkezik, és a TR116 számlálót a forrás szerint 7*256+208-ig növeljük, tehát a periódus 2 x 2000 x 0.000247, azaz 988ms az 1000ms helyett. Ez azonban jóval nagyobb eltérést okozna a 9 másodpercnél 15 óra alatt..

Melegével tudatom a P4-el elindult a DS1307 RTCC, -éppen most.
A gyári példa alapján oldottam meg, a Device konfiggal kellett egy kicsit játszani. Gyakorlatilag bármelyik lábra lehet konfigurálni az SCL és SDA lábakat. Az a lényeg hogy a +5v-ra fel legyenek húzva 4,7-10K ellenállással. A PIC18F8722-nek adatott meg a szerencse...(megy 4 és 20 megán is)

Külső időalappal tökéletes órád lehet, a logikai műveleteket tökéletesen megoldja a parsic ..

Egyébként, még arra az "elvetemült" dologra is gondoltam, hogy fogok egy 12F508-at, 4.000MHz külső quartz-al ami semmi mást nem csinál, csak ad egy 1000msec időalapot (508-ból van itthon kb. egy tucat). A precíziós időalapom (kb. ezer éve csináltam) 10.000MHz osciból (4 lábú) és TTL osztókból áll (7490) nem túl gazdaságos, nagy az áramfelvétele ~250mA.

Az időalap állításával talán tudnád pontosítani 1002ms-vagy 998ms stb de az lcd is belekotyog az időzítésbe ezért nem egyszerű a "belövése"

Hát? Ez azért nem pontosság, de a vártnál jobb eredményt hozott. Lehetne még kísérletezni a quartz mellé tett kerámia trimerrel, de azért annak a belövése elég macerás, valamint külső precíziós időalappal. A szökőévek berakása nem lenne nagy ügy, csak mégegy táblázat, viszont akkor is ott van a nyári-téli időszámítás, ami már nem olyan egyszerű feladat, igaz azt az RTC sem tudja. Ha ezt is szeretném akkor DCF szinkron kellene.

Már majdnem pontos....

Nos csak a tapasztalat miatt: Óra beállítása tegnap 16.00.00, eltérés ma reggel 07.00.00 (internetes időszinkron szerit) +9mp (igaz, nem csinált mást a PIC, csak számolt).

Na azért csak a teszt kedvéért, betettem a progit a teszt-panelomba. Egyenlőre belső 1000ms időalappal (de külső időalapról is meg fogom nézni). Holnap megmondom az 1 napos eltérést .
Mellékletben a progi.

Még nem próbáltam parsicban , de ha egyszer lesz kedvem és időm talán csinálok egy rtc - s órát

Pontosan a 2ms időalappal van a baj.. az LCD, I2C miatt kezeletlen megszakítások lesznek, és valóban késni fog. Tény, hogy emiatt a parsic nem órázni való.

Az lehet hogy tmr0 van de én amit csináltam órát a parsicban 2ms es idöalappal leosztva 1 s-re akár mit állítgattam rajta soha nem volt pontos az lcd idözítése is beleszólt a programba (ott nop okkal van megoldva ami nem nagyon tesz jót az időzítéseknek ).De amióta flowcode ban írom a programjaimat ilyen gondom nincs ott hozzáférek minden megszakításhoz és az alap megszakítást tmr2 ben csinálom évi pár másodperces hibákat produkálok sima 4 megás kvarccal az óraprogramjaimmal ...

Szia!
Nos a PCF8583-as dolgodat megtaláltam, csak nem igazán értem. Valószínűleg össze kéne dobnom egy tesztáramkörben és megnézni mit hogyan csinál, mert a PARSIC szimuláció nem sokat mond (legalábbis nekem).

A tapasztalataim szerint, az RTC-t (chip) azért találták ki, hogy a processzor erőforrásit ne használja, és ha éppen a processzor nem működik akkor is egy alacsony fogyasztással a háttérben ketyegjen. Még a PIC-esnél komolyabb cuccokban, PC-kben is ezt használják. Ha hiteles pontos időt és kalendáriumot akarunk, akkor mi is ezt használjuk. A topic elején tettem fel, egy PCF8583-al megvalósított project részleteit. Az is segítség lehet. Az valójában egy függyetlen szubrutin, ami szoftveresen működik, és mindegy, hogy melyik lábra van kötve a PIC-nél. Most szintén van egy hasonló feladatom, ott DS1307-t fogok használni, ez majdnem ua.mint a Pcf8593. Majd felteszem ide, de 18F-re fog készülni... Az új Parsicban van egyébként HW I2C is. ezt még nem próbáltam.

Szia Zoli_bácsi!
Ezért van odaírva a progiba, hogy a belső generátor csak teszt, mert én is ezt gondoltam.
(Jól, vagy rosszul, majd kiderül.)

Szia kaqkk!
Biztosan igazad van, mert kezdő PARSIC-os időszakomban csináltam órát (akkor sokat beszéltünk itt a fórumon a 7 szegmenses kijelzők meghajtásáról), aztán az a projekt behalt. Utána csináltam autóba LCD-s órát, az sokáig ment és elég ritkán kellett állítgatni. Azért lett csak kivéve a kocsiból, mert az LCD nem bírta a nyári 60°-ot. Persze az csak egyszerű dátum nélküli óra volt. Ennél a proginál megcsinálom még az évszám kijelzést és betöltöm a teszt panelembe, azt had menjen. Ha nem jó, tényleg csak ujj-gyakorlat volt.

Hacsak... külső jelgenerátorról jön a clk jel. Ha külső clk jel jön, akkor parsic-al is megfelel az óra logika felépítésére (számlálók). Egyébként való igaz, ha a parsic végzi a clk jel előállítását, akkor bizony nagyon pontatlan lesz az óra (kb fél óra után több másodperc eltérés)

Szia Csabi!
Hát igen, PARSIC4 táblázatból küldeni tényleg elég macerás, ráadásul 100 feletti a max. küldendő adat (mondjuk ezekből tudok faragni). Én most úgy csináltam a demót, hogy egy konverter progival minden hex és ASCII karaktert átkonvertáltam DEC formátumra és beszerkesztettem egy txt fájlba, majd behívtam a táblázatba. Persze ezek fix karakterek. A baj, hogy vegyesen kell kiküldenem a vezérlő és fix karaktereket, ráadásul figyelnem kell a blokknyomtató hibajelzéseit. Nem lesz egyszerű feladat, de hogy megy-e, csak akkor fog látszani, ha kézben lesz a nyomtató.

Hogyne lenne megszakítás, a timer0 megszakítás mindig él! Az interruptban használt timer változó az alapja minden időzítő blokknak! (Ha nem hiszed, nézd meg a generált assembly forrást. Az egy dolog, hogy rejtve van a szemek elől, de ha igényled, egy DAT blokkal hozzáférhetsz parsic alól is, csak nincs értelme. A timer0 beállításait megnézheted az init blokkban). Ha nem pontos, ott más lesz a baj... pl. kezeletlenül maradt megszakítás - ezt tipikusan a lassú uC-kre írt LCD és I2C modulokkal telipakolt progik adják.

A parsicban az óra csak gyakorlásnak jó a valóságban szinte használhatatlan , akár hogy állítgatod vagy siet vagy késik (nincs megszakítás minden a programban fut, és minden lépés idöbe telik)Tapasztalatból mondom kipróbáltam ...

Azt vedd figyelembe, hogy a "táviratok" adatcsomagok vége az majdnem mindig 13 és 10 ASCII vel végződik. vagy esetleg valamilyen egyéb vezérlő karakterrel. Ezt a PC terminál program esetleg figyelmen kivül is hagyja számodra, de a PIC-el ezt küldeni kell. Ha 100-as nagyságrend a küldendő adat, akkor elég macerás lesz. Továbbá olyan quartz-t kell használni, ami a PIC-ben belül osztva hiba nélkül adja a "boodrátát". A régi parsic csak 4mhz-n kezeli az UART-ot. Nemrég írtam GSM modem kezelőt, ide is ASCII kódok szerint kellett a bájtokat kezelni. (AT paarancsként) Egy macro-ba beraktam a fontosabbakat és azt látja az Uart modul változó listája. Ebből lehet válogatni... Ezt nyilván P4-el. Ha csak 50-10 byte a kültendő adat, azt kimásolod a terminál progiból, vagy más progi segítségével. Ezeket elküldöd az ASCII tábla szerinti DEC értékekkel. Pl. A=65, U=85, 13=enter, 10 soremelés, stb

Sziasztok!
Kicsit elkalandoztam a soros nyomtatóvezérléstől (nyomtatóra várok), de ez is ahhoz kapcsolódik.
Talán valakinek máshoz adhat ötletet. Ez egy óra dátummal és idővel, figyelembe véve az év hónapjainak napszámát. Szerintem a legegyszerűbben megoldva (mármint PARSIC-al). Tudom, hogy RTC-vel egyszerűbb lenne, de így is jónak tűnik (legalábbis szimulációban és le is fordul). Azért szültem meg mintegy 3 óra alatt, mert nem akartam (nem igazán értek hozzá) I2C kezelést írni.
Direkt választottam a16F628A-t, mert kíváncsi voltam mi fér bele.
Üdv:
Zsolt

Köszönöm. Közben próbálgattam a subrutinos verziót, de sajnos eddig nem megy.
Az általad javasolt megoldás lényegét értem, valószínűleg meg is tudom csinálni, csak kissé bonyolult lesz első átgondolásra. (Bár? Nem ez az első progim PARSIC-ban és jártam már úgy, hogy elsőre bonyolultnak tűnt a megoldás aztán jött egy ötlet és sokkal egyszerűbben is ment.)

Biztosan működni fog a dolog, de bele kell kalkulálni, hogy csak akkor szabad új adatot küldeni, ha az előzőt sikerült elküldeni (baud és CT alapján meghatározhatsz egy tuti időt, de ha időigényesebb kommunikáció is van, amit nem szabad megszakítani (LCD, I2C), akkor érdemes az UART modul ACT lábával is kontrollálni). A tábla segít a fix, hosszabb parancsok átküldésében, a változókat sajnos csak DAT modullal tudod belepakolni a kommunikációba. Vagyis szükséged lesz több UART DATA modulra. Számlálóval lépegetsz át rajtuk, de csak ha végzett az előtte lévő modul. Több ilyen tömböt lepakolva változhat a parancs és a változó is. Én itt makróznék..
Mennie kell. Ha gyorsabb és variálhatóbb dolgot szeretnél, az asm betéttel lehet játszani, de ha elég helyed van, és nincs sok különböző parancsod (pláne különböző hosszúságú), akkor nem fog kelleni.

Korábban "Kaqkk" kolléga tett fel egy javaslatot, de megmondom őszintén, még nem próbáltam a gyakorlatban. Elméletben még működhet is, bár az UART nem tudom mit szól a táblázat kapcsolgatási időzítéséhez, valamint hogyan teszem bele a változókat? Elméletben arra tippeltem, hogy subrutinokba megírom a fix részeket, a változók adottak és valahogyan megfelelő sorrendben ezeket ráküldenem az UART-ra. De hogy ezt hogy lehet megcsinálni???

Nos megpróbálom.
Ahhoz hogy működésre bírjak egy soros blokknyomtatót, beállítási és működtetési parancsokat, ASCII szöveget, változókat kell kiküldenem UART-on, megfelelő sorrendben. PC-ről ez működik, de jelen esetben PIC-el kell megoldanom.

Szerintem pontosítsd a feladatot/problémát.

Sziasztok!
Korábban már foglalkoztam elméleti szinten soros nyomtató kezelésével PARSIC-ból, de most élessé vált a dolog.
A kérdés: hogyan tudok kiküldeni PIC soros portjára ASCII + változó értékeket?
(Ja és jelenleg a régi PARSIC, de ha csak az újjal megy lehet megveszik a munkahelyemen.)
Üdv: Zsolt

Nahh, kielemeztem a receiver assembly forrást, csak pár időzítést kell betartani. Megfelelő ellenőrző rutinokkal (ha nagy százalékban helyes méretű adatcsomag jön), akkor szinte "magától" megoldódik a szinkron (a miértbe ne menjünk bele, mert annyit nem akarok gépelni). Több dolog detektálható egy hibajelzéssel szimplán parsic modulokkal (asm betéttel meg minden), ha a transzmitter többet küld, ha nem küld semmit, vagy nem eleget, vagy jót küld... Ami eszembe jutott szinkront befolyásoló hiba, azt leszimuláltam, kivéve a frame és overrun adathibákat, azokat nem tudom szimulálni. De asm-ből kiderül, hogy ezek bekövetkezte a vett csomagban milyen hülyeséget okoz, de parsicból védekezni lehet ellene (detektálni nem, oda asm kell).