 |
 |
| View previous topic :: View next topic |
| Author |
Message |
chingB
Joined: 29 Dec 2003
Posts: 81
|
| RS485 PC to PIC Communication |
 Posted: Sun Oct 24, 2004 6:38 pm |
 |
|
Hello,
I have tried communicating my PIC with my PC or vice versa using simple communication protocol and I have writen a simple VB program for this setup using the 9-pin RS232 port of the PC.
With this setup, I am planning to implement it also using an RS485 communincation and I have read articles on this.
On the side of the PIC I'll just add an RS485 transceiver, few resistor and protection circuits.
On the PC side I need to have an RS232 to RS485 converter... with this I plan to prototype my own rather than buying and I have already have a draft schematics on this converter.
My concern really is the VB program, so I have to rewrite it such that I can control the RS485 direction but Windows doesn't control the serial port handshaking lines very well. Actually, compared with DOS, it is very poor in its timing. Any RTS controlled RS485 converter will only have mediocre performance under windows - and with some RS485 devices at higher baud rates it may well fail to operate.
Anyone in this forum have successfully implemented such setup wherein you can control RTS/CTS using the built-in MSComm of MS VB for RS485 communication?
A recommendation, suggestions, and/or comments is welcome.
I'll appreciate any help from you guys.
Thanx
..... |
|
 |
