Virtueller COM Port CP210x: Problem unter Win8.1

[Rollo62]

Hallo zusammen,

ich portiere gerade eines meiner Projekte von XE7 zu XE8 Upd1, und arbeite
unter VmWare Fusion 7.1.2 (aktuell) und Win8.1 64Bit (aktuell), ich habe
Silabs CP210x V6.7 64-Bit Treiber installiert (aktuell 8.1).

Plötzlich scheint der COM-Port Zugriff nicht mehr zu laufen, das ging immer bis zur jetzigen Version, und
ich habe eigentlich keine Änderung am Sourcecode gemacht.

Es passiert Folgendes:
- Wenn das Gerät eingesteckt wird, wird auch der COM-Port im Gerätemanager angezeigt: OK
- Wenn ich mich damit verbinden will dann hakt es bei dem CreateFile() Aufruf mit ErrorCode 2: "File not available".
- Ich kann den COM-Port z.B. verschieben von COM3 zu COM11, keine Änderung
- Weil ich der Sache nicht ganz traue habe ich es versucht mit AsyncPro zu Öffnen, geht auch nicht.
(Ich benutze normalerweise eine andere COM-Port Library, aber beide fliegen bei CreateFile mit INVALID_HANDLE raus)
- Habe versucht Port-nummer zu ändern, neu zu booten, mit anderer USB-Hardware, etc. etc.
Der Port scheint also auch nicht belegt zu sein, denn dann käme eine andere Error-Meldung.
- Unter <= Win7 funktiniert es aber ohne Probleme
- Der Serial-Code ist in zig Projekten ohne Probleme gelaufen.

So sieht es bei mir aus: Es wird < 10 und >= 10 COM-Port Nr. berücksichtigt.
Die Methode >= 10 für einstellige COM-Ports habe ich aber auch schon unter Win8.1 getestet, weil dies
in manchen Libraries nicht mehr so benutzt wird.

Code:

    // Schnittstelle öffnen
    if (FCOMPort<10) and True then
    begin
      c:='COMx'+#0;
      c[3]:=chr($30+FCOMPort);
    end
    else
    begin
      c:='\\.\COMx'+#0+#0;
      c[7]:=chr($30+(FCOMPort div 10));
      c[8]:=chr($30+(FCOMPort mod 10));
    end;
    FSerHandle:=CreateFile( c,
      GENERIC_READ or GENERIC_WRITE,
      0,
      nil,
      OPEN_EXISTING,
      FILE_ATTRIBUTE_NORMAL or FILE_FLAG_OVERLAPPED,
      0);
    //S4: Check LastError --> hier fliegt er raus
    if (FSerHandle = INVALID_HANDLE_VALUE) then
    begin
      sErr := S4Err_LastError_AsString(0);
    end;

So macht es AsyncPro, das war ein kleiner Test um nur einen Port zu öffnen, hilft aber auch nicht:

Code:

    

  function MakeComName(const Dest : PChar; const ComNum : Cardinal) : PChar;
    {-Return a string like 'COMXX'}
  begin
    StrFmt(Dest,'\\.\COM%d',[ComNum]);
    MakeComName := Dest;
  end;

            Res := CreateFile(MakeComName(ComName, ComNum),
                   GENERIC_READ or GENERIC_WRITE,
                   0,
                   nil,
                   OPEN_EXISTING,
                   FILE_ATTRIBUTE_NORMAL or
                   FILE_FLAG_OVERLAPPED,
                   0);

          if Res > 0 then begin
            CloseHandle(Res);
            Result := True;
          end else begin
            if ShowPortsInUse then
              Result := GetLastError = DWORD(Abs(ecAccessDenied))
            else
              Result := False;
          end;

Das ist sehr seltsam, weil der Code so schon seit Jahren ohne Probleme läuft.

Hatte vielleicht schonmal jemand ähnliche, seltsame Effekte gehabt ?
- liegt es an XE7 --> XE8 Update ?
- liegt es an Win8.1 ?
- liegt es an VmWare ?
- kann es vieleicht an einem fehlenden Manifest oder ähnlichem liegen ?

Ich hoffe hier gibt es noch andere die sich noch mit den guten alten COM-Ports auseinandersetzen müssen.

Rollo

[Horst0815]

benutze diese http://sourceforge.net/projects/comport/

Was ist c?

Statt

Delphi-Quellcode:

 if (FCOMPort<10) and True then
    begin
      c:='COMx'+#0;
      c[3]:=chr($30+FCOMPort);
    end
    else
    begin
      c:='\\.\COMx'+#0+#0;
      c[7]:=chr($30+(FCOMPort div 10));
      c[8]:=chr($30+(FCOMPort mod 10));
    end;

sollte auch reichen

Delphi-Quellcode:

  
  Format(c,'\\.\COM%d',[FCOMPort]);

[Rollo62]

danke für den Tip.
ComPort hatte ich mir vor Jahren schonmal angeschaut, werde ich mir auf jeden Fall mal in der aktuellen Version ansehen.

Ich glaube ich habe schon ein mögliches Problem gefunden, es gibt einen dieser vergessenen CompilerSchalter

Code:

{$IFDEF VER200} {$DEFINE NEWDELPHI} {$ENDIF}  { BDS 2009 }
//S4: Added
{$IF CompilerVersion >= 20.0} {$DEFINE NEWDELPHI} {$ENDIF}  { XE+ }  // Added
{$IFDEF FPC}    {$MODE DELPHI}      {$ENDIF}  { Lazarus  }

Der war aber schon vorher hart auf NEWDELHPI gesetzt, deshalb hat es vorher auch schon funktioniert.

