Problem with com program

[Bob Haynes]

Hello, I'm new to power basic and I was given the task of
fixing this program!!
The program is connecting to a serial buffer device and
polling records out of the device into the program.
It appears that the code is making a clean connection and
the data is comming into the program.

Here is the code that I have a question about...

Open "COM1:1200,N,8,1" AS #2
Open "CALLREC" For Append As #3
DELAY 3
Rem
Rem ********* BEGIN DATA COLLECTION ***********
Rem
MAIN:
If Loc(2) > 20 Then
'perform logic
End If


Through debugging my program using an evaluate on Loc(2), I
noticed that the value is '?????'

Does anyone know of any reason that Loc(2) is never receiving
any of the data from the buffer device?

Thanks so much for your assistance.

Bob



------------------

[Mike Burgett]

Bob.


This is how I detect input from a bar code reader on com 1


COM(1) ON
ON COM(1) GOSUB CardInput


CardInput:

COM(1) OFF
INPUT #1, InData$
:
: Handle data here
:
COM(1) ON
RETURN



Perhaps this may help you.




------------------
Michael Burgett

[Lance Edmonds]

LOC(n) is not a variable, but a native PowerBASIC function -- therefore you cannot "watch" its value directly by placing "LOC(2)" in the Watch Window.

The solution is to assign it to a normal [integer class] variable and then add that variable to the Watch Window.

------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Lance ..

Can you offer any tips on how to handle initialization routines which
involve only passing one byte out the port and receiving one byte back
in to signal initialization?

I realize this is a possible issue with OS/2 and how OS/2 handles the
comm port routines as a DOS-VDM, or at least could be. It doesn't have
to be an issue with PowerBASIC at all. But in this case, possibly, and
in mine for sure, a device like the IR-MAN controller which is this way
has been a problem for me with the standard comm port routines in the
DOS-VDM's. Somehow, just mashing one byte out the port to start things
and getting one byte back in to signal success for initialization was
a problem when I was working on this many months ago.

Using Poor Man's Line Monitor for OS/2, PMLM, which is a distributed tool
you get when you license Ray Gwinn's SIO and SIO2K comm port substitution
drivers for OS/2 get us somewhere. This tool splices itself in the I/O
channel for a given port. It lets you see every single byte and the order
of the cascade of the data, both in and out, for the investigated port.

Further, with the licensed version, you get a complete dumpable disk
file with the data stream and sequencing in it for debugging and
reporting purposes. The disk file so produced does not require any
licensing to use the special reader or reader-printer which I am free
to distribute as a DOS tool for troubleshooting purposes.

Specifically, in this one out and one back in scenario, I can see
the byte proceed out to the UART in the trace work from the standard PB
3.5 comm routines. But I cannot see the return byte come back in from the
UART that shows that the device has initialized! Thus the program does
not really 'know' that we are ready or not to work, even though it will
work if you second guess things and begin to use the IR-MAN. It's seemingly
an issue about buffering through the UART for just one byte at a time each
way, for receive time, it seems.

I can use a native terminal program such as ZOC for OS/2, for test
purposes in native OS/2. Using ZOC the exact same send routine, byte
for byte and all, plus receive for the inbound byte, PMLM *DOES* show up
that one byte return in the PMLM trace runs. We get to see initialization
results just fine.

