RS485 loading

Yes, this is correct. The same as with standard TTL-load 20 years back.

- Henry

--

"Dan" schrieb im Newsbeitrag news: snipped-for-privacy@73g2000cwn.googlegroups.com...

RS485 is a hardware standard. The bus protocol and software is not very standardized. Very often in a microcontroller system environment the UART works in 9bit-mode. This is 8bit for data and one for decision between data or command. Command means here: Hey, a new connections should be done. Please alert all slaves. Setting this bit can activate an interrupt on several microcontrollers architectures. For example 8051 derivates have this.

Principal, you can make your bitfields as long as you want on RS485 ! If I were yours, I would implement something like the Ethernet frame format. Then you can easely switch to Ethernet someday.

- Henry

--

"Dan" schrieb im Newsbeitrag news: snipped-for-privacy@j44g2000cwa.googlegroups.com...

"devices"

256

I think this is not the right project for you. You need a big step forward.

I don't know if PCs have this 9Bit mode. You can emulate this with correct setting of even/odd parity bit. But this would be on a byte base - so you cannot send more than one byte via the pc driver as a string, I think.

Only in a very noise-less evnironment your speed/cable-length combination will work realiable. So add a data-packet checking system.

The 9th bit thing have nothing to do with the physical data layer!

Have a look

- Henry

--

"Dan" schrieb im Newsbeitrag news: snipped-for-privacy@n67g2000cwd.googlegroups.com...

UART

data

format.

have

isn't

back.

number

as

limitations

Not afraid of the work, have many years experience just not rs485 have RS232 at the hardware level so know how uarts work. Just begining research.

Yeah, the data size noted includes an 8 bit CRC, start byte and terminator character. The slave will respond with the data and its CRC. Both will check for valid CRC, if not valid, slave will not respond. Some time later the master will resend. If data received by master is not valid then it will request the last data again. I have used a similar protocol with Ormon PLC's called Hostlink for RS232. My microcontroller experience is limited to echelon microcontrollers which use the OSI 7 layer model and have nice api's so don't know a lot about the PICS which is why I asked if it is necessary to do the 9th bit interrupt driven method or can it be done through software polling of the uart. With the echelon microcontroller, i was able to just poll the uart itself and read the rx / tx registers directly to see if any data was present. I assume I can do the same thing with the PIC controllers. Youll have to pardon my igonrance on a lot of this but thats why im posting. Thanks Dan

Sorry, I have no PIC experience. There are better controllers on the market and my lifetime is very limited.

In general, you can use the UART in polling mode but this implies very strict timing requirements. Think! The transmitter can very easy overrun the receiver. Most people use it interrupt-driven. You get another interrupt number if the

9th-bit was set or there is a possibility to read a UART status register where the sampled 9th-bit is memorized.

Easy.

- Henry

--

"Dan" schrieb im Newsbeitrag news: snipped-for-privacy@n67g2000cwd.googlegroups.com...

forward.

combination

Been there, done that. You will need to use MARK and SPACE parity to emulate the 9th bit. MARK parity for the adress and SPACE parity for "normal" data.

Jim

Henry, thanks you have been very helpful. James, any chance you have some code you would be willing to post for me. I am going to be developing on windows 2K and XP

I used Power Basic for Windows and the Marshall Soft communications library to write a quick and dirty test program for a guy. The code just sent a command that was the ASCII character 'B' and then waited for a response or a timeout. all of the "%WSC_" are calls to the MarshallSoft API. The other CALLs go to junk like adding a byte to the CRC and so on. It ain't pretty but it allowed him to test his hardware.

Anyway, here is a snippet that polls nodes 1 - 127 with a command of 'B' and an empty 16 bit data field, it is an incomplete listing but you'll get the gist of what I did :

' Set the Node Number node_number = 1

'Do the loop FOR node_number = 1 TO 127 STEP 1 ' Reset the checksum to 0 and add the node number to it crc = 0 CALL CRC16(node_number, crc)

'send the node number ' xPort is the COM port that was prev opened ' Normally "Code" would be checked for errors Code = SioParms(xPort, %WSC_MarkParity, %WSC_OneStopBit, % WSC_WordLength8) Code = SioPutc(xPort, node_number) 'wait for the character to leave the UART CALL Wait4TxDone(xPort)

' Set the command command = ASC("B") ' add it to the CRC CALL CRC16(command, crc)

'Send the rest of the data Code = SioParms(xPort, %WSC_SpaceParity, %WSC_OneStopBit, % WSC_WordLength8) Code = SioPutc(xPort, command)

'Data field is empty Code = SioPutc(xPort, 0) Code = SioPutc(xPort, 0) ' add it to the crc CALL CRC16( 0, crc) CALL CRC16( 0, crc)

'send the checksum index = index + 1 Code = SioPutc(xPort, @index) index = index - 1 Code = SioPutc(xPort, @index) CALL Wait4TxDone(xPort) Code = SleepEx(50,0)

NEXT node_number

I haven't seen the newer PICs but on the usual PICs (as of around Feb

2006) the 9th bit is used to calculate parity. The PIC UART does not have built-in parity checkers so if your protocol is 8 bit data with even or odd parity you need to use the 9 bit mode to get the parity bit and calculate the parity manually in software. If this is not what you're talking about then I don't know what 9th bit you mean. If the 9 bit mode is confusing or troublesome then disable parity. You probably don't need it anyway as you stated that you're using CRC.

On the more recent PICs the UART can be configured to trigger an interrupt if the first byte of a stream of bytes matches the value of a special register (think MODBUS). For this to be effective your protocol need to have an inter-packet delay of at least one byte (again, think MODBUS). They've implemented this so that the PIC can be put to sleep between polls to conserve power.

Don't forget that EIA RS-485 pushes and pulls current to send signals, for high data rates and long cables you need proper line terminations at source and terminus. It also means that your loads need to be near either end of the cable. You can use RS-485 to send stuff down a long cable, but you can't stick an unterminated load in the middle of that cable and expect to get good data at that node. Also don't forget that the spec requires the generator and receiver(s) to have a proper low impedance signal return path through the grounds of the separate equipments. Usually this requires a third conductor. Follow the recommendations in section A.3 of the Standard, in particular the grounding arrangements shown in Figure A.2 of the specification. For longer signal runs at high data rates, use failsafe biasing as shown in the SCSI and SCSI-II specifications.