5234 and 485 Multidrop Mode

[BuddyO]

Other than the brief paragraph (26.4.4) in the Freescale manual, is there any other documentation on using the UART in 485 half-duplex multidrop mode? I have gone through all pages of this forum and have not seen any other posts about it.

I am having trouble getting the UART to read anything besides the address. Here's a sample of what I'm doing:

Code: Select all

	
	//Write Address
	serwriteaddress(fdserial, ReqMsg[0]); //ReqMsg[0] contains address
	
	//Send Break to allow slave to reconfigure
	_delay_us(10);
	USER_ENTER_CRITICAL();
	UART0->ucr = U0_CMD_ENA_TX;
	UART0->ucr = U0_CMD_ENA_BK;
	USER_EXIT_CRITICAL();
	_delay_us(100);
	UART0->ucr = U0_CMD_DIS_BK;
	
	//Write Data
	SerialWrite(&ReqMsg[1],ReqMsg[1]+1); //ReqMsg[1] contains msg length

/* Write operation works perfectly. Remote receive request successfully and 
/* replies with proper data addressed to 5234 (addr 0x0E).
/* now read...

	_delay_us(500);
	cnt = 0;
	cnt = SerialRecieve((char*)&buffer[0], 4);
	// reads 4 bytes:
	// 0xFF, 0x7F - reflected address from write operation
	// 0xFF, 0x0E - proper address of 5234 from reply
	SerialRXEnable(1);
	cnt = SerialRecieve((char*)&buffer[1], 8);
	// reads 1 byte, always 0x00, never actual data

Here's a screen shot of the data transfer: http://www.flickr.com/photos/lightviper/5307361310/

In addition, You can see that the TX data is being reflected back from the external 485 transceiver chip. While the RX is disabled during TX, it is still in multidrop mode so it reads the reflection of the transmitted address and interrupts.

Any help or direction to more complete documentation would be appreciated. BTW, the serial.h(,cpp) library provided by Netburner seems to have only a few functions documented and then only on a very surface level. It took me a day to reverse engineer the cpp code to figure out why I am receiving an 0xFF every time an address is received. Is there any better documentation or examples of how to use these functions in a 485 multidrop application?

[v8dave]

Hi,

What RS485 driver IC are you using? Normally you control TX and RX of these with either the RTS line or a GPIO pin. If you are using something like the MAX485 type devices, then during TX you should not see any RX data because the RX is disables. If you are using 2 drivers then this would explain what you are seeing. Knowing what hardware you are using would help figure out what is happening.

I also see that you are enabling the RX after you have done a receive call? Why not simply set RX after you transmit (making sure the data has already gone out of the port before doing so)

Normally receive issues are down to not enabling RX quick enough before the slave replies.

Your logic analyser images shows that there is indeed RX data coming in.

I have successfully gotten RS485 2 wire comms to work on the eTPU of the 5234 but I have not used the UARTS as they are setup for a modem and a standard RS232 interface. I don't use any of the serial drivers you are using but instead I use a File Descriptor and then the read() and write() file handlers.

What is the format of your serial data? Do you have to use the serwriteaddress() function or can you not simply build the message to send and then send the complete data stream?

Dave...

[BuddyO]

Dave,

Thanks for the response. I am using a National DS75176B tranciever. I'm not too worried about the reflection because it's predicatble and constant so it's not too hard to account for.

The RX enable is part of the Muli-port thing (according to the Freescale manual). When in multiport mode, the RX remains disabled but still reads incoming bytes looking for the address bit. When it sees an address bit it will set the RXReady (and interrupt). All other bytes are ignored. When the Master sees this ADDR bit set, it looks at the byte to see if it matches it's address and if so, enables the RX and reads the rest of the bytes until it either gets all it was expecting or gets another address byte.

ohh... just read your reply again, never mind.. I think you are suggesting to enable RX right after TX because I am expecting a reply anyway... good point, I'll try that. I set some pretty long delays (up to a couple of bytes) to alow enough set up time but that didn't seem to help.

The serial drivers I am using are the ones provided with the Netburner dev kit - interrupt based, circular buffers, etc ... but completely undocumented.

I have to use the address bit because this is a chassis controller that can have up to 17 devices on the same bus, the multiport mode make synchronization a whole lot easier. Without the address bit, if the data payload happens to contain a byte that matches one of the other cardslot addresses everything gets mucked up. The address bit differentiates an address from data. I probably don't need it on this master (Netburner) as it always expects a response... (BTW - works perfectly on the Atmega48 slaves) If I had been consulted on the hardware I would have made it an SPI bus with separate CS...

[v8dave]

Thanks for the response. I am using a National DS75176B tranciever. I'm not too worried about the reflection because it's predicatble and constant so it's not too hard to account for.

I know them well. I used them on a design last year. Drop in replacment for the MAX485 devices. If you connect the RE and DE lines together you can enabled the disable the TX and RX so that there is no reception during transmit. This is how I have it wired. Sounds like you have the RE input connected to GND which means it is always active which as you said is not an issue for your code and a good way to check teh TX was OK.

The serial drivers I am using are the ones provided with the Netburner dev kit - interrupt based, circular buffers, etc ... but completely undocumented.

This seems to be the case with a lot of the Netburner kit although support is pretty helpful along with this forum. A lot of better examples would help though. I was used to the Rabbit processors before Netburner and they had a lot of supplied samples and fairly decent documentation.

If I had been consulted on the hardware I would have made it an SPI bus with separate CS...

Personally, I would have chosen CAN bus if you had the chance to spec the hardware escpecially if the link is shortish cable runs. Since switching to CAN for anything I do that is multi-drop I have found that the mult-master capability comes into its own when you have control commands as any device on the bus can transmit when it has data. It also has some pretty neat filters that can be setup within the controllers so they only interrupt the CPU when they see the commands it wants. It is pretty bullet proof too.

For RS485 I have stuck with trying to use Modbus, especially if I have control of all the communications on the network. As a SCADA engineer friend of mine keeps pointing out, "it just works".

The only thing you need to detect is when the transmit register is empty. I have not read the Freescale manuals but the processors I have worked with have a transmit buffer register and shift register. The transmit buffer register goes empty as the shift register is shifting out. It is this shift register you need to make sure is empty before setting back to RX mode.

Basically, if your software keeps the TX active, anything trying to drive on the bus will fail and you will get arbitration. Hopefully with the TX disabled after transmit, you will get the right data on the bus.

Good luck with your project and I hope you sort out the timing issues as that is what it sounds like.

Dave...