Industrial I/O

Yes, my girl friend says that all the time. :-)
Yes, RS-485 is an electrical spec
I have seem people use RS-485 drivers to signal condition SPI signals to get across a chassis. That is where I thought you were going.
Also, people use RS-232 to mean async serial, but we both know its not. ;-)
Reply to
hamilton
Loading thread data ...
You have a girl friend?
--
John Williams, now back in the UK - no attachments to these addresses! 
Non-RISC OS posters change user to johnrwilliams or put 'risc' in subject! 
 Click to see the full signature
Reply to
John Williams (News)
I worked on some gear once a long time ago where an RS-485 bus was defined for control. All the gear was tailored to work with this bus... but some implementers had different ideas of how the bus should work. The biggest problem was how quickly they turned off their drivers and how long they waited before turning on drivers for a response. It was a real trick programming this to be controlled by a PC running Windows 3.1, lol
--

Rick
Reply to
rickman
formatting link
--
Everything you read in newspapers is absolutely true, except for the  
rare story of which you happen to have first-hand knowledge. ? Erwin Knoll
Reply to
The Natural Philosopher
Thank you, I didn't know that. :)
Reply to
mick
It might be interesting to try the UART on the Pi. Control of the driver could be via GPIO pins, allowing us to use a uS or two delay to get around timing issues. As we would have control of the timing at both ends (we can mess with delays on the remote devices too) and there would only be one master device it might be workable.
I must admit, I've never attempted to use the Pi's UART. I only know that you have to take control of it away from linux (which wants to use it as a terminal by default) before you can play with it.
Reply to
mick
There are several commercial RS-485 interface boards available (based on the MAX 485 driver chip) and many work directly on the Pi. They all use an extra GPIO line (or 2) to control the direction of the RS-485 bus.
A google finds this on the first page for exmaple:
formatting link

Linux still controls it (via the kernel interface), you just need to tell the kernel to not put messages over it and make sure userland doesn't start the getty (login) process. This is all fairly straightforward - edit /boot/cmdline.txt and /etc/inittab (under Raspbian) That link above has the runes.
-Gordon
Reply to
Gordon Henderson
Unfortunately I havn't found any schematics, but RasPiComm has its own device driver and the code is open source:
formatting link

The chip (MAX3140) is connected via SPI and leaves the UART alone.
H.
Reply to
Helmuth Kranz
start and stop can be added in software, the hard part would be receiving data: rejecting glitches detecting the rising edge of the start bit, reading the bits verifying the presence of stop bit and forming theb new byte whilst waiting for the next start bit...
either use SPI UART or a small microcontroller - something like an AtTiny2313 which can have the firmware loaded over the SPI while situ using only one extra GPIO (which couls subsequently be used as chip-select)
--
umop apisdn
Reply to
Jasen Betts
that's a better way to go as the UART has dedicated outputs for sequencing the drivers. It's Maxim though which means there might be none available after next week.
--
umop apisdn
Reply to
Jasen Betts
yeah, it's hardware, drop bytes into a buffer and serialises them and squirts them out. the prob;em is turning off the RS422 transmitter when the buffer empties, and the last stop bit hase been sent. If you use software to do that you could be a few milliseconds late. if you're late you might miss the start of the next message.
--
umop apisdn
Reply to
Jasen Betts
????
--

Rick
Reply to
rickman
formatting link

Full schematics and source code.
Reply to
hamilton
See:
man 3 tcdrain
Although I'm not 100% sure if it returns when the last character has been written to the UART, or the last character has been clocked out of the UART. The kernel gets the interrupt either way, so in-theory it can tell. It would be relatively simple to test with a 2-channel scope though - have it set another gpio line as soon as tcdrain() returns.
Gordon
Reply to
Gordon Henderson
All of this is why I suggested using a dedicated RS485 converter. You set the BAUD and forget about it!
If you do roll your own, remember you need to work at byte length, not message length. At work we had no end of trouble because a tracking laser sent out highly variable messages with erratic spacing between the bytes.
If at all possible, use fixed length messages, even if that means padding some out. Most processes work best with reasonably consistent timing, rather than always the fastest, and it makes sanity checks a *lot* easier.
When building an entire network, it make sense for the remotes to delay slightly before starting to reply (quite possibly the processing between receive and reply will be enough).
Finally, assuming a typical polling system, your approximate overall latency will be BAUD / (20 * NumChars * NumRemotes)
20 .. because you want replies! NumChars .. includes a terminator - personally, I always use line feed.
--
W J G
Reply to
Folderol
oh, that looks handy.... :)
Reply to
mick
No, I was responding to your comment about Maxim. Are you dissing their supply consistency or saying Maxim may go under?
--

Rick
Reply to
rickman
supply, they have been known to discontinue production of parts without warning.
--
umop apisdn
Reply to
Jasen Betts
Probably not much use in the UK anyway as no-one seems to stock that chip.
Reply to
mick
Eh? RS has it in stock.
formatting link

Reply to
Rob Morley

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.