I'm in the middle of a design with a PIC16LC63 which touches several
functions of the PIC that I'm not too familiar with. Please forgive me for
multiple posts related to the same project, but each of these threads may
be of use to others who, like me, find searching the Piclist archives
tedious due to the interelated issues in the questions/answers.
The application is basically a serial port "fixer" which sits between two 9
signal serial ports and can pass, block, modify and otherwise fool around
with the signals to help two devices communicate. There are some other
details to the design which are irrelevant to this discussion, and this is
a proprietary-- not a general purpose device.
Question 3: On Interrupt driven serial port tradeoffs
Background:
In this application I need two basically full serial ports, but I don't
intend to pass all the data through the PIC. Rather I intend to look at
the data passing through RX to TX on both sides, and if something happens
that I don't like or something needs to be added in the stream, I'll break
the path of a tri-state buffer between the two ends and the PIC will take
over. I also have all the flow-control lines at my disposal, so I probably
can get away with half-duplex operation for at least one side of the fence.
I'd like to be able to handle as high a baud rate as I can in the future,
possibly at full-duplex, but the present application will require only 9600
baud half-duplex. Obviously I intend to use the on-board UART for one side
of the path, and since I'm limited to 4 MHz operation with the LC part, I'm
leaning toward a 3.6864 crystal inorder to get a full selection of accurate
baud rates from the on-board UART.
Question:
I'm presenting considering the INT line on RB0 an interrupt driven bit-bang
RX and what ever port is left over for TX, but is there any advantage in
using the CPP capture/compare pins for bit banging serial ports?
Or maybe the B port interrupt on change pins or some other configuration?
My main motive for currently using the INT line for receive is that I have
canned code from "Serial PIC'n" to implement this, but I suppose I could
modify this to use a capture pin instead for now and later implement a
fully timer-capture driven UART.
I guess what I'm asking is: would this be worth the bother?
I might be able to use the capture pins for another function, but I don't
want to lock myself out of a better serial port implementation in the
future if I could get a faster serial port than on the INT pin.
My application doesn't have all that much else to do aside from this, but
it will need some cycles to poll and check things from time to time.
> Why not go to a 17C part with multiple uarts?
>
> Or an 8051?
>
> Andy
I'm under very tight space restrictions. I need about 22 or so I/O pins to
do what I need to do, and I am using the SSOP-28 package. The crystal is
almost bigger than the chip in this case.
An 8051 might be a possibility, but I'm not sure if I can get enough usable
pins with an I2C function in the same package. I'm past half-way in the
design and don't really want to jump chips in mid-stream.
I'll take a look at the Phillips product offerings though, and see if
anything they have fits the bill. There are so many 8051 variants
nowadays, it's hard to tell which ones are "real" part you can get.
Whereas I can usually trust the Microchip people in this regard.
If you didn't have the board already done, the TQFP 17C's are pretty tiny.
You might want to use RB.0 to detect a start bit, disable interrupts, and
bit-bop the character in, enabling interrupts immediately after receiving the
last big (not the stop bit).
Subject: Re: [PIC]: Tradeoffs on interrupt driven bit-banged
serial ports
> Why not go to a 17C part with multiple uarts?
>
> Or an 8051?
>
> Andy
I'm under very tight space restrictions. I need about 22 or so I/O pins to
do what I need to do, and I am using the SSOP-28 package. The crystal is
almost bigger than the chip in this case.
An 8051 might be a possibility, but I'm not sure if I can get enough usable
pins with an I2C function in the same package. I'm past half-way in the
design and don't really want to jump chips in mid-stream.
I'll take a look at the Phillips product offerings though, and see if
anything they have fits the bill. There are so many 8051 variants
nowadays, it's hard to tell which ones are "real" part you can get.
Whereas I can usually trust the Microchip people in this regard.
hotmail.com