Im in a bit of a desperate situation. I am trying to get my PIC 16f876 to talk to a Ericsson T28. The T28 has both TX/RX pins and I have connected them directly to the TX/RX pins on my PIC. I measured the voltage across the VDD and GND on the phone and I am running my PIC at the same voltage. I have written a simple program that should send the AT command AT+CFUN=0 this should turn the phone off. However this is not the case, I am not sure if i am understanding the USART spec, people have mentioned something about inversion but i thought this would only apply when wishing to reach RS232 levels.
I have connected the phone to my PC and ran hyper-terminal with the spec baud 9600, 8bits, 1 stop bit and no parity, i believe that i have set the PIC up correctly however the phone just isnt responding.
Could any one give any tips, also it may be worth looking at an older post of mine that will over a bit of background at what I have been up to.
Unfortunately, the internal USART outputs the signal using reversed polarity so that a level converter (like a MAX232) will work with it. If your T28 outputs a signal that an ordinary PC serial port can read, then you will need to invert the output of the PIC so that it can talk to the T28. When the phone is sitting idle, what is the voltage on the TX and RX pins? Compare those with the PIC.
That answers that. You need to invert the output of the PIC. Use an inverter, logic gate (NAND, XOR, or NOT) or whatever you wish to flip it over. Or you could bit-bang it. AFAIK, the PIC has no ability to invert the output of the USART, stupid as that sounds.
A PC can only read the signal when i use a special data cable, dissected the cable and found a max232 in it, therefore any signal conversion was done in the cable. I was under the impression that i would not need a max232 to connect the PIC and T28 directly because the MAX232 is used to bring a signal to RS232 standards.
Voltage on TX is 2.7V
Could i ask why this is, is the output from the TX meant to be neg?
Not sure what bit banging is but will look into it.
You didn't say that before. I figured you used a standard cable. Tidbits like this are extremely important.
Try connecting the PIC to the pc using the special cable and see if it's working. Do you have a scope to verify the baud rate is correct.?
Sounds like your phone may be 3.3V compatible. If so, it may not much like you slapping it with 5V signals from the PIC. Try powering the PIC from 3V and see what happens. Make sure brown out detect (BODEN) is not enabled.
I assume you are powering the PIC from 5V? If so, 2.7V will not register as a 1 on a Schmitt trigger input, it is too low. The spec calls for .8 * Vdd to be read as a logic 1. IOW, you need 4V to talk to the PIC. The phone may be responding, you just aren't seeing it. This is another reason to try running the PIC from 3V. You will only need 2.4V to be read as a logic 1.
In TTL levels, the high would be +5 (or actually closer to 3V in your case) and the low would be GND. In RS-232 world, a high is signified by -10V (actually a range, but this is close enough). A low is signified by +10V signal. This is what a MAX232 would do to the signals. Since your cable has a MAX232 built in, you should be able to ignore what I said before.
One other thing. Did you write this code yourself? If so, do you know about the oddities of the PIC serial port? They really aren't oddities per se, but they can cause you much grief. If you get a "framing error" or "overrun error", you have to deal with them or the PIC will stop receiving data and just sit there. It's almost gauranteed that you will be getting these at some point, especially since it appears that your PIC is probably interpreting the idle signal from the phone as a start bit since it looks like a logic 0 to the pin because of the low voltage. This would generate a framing error when it reads the stop bit as low also.
Apologies, ive taken the MAX232 out of the equation now.
The phone can speak to the PC via hyper-terminal, with the settings Baud 9600, 8 bits ,1 stop , parity none. i dont have a scope to hand till Monday morning so impossible to tell, but on friday when i was in the lab all seemed well. But since then i have made a few changes to the code but nothing i think would affect the running, but then again who knows.
Been running the PIC at 3.3V with brown out off.
with ref to the errors these would only affect the RX, yes? At the moment i am trying to send an AT command that will switch off the phone this would give me a definite confirmation that the phone received the command. Would these FERR and OERR errors affect the TX line?
Im totally baffled here, this is where im at. I have the phone and the PIC wired as so
PIC TX PHONE RX PIC RX PIC TX PIC GND PHONE GND
I have been running the PIC somewhere between 3V and 3.3V, i have tried some new code using the PICC compiler samples and some other stuff ive come up with. I have tried sending the AT command AT
+CFUN=0\\r byte by byte, this string should tell the phone to turn off, the command works no bother when i use hyper-terminal.
I have now tried a new program that will send a simpler command AT which will give the response OK, once PIC RX receives the bytes from the phone an LED should turn on to confirm this. I have attached links to the C code I am using as i thought this might help paint a better picture of what is going on. I have a feeling that something is up with the code as the TX and RX pins are constantly high and there is never any variation in the voltages.
Seem to be making some progress now i have managed to successfully send a command that turns the phone off, now ive got to build on this and try and send a command that will give a reply.
Ok, that's good. I always forget to ask about this.
Your BAUD calculations look like they should work, but I bet they generate gobs of machine code. If you don't need to change the BAUD on the fly, you can make the compiler do all the work for you, but that's beside the point. Does pic.h contain the correct values for your particular chip? I don't see anything in your code to tell the compiler what chip you are using, so I don't know how it could know where all the SFRs are unless it's in pic.h. What compiler are you using? Here is some assembler code that initializes the UART on a 16F88. It sets it to 38400 and the pic is running at 8MHz, it also enables interrupts on received characters:
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.