Na, ez tényleg egy nagyon is reális eshetőség, szép fogás!

Tényleg csak úgy érdekességképpen: megmérted a modul kimenetén lévő magas szintet feszültségmérővel? Mert a jelenség nagyon is illeszkedne erre az esetre...

Nem mértem meg mert egy tápról járnak, épp ezért fel sem merült bennem hogy ez lehet a probléma. De megmérem mindjárt. Szerintem inkább valami a programomban nem jó, mert ugyanaz a program amit írtam a PIC loopback tesztjéhez, nem működik ha az RCREG ből olvasom ki az értéket. A fura az hogy beérkező adat esetén sem igaz sem hamis jelzést nem produkál a program. Pedig párhuzamosan a PC re is rá van kötve a modul TX lába, látom hogy küldi a helyes adatot. (tesztprogram ---> #417874 Hsz) Csatolom a mostani RCREG es verziót. Olyan mintha a program eldöcögne az RX_OK rutinig, de beérkező adat esetén nem lép ki a rutinból. Mert ha kilépne akkor valamelyik LED et vezérelnie kéne.

Megmértem, nem tudom hogy ez így jó e...A tápfeszültség 3,93 V . A PIC RX lábát lekötöttem a modul TX lábáról. A modul TX lábán 2, 91 V van, a PIC RX én 0V . A PIC másik lába (TX) nincs lekötve a modulról, ezen a ponton tápfeszültséget mérek.

Azt nem tudod megnézni,h.mikor beadsz egy parancsot PIC-el a modulnak, akkor válasz jön-e ki a modul lábán?
Lehet,h.a PIC olyan formában küldi a parancsot,h.nem válaszol rá..
Gondolom ha ment terminállal, akkor így is kéne mennie..

De, jön válasz . Minden egyes beköldött AT parancsra visszajön az OK. Az egész áramkör rá van kötve illesztőn kersztül a PC s bray terminalra is.

Ha a Vhigh min. valóban = 0.7*VDD akkor a 2,91 volt eléggé határon van. De ha felhúzom 10K val a TX lábat tápra akkor sem megy...Nem ez a gond szerintem.

Tudnál csinálni egy olyan próbát, hogy kikapcsolod a PICnek az USART RXét és egyszerű digit inputnak állítod?
Ha van egy led a picen akkor egyszerűen másold az "rx" láb értékét a LEDre. Meg kéne tudni, hogy egyáltalán a PIC veszi a jelelekt vagy az sem.

Szerintem itt lesz a probléma...

Minden AT parancs után ki kell olvasni a soros porton lévő adatot az RCREG-ből, mert a picben elég kicsi a puffer - ha jól tudom 2 bájt

szerk:

Gondolom amiatt lehet hiba, mert egy FIFO-val van megoldva a 2 bájtos puffer, és szerintem vagy "kitolják" egymást a bájtok, vagy ha tele a puffer, akkor nem is másol a soros portról semmit a PIC - adatlapban biztos írnak erről is

Ha az AT parancsok küldése után egyszerűen törlöm az RCREG et, az a puffert nem törli? Mert ezt már próbáltam, és nem ment így sem.

Ezt is mindjárt kipróbálom...Fogok látni valamit abból ami történik? Mert 9600baudhoz lehet hogy lassú a szemem.

Szerintem az RX_OK függvényt kéne meghívni, aztán utána kiolvasni az rcreg-et (nem pedig törölni)

MOVF RCREG,W

ezzel törlődik az PIR1 és ürül a puffer.
Mindezt annyiszor, ahány bájt jön válaszként a modultól

Igen! Ha alap világít akkor halványul, ha alap nem világít akkor kicsit pislog! Csak mondjuk valami jó nagy adat folyam kéne! Én SMS-t olvastattam ki az enyémmel. Arra mondjuk ne számíts, hogy egy OK üzenetet látni fogysz!

De most jut eszembe, ne átmásold, hanem a negációt használd és az Rx lábon felfutó vagy lefutó élet nézz ezzel, felezed a villogás sebességét és a végére mindenképp a LED váltani fog, ha páratlan számú szint változás érkezik amit észre veszel!

Remélem érted mire gondolok, mert kicsit kusza lett!

Köszönöm, kipróbálom!

Még párszor átolvasom, de azt hiszem értem...

Az RCSTA.OERR bitet jelezd ki egy LED-re. Ha ez világít, akkor túlcsordult a buffer. Eddig valahogy nem értettem, hogy nem csak egy jelet küldesz, és a többivel nem csinálsz semmit, pedig egyértelműnek kellett volna lennie. Pixels szerintem megtalálta a hibát!

Azt tudjuk,h.mikor pl: küldök egy AT < CR > parancsot (ami 3 byte, amire OK a válasz), akkor pontosan hogy jön a válasz, hány byte érkezik vissza?Hogy kell majd kezelni a válaszban érkező < CR > < LF > -et az OK elején és a végén?
Tudom,h.most nem ez a fő probléma, csak érdekességként kérdem..

Szia Watt!

Amúgy én is megcsináltam ezt egy másik modullal és PIC-el, ahol kezelve van az OERR és FERR is, ha esetleg sok adat jönne, de a regiszterem mibe tölteném az OK-t üresen marad..
Amúgy az összeköttetés jó soroson tudok küldeni és fogadni is a modul is működik, minden megy külön-külön, de együtt nem..

Igaz, én nem GSM modulnál, hanem ledkockánál alkalmazok egy bevált technikát, ha több byte-ot kell fogadni, és feldolgozni:

Megszakítást használok, és indirekt regiszter elérést. A feltétel annyi, hogy a PIC regisztertömbjében legyen egy elég nagy összefüggő terület.

Mivel a soros port puffere kicsi, és sok adat jön, kialakítottam a regisztertömbben egy nagyobb puffert. Megszakítás "nem csinál semmit", csak kimásolja az adatot az RCREG-ből a regisztertömbbe a megfelelő címre, azután egyel növelem a címet. A megszakítás figyeli még azt, hogy az adatfolyamnak mikor van vége. Ha vége akkor átállít egy regisztert, amivel jelzi a főprogramnak, hogy kezdődhet a feldolgozás. A feldolgozás után a főprogram törli a jelzőregisztert, és a címet a buffer elejére állítja.

A feldolgozás meg bármit csinálhat, jelen esetben egy mintát kell illeszteni < CR > < LF > O K < CR > < LF >. Mind a 6 bájtot ellenőrizni kell, ha rendben, akkor mehet tovább a program, ha hiba van, akkor annak kezelése.

Dettó. Ez már egy magasabb szint, ami egy példa programban túl nehéz lenne.
Ha jobban megnézzük az RX_OK rutin se jó így(korábban erről regéket is írtunk), bár most pont jól jött, hogy jelezze, nem lép ki belőle a program soha, ha nem jön vétel. Ezt is illik majd lekezelni, csak első körben működjön a kör.

Igen, ez lesz az, a LED világít. Tehát minden válasz után ki kell olvasnom az RCREG et, ha kell az adat ha nem. Valahogy nem volt képben hogy hiába csak küldök adatot a modulnak, az vissza is igazolja minden esetben a vételi oldalon. Vagy OK t küld, vagy ha számára értelmetlen adatot kap akkor ERROR t. Ezekkel a visszajövő adatokkal valamit kezdeni kell. Köszönöm a rávezetést mindenkinek. Ennek fényében írok egy új programot, de van egy olyan érzésem hogy még fogok kérdezni e témában...(is) Még egyszer köszönöm mindenkinek.

Ránéztem a programodra ismét. Az a bajom, hogy a levegőbe beszéltem, mert a programban kiolvasod minden egyes vételkor az RCREG-et elvileg.
Az egyedüli probléma az lehet, hogy utána rögtön le is kezeled, és e miatt az idő telik. Bevallom nem néztem meg mennyi idő telik el, míg újból az RX_OK-be ér a program, és azt se, mennyi ideig tart a következő adat esedékessége, de ha az OERR beáll, akkor az csak azt jelentheti, hogy az adatok gyorsabban érkeznek, mint amennyi idő alat lekezeled őket.

A megoldást pixels megírta az imént, végig kell olvasni a bejövő adatokat a RAM-ba, és a vége jel után lekezelni őket.
Érdemes ezt már megszakításban megoldani, de ha nagyon idegenkedsz tőle, simán is megy, csak nem olyan hatékony, és később úgy sem lesz már jó. De első próbának megteszi.

Ok, köszönöm. most hogy már konkrétan tudom mi a baj már el tudok játszani a megoldással. Az a késleltető hurok 1,5 sec kb. ezalatt persze beeshet egy rakás adat az RCREG be ami nincs lekezelve. Mindjárt kiveszem a késleltetést, ami csak azért lett belerakva a programba hogy villogjon a LED, ne folyamatosan világítson. Elvileg a késleltetés nélkül jónak kéne lennie...
Régebben is javasoltad hogy indirekt címzést használva rakjam az adatokat a RAM ba, és utána értékeljem ki. de akkor nekifutottam és elég bonyinak találtam, ezért feladtam...

Na jó!
Újra fogalmazom, kissé pontosabban.
Szeretnék egy órát. És a 16F877-essel próbálkoznék, szobahőmérsékleten, átlag páratartalommal. Kéne egy ketyere, ami "halál" pontosan 1 másodpercenként ad egy impulzust ami a következő "case"-re billenti a programot. Ezt meglehet oldani, vagy inkább felejtsem el!

Válaszotokat köszi!

Az a késleltetés nem is volt benne abban a forrásban, amit csatoltál! Ejnye, kis cseles!
Tehát előtte a LED világított(azaz minden rendben volt), csak azt szeretted volna, hogy villogjon?

Igen, meg lehet oldani, mint ahogy írtam már korábban, tégy egy 32kHz-es órakvarcot a T1OSI és T1OSO lábak közé (két 22-33pF közötti kerámiakondenzátorral a GND felé), a többi már csak program kérdése.

Ismét a "halál" pontos csapdába esel(olyan nincs, még az atomóra sem "halál" pontos).
Mire akarod használni?

Persze, hogy meg lehet oldani, de nincs 'halal pontos' ora. Minden ora siet vagy kesik valamelyest.

Ha orat akarsz megvalositani, akkor valoszinuleg az un. ora kvarcokat kellene valasztanod. A kovetkezo egy lehetseges elkepzeles:

Veszed a 32768 Hz-es kvartzot, es azzal hajtod a PIC-et LP OSC modban. Az FOSC/4 osztas miatt a timer0 kapasbol 1:4-es osztasban lesz, erre meg kellene tenned, hogy 15-os shiftelt erteket kapj a masodperces megszakitasokhoz, avagy 14-est a fele masodperchez ha pl kettospottyot akarod villogtatni.

(32768-at shifteld jobbra 15x avagy szamold ki mennyi 2^15 es akkor rajossz miert...)

Namost, a 32768 -on van eleve egy 1:4-es osztas ugye, es a timer0 8 bites, azaz az is ratesz meg egy 1:256-os osztast. Marad 32. Azaz 1 mp-hez 1:32-es, fel masodperchez pedig 1:16-os eloosztot kellene beallitani.

A "halál" mint fizikai mennyiség, vagy mint statisztikai fogalom számomra értelmezhetetlen. 20 ppm pontosság elég?

16F877-ről volt szó, ahogy néztem, ott megvan külön a CPU órajelhez a kvarcoszci, plusz a timer1 oszcillátorhoz a T1OSI/T1OSO lábak. Két kvarc lesz a PIC mellett, egyikről dolgozik az utasításvégrehajtás, a másikról jár az ütemet adó timer1.