I would hope  that a 422/485 interface would very much look like a standard serial port - it is basically a standard UART with a different  hardware interface (to the world). IE a 232 device has ground, transmit and receive pins (plus a bunch of optional signal control pins) The 485 interface has a differential (+/- pair) for receive and transmit. This allows one to send high speed signals over long distances. Long ago I set up a snow making system at Whistler with more than a mile of wire between the control computer and the hydrants & sensors we were controlling.

So assuming you get a driver loaded, it will probably look like a serial port. The big issue with 485 software, is that you may be operating in a mode where the transmit and receive pairs are tied together onto a single pair so that you see whatever you transmit. In this case, you need to turn off the transmitter after sending a message out to your instrumentation in order to get a reply back. In transmit mode the controlling transmitter is driving the line levels and only one transmitter can do that at a time. The trick here is determining when you've finished sending. Even with a 1 character hardware send buffer you may get a buffer free interrupt before the last bit is out. If you turn the line around too soon, you'll clobber the last few bits (or bytes) of the message you just sent. Two solutions without an interrupt that tells you that the transmit buffer is truly empty)

1 - wait a bit until the buffer is surly free
2 - look at the data you've just sent until you see it all (since the receive pair is tied to transmit)
This latter method will work with a standard 232 serial port driver.

I typically used an external 232 - 485 converter which has hardware built in to turn the line around as needed.

Well third (or is it more) time's a charm.
Thanks,
Dave

Hi,

Your instructions for updating the plug are the clearest that I've seen. Unfortunately, I'm having a problem in that the kernel is not able to find the file system. I note that the file sizes are different from that in your log posting, so I assume that the archive is newer that that used the post. 
Here's the tail of the boot log - it looks like I need to play around with bootargs:

oprofile: using timer interrupt.
TCP cubic registered
NET: Registered protocol family 17
lib80211: common routines for IEEE802.11 drivers
rtc-mv rtc-mv: setting system clock to 2000-02-07 12:16:19 UTC (949925779)
UBIFS error (pid 1): ubifs_get_sb: cannot open "ubi0:rootfs", error -19
VFS: Cannot open root device "ubi0:rootfs" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
1f00            1024 mtdblock0 (driver?)
1f01            4096 mtdblock1 (driver?)
1f02          519168 mtdblock2 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
[<c0032b24>] (unwind_backtrace+0x0/0xdc) from [<c041cb3c>] (panic+0x3c/0x128)
[<c041cb3c>] (panic+0x3c/0x128) from [<c0008f24>] (mount_block_root+0x1d4/0x21c)
[<c0008f24>] (mount_block_root+0x1d4/0x21c) from [<c00090fc>] (prepare_namespace
+0x8c/0x1c8)
[<c00090fc>] (prepare_namespace+0x8c/0x1c8) from [<c000844c>] (kernel_init+0xdc/
0x114)
[<c000844c>] (kernel_init+0xdc/0x114) from [<c002e45c>] (kernel_thread_exit+0x0/
0x8)