Searching \ for '[PIC]: problem with some very simple serial comms' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/ios.htm?key=serial
Search entire site for: 'problem with some very simple serial comms'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: problem with some very simple serial comms '
2000\09\19@121913 by Simon Nield

flavicon
face
part 1 1433 bytes content-type:text/plain; charset=us-asciiMy forehead is bleeding from banging it against the wall trying to work out just what is happening
here...
I have some code that is interfacing an rs232 device that constantly emits packets to a polled rs485
bus.
The 232 interface is bit-banged in software and the 485 is done using the hardware uart.

my first cut of code worked pretty well - I was servicing the 485 / hw uart in an interrupt routine,
and my main loop was doing the software uart with hard coded delay loops.
I was getting a fair number of trashed packets back from the SW uart, probably due to the ISR
interupting my carefully timed delay loops. So i figured I would flip the system around... use TMR1
to generate accurate interrupts for my SW uart, and poll RXIF / TXIF in my main loop for the HW
uart.
This didn't work... I have cut the system down to the point where all i am trying to do is the
polled HW uart thing... still no joy;
the first packet kind of works - I get 0x11, 0x33, 0x55, 0x77 and then nothing... every other byte
missing (also 0x99 onwards is missing).
from then on i get no replies! I am pretty sure there is something stupid wrong with my code, but I
can't see it... help!

WDT is disabled, as is the BOR and ICD...

I have attached the asm.

What should happen is it gets sent ('Z', 0x03, 0xnn) and replies with (0x11, 0x22, 0x33, 0x44, 0x55,
0x66, 0x77, 0x88, 0x99, 0xaa, 0xnn)



Yours in hope,
Simon


(See attached file: tab_c.asm)


part 2 4924 bytes content-type:application/octet-stream; (decode)

part 3 184 bytes
--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\19@164553 by Olin Lathrop

flavicon
face
> My forehead is bleeding from banging it against the wall trying to work
out just what is happening
> here...
> I have some code that is interfacing an rs232 device that constantly emits
packets to a polled rs485
> bus.
> The 232 interface is bit-banged in software and the 485 is done using the
hardware uart.

You left out some important information.  What baud rate is your software
UART running at and what clock speed is the 16F877 running at?

I've done software UARTs before, and they are definitely tricky.  Sending is
easier because you decide when to send.  That allows you to neatly shut off
interrupts before starting a character and enabling them as soon as you are
done.

Receiving, however, is a different story.  You have to be constantly looking
for the start bit, and you had better catch it very accurately because all
the timing for all the remaining bits is driven from that.  This also means
you have NO BUFFERING at all.  It is very easy to loose characters if the
transmitter is sending them at full rate because you have only 1 1/2 bit
times from the center of the last data bit to the leading edge of the next
start bit.  This doesn't leave much time to return to the caller, process
the character, or do whatever else the system needs to do.

I did a software UART once on a low power and low cost system with the PIC
running at 160KHz and using 4,800 baud.  That allowed 3 to 4 instructions
per bit, if I remember right.  Note that the minimum loop waiting for the
start bit is 3 instruction cycles, so there was a problem right there.  In
addition, I couldn't turn off interrupts until after the start bit was
received.  The purpose of the communications link was to download measured
data to a PC.  I kept the PC to PIC command set very small and all commands
were individual bytes that stood by themselves.  The PC would issue the
download command, then retry every 250mS if the PIC didn't respond with a
download.  In otherwords, I treated the PC to PIC channel as lossy (about 1
in 10 characters got garbled in practise) and designed the higher level
protocol to tolerate that.

AsmXz, depending on the speed of your PIC and the baud rate, you could
possibly use the CCP module or PORT B interrupt on change to figure out when
the edges are occurring.  However, that requires many cycles per bit time.

How about an external UART or another PIC with a UART connected to IIC, SPI,
or something?


*****************************************************************
Olin Lathrop, embedded systems consultant in Devens Massachusetts
(978) 772-3129, spam_OUTolinTakeThisOuTspamcognivis.com, http://www.cognivis.com

