Cant read PIC usart data with my pc.

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
etc)

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
appreciated.

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,
Mark

 

Mark,

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

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


Website : http://www.orbitcoms.com
PO Box 4474 Lakehaven
NSW 2263, AUSTRALIA
Phone: 61-2-4393-3627
Fax : 61-2-4393-3685
Mobile: 61-413-715-986

 

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.

 

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.

 

^^^^^^^^^^^^^^^^^

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

Good Luck!
Rich

 

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.

Mark

 

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.

 

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.

Thanks
Mark

 

Mark,

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

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


Website : http://www.orbitcoms.com
PO Box 4474 Lakehaven
NSW 2263, AUSTRALIA
Phone: 61-2-4393-3627
Fax : 61-2-4393-3685
Mobile: 61-413-715-986

 

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)

 

Mark,

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

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


Website : http://www.orbitcoms.com
PO Box 4474 Lakehaven
NSW 2263, AUSTRALIA
Phone: 61-2-4393-3627
Fax : 61-2-4393-3685
Mobile: 61-413-715-986

 

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.

 

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?

 

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.

(11110000)

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.

 

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)

Bye.
Jasen

 

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
stiff
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
..