Szia!
Nagyon köszönöm, tetszik a program, az időalap nem a saját órajele lesz külső 1Hz -ről kap pontos időzítést. A pragotron óra vezérlő amit csináltam az is külső órajelről jár, hálózati 50Hz. Meglepően pontos, évek óta csak a téli nyári átálláskor nyúlunk hozzá! PC órához nézve pár másodpercen belül van az eltérés hat hónap alatt! Áramkimaradás a nagy ellensége, de az kibírható.
Üdv! Gábor

Egy atomórát ne cserélj le erre de talán havonta 1-2 s pontosság talán reális lehet ...
Maximum annyit még változtatnék a kijelzésen hogy a kezdő és a befejező digit közé tennék egy szünetet hogy látsszon hol kezdődik a kiíratás ...

Köszönöm!
Megnézem szerintem hasznos lesz!
Üdv: Gábor

Csináltam valamit 628 ra és 7 szegmenses kijelzőre próbáld ki ( beállító lábakat konfiguráld ahogy jónak látod én RA3-4 lábakra tenném 4 MHz-s külső kvarc kell rá )

Régebben játszottam PIc 16Fxxx-hez órával. Aztán egy ajándék ASM betét lett az eredmény a fejlestőtől. (PCF RTC..8-PIN...I2C.) Ezt anno fel is tettem... nagyon régen volt, a topic elején van.. használható INC file) Vagy egy másik PIC felől egy quartz 1s impulzusok valamelyik bemenetre. ez tovább használható...Sok sikert.

Tudod milyen pic és milyen kijelző volt rajta ? Ha igen újraírom neked de ne reménykedj hogy pontos is lesz , a parsic nem órának való ...

Sziasztok!
Régebben volt egy egy digites óra megoldás PARSIC-on. Nem találom sehol, bár lehet rosszul keresem.
3.4... verzióra volt és szeretném megépíteni. Ha valaki találkozott vele és feltenné vagy elküldené, megköszönném!
Köszönöm: Gábor

Csinál még mást is a pic ? A 28 lábú jószágnál miért kell a kijelzőt I2c -n használni ? Egyébként a parsic 4 már tudja ezt a kommunikációt de csak ezért megvenni nagyon kár .

Sziasztok,

Lehet hogy olyat kérdezek ami már megvolt , de eddig hiába kerestem a megoldást.
Szóva egy műszert építenék, ami néhány sort jelez ki , és egy léptető motort hajt meg.
Arduino nano val próbáltam ée egy 4x16 os LCD vel. Amíg a 6 vezetékes bekötéssel működött , tudtam 2-500 Hz-es step jelet levenni róla a motor vezérlőnek.
Áttettem I2 C re a kijelzőt és azóta ötödére lassult a program. 50Hz nél nem tudok gyorsabbat csinálni, a beállítások ugyanazok. Egyértelműen az I2c lassítja be.( PIC16F 876)
Áttértem a Parsicra, eddig többet is tud akár 500 Hz et is, kijelzővel. De át akartam tenni az I2c -s LCD konverterre, de itt nem tudom hogyan kell beállítani. A sok példában sem találom, hogyan tudom az i2c data modulba bekötni a TEXt modulokat. Vagy nem is így kell? Aztán jutott eszembe, hogy a Parsicban van-e ilyen egyáltalán? Vagy használta már valaki így ?
Köszi a segítséget előre is !

Üdv.

Ha érdekel valakit,itt van a 128x64 es grafikus kijelző progija nekem szépen müködik ,mint tv scanner sorok egymás után irja ki az adatokat ,16 megás kristályt használtam 4x multipleddel és 250khz PRE beálításal a ha a 2ms 500hz nek felel meg 4x multipled 2000hz ,16 megát osztjuk 250khz vel 64x2000 128khz a 2ms ,a 2ms 4 progi lépés nem jött ki a sor rendesen ezért 4 ms ot használtam 64khz n

Jó szórakozást !

A kép alapján nem értem az interrupt megfogalmazást ... A bemenet számolja a bejövő impulzusokat , az interrupt az megszakítás , mit szeretnél megszakítani -nullázni-resetelni-indítani azon a bemeneten ?

