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.

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"

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.

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

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)

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..

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.

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.)

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.)

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

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.

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.

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 .

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..

Szia! Itt az asm.

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..

Köszönöm.

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..

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?

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

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

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

További takarékosság az esetleges megvalósításhoz. A "gyári RTC(C)-k" pl: helyől tudják hogy az adott naptári naphoz a hét melyik napja tartozik...Ez itt egy példa a szökóév detektálására és érvényesítése a február hónapnál. (28 vagy 29)

Igen, köszönöm, így egyszerűbben is működhet.

Sziasztok! Megint kellene egy kis segítség. Beletettem az UART-ot az órába, de a HyperTerminál-ban értékelhetetlen karaktereket kapok. Vajon miért? Arra tippeltem, hogy nagyon foglalt a proci, így beégettem egy 16F876-ba, ott ugyanez az eredmény. A baud beállítások szerintem jók.

Azért mert, a HyperTerminal ASCII kódokat vár. te meg hétköznapi 0-255-ig terjedő adatokat küldesz. Ezek az ASCII tábla szerint éppen azok, amiket éppen értelmetlen karaktereket látsz. Használd az RS-Check exe nevű programot, (a topic elején feltettem)ez azt az értéket mutatja, amit küldesz. Ha pl 4 számot küldesz, ott be kell állítanod a vételre 4 db adatot. Ha van Checksum akkor 5 db-ot. Vagy a PIC-ben alakítod át az összes adatot ASCII-re. Ez szerintem macerásabb. Pl: a 123-at el akarod küldeni a terminálprogramnak, akkor 49,50,51-et kell elküldened. A "táviratod" végére célszerűen még 13, 10 (enter és soremelés)

Köszönöm, megnézem az Rs.Check-el.

Köszönöm, működik.

Új verzió:
- Fixes:
- Simple 8-Bit Counter: Problems with bankswitching fixed.
- PIC18F: Some programmers displayed error messages,
because invalid Configurations Bits were set to 1. Now they will be set to 0.
With the PIC12F, PIC12F, PIC16F it is reversed


Se hardveres szorzás, se timer korrigálás

4.0.17.8 (28.03.2015)
---------------------
- New
- Bootloader für PIC18Fxxx (Beta)

- Fixes:
- Problems with initialisation at PIC18F25K80 and PIC18F87K22 are fixed.
- Problems with bankswitching at some objects fixed.