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

De kipróbálhatod ezt is ,itt nincs időzítés de valószínűleg a ciklusidő ezt is befolyásolja

A shiftregiszteres meghajtás villogásmentes lesz az tuti ....

Kipróbáltam, de ránézésre is sejtettem,hogy nem lesz jó. Az a gond, hogy teljes ciklusidő van 2 szegmens közt, vagyis még lassabb lett a kijelzés.

A képen lévő megoldás több óra matekozás eredménye.(+ a te Szegmens oldalad) Ez volt a legjobb.
A számlálón azért van Bit-Byte átalakítás, hogy ne kelljen resetelni. Ez így 4 szegmensre pont jó. Valamiért a resetnél az utolsó számjegy elcsúszott, hiába van Mono-Flop 1ms, azaz 1 számjegy akkor is átcsúszott.
Szegmens vezérlést, én máshogy csináltam, azt átemeltem köszi
Viszont a megoldást a 8bites Shift-Registerben látom amit fentebb írtak. Ezzel minden gond megoldódik. Ha 1mp alatt 5x kiírom az is bőven elég. Nem kell aggódni, hogy pakolom a programot még, és még jobban lassul a kijelzés. 877A-t használok én.

Ezt a megoldást próbáld ki

Ne haragudj azóta se jártam erre. Egy asztalos barátomnak magasság állításához kellet a dolog. Elmenteni több méretet, és vissza tudja hívni. Nagyon prímán leprogramoztam, csináltam egy bemutató eszközt is amin működött, de nem lett megvalósítva, mivel a gép mechanikai átépítése nagy falat lett volna. :/
Viszont most a kijelzős dologhoz felhasználom, egy "bomba" hatástalanítós játékban, 4db számjegyet megadása, majd azt vissza kéri, ott is remekül működik.

Üdv.
7 szegmenses multi-plexeléssel van gondom. Sikerült az átcsúszásokat kicsipegetni, viszont 2ms es Clock-al is vibrálnak a szegmensek, így hogy már eléggé meg van pakolva. Ha kiveszem a funkciók felét akkor sokkal simább, szinte alig látható. 4MHz-es kvarc van benne. Azzal is próbálkoztam, hogy csak kevesebbet állítok be neki, de még rosszabb lett a helyzet. Nagyobb kvarca segítene rajta? Vagy valami külső hardveres megoldás? 8bites RS flip flopon gondolkodtam, ami letárolja az adott szegmens állást, és világítva tartja frissítésig. Ezáltal nem az lenne, hogy 1 világít addig a többi sötét, és az alacsony frissítési ciklus miatt vibrál. Szerintetek ? Köszönöm előre is!

A pasicnak egy "átka" van pontos időzítést nem (vagy csak nagyon körülményesen) lehet vele csinálni . Régebben próbáltam órát készíteni LCD vel de akármit csináltam vele vagy sietett vagy késett éppen a kijelző vezérlés és a többi "rejtett" nop miatt , ezért váltottam fejlesztő programot ,és nem bántam meg ...

Köszönöm ! Értem a választ és így megmagyarázva egyértelmű.
De gondolom a timer-nél nincs ilyen probléma.
Bár ha átviszem timert-t egy például nand kapun akkor már lehet hogy nem szinkronban viszi át ,mert oda kell érni a program ciklusnak. Így már egy kicsit érdekes a dolog.Vagy gondolom a minimim 2s-nál belefér,addig így is úgy is odaér a program

Nem fogod tudni megadni rá a választ, mert ez a megoldás nem megszakításból számol, hanem minden teljes programciklus lefutásnál. A teljes programciklus ideje pedig attól függ erősen, hogy hány utasítást kell végrehajtani, ami a lerakott modulok száma és a szoftveres megvalósításban lévő sok feltételes elágazás miatt gyakorlatilag széles tartományvban változhat és még csak nem is állandó.
A nem 'hajtja túl' igaz, mivel mindenképpen egyszer (és csak egyszer) végre fog hajtódni a kapu szoftveres leképzése a ciklusban.
Felesleges össehasonlítani timer alapú számlálással, mint ahogyan a későbbi hozzászólásodban tetted.