Hi,

I ran a search for my problem but didn't find anything - of course, I couldn't think of very good search criteria for this one, so I'll describe it.

I work at a helpdesk for a supermarket chain. The registers in our supermarkets are all linux boxes: Red Hat 7.3 (Valhalla), 2.4.18-3custom kernel.

These registers have four serial ports. Plugged into these serial ports are a customer display (just an array of LEDs capable of displaying a couple of lines of text), a receipt printer, a scanner/scale unit and an EFTPOS terminal.

(EFTPOS, I believe, isn't what its called outside of Australia, but it is just the device you swipe your card through and punch your pin into when buying groceries without cash.)

We want to be able to plug the customer display into the EFTPOS port, and send text to it that way. But it doesn't work.

We can plug the display into the receipt printer port and display text (and vice versa, the printer will print whatever text is sent to the customer display port). We can plug the display into the scanner/scale port and it will print the correct number of characters in an alphabet of symbols. But when we plug it into the EFTPOS port we get no response.

My question is what can I do to figure out how this can be done, or even whether it can be done?

Any help would be greatly appreciated.

If you are sending something out the EFTPOS port that you would actually expect to produce output, I would suggest checking the settings of the various ports using the stty command and seeing if there is a difference that might account for your observations.

will list all settings for /dev/ttyS0, for example. You can check stty's man page for the meanings of the settings. You can also change settings with stty. I believe both for examining and changing, you will have to run the command as root.

Thanks. This looks promising.

My problem now is that a few of the settings are set to things I don't know how to define. I would like to be able to set the eof char to "M-p", and the kill char to "M-~", but stty does not accept this as an argument.

I'm not sure what M-p or M-~ mean, I'm simply trying to make the settings of one serial port look exactly like another.

Okay, that didn't work. I was hopeful for a while there, but I managed to make the settings for ttyS1 (the EFTPOS serial port) mirror the settings for ttyS3 (the customer display) but it still does nothing.

There are also a few low level settings that can be set with the setserial command. I just looked through the man page and didn't see anything I would expect could cause what you see. If you decide to take a look at that, be sure you don't confuse the baud_base which is set with setserial with the baud rate which is set with stty. stty controls the actual baud rate that is used; setserial is controlling something lower level.

If you have a system you can afford to play with, I have a couple of ideas you might try. No guarantees. One thing you can try, just to see if produces any output (and thereby gain some more diagnostic info) is to, as root send some text to /dev/ttyS1 using echo:

Please note that I have sometimes rather hosed a system while trying such things. Nothing serious -- a reboot restored things to functional.

The other thing you might try (again, to get some diagnostic info) is leaving things hooked up the way "they are supposed to be" and try simply redirecting the output of EFTPOS to the customer display at ttyS3. What I think this should show you is whether the problem is simply that your software is expecting something from the EFTPOS that the customer display is not providing.

This is probably a little riskier, so decide what your comfort level is before deciding whether to proceed.
What I am proposing is something like, as root

The above termporarilly renames the node /dev/ttyS1 just to get it out of the way, and then creates a symbolic link with the name /dev/ttyS1 which actually points to /dev/ttyS3. This way what the software would normally send to EFTPOS gets sent to the customer display, but the customer display is still physically sitting on its normal port. If this fails, I think it would mean the software is expecting something that the customer display simply doesn't provide. Perhaps identifying itself or something related to the security that EFTPOS requires. (I am not real familiar with the udev system, so I can't be certain it won't try to get into the game and complicate things.)

I believe I have seen tools on the Internet to actually let you see the data sent across the serial lines, but my recollection is it was rather involved to use, perhaps requiring recompiling the kernel. I also know there used to be equipment (we just called it a communication analyzer) that can physically monitor a serial line and show what has transpired, including the ability to set trigger points. That would probably require your company to drop a few bucks to rent one, and might be more trouble than you are willing to go to.