Using Multi-Processor Mode with RS-485 and PC's

Go To Last Post
53 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've seen alot of threads on using RS-485 with PC's which indicated the use of signal converters or even add-in cards to allow the PC to do RS-485. But none of these add-in cards seem to support the 9-bit Multi-Processor mode that would be needed for a multidrop environment. Same goes for the 16550 style UART in the PC, doesn't appear to support this mode either.
So if I want to develop a multi-drop setup with 8-10 AVR based modules all on the same RS-485 line, with a PC as a master, how do I get the PC to do multi-processor communications?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Getting a PC to work with 9 bit comms is a nightmare.

(We have to deal with 9 bit communications for a comms protocol used within vending machines.)

If you are programming under DOS, you can transmit a byte (8 bits + parity) at a time and change the parity appropriately for each byte!

AFAIK it is a non-starter under (say) XP. Sorry. :cry:

Cheers,
Andy

If we are not supposed to eat animals, why are they made out of meat?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Very interesting, AndyG. We do a lot of RS485 to PCs, and I've got a couple apps with 9-bit that are AVR-to-AVR. I would not have known that marrying the two would be a nightmare without your heads-up.

We had been using RS232-to-RS485 converters on the PC side. What with new computers (especially laptops) arriving without conventional serial ports, and the cost (~US$80) of the converter, we made our own USB-to-RS485 with an FTDI chip and RS485 transceiver.

Maybe do the same thing for the 9-bit on the PC side: Have the master app "indicate" which character(s) need the 9-bit on a transmit, USB-to-FTDI FT245BM-to-AVR, then AVR-to-RS485. Tiny2313 or Mega48, perhaps?

Lee

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi!
A year ago I used "US Digital" encoders, which are on SEI bus (2xRS485), and they have a good adapter to PC, which automaticaly detects transmiting from the PC, and switches the RS485 driver ON. The time to be ON is controled by RC circuit which is choosed dependent from the baudrate. May be you can visit their site and download the schematic of the adapter!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

... here is the link:
http://www.usdigital.com/data-sh...
It's for COM, but there are also adapters and for LPT!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

That's just a level translator, it won't help me generate 9-bit multiprocessor modes, unless I missed something.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This subject is dear to my heart! :) It would be nice to have an easy (?)solution. Especially if there is a Delphi driver, since I have started to play with Delphi. I have been thinking about the parity bit solution and it should not be too hard, at least it would be easy enough in AVR asm for me, but the 16550 etc.. inside the PC worries me a little. So basically for each byte being send the parity bit is caculated and then flip the chip's parity mode to odd or even in such a way that when the PC Uart works out the real parity value of the byte being sent the parity bit is always set for an address byte and always clear for a data byte. Instead of having just a send routine there would be 2 routines, SENDADRESS and SENDDATA.
Any comment hint etc (especially code bits :D ) would be welcomed!

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I couldn't cope with the PC UART so I solved my problem with a rather radical solution. I made the communication 8 bit, with eight bit indicating addressing byte. When transmitting raw data I strip eight bits and store them into additional byte. This adds a little overhead but saves a lot of headaches on the PC side.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You don't need any special hardware. Most of the RS485 cards and converters will all handle 9 bit. You must do a slight of hand trick with your software. If you program in Visual Basic, think about using 'MARK' and 'SPACE' in MSCOMM. If I remember correctly the mark is a 1 and space is 0. When you're sending an address you must set it to mark, otherwise you set it to space for data. Your serial stream will always be 9 bit. I know my explaination is a little fuzzy, but if you plan to use VB, there is plenty of info out there. A good source is Serial Port Complete by Jan Axelson.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
I made the communication 8 bit, with eight bit indicating addressing byte. When transmitting raw data I strip eight bits and store them into additional byte. This adds a little overhead but saves a lot of headaches on the PC side.

If I understand correctly the following part of the Mega 8 data book the new USART will support 8 bit MPCM so all that is required is to send out each byte as 2 ASCII values. For an Address set the MSB of the first half to 1 and for data set it to 0. The data rate will of course be halved and the maximum addresses will be 128.