Ilyen nagy frekvenciánál hogy kell interruptot csinálni a RD.0 bemenetre ?

Sikerült! OK !

dcsabi ! Ezt a linket ismerem,de ha ezt feltelepítem akármelyik mappába egy "új" verzió lesz,de azt nem tudom használni dongle-val sem

Ha ügyesek vagyunk, akkor elcsíphetjük a legújabbat, egy hőnapja frissítették valamivel.
Ha kézzel gépeljük, sokadik variációra jön be... Itt a link...Upd_P4 ...Ha jól értelmeztem wifi access kezelés vagy példa(?) is van már.

Két hete megjött a Parsic V4. Minden nagyon jó csak hogy lehet frissíteni új verzióra ?
Ha esetleg valaki tudja.....

Természetesen mindenki abban írja a programokat, amiben tudja/akarja. Mindössze arra utaltam, hogy mi lehet a szimuláció hibáinak hátterében. Elnézést ha félreérthető voltam, nem sértésnek szántam, mindössze a fejlesztőkörnyezet szimulációját minősítettem kicsit. Az is igaz, hogy kb. mindenhol ez van.

Igazad van, hogy a alap koncepció és moduláris "összefűzögetés "módszere más logikát használ. Ez így igaz, de még nem fagyott le egy programom sem. Aztán, nem egy alkalommal, egy beigért kütyüvel, ha megcsúsztam időben, a program megírása rendszerint 10-20 percet vett igénybe a helyszínen a "nagy hardwerrel". Tanulni is lehet vele, ha elfogadjuk, vagy felismerjük azt a strukturát, vagy hasonlót amit a fejlesztő használ. Egy feladatot, több féle képpen meg lehet oldani, ez ilyen. Gyors, nem fagy le, az egyedi attraktív megoldások egy kis fejtöréssel mennek csak vele, Kónya Imre mikrokontrolleres könyvében, többször leszögezi ezt, Továbbá, a programozás mindemellett "művészet" ! Van egy szerzői szabadság benne!. Pl A Parsic kijelző kezelése memóriafaló, de, hiba mentesen lehet vele dolgozni, és gyorsan!

Idézet:
„A program működik, le is fordul, csak nem azt fogja csinálni amit szeretnénk.”

Nem csoda, ha a feljesztőkörnyezet eleve homlokegyenest más logikát használ, mint ahogy a program fut a kontrollerben.

Sziasztok, a kicsit fentebb levő adattologatás és tárolgatáshoz fűznék hozzá egy gondolatot. Anno nekem is sokszor okozott meglepetést a random modul kötözgetés. Aztán vettem a fáradtságot és a szerény A "ASM" programozói tudásommal újragondoltam sok megoldást. A Parsic sok mindent elbír a "Rajz tekintetében", de a processzorok képességeit és tulajdonságait nem lehet így feltúrbózni. A már többször emlegetett Timer(ek), az a bizonyos 2ms(!) tudja-e itt mindenki, hogy mennyi az és mi szükség rá?
Adott esetben egy egy feladat vagy szubrutin, vagy egy programreszlet, nem is fut le ilyen gyorsan, valami történni fog! "Szimulációban biztosan" meg kellene barátkozni a 10-20 vagy 100 ms használatával! Egy-két bosszúság elkerülhető! A program működik, le is fordul, csak nem azt fogja csinálni amit szeretnénk. A multiplex ledes kijelzőknél, adat tárolásnál, adat tologatásnál, figyeljünk ilyesmire, vagy szükség esetén használjunk 20Mhz-s Quartzot, de sem old meg mindent a fentebb említettek közül. Nem beszélve a belső oszcillátoros megoldásokról, amik hatványozottan gyűjtik az ilyen jelenségeket. Ezeket már régebben megjegyeztem, ebben a topicban. Ha nem jönne le így, akkor most segítségnek újra itt van, Nem beszélve az "Aszinkron kommunikáció" (RS232) esetleges hibáiról és csúszásairól! Adatsebesség, adat kimaradás, adat elcsúszás... A Quartz itt is "létfontosságú"!

