BasicX to ZX-24 Conversion

[pdubinsky]

Howdy, Folks,

I have some old code that was written years ago for the Basicx-24 and it works fine on the BX-24. The software on the BX-24 makes requests on COM1 (8,N,1,19200) of a PIC16 and the PIC16 responds. Works fine on the BX-24 so I tried to run the same code on a ZX-24. It compiled with no errors but the app failed.

After some poking about, I found that the requests were not leaving the COM1 output buffer. I had been using a PutQueueStr command to feed the COM1 output buffer. I tried PutQueueByte and that failed also. The only commands that work are Debug.Print and Console.Write.

Am I missing something?

TIA,
Paul

[dkinzer]

I had been using a PutQueueStr command to feed the COM1 output buffer. I tried PutQueueByte and that failed also.

It sounds like you are opening Com1, specifying new input and output queues. If so, you must close Com1 before you open it again. If you don't, the re-open will be ineffective and nothing that you add to the output queue will be sent.

[pdubinsky]

Thx, Don. That did it. Did I miss this in the manuals? (Or are my manuals out of date?)

Thx,
Paul

[dkinzer]

Did I miss this in the manuals? (Or are my manuals out of date?)

The caveat that a serial channel must be closed before being opened again has been in the documentation for OpenCom() for quite some time. However, due to an implementation error in the VM, that specification was not enforced until v2.6.0.

I have reviewed the behavior of BasicX in this regard and I have concluded that requiring the explicit call to CloseCom() in inadvisable. We have modified OpenCom() to automatically close a channel before proceeding with the open process. The documentation will also be updated to remove the caveat.

Even with this change, however, some care needs to be exercised when re-opening a serial channel if data had been previously sent. The call to re-open should be delayed until StatusCom() indicates that there is no data remaining to be sent.