Das wird dann hier so eingesetzt:

Code:

  {$IFDEF NEWDELPHI}
  c : array[0..63] of WideChar;  // <-- hier kommt er vorbei
  {$ELSE}
  c : array[0..63] of char;
  {$ENDIF}

Jedenfalls ann alle die auch noch die Toolbox Serial-Library im Einsatz haben:
- Mal nach NEWDELPHI schauen



!! Trotzdem funktioniert es noch nicht (genausowenig wie in AsyncPro).
Das Problem scheint tiefer zu liegen, denn CreateFile() lässt sich einfach nicht verbinden.
Der COM-Port ist sichtbar und OK im GeräteManager.

Ich habe ja XE8 im Verdacht, weil ich da schon andere Seltsamkeiten gesehen habe.

Hat sie vielleicht etwas an CreateFile geändert ?

Die XE8 Defines sind bei mir so definiert:

Code:

  GENERIC_READ             = DWORD($80000000);
  {$EXTERNALSYM GENERIC_READ}
  GENERIC_WRITE            = $40000000;
  {$EXTERNALSYM GENERIC_WRITE}

  OPEN_EXISTING = 3;
  {$EXTERNALSYM OPEN_EXISTING}

  FILE_ATTRIBUTE_NORMAL               = $00000080;
  {$EXTERNALSYM FILE_ATTRIBUTE_NORMAL}

  FILE_FLAG_OVERLAPPED = $40000000;
  {$EXTERNALSYM FILE_FLAG_OVERLAPPED}

{$IFDEF MSWINDOWS}
  FixedInt = LongInt;
  FixedUInt = LongWord;
{$ENDIF}
{$IFDEF POSIX}
  FixedInt = Integer;
  FixedUInt = Cardinal;
{$ENDIF}


  DWORD = FixedUInt;
  {$EXTERNALSYM DWORD}

  DWORD = System.Types.DWORD;
  {$EXTERNALSYM DWORD}

Da sehe ich auch keine Fehler.

Übrigens scheint die ComPort-Komponente das gleiche zu machen:
Da sehe ich prinzipiell keinen Unterschied bei allen drei Lösungen, sondern eher bei CreateFile selbst.

Code:

// create handle to serial port
procedure TCustomComPort.CreateHandle;
begin
  FHandle := CreateFile(
    PChar('\\.\' + FPort),
    GENERIC_READ or GENERIC_WRITE,
    0,
    nil,
    OPEN_EXISTING,
    FILE_FLAG_OVERLAPPED,
    0);

  if FHandle = INVALID_HANDLE_VALUE then
    //raise EComPort.Create
    CallException(CError_OpenFailed, GetLastError);
end;

Rollo

[mensch72]

neben FTDI verwenden wir auch diese USB <-> serial Wandler ganz normal.

Wenn im Gerätemanager alles OK angezeigt und nach einem echtem VM Neustart (nicht nur Suspend) es immer noch nicht will deutet das eher auf einen bereits belegten ComPort hin.
Bei einem VM System Fusion/Workstation/ESXi kann der ComPort auch "shared" zwischen Host&Client sein... sauber VM-USB-Only ist es da nur, wenn im HostUSB der ComPort nicht mehr angezeigt wird.

Also einfach mal TerraTerm oder ein beliebiges anderes Terminalprogramm starten und dort den Port auswählen und öffnen. Dann Ausgaben machen und "irgendwie" prüfen ob was raus geht oder was reinkommt angezeigt wird.

[Rollo62]

Hallo mensch72,

ja, das habe ich auch ausprobiert.
Ist es leider auch nicht.

Es sollte dann bei belegtem Port eine andere Meldung von CreateFile zurückkommen (nicht ErrorCode 2, so wie jetzt).

Aber nochmal zur Sicherheit:
Womit finde ich denn 100% sicher raus ob ein Port belegt ist oder nicht ?

EDIT:
TeraTerm scheint auch CreateFile zu benutzen
Anhang 43596


Rollo

[Der schöne Günther]

Ich weiß nicht wie er es macht, aber Process Explorer kann dir anzeigen welcher Prozess welchen COM-Port belegt (http://superuser.com/q/55334)

[Rollo62]

Hallo Günther,

sehr schöner Tip, gut zu wissen :-)

Hier noch mehr Details.

Aber leider war es das auch nicht, bei mir ist nichts belegt ...
Anhang 43597

[Rollo62]

Hallo mensch72,

ich habe auch versucht Einstellungen wie "shared" für virtuelle USB Ports umzustellen,
habe aber leider nichts gefunden.

Anhang 43598

Wie macht man denn soetwas, in den Einstellungen von VmWare Fusion scheint nichts dergleichen drinzusein.

Grosse Hoffnung habe ich aber nicht, denn das hat ja in der Vm, mit gleichen Einstellungen unter XE7 auch funktioniert.

Rollo

[mensch72]

wenn auch TerraTerm den Comport nicht auf bekommt, liegt es NICHT an Delphi, egal ob XE7 oder XE8! (ich wette da zu 99% das auch eine alte noch mit XE7 übersetzte exe jetzt nicht in dieser Kombi aus Win8.1, VM und Fusion als Host läuft.

Daher StepByStep erstmal am Host ohne VM einen Connect hinbekommen. Fusion... heißt MacOSx als Host... also dort ein Termnalprogramm mal auf den ComPort loslassen und schaun das dort ein Open samt irgendeiner Datenübertragung klappt.

Wenn das OK, dann weiter mit einer kleinen CleanVM wo nur TerraTerm drin ist...