Serial Communications and Resets

[Just Another Joe]

Would like to use ZX-24 as a translator between two other microcontroller devices via serial ports. One of the peripherals communicates at 9600 baud, the other at 4800 baud. Each of them has only a single serial port, which would be connected to one of the ZX-24's secondary serial ports. The primary (hardware) port would be connected to the PC.

During normal operation, the ZX-24 would pass translated commands between the two peripherals; the PC port would be idle, or perhaps monitoring the traffic. However, a command from the PC would place the ZX-24 into a 'pass-through' mode to one or the other of the peripherals, in which normal operations would be suspended, and all traffic would simply be passed between the PC and the selected peripheral. This would be used to program the peripheral from the PC, without having to move cables.

So my first question is: would the ZX-24 handle a constant 9600 baud data stream between the PC and the peripheral without overruns/underruns? It seems likely to me that it should be well within its capabilities, but just want to be sure.

Secondly, this pass-through mode would have to allow any arbitrary byte sequence for programming the peripheral, so once the mode is entered, the only way to exit the mode would be with a reset via DTR. A software reset command would not be useful, even if it were a sequence of characters, since any such sequence could conceivably be part of the data stream. Does this analysis sound correct?

Terminating pass-through mode via reset is acceptable in this application, but what about the problem of Windows toggling DTR at boot? Does that OS toggle that line only at boot time, or are there other circumstances when it does so?

And, how many times does the OS toggle the line? If just one time, then I wonder if it would be possible to add a simple circuit which would mask the first DTR transition, but use it to open a gate allowing subsequent transitions to pass through to the ZX-24 for a specific time period? If feasible, could someone suggest such a circuit?

Thanks!

[dkinzer]

[W]ould the ZX-24 handle a constant 9600 baud data stream between the PC and the peripheral without overruns/underruns?

If you're referring to Com1, I think it quite unlikely that there would be a problem. If you're thinking of using one of the SW UART ports (Com3 - Com6) it will probably be OK but it may be a problem depending on what else the application needs to do.

A software reset command would not be useful, even if it were a sequence of characters, since any such sequence could conceivably be part of the data stream. Does this analysis sound correct?

This is precisely the problem that we've been discussing on the DTR-less Downloading thread. If you can choose a sequence of one or more bytes that you can guarantee will not appear in the data stream then you're all set. Otherwise, you have to come up with an alternate stragegy.

Terminating pass-through mode via reset is acceptable in this application, but what about the problem of Windows toggling DTR at boot?

Not much is known about this issue - only that the DTR line has been observed to toggle during the XP boot sequence. It may or may not occur on other versions of Windows. It may depend on the particular implementation of the serial port driver. And, an update to Windows may change what it does and when it happens.

It may be feasible for your application to control the gating of the DTR signal. That is, when it is in the pass-through mode it enables DTR resets. Also, it may be feasible to store a value in Persistent Memory that is used to decide what to do when a reset is received.

[Just Another Joe]

[W]ould the ZX-24 handle a constant 9600 baud data stream between the PC and the peripheral without overruns/underruns?

If you're referring to Com1, I think it quite unlikely that there would be a problem. If you're thinking of using one of the SW UART ports (Com3 - Com6) it will probably be OK but it may be a problem depending on what else the application needs to do.

In the pass-through mode, the ZX-24 would do nothing but pass bytes received at COM1 to COM3(or 4), and bytes received at COM3(or 4) to COM1. So two ports would be running at 9600 baud.

It may be feasible for your application to control the gating of the DTR signal. That is, when it is in the pass-through mode it enables DTR resets. Also, it may be feasible to store a value in Persistent Memory that is used to decide what to do when a reset is received.

That's a good idea. I had only thought of gating all DTR transitions (by use of the first), which has the benefit that the ZX-24 could also be downloaded to without having to first set a DTR-enabling jumper.

But it would obviously be easier to simply use a ZX-24 output pin to gate the DTR in a specific mode. Hmm... maybe a command from the PC could also tell the ZX-24 to gate the DTR when ready to download to it.

[stevech]

I'm coping with the undesired toggle of DTR - which happens not only at boot-time in XP, but also each time the serial port is opened (including launching the ZBasic IDE) - in my PC anyway.

My scheme is to use the cause-of-reset flags in the VM. If it's not a power-on reset, I resume operation by getting the date/time from a hiding place I found in RAM and setting the clock. I save the date/time every one second. One could also save the state ID or vector for a user's state machine in the same way, to resume.

This is a hack. I'll switch to the DTR-less scheme when it works and I'll disconnect the DTR reset wiring.

Another XP problem I used to have is that XP probes all serial ports during booting - trying to find a serial mouse. When an embedded device is sending random data on that port during this "enumeration", XP would sometimes think there's a mouse on the port and then things got really wild. There is a registry edit to disable enumeration on a given serial port. Perhaps later versions of XP stopped doing this. Maybe because of these problems, or because a serial mouse is rarely used. It was also a problem for a serial port connected to a GPS receiver.

[dlh]

I'm coping with the undesired toggle of DTR - which happens not only at boot-time in XP, but also each time the serial port is opened (including launching the ZBasic IDE) - in my PC anyway.

It's not just XP. It happens on all Windows machines when VB opens the port. The VB default for the MSComm control is DTREnable = True. I set DTREnable = False as the default.

[Just Another Joe]

Thanks for the (unahppy) information about Windows (and VB) handling of DTR.

It sounds like Don's idea may still work; have an output pin gate DTR so it only reaches the CPU after one has sent a command to toggle the output pin?

Or, I think the idea was mentioned of using RTS instead of DTR. Does Windows also do funky things with this line?

[dlh]

Thanks for the (unahppy) information about Windows (and VB) handling of DTR.

It's not a problem when using VB. Just set DTREnable = False in the MSComm Properties window (or do it in code ). That eliminates the transition when your app opens the port.

[stevech]

DTR toggles when I open the ZBasic IDE. Does it use the same DLL that you guys are talking about for VB?

[dlh]

DTR toggles when I open the ZBasic IDE. Does it use the same DLL that you guys are talking about for VB?

I have no idea what the IDE is written in but I'm talking about what happens when the port is first opened not what happens when you call the DLL.

[dkinzer]

DTR toggles when I open the ZBasic IDE. Does it use the same DLL that you guys are talking about for VB?

There is a checkbox in the Serial Port Options dialog (access via the Options menu) that controls whether the device gets reset (i.e., DTR is toggled) when the serial port is opened. I think that this may be on by default.

The IDE does not use the ZLoad DLL but the code is very similar.