Searching \ for '[PIC]: Need creative help with bit-banging' 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/devices.htm?key=pic
Search entire site for: 'Need creative help with bit-banging'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]: Need creative help with bit-banging'
2001\05\01@140248 by Josh Koffman

flavicon
face
Greetings. After a bit of a hiatus, I'm back on the PIClist. That is of
course, until work sucks my time away again, and I haven't the chance to
experiment. Anyway, while I have the time, I am working on a new
project, and I have come up against a bit of a wall. I would appreciate
any advice or help anyone can give me with this one.

Basically my problem is this: I am trying to bit-bang a serial signal at
250Kbps, using a 16f84 running at 4MHZ. This is not as big of a problem
as it seems. It has been done before. I am putting a bit of a spin on
it. At the required speed, there are only 3 instruction cycles between
the time that the output bit must be set (well 4, but one of them is
used to actually set the output). I am running out of time in
determining what the bit should be, and then setting it. Here are a few
of the solutions I have come up with, and why I don't like them.

1) I could just rotate the bits using a rrf and just copy the register
to the port. This is how it is traditionally done, however, I need
almost every i/o line I have. Normally I would just mask off the first
bit, then combine it with whatever else is going on with the port.
Unfortunately I don't have enough time to perform these operations on
the fly. Just rotating would eliminate 4 i/o lines, unless I made them
my inputs. I could do this, and right now, it seems like the best
solution.

2) Increase the clock speed of the PIC. I could do this, but I sometimes
have a hard time getting ahold of 16f84's that are rated that high. I
could overclock I suppose. I would probably want to keep the clock speed
a multiple of 4 so I don't have to totally recalculate my delays.

3) I could pre calculate what the bit settings for each bit will be. In
this application, I am transmitting the same 8 bit value over and over,
so it would not be too hard. However, I want to use this subroutine in
the future to transmit 256 different values, and figuring everything out
in advance for 256 values is too much work.

Well, that's about all I can think of right now. Comments? Criticisms?
Suggestions? Please, Please let me know.

Thanks!

Josh Koffman
spam_OUTjoshyTakeThisOuTspammb.sympatico.ca

--
http://www.piclist.com hint: To leave the PICList
.....piclist-unsubscribe-requestKILLspamspam@spam@mitvma.mit.edu


2001\05\01@141724 by Andrew Warren

flavicon
face
Josh Koffman <PICLISTspamKILLspammitvma.mit.edu> wrote:

> Basically my problem is this: I am trying to bit-bang a serial
> signal at 250Kbps, using a 16f84 running at 4MHZ. .... At the
> required speed, there are only 3 instruction cycles between the
> time that the output bit must be set (well 4, but one of them is
> used to actually set the output). I am running out of time in
> determining what the bit should be, and then setting it.
> ....
> In this application, I am transmitting the same 8 bit value over and
> over

Josh:

With the 8-bit value in a register called "BYTE", and assuming that
you're transmitting on RB0 and you want to send LSB first:

   MOVF    PORTB,W

   ....

   ANDLW   11111110B
   BTFSC   BYTE,0
   IORLW   00000001B
   MOVWF   PORTB

   ANDLW   11111110B
   BTFSC   BYTE,1
   IORLW   00000001B
   MOVWF   PORTB

   ANDLW   11111110B
   BTFSC   BYTE,2
   IORLW   00000001B
   MOVWF   PORTB

   .... etc ....

   ANDLW   11111110B
   BTFSC   BYTE,7
   IORLW   00000001B
   MOVWF   PORTB

-Andy


=== Andrew Warren --- .....aiwKILLspamspam.....cypress.com
=== IPD Systems Engineering, CYSD
=== Cypress Semiconductor Corporation
===
=== Opinions expressed above do not
=== necessarily represent those of
=== Cypress Semiconductor Corporation

--
http://www.piclist.com hint: To leave the PICList
EraseMEpiclist-unsubscribe-requestspam_OUTspamTakeThisOuTmitvma.mit.edu


2001\05\01@173749 by Olin Lathrop

face picon face
part 1 2021 bytes content-type:text/plain; (decoded 7bit)

> Basically my problem is this: I am trying to bit-bang a serial signal at
> 250Kbps, using a 16f84 running at 4MHZ.

Attached is the code of a software UART routine I used to do 9600 baud on a
16C622A running at 160KHz.  That comes out to 240Kbaud scaled to your clock
rate.

The basic strategy is to unroll the bit loop and use a separate hard wired
bit test instruction to determine which way each data bit is.

The real clever part (at least I like to think so) is making the assembler
automatically insert the right number of NOPs between the bits and advance
thru the bits within the byte.  The timing is automatically derived from the
BAUD constant you set at the top of the module, and the FREQ_OSC constant
assumed to be in the project include file.  The assembler keeps track of the
bit timing in fixed point with FRACB fraction bits (set to 6 in the attached
file).

Note that it is possible to do reliable transmission at this rate, but not
reception.  Since the transmitter sets the start bit, it at least knows
exactly when its leading edge is.  The remaining bit transitions are then
within 1/2 instruction of where they should be.  On reception you still have
the 1/2 instruction error reading the bit, but added to every bit is the
error in determining the leading edge of the start bit.  If you add all that
up, you will see that reliable reception is not guaranteed even given a
perfect transmitter.  It seemed to me I was getting one garbled character
out of about 5 to 10, but I didn't test it rigorously.

Also note that this routine is only meant for software UARTs near the speed
limit implied by the oscillator.  The code space used is inversely
proportional to the bit rate.  In other words, the assumption is that only a
"small" number of NOPs will be inserted between each bit.  There are better
delay methods for slower baud rates.  The macros in this module could be
updated to detect and handle longer delays, but this has not vt/n done.


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

part 3 304 bytes

********************************************************************
Olin Lathrop, embedded systems consultant in Littleton Massachusetts
(978) 742-9014, olinspamspam_OUTembedinc.com, http://www.embedinc.com

--
http://www.piclist.com hint: To leave the PICList
@spam@piclist-unsubscribe-requestKILLspamspammitvma.mit.edu


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