Sziasztok

Vasaroltam egy M33G GSM modult osszekotottem egy max232 -vel es a PC -vel. Szepen mukodik is, veszi az AT parancsokat es a valaszt is megjeleniti.
Rakotottem az RX, TX labra egy pic18f45k20 -at es onnan adtam ki a parancsokat, mennek is szepen a terminalon latom a kimeno parancsokat es az OK vagy ERROR valaszt. Egy gond viszont van, a PIC RX laban csak CR LF valaszokat kapok.
Probaltam ugy hogy kiveszem a max232 -t, a gsm -et szepen vezerli (kuldi az SMS -t), de igy sincs valasz.
Az echo ki van kapcsolva ATE0, kulonben AT -et kapok vissza.
Probaltam kikapcsolni a flow controlt AT+IFC=0,0, de semmi valtozas.
Probaltam a GSM soros labaival varialni, felhuzni DTR, RTS, osszekotni RTS-CTS DSR-DTR, de semmi valtozas.

Tobb helyen olvastam, hogy masnak is volt ilyen gondja, de a megoldast nem sikerult megtalalnom.

Elore is koszonom a valaszokat

Az adatlap szerint a tápja 3,3V-tól 4,2V.
A pic data lábáról 5V-os jelet kap, ez nem lehet gond?
Nézd meg szkóppal hogy a MAX-232-es interface esetében a kommunikáció milyen feszültségszinten megy, mikor jó, és milyen amikor nem jó pic-kel.

Szia!
Szerintem a pic18f45k20 3.3V-ról kell járjon, a gond a max232 -vel lehet, az 5V-os - max3232 lenne a 3.3V-os megfelelő.

A picben csak egy két tárolós megoldás van a vételi oldalon. Lehet, hogy nem veszed el időben a beérkező karaktereket (az RCSTA ráfutás bitje nem jelzi?) és csak az utolsó kettőt tudod csak kiolvasni...

Egy megszakításos, pufferelt uart kezelés megvalósítását javaslom.

Igazad lehet.
Én is arra gondolok hogy az RX/TX vonalak eltérő szintje lehet a ludas.
Habár fura hogy MAX232-vel megy, PIC-kel meg nem.
Elvileg mindkettő %V-os szintekkel dolgozik.
Esetleg az adatláb(aka)t fel kellene húzni, erre is utal az adatlap.

Szia!

Az adatlapja "Electrical characteristics" fejezete szerint pic18f45k20 max. 3.6V-ról (4.5V - a tönkretétel határa) működtethető. Ha a soros vevője a 0x0D és a 0x0A karaktereket tudja venni, a szintekkel nem lehet gond....

Látod, erre nem figyeletem
Johnni 21 sem utalt semmire a tápokkal kapcsolatban,
ezek szerint a modul és a pic is 3,3V-ról jár.

Igen ezt nem mondtam. A GSM is es a PIC is 3.3V -rol megy. De ha kiveszem a max232 -t az aramkorbol, a kommunikacio akkor is mukodik es az RX en ugyanugy kapom a CR es LF -et.
Azt vettem meg eszre, hogy ha bekapcsolom az echo -t (ATE1), akkor a valasz minden esetben AT. Es ekkor mar nincs CR LF. Olyan mint ha csak az elso ket karaktert venne es nem az utolso kettot. Az RCSTA -t folyamatosan figyelem es nincs rafutas, de azert a biztonsag kedveert minden parancs kiadas utan van egy CREN=0; CREN=1.

Szia!

A CREN = 0 törli a buffert és az épen vett adatot tartalmazó shift regisztert. Ne töröld a CREN-t minden vétel után, csak akkor, ha ráfutás történik. A vétel legyen gyors, a RCSTA-t egyszer szabad kiolvasni vett karakterenként (a karakter kiolvasása előtt - az értékét eltárolni, a tárolt értéken végezni a műveleteket), a vett karaktereket egy bufferbe betenni. A feldolgozást csak az üzenet zárókarakterének vétele után kezdeni.

A parancs pontosan ugy van:
if(RCSTAbits.OERR)
{
RCSTAbits.CREN=0;
RCSTAbits.CREN=1;
}

Ezt probaltam ugy hogy parancs kiadas ele, aztan hogy utana teszem, de nem valtozott semmi.

Szia!
Van egy apró, de bosszantó dolog az uart -ban, a CREN vagy az SPEN törése nem törli a vételi megszakítás kérést. A hibás karaktert ki kell olvasni. Valamint a FRERR bitet is le kellene ellenőrizni, ehhez viszont a RCSTA regiszter értékét egy segéd változóba kell áttenni. Csak egyszer szabad az RCSTA regisztert kiolvasni - mindig a vett karakter kiolvasása előtt...

