Connect with us

Cant read PIC usart data with my pc.

Discussion in 'Misc Electronics' started by Mark Fortune, Aug 16, 2006.

Scroll to continue with content
  1. Mark Fortune

    Mark Fortune Guest

    Hi All,

    Sorry in advance if this turns out to be double-posted, it seemed to
    bounce from one group the first time and im not sure if that means it
    bounces from all.

    This might be a little OT on some groups, but I am having a little
    trouble getting my computer to read output from a pic microprocessor
    over a serial connection and i'm hoping its one of those "ah you just
    need to this" solutions an expert could tell me in seconds which would
    probably take me a couple of weeks to work out on my own.

    I have an 18F1320 pic, which i've programmed to periodically send data
    out to a small radio transmitter (easyradio433TS) about once a second.
    It's about 10 bytes of assorted data, sending at aproximately 19200 baud
    (or there abouts) using the PIC's onboard usart.

    the data out pin is connected to a small radio transmitter. So far so
    good, I can see data flowing out of the pic on my scope.

    At the other end is a matched radio reciever, again, I can see that it
    is recieving what appears to be the same data that goes into the
    transmitter on my scope (ie all the bits in the same place, not inverted

    The reciever is supposed to handle logic level CTS/RTS RX/TX etc. The
    reciever is connected to a MAX232CPE RS232 interface chip which does all
    the voltage conversions required for logic/rs232 interfacing, which in
    turn is connected to my computers serial port by a cable.

    Again all seems fine to this point, if I connect my scope up to the
    RS232 side, I see data pulsing down the line, and I can see the varying
    digitalness of each character representation.

    On the PC I am using linux (debian, kernel version 2.6.8 (customised
    kernel) / gcc 3.3.5 (debian 1:3.3.5-13) for those that need to know)
    Platform is i386, SiS chipset (not sure of the exact chipset but its got
    a 651 AGP host bridge, and SiS 962 ISA bridge, and it's the standard
    9-pin onboard serial port i'm using (only has one) i/o range 03f8-03ff).
    UART is a standard 16550A So any windows/dos suggestions will probably
    be wasted on me.

    so anyway, I decide to try and read the data coming into my PC's serial port

    cat /dev/ttyS0

    which in theory should give me a nice display of the incomming data.
    only it doesnt, it just sits there doing not much more than an ice cube.

    As a test to make sure the hardware was working (as best I can) I hooked
    the _logic side_ (ie the bit the radio is directly wired to) RX to TX,
    CTS to RTS and in another console did echo "hello" > /dev/ttyS0

    Lo and behold, I recieved a big hello in the window that I did cat
    /dev/ttyS0. I also get a load of linefeeds (0x0A) which i'm not sure
    about, but it certainly appears to me that data is going both ways
    through the RS232 chip.

    To note, I have also done cat /dev/ttyS0 | hexdump in an attempt to get
    hex data just in case it's garbaging the data somewhere along the line
    and sending non-printable characters. but still I get an integer less
    than 1.

    now i've checked my wiring, i've double checked my wiring, i've tripple
    checked my wiring, and hooked LED's up here there and everywhere to see
    when data pulses through, and I can, the led's pulse as I would expect.
    I have removed the radio transmitter/receiver pair and tried to run the
    RS232 chip direct from the pic. nothing, zilch, nada, nil, 0.

    Yet data is being send down the serial cable, to my pc's serial port, at
    19200 baud. my pc just will not pick it up.

    I have tried using the setserial utility to set the serial port to 19200
    baud, again the output I got was the square root of 0.

    I can think of only 4 possible causes for this problem:

    1. The reciever is sending out data with hardware flow control
    (RTS/CTS), yet my serial port is probably set to software flow control
    (Xon/Xoff). or any other number of serial port perameters are not met,
    such as start bits, stop bits, parity, number of mars bars etc. I can
    just about set the baud rate, but I have no idea how to set all these
    other parameters since i've not had to do anything like this since the
    early 90's, and back then I was using Dos. and so far i've not been able
    to find anyone that can give me a straight answer (resorting to the
    default rtfm reply - which manual? all setserial seems to do is set the
    baud rate and a number of seemingly unrelated things). Any advice or
    pointer to a really good info. resource on this would be greatly

    2. As above, but may be easier to set the PIC to manage software flow
    control, parity etc. if so, how do I find out how my serial port is set
    up in terms of parity, start/stop bits etc?

    3. The receiver (an Easyradio 433RS) mentions something in the datasheet
    about the output being inverted? so it can be directly interfaced with a
    pic. ie logical high = 0v, logical low = 5v. Apparently the MAX232CPE
    deals with this, but is this true? do I need to put an inverting buffer
    between the reciever pins and the max232?

    3. I am slowly going insane and everything is working perfectly, my
    brain is making me believe a problem exists where in reality I havent
    even got a computer.

    Thanks for any tidbits of advice,
  2. David

    David Guest


    What is the EasyRadio ? Is it designed to handle NRZ data ?
    Many radio links use an adaptive style data slicer that requires some
    preamble to set it up and usually the data needs to be DC balanced (long
    runs of "1" or "0" cause errors) so some form of Manchester coding is
    usually utilized.

    Can you capture the received data and analyze it for missing bits ?

    Kind Regards

    ORBIT COMMUNICATIONS Pty Ltd - Wireless Solutions that Work
    (Telemetry, Control, Monitoring, Security, HVAC ...)
    A.C.N. 107 441 869

    Website :
    PO Box 4474 Lakehaven
    Phone: 61-2-4393-3627
    Fax : 61-2-4393-3685
    Mobile: 61-413-715-986
  3. Guest

    Serial port on unix is not straight forward. Unix (linux included)
    serial port drivers assumes that the serial port is attached to a
    terminal and so the device drivers does all sort of "smart" things like
    echo, remote echo, readline etc. You need to bend over backwards to get
    it to work as a "simple" serial port.

    To get/set serial port parameters, use stty:

    stty -F /dev/ttyS0

    I'd recommend using a terminal program like minicom instead of directly
    reading /dev/ttyS0 for testing.
  4. laodao

    laodao Guest

    Mark Fortune 写é“:
    You may use the software "minicom" to read data from PC's serial
    port.And you can set the serial port's status,including band,hardware
    flow control,and so on by this software.
    Maybe this will help you.
  5. Rich Grise

    Rich Grise Guest


    The first thing I'd suspect is mismatched baud rates.

    Good Luck!
  6. Mark Fortune

    Mark Fortune Guest

    the easyradio handles preamble and manchester encding automatically. You
    basically feed data from the usart into the transmitter, and it
    transmits when its buffer reaches 128 bytes or detects a 2 byte gap (ie
    no data). it defaults to 19200baud but this can apparently be
    programmed. i'm using the pic usart set to 19200 baud. it then
    automatically sends the preamble, which the reciever automatically locks
    onto, and the data is transmitted using manchester coding (according to
    the manual anyway, I dont admit to knowing exactly how all this works).
    My scope is fairly old, so I have some difficulty in capturing the data
    with any accuracy, but it certainly appears that the data streaming out
    of the reciever is the same as the data going into the transmitter.

  7. Mark Fortune

    Mark Fortune Guest

    How much of a difference does it make if the baud rate is off by +-50?
    the problem here is the usart is clocked using the PICs internal
    oscilator, which tends to drift with temperature variations.
  8. Mark Fortune

    Mark Fortune Guest

    OK thanks, i've tried minicom now and i'm getting garbage through - but
    at least it's a lot more than I was getting before. I think I need to
    invert the output from the radio to stop it being garbage. Some
    experimentation is needed now.

  9. David

    David Guest


    Did you mean in your earlier posting that you attached the TTL UART
    output from the PIC into the MAX232 converter (bypassing the radio link)
    and the data displayed on the PC fine ? Was this using TX and ground
    connection only ?

    If not, this is something you could try to eliminate the PIC,Data and PC
    terminal program, leaving just the radio link to investigate.

    If you have done this then the terminal program is fine.

    If you have an old scope and cannot capture a packet then send a single
    character (say an "A") in a loop as quickly as the radio link can handle.

    This will enable the scope to trigger and the display will be steady
    enough to study the received data.

    Alternately, if you just want to "suck it and see" then write a small
    routine to bit bash a character out the serial port pin. This will
    enable you to change the polarity of the data sent and see if the data
    now gets through to the PC. If it does then you need to either bit bash
    all your transmitted data or place an inverter between RXD on receiver
    and the MAX232.

    Kind Regards

    ORBIT COMMUNICATIONS Pty Ltd - Wireless Solutions that Work
    (Telemetry, Control, Monitoring, Security, HVAC ...)
    A.C.N. 107 441 869

    Website :
    PO Box 4474 Lakehaven
    Phone: 61-2-4393-3627
    Fax : 61-2-4393-3685
    Mobile: 61-413-715-986
  10. Mark Fortune

    Mark Fortune Guest

    Yes and no, I did connect the TTL UART output from the PIC into the
    MAX232 - thus bypassing the radio link using just the TX and ground, but
    on the initial runs I got absolutely nothing on the PC.. Now in minicom
    I am getting (garbage) data through, but it's _exactly_ the same data -
    garbage or not - weather it's direct from the PIC or via the radio. Thus
    my suspicion is that the radio is transfering the data in one piece
    without any corruption.
    See above
    I am going to try inverting the signal, i'm just looking through my
    parts now to see if I have something I can bodge together (unfortunately
    last time I ordered some hex inverters I didnt realise they were surface
    mount - doh)
  11. David

    David Guest


    If you have not been able to get data to the PC via Micro UART to MAX232
    then inverting it won't help.

    The data from the micro should already be the correct polarity.

    From what you say, it looks more likely there is a problem with the
    Data itself (Check Baud rate and receive mode etc on the terminal
    program). Also check your program to ensure you have selected the
    correct Baud rate divisor (BRGH and SPRG regs). Particularly ensure these
    values are correct for the given crystal you are using on the PIC. (I am
    assuming the oscillator circuit on your PIC is working correctly).

    Kind Regards

    ORBIT COMMUNICATIONS Pty Ltd - Wireless Solutions that Work
    (Telemetry, Control, Monitoring, Security, HVAC ...)
    A.C.N. 107 441 869

    Website :
    PO Box 4474 Lakehaven
    Phone: 61-2-4393-3627
    Fax : 61-2-4393-3685
    Mobile: 61-413-715-986
  12. Guest

    If the baud is off by more than
    5%,there will be some error.If 50%,I think you will just get garbage.
    If so,I think that you could use low
    baud rate,like 4800,2400,1200.This may make it on the rails.

    I'm sorry that my english is not good enough.I hope that these will
    help you.
  13. Guest

    A difference of +/-50 (if that's really what it is) is 0.2% which is
    well within the recommended +/-1.5%.

    I once did a bit-banged UART (transmit only) on a 16C770 at 9600 baud
    using the internal RC oscillator. Looking at the data sheet it wasn't
    guaranteed to meet the spec even at room temperature but in practice it
    worked OK. We got a failure rate of a few percent at end-of-line test
    (this was a very low cost product and the UART was only used for
    calibration so this was deemed acceptable).

    Do you have any way of *accurately* measuring the bit-times at the PC
    RX input pin?
  14. rolfer

    rolfer Guest

    Maybe you should bite the bullet and buy a 50 cent crystal. I would
    recommend a 7.3728mhz, This will be easier than a 10mhz, or other
    value. It divides exactly to give a serial UART its charm.

    If you send a single character '0xF0' to the PC from the micro, you can
    see what the PC shows.


    If you you see more than one charcter coming out, then speed up the
    PIC. you then can draw out in binary the bits you get out, and use this
    to tune your speed.

    Then only other way is a digital storage scope.

    I would also suggest to try sending one character at a time. This will
    be easier to debug.

    Another possible trick is to send hex AA AA AA AA AA AA AA forever out
    of the micro and use a frequency counter. However you need to remember
    to make an allowance for the stop bit. So 9600bps baud should show up
    as 96,000hz. This is corny, but some multimeters measure frequency.
  15. jasen

    jasen Guest

    if you can wire it to one of the other input pins I can get better than
    microsecond timings in dos (from the timer chip) or linux (gettimeofday)

  16. werty

    werty Guest

    There will be no PICs in the near future . ARM cpu's will kill
    everything made .

    Computers , when they change , destroy hardware in the
    100's Millions of $$
    and RIF millions of jobs !

    Just ask Sun microsystems in 2001 !! It took Nasdaq from 5000 to
    1200 !

    And its so easy to improve hardware and software ! but govts have
    penalties for improving .
    But s/w is slow to change for they have obtuse hardware ( PC ) ,
    but when a new CPU comes along that nix's need for
    North/South bridge , FDC , HDC ....

    PDAs have an ARM CPU that burns 2 watts and has all these chips built
    in .
    It can do giga bytes , and 100's of MegaFlops , which means , some one
    will find it much easier to create a free OpSys on the easier h/w .

    Linux is actually tied to the PC , it can't migrate to PDA , for it
    will be
    obsoleted by the FREE OpSys that has not the problems with simple
    stuff like Files/Folders ( Linux cant do this stuff )

    I will do a free OpSys . It manages all objects /Files/folders .
    It will be totally integrated . No separate HLL to load , you can
    create assmbly code from high level , in place , and run it imediately
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