Lett annyi technikai eszközöm. Kipróbáltam! Az RD.0-ra 15KHz jön ki .Nem stabil 15-16KHz között ugrál. Utána betettem egy 2ms impulzust RD.1 kimenetre .Az RD.1 stabilan 500Hz lett.
De ekkor az RD.0 9-10KHz-re csökkent ! /Ennyit jelent ez a kicsi "leterhelés"/
PIC16F877A 4MHz HS

Ez egy 8 bites számláló , ráadásul reset nélkül tehát a 255. impulzusnál nulláz viszont 3 kimenetet figyel csak a "kütyü" Viszont Geri nem lepődött meg ....

Gondolom azért, hogy bemutassa, a képen látható módszer (ZV1, legyen ez bármi is) használatával milyen szép "szinkronban" váltanak a kimenetek állapotot.

Pl. 0b111 -> 0b000 kb. 8 µs úgy, hogy a kimenetek nem egyszerre váltanak.

Ha azt írod az első hozzászólásodban hogy logikai analizátor (a kütyü helyett) akkor semmi meglepő nem lett volna a hozzászólásodban , így viszont teljesen értelmetlen volt az egész . akkor miért is keletkezett a hozzászólás ?

Az csinálta a grafikont, nincs közvetlen jelentősége. De ha érdekel egy ilyen:

https://www.aliexpress.com/item/4000755596172.html?spm=a2g0o.produc...01603_

Ez nem mond sokat senkinek ...

Szereztem egy kütyüt és rápróbáltam a picre. Nem lepődtem meg az eredményen. A program csak ezt tartalmazza semmi mást. Ha több minden lenne benne sanszosan még nagyobb eltérés lenne...
A letárolgatós módszer nagyon prímán működik.

A grafikonon a 7-ről 0-ára billenés látszik, illetve 1-ről 2-re.
Sajnosan ezt nem szereti a multiplex.
1 és 2 közt van egy kis 0 is... 7 és 0 közt meg minden ami belefér.

Nem próbáltam ki, de valószínűleg ugyan azt eredményezi mint a 1db kapu negáltan vissza kötve saját magában, A másiknál a szellemképesség az 100%

A Shiftes jónak tűnik, még nem próbálgattam csak fejben gondolkodtam, hogy kéne.
Megveszem az alkatrészeket és neki ugrok.
Elméletben ott tartok, hogy a Byte-ot le kell kódolnom szegmensekre, (ami már adott) aztán azokat 2ms-es clockal végig léptetni a registerben. Ha jól értelmeztem a belső logikai leírását, kell egy jel amire letárolja a belső pufferba a dolgokat, és akkor teszi ki a kimenetekre. (és persze a kimenet is engedélyezve van, de mivel mentéskor jelenik meg az új adat azt nem is kell lekapcsolnom, így villanni sose fog.) Az "anod jelet" ez a láb kapja az andok pedig fixen tápon. Mindig beírja mind a 4 registerbe az összes adatot, de csak azzal tároltatom le, amelyikhez tartozik a szám. Annyit kell még beledobni, hogy ha elkezdte a Byte szegmenseit a regiszterbe tolni, akkor az a szám nem változhat. Ha pont akkor vált akkor elméletileg max 8*4*2ms-et "csúszik" az idő kijelzése az 64ms ha a programban a leterheltség miatt nem tud 500Hz-et kipréselni akkor is max 100ms re nő, vagyis 1mp alatt kb 10x frissíti a kijelzést. Ez annyira nem vészes. És csak akkor, ha pont akkor szeretne váltani, mikor már az "A" szegmenst elkezdte beírni a registerbe. Azzal tudnék időt nyerni, ha bináriban hagynám a számot, és akkor elég lenne 4-Bites Register, ekkor fele ciklussal át bírom küldeni a számjegyet, csak kell egy 7447 kikódolni a szegmenst.

https://lomex.hu/pdf/ti7hc595.pdf

Összedobtam valamit a shiftregiszterhez ... Akár még működhet is

És itt van egy aminél nincs kioltás a kijelzések közt (viszont 2*gyorsabb ) de lehet hogy szellemképes ....