A megoldás a CCP modul. A CCPx láb váltására a CCP modul a TIMER1 (3, stb) értékét eltárolja és megszakítást is kér.

Ez jó ötlet lehet, bár 10.000Rpm -nél már másodpercenként 166 megszakítást generál. Ránézésre soknak tűnik, de lepróbálom. Az eszköz 2400 baud-on kommunikál, végül is, két byte vétele (a pufferből kiolvasása) között mondjuk azért bőven bele kell férnie.
Köszi!

Az uart.h-ban itt:

Ha alacsony szinten akarod az uart-ot (ez a célszerű nálad) akkor 0-t irsz az RXPR18 és a TXPR18 definíciójához.

Ezt most lassan, és tagoltan, légyszíves!

Miért kell alacsony prioritásúnak lennie? A legfontosabb, hogy ne maradjak le adatról, tehát nehogy valamiért felülírjon egy új adat egy régit a pufferban..

A legfontosabb, hogy az impulzusok távolságát minél pontosabban mérd. Ha a magas prioritású RB int-ben nem töltesz el több karaktervételnyi időt (ez ugye több milliszekundum), akkor egyetlen vett adatról sem fogsz lemaradni.

ezzel ez a gond:
"legrosszabb esetben akár ~239ms -be is telhet 2 impulzus beérkezése"

Azthiszem, nem marad más, minthogy ha mérés közben adat jön, akkor azt lekezelem, aztán újramérek. Válaszolni ráérek azután is, amíg meg nem válaszolok, úgyse kapok újabb adatsort.
Bár már kínomban azon is gondolkodtam, berakok mégegy (kisebb) pic-et puffernek, amiből a nekem tetsző időben olvashatom ki az adatokat.

Ez nem rossz gondolat. Nekem egyszer egyidejűleg kellett fogadnom 2 db encoder jeleit, de közben más dolga is volt a PIC-nek. Ezért az encodereket másic PIC kezelte, és a főegység számára már csak a feldolgozott jeleket küldte. Ezt is igen lerövidített formában. Gyakorlatilag 4 bitben közölte melyik encoder mért elmozdulást, és merre. Az már csak plusz haszon, hogy 4 bemenet helyett csak 2-őt használt.

Csak azért reménykedtem, mert a minap a kezembe akadt egy 5 éves elektronika, ami "szimultán" kezelt 2 motor fordulatszabályzást (hall jeladós), 2 fűtőszál-hőfokszabályzást(a hőelem a fűtőszálon volt,4 fok pontosan tudta tartani a beállított értéket)), és mellette lekezelt egy !82 byte-os beérkező adatsort...
Mondjuk lehet, hogy hardveres motorszabályzás volt benne (a típus nem volt leolvasható a mikrovezérlőről, de vmi Motorola volt, kb 3x3 centi alapterülettel).
Nekem már az is megváltás lenne, ha nem 2 byte-ból kellene gazdálkodni,már ami a puffert illeti.

Arra célzott, hogy ha CCP-vel mérsz, az úgy működik,hogy a jel beérkezésekor elmenti a Timer értékét és beállítja a flag bitet ami megszakítást kér. De ezt a megszakítást le is tilrhatod arra az időre amíg a kommunikáció folyik, mégsem maradsz le semmiről, hacsak nem jön be több jel a fordulatszám felől, vagy többször is túlcsordul a timer.

Sajna csak magam szerkesztette adatátvitelt használtam eddig, (2-5 byte szoftveresen és gyorsan)
így érdemben ehhez nemigen tudok szólni.
De azt olvastam valamelyik hozzászólásban, hogy a beérkező adat ki tud váltani megszakítást.
Így pedig egy egyszerű POSTINC-el pillanat alatt átrakható az adat a ramba, (megszakítási idő+2 utasítássor). Aztán ha ráér a PIC, majd kiveszi.

És ez miért is gond? Fogsz egy 16bites timert, az osztóját beállítod úgy hogy a 239ms alatt még véletlenül se csorduljon túl. Az RB int -ben kiolvasod a timer értékét, berakod egy globális változóba, valamint egy bitet bebillentesz, hogy frissült a mért érték. A timert lenullázod, majd kilépsz RB int-ből. A főprogramhurokban szinte végtelen időd marad a feldolgozásokra, és a soros port küldés/fogadásra. A kétszintű megszakítás mindössze azért kell, hogy ha a bejövő impulzus éppen akkor jön amikor a soros port megszakítása fut, ne kelljen megvárnia az RB int-nek azt a néhány us-ot amig az befejezi, így nem mér tévesen hosszabb időt a valóságosnál.
A kettős prioritású megszakításnak ugyanis az a lényege, ha az alacsony prioritás már fut és közben esik be a magas, félbe fogja szakítani az alacsony futását, majd miután a magas befejeződött befejeződhet az alacsony is.
Ja és ha még pontosabban akarsz mérni akkor a CCP-t is bevetheted (ahogy előttem már megírták).

