Chris Walker wrote:
How about putting a loopback tool (a paper clip or two if you're feeling brave) on the port to make it think something is connected? Would that improve anything?
I was thinking about something along those lines so that I'd know when the stream had actually been transmitted from the hole at the back. The RS232 to RS485 adapter has a facility for echoing the data on the TX line back to the RX line and that would have done the 'paperclip' trick nicely. Unfortunately, it still doesn't get me clear of the problem, because I'd have no way of knowing how much delay had been introduced by the emulation between the echo coming back to the port and the emulator actually passing it back to my DOS programme. If there were an appreciable delay, I'd miss the real received response from the far end of the RS485 link.
Ted.Harding wrote:
mv /dev/ttyS0 /dev/ttyS0.bak
There may be a problem arising from the initial hardware probe at the start of boot: if Linux _at that point_ lays claim to the hardware device then there may still be conflicts. I haven't tried the above, so it's only a (possibly uninspired) guess.
It does seem to claim the port very early on, judging from teh dmesg output.
MJ Ray wrote:
Feed the serial driver the io address and irq of com2 as com1 or something equally odd, then call it ttyS0. I forget how, sorry, but I'm sure I've done similar things in the past to get an internal ISA modem working.
Oh - that sounds intriguing! Does that mean that Linux would be trying to get at /dev/ttyS0 and /dev/ttyS1 both at the same actual hardware address? I suppose that would be alright, so long as it didn't want to write to both 'ports' at the same time.
I'll try that as soon as time allows.
Thanks for all the suggestions, as always!
Cheers,
Gerald.