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?

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.

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

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.

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.

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

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.

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

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

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

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.

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

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.

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

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

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

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

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.

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

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

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

A tapasztalataim szerint, az RTC-t (chip) azért találták ki, hogy a processzor erőforrásit ne használja, és ha éppen a processzor nem működik akkor is egy alacsony fogyasztással a háttérben ketyegjen. Még a PIC-esnél komolyabb cuccokban, PC-kben is ezt használják. Ha hiteles pontos időt és kalendáriumot akarunk, akkor mi is ezt használjuk. A topic elején tettem fel, egy PCF8583-al megvalósított project részleteit. Az is segítség lehet. Az valójában egy függyetlen szubrutin, ami szoftveresen működik, és mindegy, hogy melyik lábra van kötve a PIC-nél. Most szintén van egy hasonló feladatom, ott DS1307-t fogok használni, ez majdnem ua.mint a Pcf8593. Majd felteszem ide, de 18F-re fog készülni... Az új Parsicban van egyébként HW I2C is. ezt még nem próbáltam.

Szia!
Nos a PCF8583-as dolgodat megtaláltam, csak nem igazán értem. Valószínűleg össze kéne dobnom egy tesztáramkörben és megnézni mit hogyan csinál, mert a PARSIC szimuláció nem sokat mond (legalábbis nekem).

Az lehet hogy tmr0 van de én amit csináltam órát a parsicban 2ms es idöalappal leosztva 1 s-re akár mit állítgattam rajta soha nem volt pontos az lcd idözítése is beleszólt a programba (ott nop okkal van megoldva ami nem nagyon tesz jót az időzítéseknek ).De amióta flowcode ban írom a programjaimat ilyen gondom nincs ott hozzáférek minden megszakításhoz és az alap megszakítást tmr2 ben csinálom évi pár másodperces hibákat produkálok sima 4 megás kvarccal az óraprogramjaimmal ...

Pontosan a 2ms időalappal van a baj.. az LCD, I2C miatt kezeletlen megszakítások lesznek, és valóban késni fog. Tény, hogy emiatt a parsic nem órázni való.

Még nem próbáltam parsicban , de ha egyszer lesz kedvem és időm talán csinálok egy rtc - s órát

Na azért csak a teszt kedvéért, betettem a progit a teszt-panelomba. Egyenlőre belső 1000ms időalappal (de külső időalapról is meg fogom nézni). Holnap megmondom az 1 napos eltérést .
Mellékletben a progi.

Nos csak a tapasztalat miatt: Óra beállítása tegnap 16.00.00, eltérés ma reggel 07.00.00 (internetes időszinkron szerit) +9mp (igaz, nem csinált mást a PIC, csak számolt).

Már majdnem pontos....