From the Mega8 USART data:

If the receiver is set up to receive frames that contain 5 to 8 data bits, then the first stop bit indicates if the frame contains data or address information. If the receiver is set up for frames with 9 data bits, then the 9th bit (RXB8) is used for identifying address and data frames. When the frame type bit (the first stop or the 9th bit) is one, the frame contains
an address. When the frame type bit is zero the frame is a data frame.

[ quote]
Most of the RS485 cards and converters will all handle 9 bit. [ /quote]

The "standard" UART found in the PC will be a descendant of the 8250(? ie 16550) These have built in hardaware parity calculators (unlike many controller's UARTs), so the chip will have to be fooled into calculating the correct parity bit for the task at hand for each byte being sent. Please tell me I'm wrong and that there is an easier way :D :D

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually the frame would be 11 bits, with start,stop and parity. :) But I see what you're saying now, is rather then have the UART generate a parity bit, use the sticky parity bit (R3.5) and the even parity bit (R3.4) to create MARK or SPACE as needed to define an address byte or data byte. The current application is actually a DOS program (BP7) so direct control of the UART shouldn't be a problem. We hope to migrate the app to a windows program in the future and that would probably be VB6.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
The "standard" UART found in the PC will be a descendant of the 8250(? ie 16550) These have built in hardaware parity calculators (unlike many controller's UARTs), so the chip will have to be fooled into calculating the correct parity bit for the task at hand for each byte being sent. Please tell me I'm wrong and that there is an easier way :D :D

Look at the Sticky Bit description, it disables the generation of parity.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,

Why do you think you have to use 9 bits to achieve a multi-drop Rs485 master/slave system? :?

Dave.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Why do you think you have to use 9 bits to achieve a multi-drop Rs485 master/slave system?
You don't have to, but the 9 bit mode has been designed to use the, otherwise mostly unused, parity bit to wake up the receivers in the micros and leaves the other full 8 bits for real data. So the slaves can go merrily with their business and ignore the traffic on the communication buss untill an address frame is detected by the hardware. Then all that is required by the slave(s) is to check the incoming 8 bit address to see if the rest of the packet is addressed to it. If it is then it will enable the UART to receive the incoming data otherwise it goes back to what it was doing...even sleeping! :D It make life sooo much easier.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi John,
Thanks for that! :lol:
Dave.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

To add to what John said, the newer micros can even be programmed with what their address should be, and then they only get the interrupt when it's an address byte and a matching address.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It took a few days to get some free time, but I was able to program the PC's UART to use a 9-bit multiprocessor mode. Using a combination of the odd/even bit (bit 4) and the sticky bit (bit 5) in the line control register (R3) of the 16550, I can send address bytes or data bytes that conform to the 9-bit mode.

One last head-banger I ran into was to make sure the PC's UART has transmitted the full frame before you alter the line control register, otherwise the current frame being sent will get altered. 8)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well.....when are we going to see the code :D What language did you use etc...

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

And operating system?

And can you correctly receive the 9th bit too?

/A

If we are not supposed to eat animals, why are they made out of meat?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I can post it Monday when I'm back at work. I tested using BP7 under w95.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dksmall wrote:
It took a few days to get some free time, but I was able to program the PC's UART to use a 9-bit multiprocessor mode. Using a combination of the odd/even bit (bit 4) and the sticky bit (bit 5) in the line control register (R3) of the 16550, I can send address bytes or data bytes that conform to the 9-bit mode.

One last head-banger I ran into was to make sure the PC's UART has transmitted the full frame before you alter the line control register, otherwise the current frame being sent will get altered. 8)

Nice solution in playing with the parity mode, in order to generate a controlable 9th data bit. That was definatley thinking outside the box.

AndyG wrote:

And can you correctly receive the 9th bit too?

/A

There should be no problem receiving the 9th bit, as it will be interpreted as the parity bit by the PC's UART. Simply looking for parity error, and calculating the parity on the received byte, will tell you what the parity bit was. This takes some additional overhead, but is a nice work-around for a hardware limitation.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The test code I used was written in BP7 and talks to the UART directly. The basic concept is to setup the UART normally, then enable the sticky bit and set or reset the Even parity bit to get generate Mark or Space, which equate to Data or Address frames using the 9-bit protocol. Two procedures are used to set the UART.

procedure SetData;      { reset the 9th bit }
  begin
  While Port[CommPort+5] and $40 <> $40 Do;      { make sure UART TSR is empty }
  Port[CommPort+3] := Port[CommPort+3] Or $38;   { set sticky, even, and parity enable }
  end;

procedure SetAddress;   { set the 9th bit }
  begin
  While Port[CommPort+5] and $40 <> $40 Do;      { make sure UART TSR is empty }
  Port[CommPort+3] := Port[CommPort+3] Or $28;   { set sticky and parity enable }
  Port[CommPort+3] := Port[CommPort+3] And $EF;  { reset even }
  end;

Then a test routine that sends a message would look like:

SetAddress;
SendByte($AA);
SetData;
SendByte($35);
SendByte($36);
SendByte($37);
SendByte($38);

As for receiving the data on the PC, the PC is the master so it only has to listen when it expects a response. So far all I do is receive all bytes without checking to see if the 9-bit was set when it should be, but it could be checked by setting the parity bit before reception and comparing it to the parity error bit once a frame is received.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If It is possible, use receive interrupt on the PC side, because if your application is runing under Windows you may miss a byte(s), because Windows has a lot of interrupts (for the keyboard, mouse, VGA and so on.........) which can take more time than the duration of 1 byte at your speed. I have a similar problem with my PC applications, because I use only polling, and under Win'98 i miss bytes, but under XP It's OK, so XP is very very stable and clever OpSys, taking care for my bugus software.
But you know that, I beleive, just for reminding!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

:oops: Notwithstanding my previous raving :oops:

I have been playing with the above using Delphi 6 (with ComPort264 instead of QCcom32) and seem to manage to receive packets into one of my boards with the 8535 and the ICE200. By simply setting the parity bits to Mark an adress byte is sent and by setting the parity bits to Space a data byte is sent. The following is just a quick test to interface to our RS485 comms protocol. CRC is not implemented yet but I can receive most of the data bytes, may be I'll change the data send part to a routine that reads the chars from a buffer and sends them out 1 at the time with some small delay to allow the AVR to keep pace.

ComPort.parity.bits:=prMark; //Bit 8=1 (address)
ComPort.Open;
ComPort.WriteStr(#26); //Write address
ComPort.Close;

ComPort.parity.bits:=prSpace; //Bit 8=0 (data)
ComPort.Open;
ComPort.WriteStr(#127); //Origin Address
ComPort.WriteStr(#12); //Number of bytes
message_out:=('Hello There!');
ComPort.WriteStr(message_out);

It's exciting! :D :D

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

John,
What OS are you dong you're testing with? I had everythign working fine under W95 and then moved to a new W2K platform and now things went down the toilet. It appears to me that the serial driver for W2K doesn't handle the UART's sticky bit properly. Anyone else run into something like this? Anyone know if XP will do better??

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I use Win98SE and it works well.

Quote:
The test code I used was written in BP7 and talks to the UART directly.
Win 2000 may not allow you to talk directly to the chip. I will try my program with an XP machine as soon as I get some time an see what happens.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi guys,

If you want to setup 9 bit communication in windows (95, 98, 2000 or XP) and the programming language is Delphi (delphi 5, 6 or 7) you can download port component from sourceforge (Turbo Power Async Pro) the following is the link:

http://sourceforge.net/projects/...

This component was from turbo power and just release to public domain for free about 2.5 years ago (before cost you $2500. Yes Two thousand and Five hundered US Dollar - I used this component since four years ago and we bought it !!!)

Just recently I am using this component for addressing 9 bit network drop. The attachment show how to use this component.

I don't have any problem PC addressing 9 bit RS485 protocol but I have some question regarding 485 terminator. My question is why when I put termination resistor in front of the 485 chip (across pin A and B) 120 ohm, I got like resonance and the data is back to sender, but when I take out the terminator, it works.

The chip I am using is ST485 and the distance between chip and terminator just only a few millimeter (very close)

If you have any question regarding PC Communication 9 bit, you can ask me. And I will try to help you with all my best.

Thanks and regards,

Rudy

Attachment(s): 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
My question is why when I put termination resistor in front of the 485 chip (across pin A and B) 120 ohm, I got like resonance and the data is back to sender, but when I take out the terminator, it works.

The 60 ohm termination (120 ohm at start of line and 120 ohm at end of line) is to match the impedance of the twisted pair communication line, which could be up to 4000ft or 1.2 Km long, so if your line is very short you will get reflections due to impedance mismatch. I have long forgotten (and happy to do so :D ) the maths for communications line matching, but it can all be worked out mathematically. I have downloaded the above driver but it seems an overkill for what I'm doing, I will play with it in due time I guess. Thanks for the info.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Rudy,
Have you actually used the Delphi code on a W2K machine? I've done BP and VB versions on W95, W98, and W2K. Only hicups on the W2K machine.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I played with Delphi several years ago to do some serial communications. I used the standard Windows API. Below is a snippet of that code:

   dcb: TDCB;
   comTO: TCommTimeOuts;
.
.
.
     GetCommState(cp,dcb);
     GetCommTimeOuts(cp,comTO);
     comTO.ReadIntervalTimeOut:=250;
     comTO.ReadTotalTimeoutMultiplier:=0;
     comTO.ReadTotalTimeoutConstant:=0;
     comTO.WriteTotalTimeoutMultiplier:=0;
     comTO.WriteTotalTimeoutConstant:=0;
     case comBaud of
          2:   dcb.BaudRate:=CBR_1200;
          3:   dcb.BaudRate:=CBR_2400;
          4:   dcb.BaudRate:=CBR_4800;
          5:   dcb.BaudRate:=CBR_9600;
          7:   dcb.BaudRate:=CBR_19200;
     else
          dcb.BaudRate:=CBR_9600;
     end;
     case (comParity and $07) of
          0: dcb.Parity:=NOPARITY;
          1: dcb.Parity:=EVENPARITY;
          2: dcb.Parity:=ODDPARITY;
          5: dcb.Parity:=MARKPARITY;
          6: dcb.Parity:=SPACEPARITY;
     else
         dcb.Parity:=NOPARITY;
     end;
     if (comParity and $80)=$80 then
        dcb.StopBits:=TWOSTOPBITS
     else
        dcb.StopBits:=ONESTOPBIT;
     if (comParity and $40)=$40 then
        dcb.ByteSize:=8
     else
        dcb.ByteSize:=7;
     dcb.flags:=$0403;
     dcb.ErrorChar:=char($0);
     SetCommTimeOuts(cp,comTO);
     SetCommState(cp,dcb);

Some notes on the above code:
cp is a handle to the com port obtained through the CreateFile() function. (Also from the WindowsAPI IIRC) comBaud and comParity are variables from my application for the settings to be used.

It's been at least 5 years since I've looked at Delphi, or the above code, so don't expect me to be able to answer too many questions about it. Refer to the windows API documentation for the set/get comstate & timeout functions. As for the structures, I found that most of the windows API structures could be used in Delphi, just by adding a T in front of it. (eg. Windows API: DCB => Delphi TDCB) I think I needed to search through the Delphi headers to confirm this, at the time.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi dksmall,

currently I am using Windows 2000 with service pack 3 and it work find. I also use Windows NT Version 4 with service pack 6 and Windows XP.

I use Async Pro (from turbo power) for all of the OS above. None of the OS have any problem with it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Just checked my code with Win XP on a 2.8GHz machine and it still works!! :D

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

rmoniaga wrote:
Hi dksmall,

currently I am using Windows 2000 with service pack 3 and it work find. I also use Windows NT Version 4 with service pack 6 and Windows XP.

I use Async Pro (from turbo power) for all of the OS above. None of the OS have any problem with it.

You're saying that Async Pro allows you to send 9-bit frames, with the first byte being an address byte that an AVR in 9-bit multiprocessor mode will respond to? And the PC can read that response from the AVR without any bit mangling?

I'll have to spend more time with this, I couldn't get a VB test program to work completely under W2K SP3. Either the AVR didn't respond to the address frame or I got bits dropped.

js wrote:

Just checked my code with Win XP on a 2.8GHz machine and it still works!!

I hope to get an XP box in the next few days. I'll try it there as well.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Ok, looks like I made some progress. I tried what I saw in John's code, which was to close the port before changing things, then opening the port again. Under W95 this would work.

MSComm1.Settings = "9600,m,8,1"                 'set address bit

But to make it work under W2K I had to do this.

MSComm1.PortOpen = False
MSComm1.Settings = "9600,m,8,1"                 'set address bit
MSComm1.PortOpen = True

Why I have to do this, I don't know, but it appears to work now.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Why I have to do this, I don't know, but it appears to work now.
I asked myself the same question but after a couple of hours trying to get it to work without closing and reopening the port I gave up. :) I looked at the code for the comport component and the author was doing the close/open everytime any of the port setting were changed, so I did the same with good results. I will have to try and get some data back from one of my boards when I get some time. The application I have written, so far, is just a combination of notepad and Hyperterminal where one can write, edit , save message etc and then send them to our dot matrix displays. The 9 bit mode is usefull where more than one display is on the same line, so messages can be directed to a particular display.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi dksmall,

In Async Pro, there is a selection for RS232 or RS485 communication. When you select RS485 mode, RTS line (pin no 7 in DB 9) is automatically set to false (low) when not send anything. When you write to the port, RTS goes high.

Another option set the RS485 to false and you have to set RTS (True) when you write to port and reset (false) RTS when you want to read PORT.

The problem with half duplex RS485 is collision (when two or more devices send value at the same time). I just working on a project with RS485 communication with upto 25 devices on the line. I still struggle how to make devices on the line (I build five prototype devices - it work individually, but when I put more than one device on the line the signal is drop and the communication break down - I can see from oscilloscope) if you have any idea.

Suggestion from Js for matching impedance is in my consideration as well, but the model I build is from ST485 data sheet. I don't put any component in from of it.

Also I try put bias in fron of the master only (750 ohm - 120 ohm - 750 ohm) but I still have the same problem.

Does any one have any idea?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The easiest way to avoid collisions is designate one master and all others are slaves. The slaves only speak when spoken to, the master initiates all communications.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The ST485 data sheet shows different ways of biasing and terminating the line. All your nodes MUST BE listening unless one is transmitting otherwise you will be loading down the line. I use one master and many slaves, but if you must use multiple masters then you will have to implement some form of anticollision. Usually the sender needs to monitor the data line and if there is no activity then it starts to send. If a collision occurs then it will stop transmitting, wait a random number of milliseconds and tries again. The random time is there so that the sender(s) will not try to send at the same time again. I don't have any experience with multimaster mode so perhaps someone else can help with this.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

this problem is quite actual for me... do you have anybody some new experiences?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

1) Is it possible to use Turbo Power Async Pro also in C or VB.NET?

2) I have made a code in C which runs in Win XP and it is possible using standard Windows API to control the 9th bit (mark, space parity). But as someone mentioned there is really problem to receive that 9th bit. Parity checking doesn't work. From my experiences, OS is simply too slow so I could not distinguish where (in which byte) the parity was 1 and 0. I just found out that during receiving last bytes parity error was detected.

3) Another more serious problem is that I am unable to quickly switch off the driver after transmitting the last byte. There is only information when the output buffer is empty but at that time last byte transmition is still in progress.

