Industrial I/O

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! Who is John Williams?

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

Thank you, I didn't know that. :)

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.

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:

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

Unfortunately I havn't found any schematics, but RasPiComm has its own device driver and the code is open source:

The chip (MAX3140) is connected via SPI and leaves the UART alone.

H.

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)

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.

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.

????

Full schematics and source code.

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

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)

oh, that looks handy.... :)

No, I was responding to your comment about Maxim. Are you dissing their supply consistency or saying Maxim may go under?

supply, they have been known to discontinue production of parts without warning.

Probably not much use in the UK anyway as no-one seems to stock that chip.

Eh? RS has it in stock.