Fórum témák

» Több friss téma
Fórum » PIC - GSM hibák
 
Témaindító: johnni21, idő: Szept 23, 2010
Témakörök:
Lapozás: OK   1 / 1
(#) johnni21 hozzászólása Szept 23, 2010 /
 
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
(#) (Felhasználó 1947) hozzászólása Szept 23, 2010 /
 
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.
(#) Hp41C válasza (Felhasználó 1947) hozzászólására (») Szept 23, 2010 /
 
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.
(#) (Felhasználó 1947) válasza Hp41C hozzászólására (») Szept 23, 2010 /
 
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.
(#) Hp41C válasza (Felhasználó 1947) hozzászólására (») Szept 23, 2010 /
 
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....
(#) (Felhasználó 1947) válasza Hp41C hozzászólására (») Szept 23, 2010 /
 
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.
(#) johnni21 válasza Hp41C hozzászólására (») Szept 24, 2010 /
 
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.
(#) Hp41C válasza johnni21 hozzászólására (») Szept 24, 2010 /
 
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.
(#) johnni21 válasza Hp41C hozzászólására (») Szept 24, 2010 /
 
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.
(#) Hp41C válasza johnni21 hozzászólására (») Szept 24, 2010 /
 
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...

  1. stat=RCSTA;
  2. c=RCREG;
  3. if (!(stat & ((1 << OERR)||(1 << FRERR))))
  4. {
  5.  buffer=c;
  6. }
  7. if(stat & (1 << OERR))
  8. {
  9.   RCSTAbits.CREN=0;
  10.   RCSTAbits.CREN=1;
  11. }
(#) johnni21 válasza Hp41C hozzászólására (») Szept 24, 2010 /
 
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.

  1. putrsUSART((const far rom char *)"AT\r");
  2.  
  3. if(RCSTAbits.OERR)
  4. {
  5.         RCSTAbits.CREN=0;
  6.         RCSTAbits.CREN=1;
  7. }
  8.  
  9. while(DataRdyUSART())
  10. {
  11.        
  12.       stat=RCSTA;
  13.       c=RCREG;
  14.       if (!(stat & ((1 << RCSTAbits.OERR)||(1 << RCSTAbits.FERR))))
  15.       {
  16.        keybuf[k]=c;
  17.       }
  18.       if(stat & (1 << RCSTAbits.OERR))
  19.       {
  20.         RCSTAbits.CREN=0;
  21.         RCSTAbits.CREN=1;
  22.       }
  23.         k++;
  24. }
(#) Hp41C válasza johnni21 hozzászólására (») Szept 24, 2010 / 4
 
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...
(#) johnni21 válasza Hp41C hozzászólására (») Szept 24, 2010 /
 
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.
(#) Hp41C válasza johnni21 hozzászólására (») Szept 24, 2010 /
 
Úgy gondolom, hogy csak a végén levő -t veszi...
(#) Ladoz válasza johnni21 hozzászólására (») Szept 24, 2010 /
 
Használsz paritást? A 9. bit (TX9, RX9) ki- vagy bekapcsolt? Baud rendben?
(#) Hp41C válasza johnni21 hozzászólására (») Szept 24, 2010 /
 
Szia!

Nem is figyeltem, de ez
Idézet:
„if (!(stat & ((1 << RCSTAbits.OERR)||(1 << RCSTAbits.FERR))))”

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
Idézet:
„if(stat & (1 << RCSTAbits.OERR))”
sem jó...

Idézet:
„if (!(stat & ((1 << OERR)||(1 << FERR))))”

Ebben a maszk 6,
Idézet:
„if(stat & (1 << OERR))”

Ebben pedig 4...
(#) johnni21 válasza Ladoz hozzászólására (») Szept 27, 2010 /
 
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.
(#) johnni21 válasza Hp41C hozzászólására (») Szept 29, 2010 /
 
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
(#) Hp41C válasza johnni21 hozzászólására (») Szept 29, 2010 /
 
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...
(#) borvendeg hozzászólása Júl 30, 2013 /
 
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
Következő: »»   1 / 1
Bejelentkezés

Belépés

Hirdetés
Lapoda.hu     XDT.hu     HEStore.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem