Szia Zoli_bácsi!
Ezért van odaírva a progiba, hogy a belső generátor csak teszt, mert én is ezt gondoltam.
(Jól, vagy rosszul, majd kiderül.)

Szia kaqkk!
Biztosan igazad van, mert kezdő PARSIC-os időszakomban csináltam órát (akkor sokat beszéltünk itt a fórumon a 7 szegmenses kijelzők meghajtásáról), aztán az a projekt behalt. Utána csináltam autóba LCD-s órát, az sokáig ment és elég ritkán kellett állítgatni. Azért lett csak kivéve a kocsiból, mert az LCD nem bírta a nyári 60°-ot. Persze az csak egyszerű dátum nélküli óra volt. Ennél a proginál megcsinálom még az évszám kijelzést és betöltöm a teszt panelembe, azt had menjen. Ha nem jó, tényleg csak ujj-gyakorlat volt.

Hacsak... külső jelgenerátorról jön a clk jel. Ha külső clk jel jön, akkor parsic-al is megfelel az óra logika felépítésére (számlálók). Egyébként való igaz, ha a parsic végzi a clk jel előállítását, akkor bizony nagyon pontatlan lesz az óra (kb fél óra után több másodperc eltérés)

Szia Csabi!
Hát igen, PARSIC4 táblázatból küldeni tényleg elég macerás, ráadásul 100 feletti a max. küldendő adat (mondjuk ezekből tudok faragni). Én most úgy csináltam a demót, hogy egy konverter progival minden hex és ASCII karaktert átkonvertáltam DEC formátumra és beszerkesztettem egy txt fájlba, majd behívtam a táblázatba. Persze ezek fix karakterek. A baj, hogy vegyesen kell kiküldenem a vezérlő és fix karaktereket, ráadásul figyelnem kell a blokknyomtató hibajelzéseit. Nem lesz egyszerű feladat, de hogy megy-e, csak akkor fog látszani, ha kézben lesz a nyomtató.

Hogyne lenne megszakítás, a timer0 megszakítás mindig él! Az interruptban használt timer változó az alapja minden időzítő blokknak! (Ha nem hiszed, nézd meg a generált assembly forrást. Az egy dolog, hogy rejtve van a szemek elől, de ha igényled, egy DAT blokkal hozzáférhetsz parsic alól is, csak nincs értelme. A timer0 beállításait megnézheted az init blokkban). Ha nem pontos, ott más lesz a baj... pl. kezeletlenül maradt megszakítás - ezt tipikusan a lassú uC-kre írt LCD és I2C modulokkal telipakolt progik adják.

A parsicban az óra csak gyakorlásnak jó a valóságban szinte használhatatlan , akár hogy állítgatod vagy siet vagy késik (nincs megszakítás minden a programban fut, és minden lépés idöbe telik)Tapasztalatból mondom kipróbáltam ...

Azt vedd figyelembe, hogy a "táviratok" adatcsomagok vége az majdnem mindig 13 és 10 ASCII vel végződik. vagy esetleg valamilyen egyéb vezérlő karakterrel. Ezt a PC terminál program esetleg figyelmen kivül is hagyja számodra, de a PIC-el ezt küldeni kell. Ha 100-as nagyságrend a küldendő adat, akkor elég macerás lesz. Továbbá olyan quartz-t kell használni, ami a PIC-ben belül osztva hiba nélkül adja a "boodrátát". A régi parsic csak 4mhz-n kezeli az UART-ot. Nemrég írtam GSM modem kezelőt, ide is ASCII kódok szerint kellett a bájtokat kezelni. (AT paarancsként) Egy macro-ba beraktam a fontosabbakat és azt látja az Uart modul változó listája. Ebből lehet válogatni... Ezt nyilván P4-el. Ha csak 50-10 byte a kültendő adat, azt kimásolod a terminál progiból, vagy más progi segítségével. Ezeket elküldöd az ASCII tábla szerinti DEC értékekkel. Pl. A=65, U=85, 13=enter, 10 soremelés, stb

