On 19 Mar 2007 06:22:42 -0700, "frikk" <> declaimed the
following in comp.lang.python:
>
> I am looking into a project for the company I work for. Essentially
> it involves setting up a real time monitor / signal injector in
> between a CPU board and a system controller. The system controller
> sends signals (message packets) to the CPU board. We would like to
> create an environment where we can modify signals, inject new
> messages, drop signals, etc. This would simulate communication
> failures and message dropouts to see how the CPU board responds. The
> application monitor would use a COM port to send and receive
> messages. The most important part about this monitor is that
> absolutely no messages get delayed or dropped due to inturrupts or lag
> on the PC that the monitor is running on. What would be the expected
> sampling time range that I could expect to handle?
>
Insufficient information: processor speed, OS, UART capabilities,
dedicated or general usage (ie, are you running a spreadsheet in
parallel?); protocol specs... (if the messages are in an byte-HDLC
format, the timing may be slightly tighter).
> I have seen similar applications written for other projects that we
> have which were done in Visual Basic. I assume that if VB is up to the
> task, Python should be as well. What kind of libraries am I looking
> at? I will probably use wxWindows, but what about for the serial ports
> and packet timing?
>
Visual C++ isn't up to the job of tight realtime! Mainly because
Windows isn't up to realtime specs. I had an application that had to
precisely time output on a parallel port (using an external clock signal
coming in on the port)... Even with the program running in "realtime"
priority class on W98 (don't ask*), the timing became glitched every 200
or so "ticks".
One thing -- you probably do not want the serial port handler to be
in the same thread as the GUI. As for module: pyserial is about all that
I know of (unless you intend to go down to the level of win32 I/O
calls). Inbound timing you have no control over -- the hardware will
interrupt as the UART fills, and the OS I/O subsystem will pass data to
any pending read operation (which will probably work better if you have
a recognized "end-of-packet" -- like a newline -- that the subsystem can
use to send complete packets to the application; otherwise you run the
overhead of reading one byte at a time and parsing). Outbound? Well,
once you pass a complete packet to the I/O subsystem (via a write
operation), the OS will be sending bytes to the UART whenever it signals
the buffer is near empty...
> Like I said - I'm not sure what kind of "real time" this is - all I
> know is that I need messages to not get dropped when they're received.
>
If you are using serial ports, you're probably already using
interrupt driven behavior. Are the systems using RTS/CTS (hardware
handshake)? Any modern machine has a UART with 16-byte buffering.
Question now is: what baud-rate? Your requirements will be quite loose
at <19200 (some machines can keep up 19200 WITHOUT handshaking, just
using the start/stop bits of each byte). At 115Kbps, you'd better be
using hardware handshaking (maybe with the UART set to interrupt at
8-bytes, giving you an 8-byte margin to respond and read).
Serial ports are commonly asynchronous -- other than the bit-rate
per byte, the data transfer is not hard realtime. The UART doesn't care
if byte-2 comes immediately after byte-1, or next month <G>
* Okay, I'll inflict the pain on you anyways: government furnished
laptop; used six of the 8 data pins on the port to emulate 3 balanced
serial output signal -- as a pseudo ground station command formatter. At
the time, GPS PPS keys couldn't pass through the full ground station
without turning the station fully classified/crypto; the laptop could be
kept secure and plugged in for key uploads. Keys could not be stored on
disk, had to be taken directly from DTD to output port after packing
into upload commands; then memory wiped.
--
Wulfraed Dennis Lee Bieber KD6MOG
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff:
web-)
HTTP://www.bestiaria.com/
Similar Threads
