using Quad UART

[harryweb]

Hi,

I plan to use "quad uart IC" because my app need to control many other pic doing their jobs
I have some question about them:

-When data sheet told 16 bytes FIFO, is it a kind of 16 bytes buffer ?
(because my pic cannot read all data at same time)

-Is it not too hard to control a quad UART ?

-What IC is the most common used ? (SPI or I2C interface, not //)

I would like to know if someone is using this kind of IC... Example will be very useful to start play with.

Regards

[Charles Linquis]

Most of the time, I find that using a PIC as an intelligent peripheral is easier than using a dedicated chip. Why not use a chip like an 8723 (with two USARTS) as a peripheral? It can then do things exactly as you wish. That device could could easily have a 1K buffer.

More importantly, why do you think you need all those USARTs to network your PICs? I have networked over 40 PICs together using one 18F8723 as a master talking to 18F2321's as slaves - and no extra chips are involved. The master's TXD line is connected to the (hardware) RXD line of all the slaves.
The slaves then send data back using a bit-banged (SEROUT2 port), because the hardware TX port can't drive open-collector. All the output ports of the slaves are tied together, and that goes to the master's hardware serial RX port. The master polls the slaves by sending out an 8 bit address followed by a command and a checksum. The slaves use an interrupt to grab the bytes. If there is an address match, the slaves wait 600uSec and then send the requested data back in inverted (idle high) open-collector mode. Using this mode prevents bus contention. A 22K pull up is used on every slave.


The whole scheme is still working flawlessly, and polls all the slaves in less than half a second. Although I have checksums and retries buit into the system, the only time it ever retries is when I hot-plug a slave. I also reserved address 253 for a "general call" that all slaves receive, but don't respond to. It is used to produce an output on the pins of all devices simultaneously. Address 254 is used to re-address the slaves. The 2321 board is so small there is no room for DIP switches or jumpers for addressing. By hooking up one device (only) to the master, and then sending to address 254, followed by a new address, followed by a checksum, you can change or set the device's address. It is stored in EEPROM and read on every power up.

The only downside to using RS-232 between devices is that their oscillators have to be pretty stable if you want fast communication. Crystals on both sides are a must for speeds greater than 19.2Kbaud.

[Archangel]

Reply to Charles:
Hi Charles,
Have you considered making an article out of the project you described? I think it would be "Required Reading" for all members especially the noobies. I am pretty sure it could be set as not comment-able so it would stand alone. I know I would sure read it.

[Charles Linquis]

I suppose I could. The easiest thing for me would be not to write to much verbage, but to post the code. And I don't think it would be appropriate/wise for me to include pictures, since most of what I have done recently has been for my current employer.

Nonetheless, I'll try to put together something useful (yet non-conflicting) in the next week or two.

[timmers]

We use a 2 line comms system.
One line is a transmit request (TR) and the second is a common data line.

All chips poll the TR for a high state. Chip that requested transmit then waits 5 mSec (pause 5) for all the other chips to listen in, then the message is passed. At the end of the transmit sequence, chip changes its serout2 port pin to an input, freeing up the bus for the next chip.

Both port pins (TR & D_LOOP) are set as inputs.
Fit pull down resistor to TR to hold line normally low and pull up for D_LOOP.
Protocoll between chips can be anything you like, but in general you will want a header, ident (who sent it and who it is destined for), command index, data values & a checksum.

I have used the hardware serial port for multi-chip transmision, simply drive a PNP transistor from the hardware serial out. Transistor then drives the data line in a open collector (emitter!) mode. Use a lowish (1k) pull up resistor on the data line.

I have attached a couple of examples if it helps.

[gadelhas]

Reply to Charles:
Hi Charles,
Have you considered making an article out of the project you described? I think it would be "Required Reading" for all members especially the noobies. I am pretty sure it could be set as not comment-able so it would stand alone. I know I would sure read it.

x2.......... ;)

[harryweb]

Thank you for your reply.

Why does I want to use external uart with buffer ?

Please see PDF attached file.

Actually my PCB has 5 PICS.
The PIC 1 to 4 are connected to network (via tibbo modules with usart 1 and to the "master" PIC via USART2
These 4 PICS are driving RF attenuators

4 distant Network sends order to each PIC (1 to 4)
These PIC also received order from Sensitive keyboard or a local (RS232) terminal connected on the master PIC

As you can see, I need 1 USART. I MUST use SERIN2/SEROUT2 (witch are not good as hardware usart)

This is my problem

Communication are 9600 and 38400 Bds

So my idea is to use an external USART to bypass the use of SERINOUT2

regards

[Dave]

harryweb , That is why Charles suggested using a 18F8723. It has 2 USART's and therefore has no need to use SEROUT/SERIN commands which were written to use any port pin and are therefore not buffered. The internal USARTS have 1 character buffers. If you wanted too, you could also use the SEROUT/SERIN commands with an 18F8723 for a total of 3 comm ports....

Dave Purola,
N8NTA

[Archangel]

Thank you for your reply.


As you can see, I need 1 USART. I MUST use SERIN2/SEROUT2 (witch are not good as hardware usart)

This is my problem



So my idea is to use an external USART to bypass the use of SERINOUT2

regards
OK, so I am thinking USART is a hardware thing which works in the background while Mr. PIC does other things in software. SERIN2 SEROUT2 is a bit banged software serial port which can execute 1 instruction at a time, receive data on only 1 pin at a time . . . so why not slave them all on only 1 line and let them speak only with permission from the host. As I see it the host can only communicate with 1 at a time anyway unless using USARTs.
Here is a sample of an lcd unit featuring a ring buffer so you do not lose data. Add to it a CTS clear to send and an RTS ready to send and you can do as Charles suggested, as for controlling 2 USARTS, I have no experience.
http://www.picbasic.co.uk/forum/content.php?r=171-LCD-serial-backpacks

[Charles Linquis]

I'm presently writing a little tutorial on PIC serial port networks, but until I get that done, consider a few things:

The best architecture will depend a lot on how many bytes you need to transfer, and how much latency you can tolerate.

If you use one or more 8723's as I suggested, you have a lot of options.

Each one (of the "slave" devices) can receive data from both ports on interrupts and store them in big buffers.

From there, you can -

1. Use the PSP port (PORTE) and transfer the bytes in byte-wide chunks between devices. You can use interrupts if you like.
2. Use a serial protocol like SPI. That is fast, and addressable. - and can use interrupts. 8723s have two SPI ports.
3. Use good old SERIN2/SEROUT2. Not particularly fast, and no interrupts, but because of the large buffers in the slaves, the master can ask for the data whenever it is ready.
4. Use SERIN2/SEROUT2 + interrupts. You can connect one or two extra lines from the slaves to PORTB of the master. When a slave wants to send data to the master, it pulls the interrupt line low. The INT lines are edge-triggered, so the slave only needs to pull the line low for a couple clocks and then lets it go high again (should be driven open-collector with a pull up). The ISR in the master pulls the interrupt line low from that end. When the slave sees the low, it transmits data to the waiting master.
5. Use the I2C slave routine I posted a few weeks ago. It is interrupt-driven and can transfer a byte in about 150uSec using (bit-banged) I2CWRITE on the sending end. 8723s have two I2C ports. The good thing about I2C is that it uses hardware addressing - it doesn't interrupt the processor unless there is an address match.
6. Roll your own.