Sziasztok!
Kicsit elkalandoztam a soros nyomtatóvezérléstől (nyomtatóra várok), de ez is ahhoz kapcsolódik.
Talán valakinek máshoz adhat ötletet. Ez egy óra dátummal és idővel, figyelembe véve az év hónapjainak napszámát. Szerintem a legegyszerűbben megoldva (mármint PARSIC-al). Tudom, hogy RTC-vel egyszerűbb lenne, de így is jónak tűnik (legalábbis szimulációban és le is fordul). Azért szültem meg mintegy 3 óra alatt, mert nem akartam (nem igazán értek hozzá) I2C kezelést írni.
Direkt választottam a16F628A-t, mert kíváncsi voltam mi fér bele.
Üdv:
Zsolt

Köszönöm. Közben próbálgattam a subrutinos verziót, de sajnos eddig nem megy.
Az általad javasolt megoldás lényegét értem, valószínűleg meg is tudom csinálni, csak kissé bonyolult lesz első átgondolásra. (Bár? Nem ez az első progim PARSIC-ban és jártam már úgy, hogy elsőre bonyolultnak tűnt a megoldás aztán jött egy ötlet és sokkal egyszerűbben is ment.)

Biztosan működni fog a dolog, de bele kell kalkulálni, hogy csak akkor szabad új adatot küldeni, ha az előzőt sikerült elküldeni (baud és CT alapján meghatározhatsz egy tuti időt, de ha időigényesebb kommunikáció is van, amit nem szabad megszakítani (LCD, I2C), akkor érdemes az UART modul ACT lábával is kontrollálni). A tábla segít a fix, hosszabb parancsok átküldésében, a változókat sajnos csak DAT modullal tudod belepakolni a kommunikációba. Vagyis szükséged lesz több UART DATA modulra. Számlálóval lépegetsz át rajtuk, de csak ha végzett az előtte lévő modul. Több ilyen tömböt lepakolva változhat a parancs és a változó is. Én itt makróznék..
Mennie kell. Ha gyorsabb és variálhatóbb dolgot szeretnél, az asm betéttel lehet játszani, de ha elég helyed van, és nincs sok különböző parancsod (pláne különböző hosszúságú), akkor nem fog kelleni.

Korábban "Kaqkk" kolléga tett fel egy javaslatot, de megmondom őszintén, még nem próbáltam a gyakorlatban. Elméletben még működhet is, bár az UART nem tudom mit szól a táblázat kapcsolgatási időzítéséhez, valamint hogyan teszem bele a változókat? Elméletben arra tippeltem, hogy subrutinokba megírom a fix részeket, a változók adottak és valahogyan megfelelő sorrendben ezeket ráküldenem az UART-ra. De hogy ezt hogy lehet megcsinálni???

Nos megpróbálom.
Ahhoz hogy működésre bírjak egy soros blokknyomtatót, beállítási és működtetési parancsokat, ASCII szöveget, változókat kell kiküldenem UART-on, megfelelő sorrendben. PC-ről ez működik, de jelen esetben PIC-el kell megoldanom.

Szerintem pontosítsd a feladatot/problémát.

Sziasztok!
Korábban már foglalkoztam elméleti szinten soros nyomtató kezelésével PARSIC-ból, de most élessé vált a dolog.
A kérdés: hogyan tudok kiküldeni PIC soros portjára ASCII + változó értékeket?
(Ja és jelenleg a régi PARSIC, de ha csak az újjal megy lehet megveszik a munkahelyemen.)
Üdv: Zsolt