Mainly for third problem I am starting to think about external hardware master. Master would be responsible for all 9-bit transmisions on 485 lines but communication with PC would be simple 8-bit.

Roman

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi,

Use a Mega 162 or Mega128 with two serial ports. One for the RS485 and one for the PC.

Neil.

Kind Regards,

Neil Wrightson.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

nwrightson wrote:
Use a Mega 162 or Mega128 with two serial ports. One for the RS485 and one for the PC.

Yeah, exactly this thing I was thinking about.
But for now I have also another idea. I checked some 485 PCI cards and from datasheet it is seemed that switching between transmitting and receiving should be fast (without OS's "help"). Disadvantage is a price of such cards. But it should be direct access to COM ports so it should be much faster than windows API, I suppose.

R

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For my development the PC is always the master, so it will send out a command using address alerts with the 9th bit active for the first byte. The response it gets back from an embedded controller also has the first byte using the 9th bit for an address alert, but the PC will get a parity error if I recall. Basically when the PC receives the response it assumes that the proper shelf is responding and doesn't verify the address frame, just the rest of the packet.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

maybe this will help...this is a good software library well worth the coin
http://www.wcscnet.com/

I designed my rs232 to rs485 (9 bit mode adapters years ago ..51 based designs) to support products/protocols my company shipped for many years. Most of the off the shelf solutions seem to have disappeared as 51 based designs lagged....actually I recently was asked by a client to create another adapter for their field engineers to support their rs485 protocol...I think the Mega162 or the AT90USBKEY are good candidates for an adapter..probably do the Mega162 with dual uarts first since it will be an easy port from a 51 over a weekend.. (same socket)
FYI ..Signetics and Zilog/Excel discrete uarts supported 9 bit mode for years and there were ISA serial cards with these parts on them

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

We just installed some fancy rack mount PC's to run our chamber tests and the darn things don't have a true 16650 UART in them. Must be some knockoff on the MB that won't do 9-bit at all. I'm about ready to go the same route, making an RS-232 to RS-485 with real 9-bit support. Were you able to power your's off the serial port or did you use an external power source?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
Were you able to power your's off the serial port or did you use an external power source?

For field work I never considering powering any adapter , device or whatever off the pc. USB would be ok with an isolated dc convertor. Other people may have a different opinions, but I like things that are built like a "brick sh*t house". I am a true believer in ISOLATION after seeing several disasters in the field. The adapter power was provided by the rs485 network or an external wall wart dc supply. Usually the RS485 daisy chain had 1 or more data pair and 2 power wires (typically 12 to 24 vdc). The adapters rs485 worked from a dc regulator as simple as a lm7805. It also included an isolated dc to dc convertor though for the rs485 to rs232 data path so a pc was always isolated from a rs485 network attached to it in the field. The previous designs used optocouplers for data path isolation but now these new Silabs convertors are working quite well for me and consume a bit less current which makes less demand on the isolated dc to dc convertor.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I might rob +12 from the PS2 ports, otherwise it's WallWarts. I like the idea of bringing +24 back from the fixtures but our cables and backplane are already built with a 3-wire connector.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

dksmall, bluegoo

are you still generating the 9th bit on the PC side? If yes, are you using some third party libraries or you have writen own code? Which OS are you using?
If you are talking about UART that supports the 9bit mode, do you mean 9 bits plus parity? I mean 9th bit as parity bit. Parity bit used as an address bit and therefore is no parity information in the frame.

bluegoo, about your adapters. What was the current consuption of your adapter. From my experiences at least 15 mA on 485 side and another 15 mA on 232 side plus 30mA for DC/DC converter. I addition I am using 5/9V or 5/12 unregulated DC/DC converter and so from 15 on 232 side it is on 485 always higher value. So power dissipation would be quite high with input voltage 24V.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ploskon wrote:
dksmall, bluegoo

are you still generating the 9th bit on the PC side? If yes, are you using some third party libraries or you have writen own code? Which OS are you using?
If you are talking about UART that supports the 9bit mode, do you mean 9 bits plus parity? I mean 9th bit as parity bit. Parity bit used as an address bit and therefore is no parity information in the frame.

bluegoo, about your adapters. What was the current consuption of your adapter. From my experiences at least 15 mA on 485 side and another 15 mA on 232 side plus 30mA for DC/DC converter. I addition I am using 5/9V or 5/12 unregulated DC/DC converter and so from 15 on 232 side it is on 485 always higher value. So power dissipation would be quite high with input voltage 24V.

as you know there are many ways to do this, but the one I like best is to make the adpater do a lot of the work, like generate and filter the 9th bit inside the adapter...the gui on the pc sends a cmd and "packet" of data to the adapter and it formats it and sends it.....likewise there are several cmds I can send to the adapter to log or filter certain addresses/info on the rs485 line and only send the pc gui a "packet" of relevant data....in the old days I did have pc's squatting on a rs485 line using ISA adpaters that supported the 9 bit mode and the os was DOS with asm/c com library code to support it. These days with Windows, I think the "intelligent" adapter works best for my apps.
Your current consumption is very similar to mine except in some situations where the power is a factor and dropping the dc input is also of concern, I use high speed switchers for the conversion and the newer lower current rs485 drivers like TI and others are making now.....

I recently purchased several AT90USBKEY's and one of the first apps I considered for it was a "intelligent" rs485 adapter..it is perfect...it has data flash for logging rs485 traffic and lots of sram...a spare Uart port, a usb high speed link to send and recieve packets from the pc gui and lastly and most important as an "intelligent" adapter the firmware/cmd set can be updated from the pc thru the bootloader...I considered a PIC with integrated USB a year ago as they beat Atmel to the gate, but I aborted that for several reasons. I also considered the Atmel 51 family with USB as I have a ton of seasoned bug free 9 bit mode networking code for it.....but I really like Jtag development vs. 51 emulators so the AVR is the path of least resistance for future development.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you look back through this thread, I posted a VB6 example of how you can use the PC's UART to generate 9-bit messages. It won't work with W2K or XP, which is why I'm considering going the external converter method like BlueGoo did.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
It won't work with W2K or XP,

I don't have any troubles generating the 9th bit with Win XP and VS2005 (I used Delphi with Win XP too see code snippet in page 2 of this thread), just set or reset the sticky parity bit in the UART of the pc.

Just adding a code snippet from my send packet routine for VB2005 which works also under Win XP.

             SerialPort1.Parity = Ports.Parity.Mark 'Bit 8=1 (address)
         Try
             SerialPort1.Open()
             SerialPort1.Write(Chr(Destination_Address)) 'Write Dest. address
             ByteCrc(Destination_Address)
             SerialPort1.Close()
             SerialPort1.Parity = Ports.Parity.Space 'Bit 8=0 (data)
             SerialPort1.Open()
             SerialPort1.Write(Chr(Origin_Address)) 'Origin Address
             ByteCrc(Origin_Address)

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Actually I did try my routine awhile back with VB2005 with W2K and it did work. In fact I think I was able to remove all the open/close statements, but I'll have to verify that again. Some day I'll convince the stick-in-the-mud dinosuars in my group to upgrade a little!!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

From my experience 9bit 485 comms driven from the ap PC is just tempting Murphy.
The reception of the 9th bit requires your ap to get to the byte before the next one comes in and overwrites the parity bit. Windows loves taking it's time and matters becomes worse if you've added a USB to serial converter : Then the bytes come in at a helluva rate.

Also if you want to log the data, or transmit it over Ethernet, Internet etc, you now have to use 16bits as these comms systems work in bytes. Future proof your design by supporting multiple media : go 8bit.

SLIP is a simple 8bit packetizer for your comms. As SLIP will packetize the data, simply use the first byte as the "to address".
bang! all done. future proof as well.
As for the source. All the source for a SLIP implementation is a available on http://www.opend.co.za . Delphi and GCC winavr c code.

Enjoy.
Murray Horn.

Murray Horn.
http://www.opend.co.za