This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

GSM MODEM INTERFACE

hello everyone ,
i am facing a strange situation.
i simply sent AT<CR> to gsm modem but in response receive only CR and character A instead of proper response i.e. <cr><lf>ok<cr><lf>
already tied DTE and RTS pins to +5v for handshaking.

with hyperterminal everything was ok but this is not the case with uc.I also read previous threads but nothing worked.

Any idea which can help?????

thanks n regards
rishi

Parents
  • I asked:

    How have you made sure that you don't loose any received characters?
    

    I don't really think "I am running uc at 48Mhz..." is a very comprehensive answer.

    Are you polling the serial port, or are both serial ports interrupt driven?

    Are you using ring buffers for both serial ports?

    What do you mean with perfectly matched baudrate? That you have the same baudrate on both ports? Or that you have checked with an oscilloscope that the actual baudrate matches your expected baudrate?

    Are you using printf() or similar for emitting the trace output, or are you just moving the received character to the transmit buffer? And if printf - is it from the ISR or in a main loop?

    Right now, we don't have much information - other than your 48MHz setting. We don't even know if you run your serial ports at 1200 baud or at 115400 baud...

Reply
  • I asked:

    How have you made sure that you don't loose any received characters?
    

    I don't really think "I am running uc at 48Mhz..." is a very comprehensive answer.

    Are you polling the serial port, or are both serial ports interrupt driven?

    Are you using ring buffers for both serial ports?

    What do you mean with perfectly matched baudrate? That you have the same baudrate on both ports? Or that you have checked with an oscilloscope that the actual baudrate matches your expected baudrate?

    Are you using printf() or similar for emitting the trace output, or are you just moving the received character to the transmit buffer? And if printf - is it from the ISR or in a main loop?

    Right now, we don't have much information - other than your 48MHz setting. We don't even know if you run your serial ports at 1200 baud or at 115400 baud...

Children
  • @ westermark-
    By perfect baudrate match i mean baudrate error can not be an issue because i have checked it on DSO as well as on hypertermianl.My modem communicate at 115200 bps.
    I simply transmit AT<CR> and then wait (polling) for receive interrupt to get set.As soon as it get set i read the receive register and transfer this byte into 1-dimensional array location.Now clear the flag and again wait for the next character.

    For testing currently i am doing only serial communication.No other task is being handled by uc.So it is less probable that in just clearing flag and saving a byte may result in missing data.

    I have given a deeper thought once again and think that may be my modem is using high speed processor this means although baudrate is okey but when it responds i loose some data during flag bit clearing and transferring data.Now trying to get more faster uc.

  • "Now trying to get more faster uc."

    There's no need for that - as you said yourself, a 48MHz processor should be fine:

    Instead, use interrupt-driven serial IO.

    There are perfectly usable examples in the downloads section...

  • The UART is (at least) single-buffered, i.e. when it has received a character, it moves it to the receive register and then give you a full character transmit time to pick up the receievd character.

    8n1 givs 10 bits at 115200 baud (followed by a short pause before the next character) and means that you have at least 90 us to react.

    So you pick upp all characters first - and then emit all received characters? That should avoid problems with difference in baudrate between GPS and debug serial port, and time required for whatever method you use to emit the debug info.