Értem. Azt gondolom, ez így járható. Mindenképpen köszönöm, (mindekinek), azt hiszem ezalapján megyek tovább.
Köszönet(ek)!

Mielőtt a 'még egy pic-et berakok' felvetésébe belekezdesz érdemes megnézni mi minden lehet beletuszkolni a processzoridőbe: Video game with PIC18
Csak úgy mellékesen: színes grafika előállítsa (amire úgy igazán nem is nagyon alkalmas egy PIC) + 5 hangcsatorna + maga a játék logikája irányítással együtt.

Nem állítom egyértelműen, hogy fake, de valamit nagyon tudnia kellett az illetőnek. Elég csak kiszámolni: "monitor" 640 x 320 pont legalább 8 fps-el, az 610 nanosec idő pontonként, amikor az utasítások végrehajtási ideje legkevesebb 83 nanosec. Jut 7.34 utasítás idő képpontonként. Lévén nem tud elég lenni a memória teljes képernyőre, csak karakterenként modellezettre, folyamatosan ciklusban kell futnia ellenőrzéseknek, mikor melyik karaktert rakja ki, mert az ahhoz tárolt karakter memóriát kell beállítania streaminghez. Minden alkalommal egy ugró utasítás is kell, ami 4 utasítás idő. A pic18-asnál nincs közvetlen memória elérés. Bank regisztert is írni kell előbb (1 írás, 1 olvasás ciklus időnként), amit előbb ki is kell számolni a cím alapján, hogy hova kerüljön (legalább egy bit shift a cím számításra). És akkor még mindig csak akkuban van az adat, nem a kimeneten, ki is kell írni (újabb bit maszk műveletek). Szóval a matek azt kérdezi, ezt meg hogyan?

Mekkora frekivel megy az a mag? Csak mert nem kellene gondot jelentsen egy akár 1 millisec alatti ciklusidő sem, nem hogy 10-20 millisec idő.

12 mips hajtással (igaz, az 16 bites mag volt) csináltam már ilyesféle szanaszét mindent mérni / vezérelni főciklust c-ben, és a méréseim szerint (még a mérés is belefért) átlagosan 6.87 usec időnként lefutott (ja, amúgy én is meglepődtem, de annyit mértem). Most nem is arra mutatnék rá, mi a feladat, hanem a jellegére, és a dimenzionális különbségre. Nem létezik, hogy ne férj bele a gépidőbe egy 16 mips magon, még ha kicsit problémásabb is a memória kezelése (bankokkal is játszadozni kell), mint egy 16 bites magnak.

Nem fake, megépítettem (igaz a hangot nem csináltam meg, meg a gombokat sem kötöttem be). Ott a forrás és a HEX is. Nézd meg a forrást, a hardvert meg akár egy dugdosósosn is megépítheted annyira egyszerű. Azért nem kell pixelenként egy utasítás, mert a világosságjelet a soros port DT kimenete adja, a színjelek meg csak 16 pixelenként változnak. De az tény, hogy precíz ütemezés szükséges hozzá.
Ja és "csak" 256x200 pixeles felbontást használ (függőlegesen valószínűleg duplázza a sorokat, mert a monitor nem tudná kirajzolni a 200 sort csak a 400-at).

Igen. Ez matematikailag így van. Ezért nem is fér bele a felyembe, hogy a Commodore 16- os hogyan futtatott ilyen szintű játékokat 5MHz- s órajellel. Bár ott volt egy külön video illesztő chip, de annak volt dolga elég, míg a kompozit videojelet összerakta. A sid chip pedig csak a C64-eskben volt megtalálható. Komolyabb hangokat is produkált a demóban hallhatóaknál. Azzal együtt a processzornak meg kellett adnia a jelalakot, a felfutási, a kitartási és a lecsengési időket. Ez több adat, mint egy PWM álltal létrehozott négyszögjel.

Beállítod a Timer1 -et, az alap órajel frekvenciája a feladathoz igazítható. Pl. a belső órajel leosztottja (ld. adatlap). Beállítod a CCPx modult Capture módba, a tárolás a CCPx lába minden fel/lefutó élére. Beállítos az uart-ot is. Felprogramozod a megszakításkezelőt (uart és CCPx). Engedélyezed a CCPx megszakítást.
A CCPx modul a CCPx jel minden fel/lefutó élére a Time1 értékét eltárolja a CCPRxH:CCPRxL regiszterpárosban és megszakítást kér. Ez az érték a következő fel/lefutó él érkezéséig kiolvasható.
Ha a programod ép az UART megszakítást kezeli le (vagy más hasonló teendője van), nyugodtan megteheti, ha végez vele a CCPx lábon érkező következő fel/lefutó él érkezéséig.

Az a "csak" videóillesztő (és video memória is), ami ott van a processzor mellett, kb az időzítési gondok 98%-át veszi le a cpu-ról egy hasonló helyzetben.

Itt találsz kapcs rajzokat a c16 system boardról is.

Ez pedig a "csak" ted 7360-asról a wiki lap.

Ráadásul nem 5 MHz hanem csak 1.

Viszont nézd meg a CPU felépítését a PIC-ekhez képest és a RAM szervezését hogy csak a fő dolgokat említsem.

A belinkelt wiki lap olvasása után újabb kérdés merült fel bennem. Ha ez csinált mindent, minek kellett bele processor?
Csirkefej hozzászólása egyenesen arra enged következtetni, hogy a PIC erősen gagyi cucc, a hajdani MOS 6510-hez képest. Most tényleg, ha azok az eszközök azzal az architektúráva, azon a frekvencián tudtak képet alkotni egy TV-re, miért hihetetlen, hogy egy PIC is megteszi?

Sziasztok!
Valamivel tovább jutottam UART ügyben. Ha felhúztam a TX lábat Uart init előtt akkor küld valamit, de nem azt amit várok. Csak hexa F8 és 00 érkezik. Csatolok képet, ha volna ötletetek megköszönném.

Ne hasonlítsd össze az almát a körtével! Más műfaj a kettő. A PIC az mikrovezérlő, a 6510 meg mikroprocesszor. A 6510 önmagában a rákötött memória nélkül semmire nem képes, a videojelet sem ő állítja elő, hanem a video chip (amit a +4-ben TED7360-nak a C64-ben meg VIC6567-nek hívtak). A számítógépekben a processzornak nem kell foglalkoznia a képalkotással, csak a képalkotásra kijelölt memóriaterületet kell feltölteni a megjeleníteni kívánt tartalomnak megfelelően. Ezért volt képes az 1MHz-es CPU órajellel azokat a dolgokat megcsinálni, amit láthatunk tőlük. A fentebb belinkelt PIC-es játék az ideje nagy részében a TED/VIC/hangchip feladatát végzi el, a maradék pár % jut a játék logikájának megvalósítására, ami azért sem egyszerű, mert memória sincs elegendő a komplett képtartalom eltárolására, hanem menet közben a képalkotáskor kell azt "lerenderelnie".

Üdv,
Nem tud valaki valami hasznos oldalat ahol lehet C nyelven példaprogramokat találni?

Gyönyörű leírás.
De igazából a memória kapcsán győztél meg. A folyamatos képi memóriához 256x200-as felbontásnál még fekete-fehér megjelenítéshez is kellene 6400byte.
Ennyi RAM pedig nincs a PIC-ben. Ergo: nagyon tud programozni aki ezt mégis létrehozta.

Írja is, hogy ZX-81-el kezdte.
ZX-81, VIC20, C64-es programozók(már aki assemblyben művelte) hozzászoktak/muszáj volt a memóriatakarékossághoz, a minél hatékonyabb és tömörebb programhoz.

Én csak VIC20/C64-el kezdtem -rengeteg memóriával a ZX81-hez képest- de a mai napig bennem van a takarékosságra törekvés.

Jó alapok ezek a PIC-hez.

tutorialspoint
cprogramming
learn-c
programiz

És még évekig tudnám folytatni, olyan sokat dobál google ha beírod a keresőbe, hogy c programming tutorial. Vagy ha konkrétan valamire van szükséged, kérdezz rá arra.

Jajj ne már! Kajak eltérő dolgokról van szó. Ha kicsit belemélyedsz a cpu-k felépítésébe, egy halom digitális állapotgépet találsz. A pic esetében az a halom sok állapotgép általános célú feladatokra van felkészítve. A TED ezzel szemben direkt arra lett kitalálva, hogy memóriából olvasott tartalomnak megfelelően képet / hangot rendereljen. "Született" rá. Az egy olyan kvázi processzor, aminek a programja eleve drótozottan fut arra a célra, amit a pic-nek előbb még külön töltenie is kell. Nyilván egy kicsit hatékonyabb a működése. Az érem másik oldala, hogy cserébe a TED semmi másra nem jó, de arra az egyre az elektronikai lehetőségeihez képest maximumot teljesít. Ha esetleg kedved van beleásni magad az FPGA-k világába, és a VHDL-be, találsz arra is topicot, bár az egy kicsit elhagyatott. Ott választ kapsz arra a már fent lévő postok alapján megtalálható cikkekből, hogy mik is a különbségek, és hogy azokban mekkora teljesítmény hatékonyság rejlik.

A pic pedig nem volt, most sem az, és remélhetőleg nem is lesz gagyi cucc a jövőben sem, ejnye-bejnye!

Biztos csak én képzelődöm, de mintha 38400-ra állítottad volna az egyik oldalt, a másikat pedig 9600-ra. Azonos sebességre és kommunikációs paraméterekre kellene őket beállítani, abban az uart initben is utána kellene lesni, hogy ne tévedjenek el a dolgok. Az uart-nak van egy sebessége (300..115200), egy paritás bit-je (even, odd, none, space), és stop bitjei (1, 1.5, 2). Sőt, még az adatbitek száma is eltérő tud lenni (7, 8, 9, 10). Mindegyik beállítás legyen azonos. Jellemzően 9600 bit / sec, 8 data bits, none parity, 1 stop bits az általános.