Searching \ for 'Serial bit-banging on a 16C57' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/ios.htm?key=serial
Search entire site for: 'Serial bit-banging on a 16C57'.

Truncated match.
PICList Thread
'Serial bit-banging on a 16C57'
1997\02\09@085236 by anick

flavicon
face
I hav been trying to get reliable serial communications on a 16C57 for
a while now, an almost have it working. The problem is that it doesnt
seem to get the first 3 bytes ok, they are always the same relative to
the data but wrong.

Here is what I should receive:

36h 32h 30h 32h 30h 38h
The rest is ok.
This is what I get:

4dh 4ch 4ch 99h 98h 38h

Can someone tell me whats wrong?

Data rate is 2400 baud, Total bessage is 32 bytes, I only need the first
16.

--
Alan Nickerson
---------
It seems to me that the best new ideas come from
people who don't know that they "can't".  -- Paul Mathews,
spam_OUToptoengTakeThisOuTspamWHIDBEY.COM

1997\02\09@100813 by Chaipi Wijnbergen

flavicon
picon face
On Sun, 9 Feb 1997, Alan Nickerson wrote:

> I hav been trying to get reliable serial communications on a 16C57 for
> a while now, an almost have it working. The problem is that it doesnt
> seem to get the first 3 bytes ok, they are always the same relative to
> the data but wrong.

you need to give more information in order for others to help you. like
how do did you implement the serial communication and whether it is input
or output.

I use CCS C compiler for RS232 between 16C57 and my PC. it works well.
output is easy and can be done in high boud rate, but, if you need input
to the 16C57, you need to pool the serial commands frequent enogth in
order not to miss some of the serial input.

My application has a main loop that check each time for kbhit() and if
true, then it gets it. I slowed communication to 1200 BPS for this.

Chaipi

{Quote hidden}

                              \\\|///
                            \\  ~ ~  //
                             (  @ @  )
----------------------------oOOo-(_)-oOOo--------------------------------------
!                                                                             !
! Chaipi Wijnbergen                                                           !
! Electronics/Computer Eng. M.Sc.  Tel    : +972-8-9343079                    !
! Optical Imaging Laboratory       Fax    : +972-8-9344129                    !
! Brain Research Center            Email  : chaipispamKILLspamtohu0.weizmann.ac.il       !
! Weizmann Institute of Science    URL    : http://www.weizmann.ac.il/~chaipi !
! Rehovot 76100 ISRAEL             IPhone : chaipi                            !
!                                                                             !
------------------------------------Oooo.--------------------------------------
                         .oooO     (   )
                         (   )      ) /
                          \ (      (_/
                           \_)

1997\02\09@113447 by John Dammeyer

flavicon
face
At 08:51 AM 09/02/1997 -0500, you wrote:
>I hav been trying to get reliable serial communications on a 16C57 for
>a while now, an almost have it working. The problem is that it doesnt
>seem to get the first 3 bytes ok, they are always the same relative to
>the data but wrong.
>
>Here is what I should receive:
>
> 36h 32h 30h 32h 30h 38h
> The rest is ok.
> This is what I get:
>
> 4dh 4ch 4ch 99h 98h 38h
>

Sounds like a jitter problem.  Once you detect your start bit edge,  you
need to wait until you are approximately in the middle of the next bit so a
total delay of 1.5 bit time is needed.  Actually not quite 1.5 bit time but
a little less.  How much?  Depends on when the start bit occurred and when
you spotted it.

For example:

2400 baud is about 416.6666 uSec per bit.  Assuming you detect the start bit
within 1 uSec of it occuring you need to delay 208 uSec,  then read start
bit again.  If not there any more than you have false triggering so go back
to waiting for a start bit.  If start bit is still there then delay 416 uSec
into the next bit position read first data bit.  Then delay 416 again for
each bit until done.  This way you are always in the middle of a data bit.

Now if, worst case you miss the start bit by 50 uSec then subtract half that
from your initial delay.  ie: delay about 175 uSec. from start bit edge and
after that back to 416 uSec.

Note that you lose .666666666 uSec each loop so over one char you'll be out
by 6 uSec.  If your data  has no inter character delay where you can resync
on a new start bit this could accumulate and become a problem but not
usually at 1200 baud.

That is how the UARTs do it.  Start bit edge begins the sequence.  8 clocks
of the 16x baud clock are counted and the start bit is verified.  After that
16 clocks are counted.

You can do the whole thing under interrupts on the PIC by choosing a Baud
rate crystal.  ie: one that divides nicely by 16 (or 8) into the baud clock.

For example.  If you produce an interrupt every 52 uSec (8x bit rate of 2400
baud) and check your serial line you can see a start bit within 1/8th of a
bit time.  Set a counter to ignore 4 of those interrupts and then on the
fifth interrupt check it again (or is it fourth???? whatever...).  If start
bit still there then set the counter to ignore the next 8 interrupts and
when the 8th arrives shift in your first bit.  Wait 8 interrupts again until
you've accumulated your last bit.  Then wait 12 to get past stop bit.  If
input line is still active after 12 interrupts you are into another start
bit or you have an over run error.

You could disable these interrupts when you don't want to receive characters.

Just an idea.

Regards,

John
Pioneers are the ones, face down in the mud,
with arrows in their backs.
Automation Artisans Inc.      Ph. 1-250-544-4950
PO Box 20002                  Fax 1-250-544-4954
Sidney, BC CANADA V8L 5C9

1997\02\09@115448 by Don L. Jackson

flavicon
face
At 08:51 AM 2/9/97 -0500, you wrote:
{Quote hidden}

You may have a slight problem in timing, especially in processing each byte
after it is received -- appears you may be missing a start bit or something.

If you write out the bit pattern of what the data should be, least
significant bit first from left to right on paper and insert a "10" between
the bytes for the stop/start bits, and then a similar bit pattern of what
data was received right below it, then you'll see that you are receiving
the data bits but out of frame sync.  (Whew! what a sentence!)  The
resultant data patterns will be skewed from each other.

What algorithm are you using?

Looks like you are *almost* there.  Good luck.

Don L. Jackson / Gilbert, Arizona
Azark Consulting Group

1997\02\09@143654 by anick

flavicon
face
Don L. Jackson wrote:
{Quote hidden}

I am polling the receive pin 3 consecutive times, if each test shows the
start bit
then I call the receive buffer function.

Here is a little more of the operation.

The remote device sends an '>' (E3h) every 1.5 - 2 seconds. After that I
can send
a command. The receiving of the E3h works fine. After I receive the E3h
and respond
with my command, (in this case a request status). The remote system
sends it's
status message, however the first 3-5 bytes are mangled but the rest is
fine.

I cannot use an external clock to generate an interrrupt because the
hardware
design is already in use. I also cannot make any modifications to the
current
electronic design. A simmilar function is already in use with a
different remote
device, and this would be an upgrade to the newer remote unit.

Thanks for your help.

--
Alan Nickerson
---------
It seems to me that the best new ideas come from
people who don't know that they "can't".  -- Paul Mathews,
.....optoengKILLspamspam.....WHIDBEY.COM

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