Miért ne tudnád kivenni ? Semmi szerepe nincs ott....

Jogos, mindjárt nyertem +3%-ot, de az MF1, MF2-t sajnos nem tudom kispórolni.

Monostabil helyett én a egyeslövést (oneshot) használom a gombokhoz.

Nos, ha már lúd, legyen kövér. Megírtam a szökőéveket. Ami a dolog érdekessége, hogy ha a hónap-számláló indítását nem küldöm át az MF5 monostabilon, 12. hónap után (évváltáskor) 02. hónapra ugrik, napszámláló RESET esetén (mind a szimulációban, mind a valóságban). Az egy gombos nyári/téli (oda-vissza) átállítást beleteszem még, valamint a dátumot és időt kiteszem UART-ra. Mi a vélemény a beállító gombok monostabiljait kihagyhatom?

Megírtam nekik, de amennyire kommunikatívak a vásárlás után (ha megkapták a pénzt, kb. le se szarnak), nem várok nagy eredményt..

Köszönöm.

Nos, igen.. a parsic4, ahogy írtam volt, 988ms-ra fordul, míg az általad küldött forrás 999,936ms-ra, azaz óránként kevesebb, mint 1/3 sec az eltérés, ami 15 óra alatt kb. 4 sec. A kvarc és a mérés pontatlanságával kiadhatja a 9sec-et. A p4-es lenne a pontosabb, ha kezdőértéknek TMR0-ba tényleg 6 lenne a 9 helyett, akkor pontosan 1000ms lenne, így viszont nagy az eltérés, célszerű figyelni rá! Azért megírom a fejlesztőnek, hogy pontosítson..

Szia! Itt az asm.

Szammer, el tudnád küldeni a parsic3 által fordított asm forrást? Gyanítom, hogy a 4-essel fordítottban az a 9-es értékadát a TMR0-nak hiba, 6-osnak kell lennie, a komment is ezt támasztja alá és a kiszámított és a szimulált időzítés is. Szeretném összehasonlítani a két kódot, és ha igazam van, jelezném a hibát a fejlesztőnek..

Egy ilyen bonyolultságú programot már ne akarj parsicban megírni ! Ilyet Dcsabi meg tud írni mert neki csak segítség a parsic , a kisujjából kiráz 8-10 asm betétet , de amíg erre a szintre nem jutsz el nem fog sikerülni , vagy ha igen akkor hosszú idő és sok kínlódás árán .

Szia "kaqkk" és "Dcsabi"!
Igazatok van de hogy miért is forszírozom: Van egy alkalmazás egy gyorsétterem láncnál, aminek a szoftverét egy nálam sokkal jobban hozzáértő kolléga írta C-ben. Ott az időalap DS1307-ről jön. A konkrét feladat az volt, hogy a pénztárgép által blokkra nyomtatott vonalkód (dátum/idő) alapján meghatározott (programozható) időtartamon belül beengedje a mosdóba a vásárló vendégeket. A nem vásárló vendég fizet. Tudni kell, hogy az üzemeltető nem akar foglalkozni ilyen apróságokkal és a konkrét feladatnál ez problémát okozott. A kolléga megírta a téli/nyári átállást is így ez megoldódott. Eddig nincs is gond, de szeretném saját kútfőből is megoldani, legalábbis megpróbálni.
Az órát nem kell bántania az üzemeltetőnek, mert karbantartási szerződés alapján negyedévente kimegyek és ha kell módosítom (csak IR távirányítóval lehetséges jelen hardvernél).
Visszatérve az elejére az 1 gombos téli/nyári dolog lehet hogy a legegyszerűbb.
Egyébként a jelen projekt teljesen más, de csak részleteiben hasonlít erre a régebbire.
Bocs a off-ért.

A téli/nyári átállást általában a felhasználó kezeli az adott készülékben, kézi vagy automata módszerrel. Ez így csak általában itt nálunk jelenség ennyire, vagy van olyan is ahol két órát állítanak előre... Általában megelégszem a "pontos "idővel.

Természetesen ! A menüben két gombnyomás ...

Egyébként egy kérdés? Azt hogy az RTC IC-k majdnem mindent tudnak egy dolog. A nyári/téli időállítást megoldottad? (Igaz, ez helyi időzónán belüli probléma.)

Hát én az asm-ot nem nézegettem, de biztosan igazad van, ugyanakkor amit leírtam az tapasztalati mérés. Ha jól értelmezem amit leírtál, sokkal többet kéne sietnie. Hol is kéne utólag hozzárendelni az asm-ban a 4MHz quartz-ot? (Ha buta a kérdés, elnézést.)

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.