Igy modositottam a kodot. De sajna nem segitett. Meg mindig csak az elso ket karaktert tudom kiolvasni.
Az AT parancs kiadasa utan egybol van egy OERR tulfutas, ott vegrehajtja a CREN=0 -at.

Szia!

Ez az, amit feszegetek...
- Hogyan van megírva a putrsUSART? Ha a karakterek adása között megvárja az adó kész jelzését, nem használható, mert ezalatt bejövő karaktereket nem tudod kiolvasni a vevőből - ráfutás lesz...

A soros adás is legyen megszakításos: A beíró függvény az adatokat tegye egy alkalmasan választott méretű, körforgó bufferba, számolja, hogy hány darab küldeni való adat van, engedélyezze az adási megszakítást.
A megszakítási rutin nézze meg, hogy van-e még küldendő adat, ha van olvassa ki, csökkentse a küldendő adatok számát, küldje el. Ha nincs, tiltsa le az adási megszakítás kérést. Az alkalmazás a beíró függvényt hivogassa megfontoltan, ne írjon egyszerre többet bele, mint a méret...

A soros vétel is legyen megszakításos: A vett karakterek - a státusz kiértékelése után - egy alkalmasan választott méretű, körforgó bufferbe kerüljenek, növelje az elérhető karakterek számát, az esetleges hibát (FRERR, OERR) kezelje le. Készüljön egy buffer olvasó rutin, ami kiszedi a soron következő karaktert a bufferből, csökkenti a rendelkezésre álló karakterek számát. A feldolgozás ezt hivogassa...

Ha ezekkel a függvényekkel kezeled az uart-ot, akkor az adás ideje alatt beérkező karakterek is bekerülnek a vevő bufferbe - nem vesznek el, nem lesz ráfutás sem...

Igen, megvarja az ado kesz jelzeset. Megneztem ez egy MPLAB C18 beepitett fuggveny.
Most elsokorben atirtam a soros veteli reszt megszakitasosra, gondoltam hatha eleg lenne. De nem, ugyanugy csak az elso ket karaktert veszi at.
Hogy ha rafutas lenne, akkor szerintem mindig mas karaktert irna ki a valasz karaktersorozatbol, nem?
Nagyon nem ertem en ezt, hogy lehet hogy a PC latja a karaktereket, de a PIC nem. (persze ha berakom a max232 -t.) Ha kiveszem a max232 -t akkor is mukodik PIC es a GSM, csak a valasz marad el nagyon.

Úgy gondolom, hogy csak a végén levő -t veszi...

Használsz paritást? A 9. bit (TX9, RX9) ki- vagy bekapcsolt? Baud rendben?

Szia!

Nem is figyeltem, de ez

nem azt csinálja, amit kellene: Ugyanis RCSTAbits.OERR vagy 1 vagy 0, ugyanígy a RCSTAbits.FERR is vagy 1 vagy 0. A stat maszkja 1, 2, 3 attól függően, hogy hogy állnak a bitek. És a
sem jó...


Ebben a maszk 6,

Ebben pedig 4...

Paritast nem hasznalok, a 9. bit kikapcsolt mindket helyen, a baudnak rendeben kell lennie, mert a PIC TX vonalan kiadott parancsot veszi a modul, az RX -el van a baj.

Igazad van/volt. Megirtam rendesen az RX -et megszakitasosra, kivettem a software delay -eket, a timer -eket at kellett rakni alacsony prioritasos megszakitasba es mukodik. Innen egy kis segitseg: interrupt_uart

Koszonom a segitseget, ezt tenyleg nem gondoltam volna

Szia!

Örülök, hogy végre működik, köszönöm a pontokat...
Kellene írni egy cikker a c-beli megvalósításról. Nekem assembly rutinok vannak 16F -re és 18F -re...

Hello!
Van egy M72-es gsm modulom! A kommunikáció megy vele, de nem tudok sms-t küldeni. Hiper terminalban küldöm neki a parancsokat. A kérésem az hogy össze tudná valaki foglalni, mit kell csinálni a modullal míg eljutok az sms küldésig?
pl.: Pin kód beírás gsm hátlózatra automatikusan feljelentkezik vagy nekem kell neki megmondani stb... Elég sokat szívtam vele, valószínűleg kihagyok valamit.
Köszi, Matyko