hi, i am doing gps tracking device prject but i am unable to receive any data from my EM-506 Module, i am using to the following piece of code to capture data: void Serial_Init() { TMOD = 0x20; TH1 =0xF4; SCON = 0x50; TR1 = 1; }
rx_data(void) { char x; while(RI==0); x=SBUF RI = 0; //lcd("2"); return x; }
i noticed that the programm is stuck because RI never changes his state but when i measure the the voltage of p3.0 (RX pin of 8051) it changes ("0" and "1") so the cpu receives data from the gps.
thanks in advance.
Are the baud rate and voltages correct? Is the "8051" expecting 5V signalling?
Try doing a simple serial port loop-back on the 8051, where you see if you can receive data you transmit out at 9600 8N1? View that on a oscilloscope.
Ask your project supervisor for assistance.
here, again we have "8051" there is NO SUCH THING anymore. the modern devices have all their little 'specials' re I/O manufacturer and ALL letters needed
for some reason i the 8051 doesn't accaept the data that the gps sends no matter what baud rate i try(4800, 9600 or 2400, 4800 is the gps default), can the voltage diffrence be an issue (3.3v output of gps to 5v input of 8051)?
"3.3v output of gps to 5v input of 8051"
That depends on what 8051 chip you have.
Some chips are designed to play nice with 3V3 devices. But some 8051 chips will be unhappy. Especially if the GPS uses TTL rules and don't go rail-to-rail but have an output voltage that is significantly lower than 3V3.
Just as an addendum. One important reason for the existence of data sheets is to make it possible to verify the min and max low and high in/out limits and the absolute max input/output limits to verify that a specific output pin on one device is compatible with the input of another device.
For more advanced designs, timing, capacitances etc also needs to be verified. So you might have to check max output current and compute how fast it can charge/discharge a capacitive load and if that is fast enough for required rise/fall times.
Anyway - ignoring data sheets is a good way to end up with unexpected and sometimes very unpredictable problems. You might create a design that seems to work well unless it's a warm day or the battery is below half capacity. When inputs/outputs aren't compatible, lots of strange things can happen.
5 minutes of validation of pin specifications can save hours or days of frustration, and a potentially huge rework.
manufacturer and ALL letters needed ... for some reason i the 8051 doesn't
why do we bother discussing problems with posters that will not even answer simple questions?
I use p89v51rd2 in the project, i have read the gps datasheets and didn't find anything wrong with my connectins(the led indicator blinks so the gps finds itS signal), so the only problem that i can think about is the 3.3v-5v uart communication so i will try a logic level shifter. even so, i still dont realize why the controller doesn't detect any serial data, even if the gps "high" output level is "low" when it reaches to the 8051, from my understanding it should detecet some data (even if its wrong), but RI register stays low all the time,so what am i missing? why RI can't be "1"?
Below a certain level you can do anything and the processor pin will still always read a zero.
Above that, you have a window where you don't know what will happen. Maybe read as zero. Maybe read as one. Maybe read as random noise. Maybe result in high power consumption. Likely to change behaviour from small change of temperature or supply voltage.
Above that you have a level where the input signal will always be detected as a one.
If your GPS signal does not have "0" transmited below the maximum allowed low voltage, and have "1" transmitted above the minimum allowed high voltage, then you are on your own. You have failed with the contracts terms, and the processor is free to misbehave in whatever way it feels like with the exception of fatal outcomes like catching fire.
If you go shopping for a sound system and the price tag says $1000 and you hand over $850 you might get it. Or the shop might ignore you. You'll depend on luck if the payment gets accepted despite being less than the requested amount. The difference is that when buying things, you can negotiate and if you get a no, you can give up or you can hand over the full amount. When designing hardware - if you skip fulfilling all contractual agreements between the different chips you just have to pray that it works and continues to work. But you most certainly can't _expect_ that it should work.
Have you done a basic transmit/receive loop-back test yet? Say sending a repetitive 'U' or 0x55 character. What does that look like on a scope? How does that compare with the signals you see from the GPS. ie form, bit-timing?
Take the GPS out of the equation, confirm you can actually use the UART, and the flags function as expected/documented.