using Quad UART

[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/cont...rial-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.