Connect with us

PIC USART troubles

Discussion in 'Electronic Basics' started by hybrid_snyper, Mar 3, 2007.

Scroll to continue with content
  1. Hello all,

    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

    Kind regards

  2. 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.
  3. 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.

    Thanks for the speedy reply.

  4. 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.
    You won't like it. ;-)
  5. Anthony Fremont wrote:

    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.
  6. You didn't say that before. I figured you used a standard cable. Tidbits
    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


  7. No apologies needed. :)
    This is only with the special cable, right? Not to be condescending, but
    you are cross connecting the RX pins to the TX pins, correct?
    Ok, that eliminates the other stuff I went on about. ;-)
    I don't know for sure, but I don't think they will prevent you from sending.
  8. jasen

    jasen Guest

    are you connecting PIC TX to phone RX (and vice versa) ?
    and also connecting signal ground at both ends?
  9. 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.

    I appreciate the assistance so far, thanks.

  10. 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.
  11. 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:

    View using a fixed width font.


    bsf STATUS, RP0 ; Select BANK 1

    movlw b'00100100' ; TXSTA
    ; |||||||+-------------- TX9D (9th bit to transmit)
    ; ||||||+--------------- TRMT (1-TSR Empty/0-TSR Full)
    ; |||||+---------------- BRGH (1-High-speed/0-Low-speed)
    ; ||||+----------------- N/A
    ; |||+------------------ SYNC (Usart Mode 0-Async/1-Sync))
    ; ||+------------------- TXEN (Transmit
    ; |+-------------------- TX9 (9 bit 1-enable)
    ; +--------------------- CSRC (Clock Source Select)
    movwf TXSTA & 0x7F

    ; movlw d'51' ; 9600 Baud
    movlw d'12' ; 38400 Baud
    movwf SPBRG & 0x7F

    bcf STATUS, RP0 ; Select BANK 0

    movlw b'00010000' ; RCSTA
    ; |||||||+-------------- RX9D (9th bit rcvd)
    ; ||||||+--------------- OERR (Overrun Error)
    ; |||||+---------------- FERR (Framing Error)
    ; ||||+----------------- ADDEN (Enables address detection)
    ; |||+------------------ CREN (Continous RCV Enable)
    ; ||+------------------- SREN (Single RCV Enable)
    ; |+-------------------- RX9
    ; +--------------------- SPEN (0=Disabled, 1=Enabled)
    movwf RCSTA

    bsf STATUS, RP0 ; Select BANK 1

    bsf PIE1 & 0x07F, RCIE ; Turn on Serial Receiver ints

    bcf STATUS, RP0 ; Select BANK 0

    bsf RCSTA, SPEN ; Turn on the USART
    bsf INTCON, PEIE ; enable peripheral interrupts

Ask a Question
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.
Electronics Point Logo
Continue to site
Quote of the day