Announcement

Collapse
No announcement yet.

Serial Interface Problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mike Luther
    replied
    Lance posted:

    The messages in this thread may be a little misleading. To be clear, PowerBASIC is designed to
    open a port and clear it, but in certain (rare) circumstances, PowerBASIC may fail to open the
    port if data is in the receive buffer.

    Do you actually have a problem, or are you just doing research?
    Ding, ding! I just may have learned the answer to a problem here! What you are
    telling us is that if, for example, I have a critical byte that is in the comm
    port for the little IR-MAN device I've never gotten working, it may be that the
    single byte that is there vanished just in the opening???

    I had to drop the research into IR-MAN a while back when I simply could not get
    PB 3.5 for DOS to open the port and see the few bytes needed. All that is ever
    sent in from the thing is a couple bytes right at first and then only two or
    three every time you push a button on the TV remote!

    The whole operation works perfectly in a native OS/2 terminal program such as
    HyperAccess for OS/2 or ZOC for OS/2 for test and development purposes. Yet
    when I've tried it with the PB comm routines with exactly the same needed
    port control parameters, it never initializes properly.

    I temporarily shelved the project because I thought that Ray Gwinn's SIO comm
    port drivers for OS/2, when used in a DOS-VDM session were failing to be able
    to process that one byte or so initial data in the buffer! I could see them still
    there in Ray's Poor Man's Line Monitor utility (PMLM) which provides for a dump
    of all traffic both ways across a port and a file of it all if needed. For the
    life of me I couldn't figure out where that initial byte or so was vanishing!

    Now, for what has been said, it may be that PB is actually flushing it down the
    drain on opening!!

    OK, if that is so, what do you suggest for a work around in this case? We need to
    note that in my case, all three other serial ports may be in use in any given
    instance of that same PB program at the same time. So it's not going to be an
    easy job to toss out PB and port operations in wide-spread use in the code at
    this point, nor do I want to!

    Any thoughts please?

    I have long ago and far away, some complete assembler port I/O code for this as
    part of what came out of Brady's books! That includes status line and up-down
    line level control and all too! However, I've found that using it in OS/2, while
    it can be done, isn't necessaritly all that nice if something blows up in the
    actual hardware connection or the attached port! PowerBASIC, for however it is
    written at the assembler level, has a far better chance for session recovery
    and port abandonement under those circumstances, than the hard way!

    Grin ..


    If this is why IR-MAN won't work for me and I can fix it, we have suddenly lept
    right up to the bedside with our 'manners'

    Thanks Lance.


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

    Leave a comment:


  • Michael Jung
    Guest replied
    @Tom Hanlin

    I would like to thank you for your help. Now i can open the COM and read the Data.

    Best regards, Michael Jung

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

    Leave a comment:


  • Tom Hanlin
    replied
    Try:

    OPEN "COM1:4800,N,8,1,RS,CS,DS" AS #1

    Yes, we expect to release a new version of PB/DOS in the future.


    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Michael Jung
    Guest replied
    Do you actually have a problem, or are you just doing research?

    @Lance:
    Yes i have a problem. In the Office we use GPS-Receivers and Navigation Software. To check that the GPS-Receiver does receive correct Data i use Hyperterminal from Win98. The Output is ASCII, but its not easy to read. So i want write a program which displays the data in a easier readable format. E.g. the number of Satelites, the Coordinates, the Date/Time, etc...
    But i fail at opening the com-port. I´m not very expirienced in programming the com-port.
    The GPS-Receiver does use only RXD and TXD, 4800b/s, no parity, 8 bits, 1 stopbit. I think that i does not open the com-port right.
    The GPS-Receiver start with sending data when he is connected to power, so the input buffer contains data when the program starts.
    With the following programm i want read a few lines from the Com-Port.

    print "Open Com-Port"
    open "com1:4800,n,8,1" as #1 len=256
    print "Com-Port open"
    line input #1,a$
    print a$
    line input #1,a$
    print a$
    print "Com-Port closed"
    close #1

    At Com2 is my modem connected. When i start the program, it failed at the open command. When i open Com2 and the modem is turned off, the program runs to the end.

    I´d tested some Parameters at the open command, but i´m not familiar with cs, ds, etc,.. I think that the handshaking should be turned off, but i don´t no to do it right. I hope that you could help me.

    Best regards, Michael Jung

    P.S. Is for the Powerbasic DOS a new version in plan?

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

    Leave a comment:


  • Lance Edmonds
    replied
    The messages in this thread may be a little misleading. To be clear, PowerBASIC is designed to open a port and clear it, but in certain (rare) circumstances, PowerBASIC may fail to open the port if data is in the receive buffer.

    Do you actually have a problem, or are you just doing research?



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

    Leave a comment:


  • Michael Jung
    Guest replied
    [QUOTE]Originally posted by Lance Edmonds:

    Gary, your observation is correct - PowerBASIC may not open a port that already has data in the input buffer - R&D have noted this for investigation. However, it is not related to Samir's problem...

    @Lance:
    Hello!

    I have a question about open a (i use PB 3.2) COM-Port which has data in the input buffer. The application i want to write should read data from a GPS-Receiver, which send every second data to the COM-Port. How can i disable the FIFO-Buffer and clear the memory of the input buffer?

    Best regards, Michael

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

    Leave a comment:


  • Samir Alamari
    Guest replied
    Lance,

    I do appreciate all the info and assistance that you have extended to me. I have emailed DAP technologies with this thread in hopes that they may have something to contribute.

    Thanks again to everyone

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

    Leave a comment:


  • Lance Edmonds
    replied
    At app start-up, the RTL queries the hardware to work out what sort of card and environment the app is dealing with. AFAIK, $LIB ALL OFF does little or anything to alter this manditory initialization of the RTL.

    BTW, the results of these interrupt calls are used to initialize interval variables such as pbvHost, pbvScrnBuff, pbvScrnApage, pbvScrnCard, pbvScrnCols, etc.

    See Internal Variables in the on-line help for more information on what the RTL provides.

    Regardless, if there is a bug anywhere, it's most unlikely to be in PowerBASIC, and at this point there is little I/we can do... sorry!

    Also, your request for more information on the unsupported interrupts of your hardware is beyond the realm and scope of PowerBASIC's [free] Tech Support. You may wish to contact our office and request [paid] Priority Support, giving you the level of help you need with your compatibility problems.

    Thanks!


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

    Leave a comment:


  • Samir Alamari
    Guest replied
    Sorry about the delay, but Friday is our weekend.

    Lance re:R&D. Is it possible to have a little more information as to the particulars of the non-supported interrupts. Also, as Ian and Tom have noted, all libraries have been disabled, therefore what are the interrupt calls issued by PB actually doing.

    Lance re:Normal PC. If this is your definition of a normal PC, then please note that this DAP unit is the most normal that I have encountered and has proven reliable and consistent. We also have not previously had any optical ports problems, and as you have seen from the PDF files, they have extensive interrupt support, and the display though limited is in-line with most other DOS-based applications. The complete PB application itself has been running for the past few months on a 24-hour basis, using interrupt calls and display routines, as well as TSR's and IR/serial/parallel printing. This actually proves that his is a normal PC. We have no problems, except that upon exit the optical port is totally inactive. Granted we may have to live with this reboot requirement, but both DAP and PB are a match made in heaven as far as I am concerned. On my wishlist however is to iron out this bug, and this is why all you guys' input is so valuable.

    Wyman re:9500. The complete application, is actually running without problems on both the DAP PC9000 and the DAP PC9500. Both however are design-wise totally different from the PC9800, and as such the UART setting (through COM S) is not there.

    John re:CGA. I have tried this just now again with and without $LIB ALL OFF, and have received similar results.


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

    Leave a comment:


  • John Kovacich
    replied
    Since R&D has identified some interrupts which may not be supported
    by the CGA emulation, would a simple basic program which does not PRINT
    be able to terminate without locking the com port?

    A$="Hello World"
    END

    ------------------
    Thanks,

    John Kovacich

    Leave a comment:


  • Lance Edmonds
    replied
    Thanks Gary, I'll pass this along.

    BTW, my definition of a "normal" PC is one that does not have problems with optical ports, does not have limited interrupt support, and does not feature a CGA-only display.

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

    Leave a comment:


  • Gary Akins
    Guest replied
    Well... define "normal PC"? Granted that laptops sometimes have odd hardware inside them when it comes to built-in modems and such, I can't believe that their serial-port hardware is that abnormal - and the Ampro 4DXi is, to the best of my knowledge, a completely "normal" 486DX/66 PC that just happens to be in a PC/104 form factor. (Given that PB/DOS's strengths - rapid development of small, fast programs in a DOS environment - make it a natural fit for embedded systems, it might be worth y'all's while to have R&D play with a couple of PC/104 boards like the Ampros if the problem isn't replicable on a "real" desktop PC.)

    Anyway, the conditions which are causing the problem, at least in my current setup, are as follows:

    The project under way is indended to receive data files from the embedded system, using a YMODEM implementation. The receiving system, at one end of the serial cable is a Dell Optiplex G1, running Windows 98. The actual user application we will send out with the instrument is an application built in PB/DLL 6.0 (which I'm quickly coming to love, BTW, even though I thought I was gonna hate Windows programming until I started using it ), although to test the YMODEM implementation I wrote I've also been using Telix (a DOS program) inside a DOS box.

    The instrument which will actually be sending data is based around the Ampro 4DXi - a 486DX/66-based PC/104 computer with 4Mb of memory; the test system has been using Caldera DR-DOS 7.03, though we're considering switching to Datalight ROM-DOS for shipping units. For software testing, I've also been using a Gateway Colorbook (486SX/33, 20Mb of RAM, IBM PC-DOS 6.3) and a Dell Latitude XPi120 (Pentium 120, 16Mb RAM, IBM PC-DOS 2000). The software is written in PowerBASIC/DOS 3.5.

    The exact sequence of events which cause the lockup here on my bench are as follows:

    (1) The two systems (the Dell, and one of the test systems) are connected together via a null-modem cable. (A full-crossover was used initially, though this problem has also manifested itself using a simple 3-wire, Tx-Rx-GND-only crossover).

    (2) The PB/DOS IDE is brought up on the test system, and the source is loaded. In this case, it is just a simple "test wrapper" around the YMODEM functions being written. It is not yet run.

    (3) On the Dell, either Telix is run in a DOS window, or the PB/DLL IDE is brought up and the user-application source is loaded and run.

    (4) Telix or the user-app is instructed to begin a YMODEM-batch download. As per spec, the programs begin sending a single "C" to the test system every few seconds, to indicate their readiness to receive data.

    (5) [F9] is pressed on the test system, to compile and run the YMODEM test app. PB/DOS compiles and runs the app - then freezes at the OPEN COM statement.

    Note that if (4) and (5) are reversed - start the test app first, then start the receiving program - everything proceeds as expected.

    This problem is observed on both the Gateway Colorbook and on the Ampro 4DXi - but not, interestingly enough, on the Dell Latitude XPi120. It has also been observed on the Ampro 4DXi that the full, precompiled embedded application (i.e. an .EXE file run from AUTOEXEC.BAT when the unit is powered up) will also fail to open the COM port if a GPS unit or some other transmission source is connected to the COM port during boot (presumably because it, too, is putting data in the COM port before the program has started.)

    The full-blown application program is probably too large and complex for your R&D guys to want to play with (plus, it relies on a ton of external graphics and data files), but if it'll help I can send you my YMODEM library PB/DOS source, plus the "test wrapper" and the PB/DLL source for the user app. I don't think I'm doing anything all that unusual, though - especially since the only lines in the test wrapper that have a chance to execute are the three lines mentioned in my previous message...

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

    Leave a comment:


  • Lance Edmonds
    replied
    On the side-topic that has surfaced in this thread (problems opening a port that has data in the RX buffer):

    I've now spoken to Bob Zale (head of R&D, and who personally wrote the PB/DOS compiler) and he has told me that PB/DOS is designed to empty the receive buffer when the port is opened.

    Now. Can anyone help with a way of getting this problem to show up at will on a "normal" PC, so we can assist R&D in their research into the port open failure problem? If we can give R&D a set of conditions that show up the problem, we should be able to get the problem fixed (assuming it is actually a problem! ).

    I've written a _lot_ of modem & serial communication applications (PBFax, et al), and I have to say that I've never come across this type of problem myself, nor even heard of it before this thread started.

    However, a _vaguely similar_ problem can show up when running a DOS app under Windows if the COMxAUTOASSIGN in SYSTEM.INI (or is it WIN.INI? - I forget!) stops applications from sharing a port correctly when the port is closed. Obviously this particular case is out of control of PowerBASIC, so lets not get sidetracked please!

    Any takers?

    Thanks!



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

    Leave a comment:


  • Wyman A Belts
    Guest replied
    I write stuff for the 9500 (an earlier version of Samir's
    Handheld with DOS 5.0) which is CGA also and it works fine. One
    thing Samir, do you have the UART set for Auto in the setup program?
    Just a wild guess, but I keep all our "bricks", as we call them,
    in auto mode.

    ------------------
    [email protected]

    Leave a comment:


  • Tom Hanlin
    replied
    The test program was built with $LIB ALL OFF.

    ------------------
    Tom Hanlin
    PowerBASIC Staff

    Leave a comment:


  • Mike Luther
    replied
    And for note Lance .. and others..

    Gary, your observation is correct - PowerBASIC may not open a port that already has data in the
    input buffer - R&D have noted this for investigation. However, it is not related to Samir's
    problem...

    ------------------
    Lance
    PowerBASIC Support
    Observed in remote site telecommunications applications where PB 3.5 programs are asked
    to open a port in OS/2 sessions that have been contaminated by any previous comm port
    failure!

    This also happens to be one way to totally dishevel an OS/2 system, still! If a previous
    port applicatopn has terminated improperly, leaving an "ownerless" thread, with data still
    in the object space that was assigned to the 'bufffer', there seems no possible way I have
    ever found yet in OS/2, to ever recover the use of it until you re-boot!

    Further, under certain circumstances, if it does, somehow, it may, at times, produce a
    SYS3175 or other trap error, and you need to realize that the resultant trap error will then
    float up to the top of the Desktop in OS/2. At that point, there is absolutely no way
    that I've ever found that any keyboard I/O can ever clear anything without being on-site
    to do it. Only the *LOCAL* keyboard will clear that ring level screen message! So, if
    you obtain this type error in OS/2, and the system is a remote system, even one with full
    remote Desktop access, such as HyperAccess and HuperHost, even in an IP instance of it as
    a VPN, you will still have to either go to the site, or, in some fashion, hardware reboot
    the site remotely to recover it!

    Now, just because I can't break this, and 'MOLE" and other task killers can't break it
    that I have tried, does not mean that it can't be done. It just means I'm not educated
    enough to know how to do it! Chuckle.

    Obviously, a 'one track mind' pure 'DOS' operation, isn't quite the same thing as the
    pre-emptive multi-tasking game, but the issue is there, and far more distructive, to my
    experience in OS?2, than it may be otherwise.

    It is *NOT* a fault of PowerBasic and PB 3.5, as far as I can tell. But trying to
    open it can lead to the long trip on the road out to reset things! It would be a
    kindness to those who face it in OS/2, if PB's R&D could somehow, also know that a
    port shouldn't be, what do we say, 'accessed', if it isn't empty to start with?

    Strange wish! Kind of like, "How do I get to love you if I've never met you?"
    Secret soy sauce? But I've been told I'm not very 'objective' about these things!
    Can anyone be? Grin!


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

    Leave a comment:


  • Ian Cairns
    replied
    Lance,
    Does R&D say that these interrupts are included in the executable
    even if the Options/Compiler/Linker/Graphics is set at off,
    or if the ../Linker/Video Cards/VGA is set to off?
    Curious in Canada,

    ------------------
    [email protected]

    Leave a comment:


  • Lance Edmonds
    replied
    R&D have perused the PDF's... here is what they came back to me with:
    In a PRINT "Hello" program, PB/DOS does make a number of interrupt calls
    that are not supported by the PC9800. It is not clear what the results would
    be. These are INT 10h video calls for retrieving EGA/VGA information:
    functions 1009h, 1200h, and 1A00h. The PC9800 emulates CGA graphics.
    ------------------
    Lance
    PowerBASIC Support
    mailto:[email protected][email protected]</A>

    Leave a comment:


  • Gary Akins
    Guest replied
    Lance Edmonds wrote:
    Gary, your observation is correct - PowerBASIC may not open a port that already has data in the input buffer - R&D have noted this for investigation. However, it is not related to Samir's problem...

    OK, I just thought it might have some bearing because of the seemingly similar end result, of no other program being able to open the port afterwards...

    While we're on the subject, though, is there any known workaround for this? A BIOS call, or bytes INP/OUT'ed directly to the COM-port hardware itself, that can force it back into a condition that PB/DOS can open? We're getting ready to ship an embedded-systems product driven by a PowerBASIC program, running on the above-mentioned Ampro 4DXi, and one of the things that it needs to be able to do is to have a GPS receiver plugged in to one of the COM ports... and many these off-the-shelf GPS systems (we don't have any control over what GPS device they use) transmit data continuously.

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

    Leave a comment:


  • Samir Alamari
    Guest replied
    Lance,
    I will email the file, as for DAP tech support, I have actually not contacted them as the problem is isolated to PowerBasic only, and is not evident in other compilers/linkers.

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

    Leave a comment:

Working...
X