PIC single wire comms bus on UART?

I'm speaking out of my ear here, since you know far more about this than I do... but just in case a fresh perspective is useful:

It seems to me that you get this self-ignoring automatically with a bus protocol like Bioloid uses. The RX line is going to be seeing stuff transmitted by all the other modules anyway; it knows to ignore those packets because they don't start with the magic "hey-I'm-speaking-to-you" code. The stuff this module transmits back to the master would fall in the same category, I'd think, and so not cause any confusion.

But then, maybe your question is at a lower level, asking about the behavior of the internal hardware of the UART on the 16F876. Hopefully someone else can lend a hand at that level, because I sure can't.

But, if encouragement is of any value, please keep up the great work! I think third-party sensors (and other modules) for the Bioloid system are vital to helping it really catch on, and basing these on inexpensive PIC chips seems like a great idea. I'm not a Bioloid user yet, but I hope to be one someday -- so I'm eagerly waiting to hear more about your project.

Best,

- Joe

Yeah, that's the level I'm talking about. Sorry I wasn't more clear. I know how to parse the data to determine if this packet is meant for me or not, but I don't know if there are hardware issues with hooking those two pins together.

Thanks for the reply and encouragement...

Later, Jon

-------------------------------------------------------------- Jon Hylands snipped-for-privacy@huv.com

The A revisions of the 16F87x series chips should be able to run that fast. For example, the PIC16F876A will do fine, but the the PIC16F876 may have some issues. This is discussed in the erratta sheet for the chips, which I read many years ago.

The answer to your question is "maybe yes" or "maybe no". If you want to take a single 87x chip and tie the RX and TX pins together, there will be no electrical problems. Of course, all you will be able to do is send data from the chip to itself. which is not very interesting. It is more likely that you want to take a bunch of 87x class chips and maybe some AVR's as well and tie all of the TX and RX pins together. Since the RX pins are inputs, there is no problem there, but the TX pins are outputs and tieing a bunch of outputs together is a definite no-no. It would be nice if the PIC allowed the TX be be either open collector or driven, but that is not the case.

If you want to tie a bunch of them together you need some sort of buffer circuitry to make the TX pin be a wired-OR. For my projects, I use the Microchip MCP2551 CAN bus transceiver. The MPC2551 provides and extremely high level of noise immunity for my robotics projects. You can use something simpler if you want though. If you have a fixed number of devices, a simple multi-input AND gate does the trick.

I run my projects at 500kbps rather than 1mbps since not all PIC UART's are spec'ed to run that fast. For example, the PIC16F688 does not allow SPBRGH:SPBRG

So, what you are saying is that it is electrically impossible to hook up two PICs like this? Or are you saying that you might end up with two devices on the bus trying to talk at the same time, which clearly causes problems?

If it is the first, then I'm out of luck without a switcher chip, which I am trying to avoid. If it is the second, then it doesn't matter, because the bus protocol guarantees that collisions will never happen.

Later, Jon

-------------------------------------------------------------- Jon Hylands snipped-for-privacy@huv.com

It is an electrical problem. If you have two PIC chips with TX1, RX1, TX2, and RX2, you can not tie all four pins together since both TX1 and TX2 are outputs. Even thought the protocol will ensure that TX1 and TX2 do not transmit at the same time, you will have a stituation where TX1 is driving the bus high and TX2 is driving it low or vice versa. Some form of electrical buffering is required.

While I am not a familiar with the AVR chip, I strongly suspect that it has the the same restriction.

I did a Google search on "bioloid" and it looks like you are trying to be electrically compatible with the AX-12. I downloaded the PDF file for the AX12 and on page 7 of the manual is specifies how to interface to their bus using a 74HC126. A PIC can clearly use the same circuit.

That's the good news. The bad news is you need to have another pin on the PIC dedicated to controlling the UART direction. When you transmit a byte, set the bus to transmit mode, send the byte, loop on the buffer empty bit, and the set the bus to receive mode. The PIC provides no help for managing the bus direction pin. By the way, this is why I use CAN bus transceivers instead of RS485 transceivers -- no bus direction pin is needed.

-Wayne

The AVR Tx pin can be disabled, so it floats. This allows you to do what I'm suggesting without the need for the extra hardware.