Nahh, kielemeztem a receiver assembly forrást, csak pár időzítést kell betartani. Megfelelő ellenőrző rutinokkal (ha nagy százalékban helyes méretű adatcsomag jön), akkor szinte "magától" megoldódik a szinkron (a miértbe ne menjünk bele, mert annyit nem akarok gépelni). Több dolog detektálható egy hibajelzéssel szimplán parsic modulokkal (asm betéttel meg minden), ha a transzmitter többet küld, ha nem küld semmit, vagy nem eleget, vagy jót küld... Ami eszembe jutott szinkront befolyásoló hiba, azt leszimuláltam, kivéve a frame és overrun adathibákat, azokat nem tudom szimulálni. De asm-ből kiderül, hogy ezek bekövetkezte a vett csomagban milyen hülyeséget okoz, de parsicból védekezni lehet ellene (detektálni nem, oda asm kell).

Jaja, épp a több modult álmodtam meg este, de azon kívül még nem gyulladt ki a lámpa.. látok számlálót, SR tárolókat, komparátorokat, kereszt reteszelést, de még nem állt össze egésszé. Meg csak holnap tudom megnézni, hogy a több modulos RS232 receiver hogyan is fest assembly fordításban.
Ha előkerülne a gsm modemes cuccod, szívesen venném, ha segítenél. Addig agyalok tovább.

Volt hasonló gondom, amikor gsm modemmel való kommunikációt csináltam. Elvileg valahol megvan, majd ránézek. Addig is előljáróban, vételi és adási modulból is több darabot lehet használni és az engedélyezéseket kapuzni is lehet...

Szia, nem azon rugózom, mert alsó 8 bit, felső 8 bit, ezt megoldom a küldő odalon, ezzel semmi gondom nincs. A byte-ok sorrendje a vevő modulban ennek megfelelően áll össze. Ha mind a 16 byte mindig megérkezik rendben, nincs is semmi gond.
A bajom az, hogy pl. jönnek az adatok, ámde mondjuk a 16 byte helyett jön 12, mert error van adó oldalon. Ekkor nem kezdhetem el a feldolgozást. Meg kell várni a másik 4 adatot. Nyomtam egy szimulációt rá: ha az adónál van a hiba, azt a parsic modul ACT kimenettel érzékelem, nincs feldolgozás, error kiír. De nem jelzi sehol a parsic, hogy épp melyik vett byte-nál tart a 16-ból. Amint az adó helyreáll és elkezdi ismét küldeni a 16-os csomagot (és nem onnan, ahol befejezte, hanem mondjuk elölről, mert resetelve lett), a parsic vevő nem az első byte-tól, hanem a 12.-ik, utoljára vett hibamentes byte-tól kezdi rögzíteni az adatokat. Amint eléri a 16-ot, kezdi beírni őket az elejéről. El is ment a szinkron, hiába érkezik be minden byte. Ha azt mondom, hogy van bevezető karakter, azzal sem megyek sokra, mert a parsic-ban nem indíthatom újra a vételt az első byte-tól, nem "resetelhetem" a vevő modult, hanem ahol tart éppen, onnantól rögzíti a következő bytokat. Így a cheksum is felesleges, mert nem oda érkezik, ahová várom. Ezt kellene megoldani, hogy megfelelő helyre érkezzen minden adat hiba esetén. Na ezen rugózom. Onnan már lenne értelme kezdő/befejező/cheksum adatnak.

Szerintem, beállítasz adatforrás modullal 8db 16 bites változót. elnevezed őket valami "móricka névvel, pl: A_RX1, A_RX2...) Az Uart vételi modullal beállítod őket vételre, egyesével A_RX1, A_RX1_1, A_RX2, A_RX2_1, ..stb...pontosan 16 db-ot. A checksum az van(?) Esetleg bevezető, befejező ASCII. Ezt deríts ki a terminálprogrammal ,vagy az RS check exe progival, amit a topic elején többször föltettem. Gondolom leginkább azon "rugózol", hogyan lesz a 8 bites adatokból egy komplett 16 bites érték. Hát így, ahogy leírtam...Ha a felső byte-ot adják először, akkor páronként felcserélgeted.

Köszi, C-ben én is bármikor megcsinálom, de jelenleg ezzel a progival kell megoldanom a saját korlátaival..

