We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
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
@ 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.