Now .. if I use a terminal program for DOS, such as COMIT, I can see
the exact same good results, even in the same DOS-VDM which we are
using for PB 3.5 development for this tool enablement in my program
suite. This, somehow, I have the as yet to be proven feeling that
this is, somehow, related to the way PB handles one byte data strings,
in relation to the INBOUND return byte, a single byte, as to LOC(#)
which is under discussion here. Somehow, it seems that LOC(#) does
not return anything for just one byte when just one byte comes back
in to you.

Although I have the ability to actually touch the hardware in OS/2
DOS-VDM's, I have avoided that in all my comm port work so far. If
I get into the IN/OUT game for ports, I could, I think, solve the
problem. But that is *NOT* the way to plan for future portability
for WIN whatever, nor LINUX, nor really, for even native OS/2 in whatever
way the source might get to these platforms.

For example, even though the old MIcrosoft PB7 compiler will produce
both DOS and Native 16 bit OS/2 executables, one of the few things that
you had to avoid was the use of IN/OUT functions for ports. That direct
port function was not usable in native OS/2, nor recommended at all
that you use it in DOS-VDM's either. The use of OUT with nowhere for
the data to go or a failure in the I/O routine is one DARNED good way
to hang an OS/2 session or DOS-VDM session under OS/2, I assure you.

Even OS/2. as wonderful as it may be, has nice neat ways to bring things
to a halt, grin!

OK .. How can I investigate this, returning all these months later
to the IR-MAN development, with LOC(#) and so on here? Is this, say,
an issue where flushing the buffer wasn't/isn't possible for just one
byte, when we are using an ON LOC(#) do this approach?

Obviously the cow is somewhere in the pen, ready to come down the
chute. even though there is only one cow in the trailer! Chuckle.

I really would like some guidance and discussion of how to work at this,
even to the extent that one MIGHT be able to do this with in-line
assembler, say AFTER the port has been opened for high level use?
Persish the thought! But, heck, as a conditional compilation, come time
to do this in LINUX from common source, with PowerBASIC for LINUX,
some discussion now over how to write this would sure be wonderful.

At the same time, I think it actually might help the original poster
to perhaps debug his routine for a bar code scanner! In a way, what
he is doing and what I tried to do, and failed at, months back,
seem strangely, perhaps, related?

Again, I'm not saying PB is at fault. I'm just asking for pointers
on how to research this issue and find for sure what is happening.
It is time to finish my embedded system interface for in-room operations
which does not even have a normal keyboard, in normal use.

Thank you for any time given to this.. and your thoughts.

------------------
Mike Luther
[email protected]

[Clay Clear]

I could write you a very simple function to put the byte OUT the
port (provided it is serial port 1-4), using the DOS 14h INT.
However, reading a byte IN is problematic (or any number of bytes).
Back when my BBS had remote login capability, I was experimenting
with writing my own COMM functions (not out of dissatisfaction
with PB's functions - I just wanted to "play"). But I could never
get it to read IN data from the remote end. Putting data OUT the
port was easy. I *believe* the problem with reading data in was
caused by the fact that the serial port used a 16550 UART. As is
the usual, my machine uses the serial port interrupts for processing
data. On the otehr hand, the INT 14h services I was using use
BIOS polling. Based on that, I am surpried that even the data OUTPUT
worked. But, because it worked, it's quite possible that I was using
bad code to read the data in.

Would you like for me to rebegin these endeavors? If you answer "yes,"
also specify whether you want the one byte that is sent/received
to be processed as a numeric byte, or as a one-byte string. You may
mix them, one for send, one for receive, if you want.


------------------

[Clay Clear]

Just did some reading in Ralf's Lists. It turns out that the INT14h
service that reads data in from a serial port will always fail if
the DSR line is (or is not?) asserted. It will do this even if
the service that returns port status says that data is ready. So,
that could have been the cause for failure in my way-back coding.
I do not know how to overcome this. However, Mike, if your proggy
uses a FOSSIL driver for the port, then it would be a piece-of-cake.
My FOSSIL procedures ALWAYS worked (provided you are using port 1-4).


------------------

[Clay Clear]

Disregard, Mike. I just read MOST of your message, this time, and
now see that you need the one byte functionality for OS/2. I do not
know how to program for that OS.


------------------

[Lance Edmonds]

I do recall going down this exact path with you before Mike -- IIRC we agree the problem was the port state as set by that hardware device?

If that is the case, then the solution will probably have to be hardware too... make an RS232C adaptor lead that isolates all but pins 2, 3, and 5. Then adapt your code to ignore all handshaking, etc.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Mike Luther]

Thanks to both of you Clay and Lance for your time and thoughts.

Clay .. you're right on target as to what I've done up to now. It
isn't getting the data out the port but recovering the one byte in
which is the problem. And yes, the 16550 series is involved. You
know, it never even crossed my mind to try a FOSSIL driver! I'll
think that through carefully. Where would that lead in a move to
LINUX if that ever happened?

Lance .. Your memory is quite correct and what happened is that
based on the work load for other more important things, the project
got shelved until other work was done. However, your reduction to
a simpler line status connection is new and thoughtful. I'll take
your suggestion and see what happens if I strip off the hardware access
except for those pins. It never dawned on me that the only way to
solve this might be to reverse the thought that we worry, worry, worry
that serial cables have the right wires in them to maximize data flow.

From both your comments, y'all are coaxing me back toward the world of
assembler for this task. You know, that whole possibility of having
to use assembler on this and not being able to use higher level code
from PB never crossed my mind, despite the fact that I'm already using
a complete assembler operation for all the ham station keying and
relay ontrol functions! Gee, I haven't touched all this and it is
still in use here today since I wrote it in the late 70's based on
Heathkit's REMARK magazine on assembler for the 8250 UART with my
old H89 computer and added sound monitoring in real-time with Robert
Jourdains's help from, "Programmers Problem Solver for the IBM PC,
XT and AT." (!)

BTW .. to the original poster and others interested in the world of
assembler for comm port work, you really ought to try to find that
Jourdain book, a Brady Book. It is a wonderful resource on all this.

But, a MASM .OBJ library yet? You guys really know how to make an
oldtimer sweat 'is own code! Gulp ...

In short, consider this a low level operation that it is, just use
the relay control issues for telegraph code and try my existing code
for it. Bonus byte! If the telegraph output functions work and I
can just add the look for the return string byte snatch, I'll get
the benefit of the existing mirror image of the tone for the action.

I could use the existing PC speaker code for the monitor tone for key
press prompts, altering the pitch for confirmation that the IR-MAN
system has acted on a request. Use the existing beep tones for that
from integrated assembler libraries I wrote back in the late 70's for
telegraph work still working today in OS/2 hosted systems. The user
would soon figure out if you hear only one tone, things ain't no good
in controller land. It takes two to tango!

But again. Where does that leave me for LINUX in the future as it
will be opened to me with PowerBASIC for that operating system? Will
we be able to use the same in-line assembler techniques in PB for
LINUX, for example?

And back to the original issue. OK, So I have opened up the port for
the really needed text based I/O for program use across the IR-MAN
port with conventional higher level PB techniques. You know, OPEN for
this or that.

Are you saying that I could do this single byte initialization stuff
with assembler, despite the fact that we have that port open the other
way as well?

I thought it was bad business to mix port I/O techniques between the
world of high level and low level tools. But is this a wrong notation
if you already have the port open at high level? Can you, as well
chunk this or that out of it and in from it via low level tools as
well ... because PB will simply gloss over it?

Is this the equivalent of the Ziploc Bag commercial, "A tiger won't
eat what a tiger can't smell!"

Puppy scratching ear here \? Not really wanting to get eaten by the
commuications tiger.


We get stuck in our own ruts. It often takes outside overview to get
the wagon turned a new direction.




------------------
Mike Luther
[email protected]