using Quad UART

[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.

[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.

[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..........