Silly Com1 question

[sturgessb]

Im sure a stupid question, but i've been through docs and cant find the answer.

How do I adjust the speed of com1. Im using the following but its not changing it from the default of 19200

Call OpenCom(1, 9600, iq, oq)

Im calling this as the first item in Main()

I can change it using Option Com1Speed 9600 , but not inline code. What am i doing wrong?

[dkinzer]

I can change it using Option Com1Speed 9600 , but not inline code.

The second sentence in the Discussion section of the OpenCom() documentation says: "If the specified channel is already open [...] it has no effect." The point that you may be overlooking is that Com1 is automatically opened for you prior to Main() being executed. Consequently, if the first statement in Main() is an OpenCom() call, it will necessarily fail.

One other item that requires attention is that the queues supplied to OpenCom() must be initialized (using OpenQueue()) so those calls must precede the OpenCom() call. The usual way of doing this is:

Code: Select all

Call OpenQueue(iq, SizeOf(iq))
Call OpenQueue(oq, SizeOf(oq))
Call CloseCom(1, 0, 0)
Call OpenCom(1, 9600, iq, oq)

It may be important to note that this will result in some wasted RAM because the default rx and tx queues will still be present but no longer used. You can reuse the default queues this way:

Code: Select all

Dim rxQ() as Byte Based Register.RxQueue
Dim txQ() as Byte Based Register.TxQueue
Call CloseCom(1, 0, 0)
Call OpenCom(1, 9600, rxQ, txQ)

On VM mode devices, you can't change the size of the default queues so if you need larger queues you'll have to use the first method shown above. On native mode devices, you can specify the sizes of the default queues using the directives Option TxQueueSize and Option RxQueueSize.

[sturgessb]

Thanks Don!

what is the default queue size?

[dkinzer]

what is the default queue size?

The table below gives the current default queue sizes. Note that the data capacity of a queue is 9 bytes less than its size.

[table][mrow] Device[col]rx Queue[col]tx Queue
[row]VM mode[col]54[col]13
[row]native mode[col]50[col]25
[/table]

[sturgessb]

Ok, another dumb question.

If Com1 and Com2 are hardware channels, why do console.write and console.read cause delays?

Also, echo is on by default, I can't see how I turn that off?

RTFM eh!

Ben

[dkinzer]

If Com1 and Com2 are hardware channels, why do console.write and console.read cause delays?

Short answer: because the serial transmission rate (baud rate) is not infinite.

Any call that adds data to a queue (which Debug.Print and Console.Write do) will incur a non-zero delay. If the queue has sufficient free space for the data being added, the delay will be relatively short. This time is required to copy the data to the queue and then adjust the queue management data elements to indicate the presence of the new data.

If the queue does not have sufficient free space, the routine must wait until there is. That wait time depends on how long it takes the queue's "consumer" to remove data from the queue. In the case of an output queue associated with a serial port (whether hardware- or software-based) the wait time will typically be 10/baudRate seconds for each byte.

[sturgessb]

ok that makes sence.

I can't seem to figure out, or find any info on how to turn echo off?

Thanks for your patience!

[dkinzer]

Also, echo is on by default, I can't see how I turn that off?

Register.Console.Echo

[sturgessb]

yeah I did try that and it wasnt working, but as I thought they were like Options, I was trying to set outside Main().

no probs, all sorted now

[dkinzer]

I thought they were like Options, I was trying to set outside Main().

The Options section of the manual contains an exhaustive list of the compiler directives/options that are available. Some of them overlap with compiler command line options (which can be placed in your .pjt file, preceding the list of files in the project).

There is a lot of information to digest; too much to read and comprehend all at once. However, you would probably be well served to take the time to leaf through the manual just to get a feel for what is available.

[sturgessb]

I am having problem with receiving serial data on com1.

I have simple VB app that send out the following string every second.
"17,1200,2222,3333"

And then a simple app on the zx that just does Console.ReadLine every second. The echo coming back from the zx is as follows

17,1200,2222,3333
17,1200,2222,3333
17,,2222,3333
17,1200,223
17,1200,2222,3333
17,1200,2222,3333
17,1200,2222,3333
17222217,12003
17,1200,2222,3
117,1200,222217,1203
17222,3333
17,1200
17,1200,2222,333
17,1,3333
1700,2222,3333
17,,3333
17,1200,2222,3333
17,1200,2222,333317,1200,22


As you can see its not quite the
17,1200,2222,3333
17,1200,2222,3333
17,1200,2222,3333
17,1200,2222,3333
etc etc, I was expecting.

I have tried at different baud rates, always the same. Queue size is more than adequate at 100bytes.

I've used a software serial port logger, and that indicates the data going out from the VB app is sound.

Any ideas?

Ben

[dkinzer]

a simple app on the zx that just does Console.ReadLine every second.

My conjecture is that it is a synchronization issue. TO test this theory, modify the VB program so that it sends a line of data only after receiving a cue from the ZX.

[sturgessb]

Yeah I tried that, was somewhat better but still had glitches 30% of the time.

However it seems that it is related to having the code in a secondary task. If i move the code into the main task, it works fine.

Strange. Ill post back when i have more info

[sturgessb]

Yeah problem lies with the pulsein I have running in another task. If I have these pulse in calls running, the console.readline in the main task does not grab all bytes.

Any way around this. Should not be a huge problem, as my use of pulsein is only a short term solution.

Ben

[dkinzer]

Any way around this.

Not if you must use PulseIn(). The problem is that in order to collect accurate data on the pulse, interrupts are disabled for the duration of the call. If that period approaches about 20 bit times (two character times) or more, serial input characters will be missed. Using a lower serial rate may mitigate the problem.

Depending on the specifics of your application, you may be able to use InputCapture() instead of PulseIn(). The difference is that whereas PulseIn() is implemented entirely in software, InputCapture() uses hardware of the AVR chip to time the high and low segments of the input signal.