--
http://www.piclist.com hint: PICList Posts must start with ONE topic:
"[PIC]:" PIC only "[EE]:" engineering "[OT]:" off topic "[AD]:" ad's


2000\09\19@173726 by Bob Ammerman

picon face
Really, software UARTs are not all the difficult nor problematic. As long as
you have sufficient clock speed you can create an interrupt-driven software
UART that your main program can treat just like a hardware UART.

The only time you run into trouble is if you have some other process that
has tight interrupt latency requirements.

Bob Ammerman
RAm Systems
(contract development of high performance, high function, low-level
software)


{Original Message removed}

2000\09\20@044847 by Simon Nield

flavicon
face
part 1 491 bytes content-type:text/plain; charset=us-asciiOlin, Bob et al.

The software UART is not a problem and is working fine.
The problem I have is with a simple polled hardware UART.

(as stated in the  .asm code the clock rate is 20MHz and baud rate is 115200 btw... i tried ramping
the baud rate down to 9600 and i have the same problem so I don't _think_ the baud rate is an issue
here)


> What should happen is it gets sent ('Z', 0x03, 0xnn) and replies with (0x11, 0x22, 0x33, 0x44,
0x55,
> 0x66, 0x77, 0x88, 0x99, 0xaa, 0xnn)




part 2 4924 bytes content-type:application/octet-stream; (decode)

part 3 144 bytes
--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\09\20@095935 by pig

flavicon
face
Have you checked to see if you are getting any over run errors on the
hardware uart. If you get an over run error it will halt the uart until
it is reset.
Regards
Stuart O'Reilly

Simon Nield wrote:
{Quote hidden}

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\09\20@111640 by Simon Nield

flavicon
face
>Have you checked to see if you are getting any over run errors on the
>hardware uart. If you get an over run error it will halt the uart until
>it is reset.
>Regards
>Stuart O'Reilly


Cheers Stuart! We had in fact discovered that this is EXACTLY what is happening about 5 minutes
ago... I just went for a Dr.Pepper to celebrate ;)

If it's not there already then it would make a good addition to any PIC faq on 2 wire RS485... make
sure you disable the receiver before transmitting or you will overflow the receive buffer.

You live and learn...

Simon

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\09\20@140953 by Andy Howard

picon face
> From: "Simon Nield" <.....simon.nieldKILLspamspam@spam@QUANTEL.COM>

> Olin, Bob et al.
>
> The software UART is not a problem and is working fine.
> The problem I have is with a simple polled hardware UART.

> (as stated in the  .asm code the clock rate is 20MHz and baud rate is
115200 btw... i tried ramping
> the baud rate down to 9600 and i have the same problem so I don't _think_
the baud rate is an issue
> here)

Check out Fr Tom's splendid UART tutorial at
http://redrival.com/mcgahee/picuart.zip. If that doesn't sort your problems
then nothing will...



.

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics


2000\09\21@182910 by Bruce Cannon

picon face
> If it's not there already then it would make a good addition to
> any PIC faq on 2 wire RS485... make
> sure you disable the receiver before transmitting or you will
> overflow the receive buffer.

Doesn't one normally tie both enables together and toggle between the two
drivers?

Bruce Cannon
Style Management Systems
http://siliconcrucible.com
(510) 787-6870
1228 Ceres ST Crockett CA 94525

Remember: electronics is changing your world...for good!

--
http://www.piclist.com hint: The PICList is archived three different
ways.  See http://www.piclist.com/#archives for details.


2000\09\22@045736 by Simon Nield

flavicon
face
>Doesn't one normally tie both enables together and toggle between the two
>drivers?

I chose not to do this so I could (if neccessary) verify my writes to the bus were not getting
trashed.
Fair point though.

Regards,
Simon

--
http://www.piclist.com#nomail Going offline? Don't AutoReply us!
use listservspamKILLspammitvma.mit.edu?body=SET%20PICList%20DIGEST


More... (looser matching)
- Last day of these posts
- In 2000 , 2001 only
- Today
- New search...