odd serial port problem

Discussion about the ZBasic language including the System Library. If you're not sure where to post your message, do it here. However, do not make test posts here; that's the purpose of the Sandbox.
Post Reply
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

odd serial port problem

Post by spamiam »

I have been using ports for a while, but this time it does not seem to work. I think I am missing something pretty basic. I am attempting to define COM1 and make it some arbitrary speed, but I am using 19200 for compatibility with the default speed settings.

After initializing everything, I use PutQueueStr() to send a string over COM1, but nothing comes through. If I use debug.print, then I get data both before and after I try to initialize and send data thru the queue.

What am I doing wrong?

-Tony

Code: Select all

Sub Main()

Const InputQueueSize As Integer = 10
Const OutputQueueSize As Integer = 40
	
Dim InputQueue(1 To InputQueueSize) As Byte
Dim OutputQueue(1 To OutputQueueSize) As Byte

	Call OpenQueue(OutputQueue, OutputQueueSize)
	Call OpenQueue(InputQueue, InputQueueSize)

debug.print "test"	

	Call OpenCom(1, 19200, InputQueue, OutputQueue)


call putqueuestr(OutputQueue,"1234")

call sleep (1.0)

debug.print "q count: ";getqueuecount(OutputQueue)
debug.print
debug.print "q size: ";getqueuespace(OutputQueue)
debug.print "status: ";statuscom(1)


End Sub
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Re: odd serial port problem

Post by dkinzer »

spamiam wrote:I think I am missing something pretty basic.
Perhaps this from the description of OpenCom():
If the specified channel is already open or if the
channel number is invalid, it has no effect.
In the past, this aspect of the operation was, erroneously, not performed. Basically, this means that you must first close Com1 before you open it again.
- Don Kinzer
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Post by spamiam »

OK, that makes sense. But for COM1, the port isn't actually closed, it just reverts to the default speed (19.2K) and the default buffers. If I haven't opened COM1 myself, then what buffers do I specify if I want to close it?

Just to try ANYTHING, I gave CloseCom() the buffers that I am going to use eventhough they are not associated with the existing COM1 stream. This worked.

Why do the buffers need to be specified in the CloseCom() command? Doesn't the program/compiler already know that info from the previous OpenCom() command? Since the buffers are not cleared, then it appears that they are not used for the closure.

Is this requirement to close the port before opening it something new? I have never done it before , and I never had a problem opening Com1 to my specifications before.

-Tony
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Post by dkinzer »

spamiam wrote:Why do the buffers need to be specified in the CloseCom() command?
ZBasic has that requirement only because BasicX does. In reality, nothing is done with the queue parameters so it doesn't matter what you pass. Unlike, BasicX, ZBasic will allow you to use zero to specify a "null queue". Consequently, you can call it thusly:

Code: Select all

Call CloseCom(1, 0, 0)
spamiam wrote:Is this requirement to close the port before opening it something new?
The documentation has always specified that you must close a channel before you can open it. As indicated in my earlier response, the VM failed to enforce this requirement. That's why your code worked previously but does not now.
- Don Kinzer
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Post by spamiam »

When did the VM tart to enforce the need to close the comport before opening it? This is the first time that I ran up against it, but maybe I did not update my compiler as often as I should.

-Tony
dlh
Posts: 395
Joined: 15 December 2006, 12:12 PM
Location: ~Cincinnati

Post by dlh »

spamiam wrote:When did the VM tart to enforce the need to close the comport before opening it? This is the first time that I ran up against it, but maybe I did not update my compiler as often as I should.
I think it was 2.5.0.
spamiam
Posts: 739
Joined: 13 November 2005, 6:39 AM

Post by spamiam »

dlh wrote:I think it was 2.5.0.
Ah, OK. That came out 6/08. I was hoping it was not substantially prior to that and I had simply not noticed for a year or 2.

-T
mtreat
Posts: 10
Joined: 27 November 2005, 16:17 PM

Post by mtreat »

I have had some software running for months in a pair of 1281s that uses one 1281 to send data to the other. I ungraded the firmware in them from 2.3 to 2.6 yesterday and I was not longer able to transfer serial data between them. After spending hours trying to figure a hardware problem I decided to reload 2.3 firmware back into the 1281s and they are now working flawless again.

I think there is more to this problem them opening and closing COM ports as I open the ports right in the beginning and don't do anything else but send and receive data.
Martin
dkinzer
Site Admin
Posts: 3120
Joined: 03 September 2005, 13:53 PM
Location: Portland, OR

Post by dkinzer »

mtreat wrote:I think there is more to this problem[...]
Your experiment clearly demonstrates that a difference between v2.3 and v2.6 is affecting the way that your program runs. Could I get your application code so that I can take a look to try to determine what it might be?
- Don Kinzer
Post Reply