I was just wondering if the PIC could do the same thing.

Sounds like not, so no big deal - I'll just have to either stick with an AVR, or get the switcher chip...

Thanks for your insight, Jon

-------------------------------------------------------------- Jon Hylands snipped-for-privacy@huv.com

Hi guys,

Since I wrote the code that Jon's using, I'll explain what I'm doing.

Basically, the AVR supports enabling/disabling the Tx/Rx functionality independently of each other. When the Tx/Rx are disabled, then they fall back to GPIO behaviour, so as long as the GPIO pins are also configured to be inputs then that should be fine.

My original intention was to connect Tx and Rx together and have the Tx disabled when not transmitting. When I was transmitting, I was going to enable the Tx and disable the Rx (with the GPIO pullup enabled). However, I was getting noise on the Rx line, so instead I opted to just leave the Rx enabled all of the time.

For each character sent, I would ignore the next received character. When the transmission was finished, the Tx would be disabled, so it reverts back to a GPIO pin and would behave as an input.

Looking at the datasheet, it appears that the PIC uses a single bit to enable the Tx/Rx functionality.

Alas, as you have noticed, the PIC uses a single bit.

Your best bet is to add a single buffer from 74xx07 to the TX pin. Then you just transmit the byte, and ignore the echo. That is what I do using the CAN bus transceivers instead of the 74xx07.

Enjoy,

-Wayne

I'm wondering if it's possible to avoid adding extra hardware such as 74xx07's without causing contention problems between the TX pins. If only the transmit shift register could go to the output ENABLE bit [AHA GPIO data direction bit] instead of the output DATA, it could act like an open-collector output (or with the GPIO output data bit set to high, it would act like a PNP-open-collector output), and you could just add a resistor pull-up (or pull-down, as the case may be). I'd also add a small resistor (220 ohms, or maybe 110 in series with each output and have the RX pins tied in the middle) to current-limit the outputs in case of code foulup, but if the connection is over a long cable (more than a foot or two) the resistance and cable capacitance could cause a problem with the signal getting through. But that will happen with any open-collector scheme (is open-collector the standard operation of this bus?) How far away, physically, are the processors from each other? How fast will the processors be running? Would it be possible to write some straight-line code to bit-bang a data direction bit at

If we're running at 20 MHz, we'd have 5 instructions per bit to play with. I suppose its possibly I could bit-bang the transmit portion in assembler, but honestly, I'd rather just buy a bus switch and use that with the hardware UART.

I think I am going to stick with AVRs for this problem. The ATMega168 is available in a 28-pin DIP, so I'll just pick up a couple of those, and start experimenting...

Thanks, Jon

-------------------------------------------------------------- Jon Hylands snipped-for-privacy@huv.com

Jon:

Until you posted the message above, I had not realized that Atmel had finally released an ATMegaXXX in 28-pin package. Thank you for mentioning that. I've been sticking with Microchip PIC's since they keep releasing products in DIP packages, whereas I thought Atmel had abandoned DIP packages.

Again thanks,

-Wayne

Hi Wayne,

Here's a few things that may help you out.

The ATMega8, 48, 88, and 168 are all available in pin compatible 28-pin DIP packages.

The ATMega-16, 32, 644 are all available in pin compatible 40-pin DIP packages.

The 48/88/168 and 644 are all what I call "new generation" parts that include things like pin change interrupts on pretty much every pin and can also run upto 20-Mhz (the 8/16/32 are limited to 16 MHz).

Dave:

Thank you for the information. I've been reading the Atmel AVR parametric table and finding out all sorts of things. Did you know that the ATmega64RZA comes in a 42-pin PDIP package?

Anyhow, I have gone through the exercise of mentally redesigning one of my PIC boards that uses a 28-pin DIP package to use the 28-pin AtMega8/48/88/168 and it looks quite trivial. What I discovered is that I can make a board that can accept both a 28-pin AVR and a 28-pin PIC. The power and ground lines do not line up exactly, but they do not conflict either. For the next rev. of my Controller28 board I will almost certainly make it both AVR and PIC compatible. It should be neat. Now all I have to do is bone up on programming AVR's; that should keep distracted for a while.

Later,

-Wayne