Ttelmah
Guest
|
| Re: RS485 PC to PIC Communication |
| Posted: Mon Oct 25, 2004 4:00 am |
|
|
| chingB wrote: | Hello,
I have tried communicating my PIC with my PC or vice versa using simple communication protocol and I have writen a simple VB program for this setup using the 9-pin RS232 port of the PC.
With this setup, I am planning to implement it also using an RS485 communincation and I have read articles on this.
On the side of the PIC I'll just add an RS485 transceiver, few resistor and protection circuits.
On the PC side I need to have an RS232 to RS485 converter... with this I plan to prototype my own rather than buying and I have already have a draft schematics on this converter.
My concern really is the VB program, so I have to rewrite it such that I can control the RS485 direction but Windows doesn't control the serial port handshaking lines very well. Actually, compared with DOS, it is very poor in its timing. Any RTS controlled RS485 converter will only have mediocre performance under windows - and with some RS485 devices at higher baud rates it may well fail to operate.
Anyone in this forum have successfully implemented such setup wherein you can control RTS/CTS using the built-in MSComm of MS VB for RS485 communication?
A recommendation, suggestions, and/or comments is welcome.
I'll appreciate any help from you guys.
Thanx
..... |
Consider approaching this differently, and having the RS485 turnround, done in hardware. Even in DOS (or on the PIC), it is hard to know when the character has actually finished 'sending' (remember the transmit buffer flag goes 'empty', one character time ahead of the end of transmisssion), so you end up having to 'poll' the data line. The normal approach, is to have either a simple (non retriggerable) mono-stable multivibrator, or a processor, looking for the first 'falling' edge of the character, and then asserting the transmit control for half a bit time less than the full charater (including stop bit(s)). With a processor, you can even 'auto-baud'. You should also enure that the 485 bus is correctly biased, so it idles when undriven, to the transmission 'idle' state. You can get solid state terminator networks that do this, and/or specific transceivers that ensure that this happens. I have used several of the simple 8pin PIC's in the past to do this type of control, with the advantage that once the code is written for it, the chip can be used at both ends of the link.
Using this approach, I have applications, in VB, VC, Delphi etc., all talking to the same link, in many cases at the same time...
Best Wishes |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Mon Oct 25, 2004 5:33 am |
|
|
| Quote: | | The normal approach, is to have either a simple (non retriggerable) mono-stable multivibrator, or a processor, looking for the first 'falling' edge of the character, and then asserting the transmit control for half a bit time less than the full charater (including stop bit(s)). |
One issue with this (commonly used) approach is that some UARTs may detect a framing error on the last stop bit of the sequence and it is up to the application software to recover from this error (or crash). There are multiple ways of solving this PC RS232 to embedded system RS485 problem. I use a PIC with an RS232 interface going to the PC and a RS485 interface to the system I am doing the development on. This lets me use any application on the PC without needing to be concerned with its ability to support RTS and besides, a low end PIC is not much more expensive than a multivibrator but gives me a lot more flexibility |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Oct 25, 2004 5:46 am |
|
|
| asmallri wrote: | | Quote: | | The normal approach, is to have either a simple (non retriggerable) mono-stable multivibrator, or a processor, looking for the first 'falling' edge of the character, and then asserting the transmit control for half a bit time less than the full charater (including stop bit(s)). |
One issue with this (commonly used) approach is that some UARTs may detect a framing error on the last stop bit of the sequence and it is up to the application software to recover from this error (or crash). There are multiple ways of solving this PC RS232 to embedded system RS485 problem. I use a PIC with an RS232 interface going to the PC and a RS485 interface to the system I am doing the development on. This lets me use any application on the PC without needing to be concerned with its ability to support RTS and besides, a low end PIC is not much more expensive than a multivibrator but gives me a lot more flexibility |
Provided the bus is biased correctly, so that the idle state, is the default, this does not happen. This is why I emphasised the importance of this. Remember a 'stop' bit, is just a bit at the idle state.
There are other 'criteria' that apply (the transmit code on other units, must not start sending before the full stop 'bit time' has passed for example).
Getting a framing error on this, is a sign that the bus is not correctly biased when undriven.
Best Wishes |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Mon Oct 25, 2004 6:15 am |
|
|
| Quote: | | Provided the bus is biased correctly, so that the idle state, is the default, this does not happen. This is why I emphasised the importance of this. Remember a 'stop' bit, is just a bit at the idle state. |
You may be right but I guess I am more conservative. Any enabling and disabling of bus drivers will likley result in transients being unnecessary being introduced on the bus. A framing error test includes the stop bit(s) - why temp fate? |
|
|
Ttelmah
Guest
|
|
| Posted: Mon Oct 25, 2004 8:55 am |
|
|
| asmallri wrote: | | Quote: | | Provided the bus is biased correctly, so that the idle state, is the default, this does not happen. This is why I emphasised the importance of this. Remember a 'stop' bit, is just a bit at the idle state. |
You may be right but I guess I am more conservative. Any enabling and disabling of bus drivers will likley result in transients being unnecessary being introduced on the bus. A framing error test includes the stop bit(s) - why temp fate? |
Why should disabling the driver, introduce transients, if the bus is allready driven to the same state?.
Manufacturers design the driver chips to handle this transition cleanly. If you are worried about disabling the driver, the same problem occurs, whatever approach is used. Remember that timings are not perfect, , and if (for instance), you wait till the nominal 'end' of the stop bit, and then disable the driver, if a transient is produced, this can be seen as a 'start', and also trigger a framing error....
You should be designing the protocol to handle this anyway, but this is actually the 'defined' way to handle the bus control, on three different industrial RS485 interfaces that I know of, and does not generate framing errors on any that I have seen. The one occasion when I have seen such errors, was where there was no bias applied to the termination, and then the company concerned were very puzzled that it was taking them a complex 'preamble', to get the bus to synchronise. With bias applied, this same bus has been in use for the last half dozen years in the UK, and has proved very reliable indeed.
Best Wishes |
|
|
asmallri
Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia
|
|
| Posted: Mon Oct 25, 2004 3:59 pm |
|
|
| The RS485 bus is a transmission line with all the associated characteristics. The output impedance of the RS485 driver when driving a stop bit is not infinity as would be the case with a driver in its high impedance state therefore an impedance change occurs on the bus when a driver is changed from its active state to high impedance state. When this happens transients can and do occur on the bus. The significance of this depends on multiple criteria such as length of the bus, number of devices on the bus, bus termination methid (active or passive - aka bias), speed of transmission, cable type, temperature, time of day, phase of the moon (ok maybe the last couple of points are a bit over the top). |
|
|
Best Wishes
Guest
|
|
| Posted: Mon Oct 25, 2004 4:39 pm |
|
|
| asmallri wrote: | | The RS485 bus is a transmission line with all the associated characteristics. The output impedance of the RS485 driver when driving a stop bit is not infinity as would be the case with a driver in its high impedance state therefore an impedance change occurs on the bus when a driver is changed from its active state to high impedance state. When this happens transients can and do occur on the bus. The significance of this depends on multiple criteria such as length of the bus, number of devices on the bus, bus termination methid (active or passive - aka bias), speed of transmission, cable type, temperature, time of day, phase of the moon (ok maybe the last couple of points are a bit over the top). |
An impedance change, only causes a transient, if there is a signal present.
Best Wishes |
|
|
chingB
Joined: 29 Dec 2003
Posts: 81
|
|
| Posted: Tue Oct 26, 2004 6:53 am |
|
|
| asmallri wrote: | | Quote: | | The normal approach, is to have either a simple (non retriggerable) mono-stable multivibrator, or a processor, looking for the first 'falling' edge of the character, and then asserting the transmit control for half a bit time less than the full charater (including stop bit(s)). |
One issue with this (commonly used) approach is that some UARTs may detect a framing error on the last stop bit of the sequence and it is up to the application software to recover from this error (or crash). There are multiple ways of solving this PC RS232 to embedded system RS485 problem. I use a PIC with an RS232 interface going to the PC and a RS485 interface to the system I am doing the development on. This lets me use any application on the PC without needing to be concerned with its ability to support RTS and besides, a low end PIC is not much more expensive than a multivibrator but gives me a lot more flexibility |
May I know what PICmicro you use? What Port connected to the PC? What Port Connected to the RS485 Transceiver?
Thankx |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