Azt arduino-ban csináltam, csak az elvet mondtam. Ott egy '\n' karakter vételekor kezdem el vizsgálni az adatot. Vagy csináld úgy, hogy számold az érkező csomagokat és ha megjött a 16byte, akkor dolgozd fel.

Nincs, de akár megoldható lenne egy záró byte küldése, de ezzel nem nagyon vagyok előrébb. Van valami publikus rajzod a GPS-es cuccodról?

Nincs a jelsorozat végén valamilyen újsor vagy kocsivissza karakter? (0A 0D)
Ha van, akkor azt kell figyelembe venni. Én a GPS jel vételénél így oldottam meg. Ha nincs, akkor időzíteni kell a feldolgozást. Ha eltelt valamennyi idő, és nem jött semmilyen karakter, akkor dolgozhatja fel.

RS232-n kellene vennem 8db 16bites adatot. Ergo 16 byte egymás után. Feldolgozás pedig csak akkor, ha már mind a 16 byte beérkezett. Az 16 byte-os "csomag" 1s-onként érkezik, tehát bőven van idő feldolgozni. Hogyan oldanátok meg a 16 byte vételét, és csak akkor elkezdeni a feldolgozást, ha már mind egészen biztosan beérkezett?

Köszönöm kipróbálom.
Üdv: Gábor

Ha 20Mhz-s quartz-ot használsz helyből közte lesz az érték. Továbbá a mellékelt kép szerinti mintaprogram (működő!) alapján INC modul beillesztve az INIT végére. az értékekkel kell variálni az adatlap szerint, illetve a kissé föntebbebb belinkelt PWM_info segít.
Figyelembe kell venni, hogy a 255 (PR2) értéke ha változik, akkor ez is befolyással lesz a kitöltési tényezőre, -mindamellett, hogy az alap modul byte-s bemenete is erre szolgál.
A 2ms alap időt nem célszerű használni mert nagyon leterheli a procit bizonyos esetekben, helyetee 20 vagy nagyobb értéket. A PWM-hez (és egyéb esetben ahol CF bementre van kötve ott az adott adat frissítés ideje) Tehát PWM esetén is, - nem sok köze van a kimeneti frekihez.

Sziasztok!
A régi PARSIC-al lehet-e 1-3 KHz között frekvenciát generálni. Az alap órajel 2 msec ami 500 Hz?
Üdv: Gábor

Sziasztok!

Köszönöm mindenkinek a segítő szándékát.

"snapscan" Az említett adatlapnál én az alábbi táblázat ajánlását vettem figyelembe 10 bit-es felbontásnál. Ezek szerint nem jól értelmeztem a leírást, az iránymutatásod alapján sikerült csökkentenem a frekvenciát, még egyszer köszönöm.

Ja, lemaradt, hogy ha beállítottad az előosztást, onnan már felfelé hangolhatsz a PR2-vel, azaz a jelenleg 255-ön lévő érték csökkentésével. Fenti képlet alapján...

Vegyük alapul a 16F87x procit.
Ha PR2 értékét, vagyis a 255-öt csökkented, csökken a periódus, ergo nő a freki:
PWMperiod = [ (PR2) + 1 ] x 4 x Tosc x (TMR2 prescale value)
Innen marad a Tosc és a TMR2 prescale value, mint befolyásoló tényező. Tosc-hoz kellemetlen nyúlni, marad a TMR2 előosztás, ami a T2CON alsó két bitje. 00: 1-es (tehát nincs) osztás, 01: 4-es osztás, 1x: 16-os osztás. A második bit mindenképp 1-ben kell legyen, hiszen az kapcsolja a Timer2-t ON-ba, tehát ha 1-et vagy 16-ot írsz a 4-es érték helyett, azzal kikapcsolod a TMR2-t, persze, hogy nem működik a PWM.
Tehát ha a 4-es értéket lecseréled 5-re, akkor 4-es osztást kapsz, ha 6-ra vagy 7-re, akkor 16-ost. Ha ez a két osztás nem megfelelő, marad a fenti képlet alapján a Tosc változtatása.
Mindez benne van az adatlapban...