Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#11 Incompatibility with java 1.4.2 commapi?

closed
nobody
None
5
2007-05-29
2007-05-11
Mario De Weerd
No

I had the following setup:
1) SuperWabaSDK
2) j2sdk_1.4.2_14
3) Installation of java commapi for windows.

Use of 'SerialPort' in SuperWabaSDK that in turn uses the commapi.
All indicates that what I did is correct: the virtual port is opened, etc. When opened, I can not open the port again in another windows program.

However, the java program stops when writing to the port. I tracked that using the Omniscient Debugger.

After many trials, I finally detected that another real port (my modem) works correctly with the port.

I have tried changing the settings of the virtual port, but that did not help.

The virtual port worked occasionally with the commapi, but that is difficult to repeat.

My windows version is XP Service Pack 2 and other patches (up-to-date).

I do not know what the problem is, but I guess that com0com is not behaving as the real port.

Discussion

  • Logged In: YES
    user_id=918965
    Originator: NO

    > However, the java program stops when writing to the port.

    It's possible because the application on other paired port is not ready to
    receive data (or two programs use different flow control settings).
    See also last FAQ in ReadMe.txt.

    > I do not know what the problem is, but I guess that com0com is not behaving as the real port.

    The com0com emulates two com ports connected by null-modem cable.
    Did you tried your program with two real com ports connected by real null-modem cable?

     
    • status: open --> pending
     
  • Mario De Weerd
    Mario De Weerd
    2007-05-11

    • status: pending --> open
     
  • Mario De Weerd
    Mario De Weerd
    2007-05-11

    Logged In: YES
    user_id=149951
    Originator: YES

    |> However, the java program stops when writing to the port.
    |
    |It's possible because the application on other paired port is not ready
    |to
    |receive data (or two programs use different flow control settings).
    |See also last FAQ in ReadMe.txt.

    The problem happens under different conditions, including when the other port remains unconnected. Baud rate emulation and overflow emulation is also inactive.
    Another virtual port emulator I found does work under the same setup.

    Also, the port access from within the application is supposed not to be blocking, but it blocks well over the timeout period. I guess that the call to get data to the port simply does not work.

    In one setup, I also hooked up a driver on the other port (a program generating appropriate data. I verified that it was ok by doing TYPE COM4: (the program being hooked on COM2:)) or a reader (doing "TYPE COM2:").

    I did not try a real null modem cabel: I only have one physical serial port and the other one is a virtual one of the on board modem (that also works).

     
  • Logged In: YES
    user_id=918965
    Originator: NO

    > Baud rate emulation and overflow emulation is
    > also inactive.

    Activate it as suggested in ReadMe.txt.

    > Also, the port access from within the application is supposed not to be
    > blocking, but it blocks well over the timeout period. I guess that the
    > call to get data to the port simply does not work.

    To detect the reason of blocking I need the com0com's trace file.

    How to enable tracing to C:\com0com.log:

    1) Get trace.reg file from com0com-1.7.0.0.zip
    2) Change all 00000000 to FFFFFFFF
    3) Import trace.reg to the Registry.
    4) Reboot (or reload driver).

     
    • status: open --> pending
     
  • Mario De Weerd
    Mario De Weerd
    2007-05-11

    Logged In: YES
    user_id=149951
    Originator: YES

    Herewith a log file.

    Starting at line 1073: a failing session. (when failing, stops at line 1226). Just after line 1226: kill.

    Starting near 1529: a working session.

    My application connects to COM4. COM2 stays open.
    The working session has EmuBR and overflowctrl enabled on COM2.
    The failing session(s) do not have this enabled.

    The good thing is, there is a solution that works. Other than that, I'll let you decide if the port behaves correctly or not. From an application perspective, I expect(ed) it to have a timeout on the write as I can specify it, but it seems that the write Timeout is used nowhere in the java libraries.

    Anyway, thanks.
    File Added: com0com.zip

     
  • Mario De Weerd
    Mario De Weerd
    2007-05-11

    • status: pending --> open
     
  • Mario De Weerd
    Mario De Weerd
    2007-05-11

    Log file

     
    Attachments
  • Logged In: YES
    user_id=918965
    Originator: NO

    > My application connects to COM4. COM2 stays open.

    COM2 is not open!

    > The working session has EmuBR and overflowctrl enabled on COM2.
    > The failing session(s) do not have this enabled.

    It's OK because
    COM2 has zero length rx buffer (because it's not open)
    and
    rx buffer overrun is disabled

    > it seems that the write Timeout is used nowhere in the java libraries.

    Some operations (like GET_TIMEOUTS, SET_TIMEOUTS, WRITE, READ) are disabled for logging in the original trace.reg file.
    To enable logging you need to change all 00000000 to FFFFFFFF in the trace.reg file before importing it to the Registry.

     
    • status: open --> pending
     
    • status: pending --> closed
     
  • Logged In: YES
    user_id=1312539
    Originator: NO

    This Tracker item was closed automatically by the system. It was
    previously set to a Pending status, and the original submitter
    did not respond within 14 days (the time period specified by
    the administrator of this Tracker).