First post here, forgive me if it's better suited for another area!

I'm tying to interface my PC with a device via a serial (rs232) port.

In general, it's working ok, but I need some software to help me out.

(Some kind of rs232/commport prototyping software.)

I need something that can run a small script (i.e., watch for a message, then respond.) I've tried a number of app.'s already, "DockLight" is the closest I've come, but it responds too slow to keep the device happy.

The app. must support custom baud rates (15625, in this case).

I'm using a USB-Serial adaptor which does indeed support 15625k, so no problem there.

I need to see the message, and then respond in less than 10mS, or the device times out.

Any ideas? Even direction to another forum would be helpful...I'm crosseyed from googling this.

Thanks!

 

I think you'll find that you're going to need to build an intermediate piece of hardware to get response times like that.

You could use a UART IC like an AY-3-1015D as a basis, but you would probably find it much easier to use something like a PIC or Parallax microcontroller to intercept messages, respond to them, and asynchronously send messages to the monitoring computer.

 

Yeah, I was afraid of that! Actually, I am trying to eliminate a piece of intermediate hardware that is obsolete, but I'm beginning to think it serves a purpose - that of giving a very fast response. It may come to a PIC, I've been putting that off as long as possible. Do you know if a PC is capable of responding that fast, if it were running its own dedicated app? (like something that I write myself, and run outside of windows.)

 

Well, PC's have an 18ms heartbeat interrupt (INT 0) for the clock routine, which steals processor cycles - and the keyboard has a very high priority interrupt (INT 1) - so, seems to me that even trying to run a 32-bit app in DOS to handle your impatient widget would be dicey at best. Just about everything except the clock is asynchronous and buffered. Your application isn't necessarily synchronous, but the required response time is so low, with so many opportunities for things to "get lost" that you'd either have to use an interrupt, meaning building a custom interface card, or use an external device to keep your widget happy.

 

excellent information - thanks!