EUSART synchronous operation

[rdburghard]

I am trying to communicate between two PIC18F46K22 controllers (@ 16MHZ internal frequency), using their EUSART's connected directly together. I am trying to understand the synchronous operation in a master/slave configuration (half duplex). I found the EX_Sync_Master.C and EX_Sync_Slave.C examples and have them working on my device. That is fine for one-way transmission/receive. However, I would like the Slave to be able to send data to the Master on request from the Master instead of simply turning on or off something on the slave.

I modified the example code so that it is working on an interrupt on the slave unit so it can do other things while waiting on the Master request or data. That is working with the example code. I can send a different character every second and the slave detects the characters using the interrupt routine and calls a routine to turn some LED's on and off. How do I stop the Master from being in transmit mode and switch to receive mode? I am not looking to do this ultra fast. A one second delay between TX and RX is fine and I have a 1/2 second and 1 second loop in my main program anyway so I feel I have plenty of time for it to switch modes if I can figure out how to do it.

I see in reading the PIC information that there are both Synchronous Master Reception and Synchronous Slave Transmit methods. It has been years since I've dealt with assembly code directly and was wondering how to do set this two-way communication up using C. I don't see any examples of that anywhere.

My only other thought would be to re-wire the UARTS so that their TX and RX lines are crossed and use them in full duplex mode. The Synchronous mode uses the TX lines as a clock and the RX lines as data in/out. I would love to figure out the synchronous operation, if I could get a little help getting me to understand the process in C, if possible? I would not mind using inline code to switch modes if necessary.

[temtronic]

I ran into the same 'brain teaser' some years ago and decided that ASYNC was a LOT easier to get 'up and running' as it made testing to a PC dead simple and well, everyone knows how it works.
Unless you've got a lot of free time to read/code/test/scratch head again and again OR someone else here has done it...I'd stick to what works and get the rest of the project finished.Maybe during the long dark winter nights when ther'e nothing else to do you can revisit the problem ?

jay

[Ttelmah]

Other thing, use SPI.

This is full duplex synch, and faster than the USART can manage. The only reason to use the USART, is if you are talking to something else that requires this format, or have run out of SPI peripherals.

The USART does not support full duplex sync. Half duplex only. So for full duplex, SPI, or async is the way to go. For half duplex with 'turn around', you have to also handle the tendency for the drivers to clash at the moment you turn round. You can do it by setting up two #use RS232 statements, one for the receive mode, and one for transmit, both with baud set to '0'. Then setup_uart on the stream you want to use, with the baud rate required, reconfigures the UART for that direction. setup_uart with a baud rate of 0, turns the UART off. You must ensure you disable the UART's at both ends, or turn off the transceivers, before you enable the transmitting 'end'.

Honestly async duplex is going to be a lot easier.

[rdburghard]

Yes, I agree, I'm thinking the normal Asynch mode would be easier. That is what I get from reading the PIC manual. It suggested using the Synch mode for things like communications between PICS. I'm going to swap the TX/RX lines around and go the normal route and see what happens. Something I noticed in using the test code that I did not particularly like is that I have TX and RX LED's on one of my boards. Well, since the Synch mode uses the TX for the clock, it basically keeps the TX LED on constantly. Looks kind of strange.