Announcement

Collapse
No announcement yet.

Serial Interface Problems

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

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

    Comment


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

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

      Comment


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

        Comment


        • #24
          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
          Thanks,

          John Kovacich
          Ivory Tower Software

          Comment


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


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

            Comment


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

              Comment


              • #27
                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

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

                Comment


                • #28
                  [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

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

                  Comment


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

                    Comment


                    • #30
                      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?

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

                      Comment


                      • #31
                        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

                        Comment


                        • #32
                          @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

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

                          Comment


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

                            Comment

                            Working...
                            X