Several usages, based around the same basic idea:
On-board relay which switches the RS232 between the standard
connector and a second connector with reversed pinout. The
power-on default of the ucsimm pin selects the debugging port.
The serial getty is modified in that it also keeps a listener
on a tcpip network socket in addition to looking for serial data.
Whichever arrives first wins; if it is the serial port, this
is considered a diagnostic act and we exec to login as usual.
If the listener, we close the serial port, kick the relay into
the other position, and do a inetd-style exec out to the remotely
requested program. That program can now open the serial port as
though it is a normal device. When the socket connection closes,
the process goes away, init notices and fires up another getty.
The modified getty always kicks the relay carefully to the
diagnostic port because it doesn't know who just used it.
Obviously I simply implemented an ethernet-RS232 bridge.
You can buy them off the shelf. However, I'm doing local
processing in that program, where the timely response of the
ucsimm is preferable to an unknown ethernet latency to the
remote hardware. This is especially relevant when I'm
working with the unit on the company ethernet while at home
and taking data over the VPN link (about 100ms round trip).
The getty tweak is written so that the same source code will
compile to a program that runs on the ucsimm in this manner,
and will compile on a desktop computer to run out of the
conventional inetd.conf mechanism with no changes to either
the source, or to the serial cable that is being plugged in.
Simplifies my development towards the target enormously.
So, where does this get used ?
(1) Serial port has no hardware handshaking, runs at 115200 baud
and is level-shifted to RS485 that goes multi-drop to a chain
of DSPs, each running a multichannel acquisition/control
environment. Operations are a command/response style, with
the ucsimm polling for information and formatting a compact
streaming report of the DSP responses on the TCP socket.
(2) Serial port had hardware h/s, also 115200 baud, other
device is fully custom programmable logic that delivers
readings without any complexity of interactive commands.
The ucsimm's job is to collect bytes and check CRCs.
Note that, for (2), the programmable logic could connect
directly to the SPI port and stream the data that way.
However, that would be a major hardware rework and
also incompatible with installations utilizing a desk PC.
(other things are being worked on too)
This message resent by the firstname.lastname@example.org list server http://www.uClinux.com/
This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST