Announcement

Collapse
No announcement yet.

Serial Interface Problems

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

  • Serial Interface Problems

    Please note that I have a problem that I have isolated to the PowerBasic Compiler and/or linker.
    In short we use Handheld computers on our sales routes for sales and invoicing.
    We use DOS-based handhelds with pseudo-286 CPU's.
    We had been using a QuickBasic 4.5 application since 1994, developed inhouse until we ran into memory constraints and switched in 2000 all our applications to PB3.5.
    The nature of the handheld is that it uses an optical port for communication with the host for data upload and download. This is in our case redirected to a serial port, either COM1 or COM2.
    If we run a short PowerBasic pgm with PRINT "HELLO" then this optical port is disabled upon exit, and what is required is to reboot the handheld without running the PB pgm and directly go and start the communication program.
    A similar QB45 pgm with Print "Hello" would leave this optical port intact for the communication to take place.

    This is why I believe the problem is isolated to the Compiler/Linker.

    As such I have tested the various configurations available through PB3.5, enabling and disabling 8086/8088, 80286, serial, printer, etc...

    However this is extremely unscientific.

    What I would like is to know what overhead code is generated along with a simple PRINT "HELLO" statement.

    I hope this is not too vague, and someone can give me some information.

    FYI: The handheld in question is DAP Technologies' PC9800
    Thanks for any help, Samir Alamari


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

  • #2
    I've seen similar reports with PC104 embedded PC's... the most common successful solution is to install appropriate memory managers (HIMEM.SYS & EMM386.EXE).

    Please let us know if this helps!


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

    Comment


    • #3
      Hi Samir,
      I program for the DAP PC9500 in PB DOS 3.5. You might try disabling
      timeouts in the open statement like so:

      OPEN "COM1:19200,N,8,1,RS,CS,DS,CD" As #1 Len = 4096.

      Maybe there's some differences since the PC9800's a Windows
      machine, but it works on the 9500. I just completed an
      upload/download program for it yesterday. Anyway, good luck, and
      let me know how this turns out, please.


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

      Comment


      • #4
        Dear Lance,
        Please note that these devices do not have extended memory as such, and as a result any memory managers would not load in the first place.

        Dear Wyman,
        There are several models of the PC9800. This problem cannot be reproduced on a PC9500 because of the different design. The PC9800 one we are actually using is DOS-based.
        As for the communication, we actually rely on the Communication pgm supplied with the unit COM.EXE and it is powerful enough for all our requirements.
        Our problem is that it will not recognize the optical interface after running a PB35 EXE program, even if that pgm is a simple PRINT "HELLO"

        All,
        What I need is overhead code generated by PB35 with EXE file for a simple PRINT "HELLO" pgm.
        One of the interrupts is causing this malfunction.
        Again for QB45 this is not the case.


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

        Comment


        • #5
          You have noted that you experimented with all compiler & linker settings, but it does not solve the problem. PowerBASIC/DOS does not cause any problems of this kind with "proper" PC's, so it suggests that you could be facing a simple (in)compatibility problem.

          One thought does come to mind... have you tried switching off all unnecessary libraries from the runtime library ($LIB ALL OFF)?

          Note that if your real code will use the CHAIN statement, then the primary EXE will automatically include all library modules (regardless of the $LIB setting) since there is no way for the linker to predict which RTL functions may be required by the called PBC/EXE module, so the complete RTL is included in the EXE.

          IOW, if you solve the problem for a PRINT "HELLO" app, you may face the same problem with "real" code, depending on what it does.

          What interests me is what you plan to do to solve the problem, assuming you can establish which hooked Interrupt is the cause? I simply don't see a solution, since altering the RTL itself would be required. Either that, or you'll have to change the way the hardware works...

          FYI, the Interrupts that the PowerBASIC runtime library uses are described in the Users Guide (in the chapter on TSR's, IIRC. I'm sorry, bit I don't have my copy handy to give you a page reference).

          One more idea: does code compiled with FirstBASIC cause this problem too? You can download the shareware version from our FILES section if you wish to experiment.

          Do you or anyone else have any comments or ideas?

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

          Comment


          • #6
            I will take your points one by one.

            $LIB ALL OFF - Just tried this and received exactly same result

            To solve the problem - The device itself has a built-in set of device specific BIOS function calls, which are probably being disabled unintentionally by PB pgm. As such I would issue the appropriate BIOS function call to restore the settings.
            As a followup please note that I have issued the device-specific BIOS function calls for Restore to Factory Settings, and for enabling the Optical Port, and setting the appropriate communication channels, but none of these is restoring the functionality of the optical port to the status prior to running the PB pgm, and as such they are not 're-enabling' the optical port.

            As for the chapter on TSR's I am not able to locate it in the 2 manuals but will continue to look.

            As for FirstBasic, I have downloaded the compiler and made two PRINT "HELLO" programs.
            Unfortunately both gave identical behaviour to PB, disabling the Optical Port upon exit.

            I'm open to other suggestions or comments on the above

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

            Comment


            • #7
              Addendum

              FirstBasic-The two pgms were one with $LIB ALL OFF and the other without.

              Nothing restores the functionality of the Optical Port except a RESTART of the device.



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

              Comment


              • #8
                I'm sorry, but I'm fresh out of ideas.

                I'll ask R&D about this, but I suspect we are not going to be able to help you with this problem since PB/DOS works with all "normal" hardware without any problems whatsoever.

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

                Comment


                • #9
                  Actually, I've been having a similar problem with straightforward laptop PC's (standard serial-port connections, no infrared stuff). A PB/DOS 3.5 program containing the following code:

                  Code:
                  $COM 8192
                  ComHandle% = FREEFILE
                  OPEN "COM1: 57600,N,8,1,DT" AS ComHandle% LEN=2048
                  PRINT "COM port opened"
                  will "jam" at the OPEN statement - no error messages, no device timeouts. (I once left it sitting overnight to see if it would ever come back, and when I returned the next morning it was still "stuck"; it will apparantly wait forever for whatever condition it wants that it isn't seeing.) [CTRL][BREAK] will get me out of the program and back into the IDE, so I don't think the program has shot off into nowhere...

                  Further, once this occurs, the COM port is completely lost to me - exiting to DOS and then restarting PowerBASIC has no effect, and no other serial-port-using programs (like Telix or Procomm) can open the COM port either - they, too, get "stuck". This has happened on two different laptops - my Gateway Colorbook, and one of our company Dell laptops - and on an Ampro 4DXi PC-104 board. (But, interestingly, it never occurs on my own Dell Latitude XPi laptop.) For the Dell and the Ampro, a reboot is sufficient; the Gateway actually has to be power-cycled off and on again to get the port back.

                  A little experimentation has yielded the following information:

                  ----- The problem seems to be caused by the system at the other end of the null-modem cable sending bytes before PowerBASIC has executed the OPEN COM statement.

                  ----- The type of null-modem cable has no effect; I've tried both full crossover cables, and simple Tx/Rx/GND-only cables.

                  ----- The various OPEN COM handshake-control options such as DS0, CD0, etc. have no effect on the problem one way or the other.

                  ----- When the "jam" occurs, using the CALL INTERRUPT statements to query the BIOS services directly, as follows:
                  Code:
                  REG %AX, &H0300        '--invoke INT 14h, service 3
                  REG %DX, &H0000        '--  ("Get Comm Port Status")
                  CALL INTERRUPT &H14 '--   against COM1
                  PRINT HEX$(REG(%AX))
                  returns 61h in the AH register, and 00h in the AL register. According to my copy of "Using Assembly Language, 3rd Edition" (Allen L. Wyatt, QUE Corp., 1992, p.532) this corresponds to an "Overrun Error' in the line status register.

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

                  Comment


                  • #10
                    Ok folks, I've heard back from PowerBASIC R&D...

                    Firstly, R&D suggest that it is possible that the design of the hand-held could such that it is doing something non-standard with one or more interrupts, such as the &H2F multiplex interrupt that PowerBASIC uses to query the environment.

                    Unfortunately, R&D are unable to offer any suggestions as to a workaround or cure. They did note to me that there is a curious lack of technical data on DAP's web site, which does not help much!

                    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
                    mailto:[email protected][email protected]</A>
                    Lance
                    mailto:[email protected]

                    Comment


                    • #11
                      Samir,

                      What brand and version of DOS is running on the handheld computer?

                      Alan

                      ------------------
                      Alan C. Earnshaw
                      Information Management Systems, Inc.
                      http://www.infoms.com
                      Alan C. Earnshaw
                      Information Management Systems, Inc.
                      http://www.infoms.com

                      Comment


                      • #12
                        Gary,
                        It seems that our problems are similar in as far as the communications port is disabled following a PB pgm is terminated.
                        However, Lance is correct as my problem occurs even following a normal termination of a simple EXE pgm, that does not involve any communications routines. This does not happen on a normal PC.

                        Lance,
                        I have a PDF file containing detailed descriptions of the interrupts supported and used by the DAP unit.
                        Basically there are special handling of Standard BIOS interrupts
                        Int5H Print Screen Routine
                        Int10H Display Services
                        Int11H Equipment List
                        Int12H Memory Available
                        Int13H Disk Services
                        Int14H Serial Communications Services
                        Int16H Keyboard Services
                        Int17H Printer Services
                        Int1AH Real Time Clock Support

                        Extended BIOS interrupts, have been grouped into Int15H, and include functions for controlling and modifying the devices.

                        I can forward these PDF files if needed by anyone.
                        re AP web site---I agree

                        Alan,
                        the DOS brand and version is a standard MS-DOS v 6.22

                        All,
                        Thanks for the replies and inputs


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

                        Comment


                        • #13
                          Please email the file to Tech Support and I'll pass it to R&D, but please do not hold your breath for a solution.

                          Out of curiousity, have you asked DAP for help with this problem on their equipment? Surely they must have a Tech Support department?


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

                          Comment


                          • #14
                            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.

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

                            Comment


                            • #15
                              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.

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

                              Comment


                              • #16
                                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>
                                Lance
                                mailto:[email protected]

                                Comment


                                • #17
                                  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]
                                  :) IRC :)

                                  Comment


                                  • #18
                                    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]
                                    Mike Luther
                                    [email protected]

                                    Comment


                                    • #19
                                      The test program was built with $LIB ALL OFF.

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

                                      Comment


                                      • #20
                                        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]

                                        Comment

                                        Working...
                                        X