Hi, ich habe hier ein USB-Gerät, welches intern einen FTDI FT245R Chip verwendet und mit 1 MBit Übertragungsrate läuft. Leider habe ich größte Probleme, mit diesem zu kommunizieren, sprich das Gerät sendet auf meine Anfragen keine Antwort. Unglücklicherweise kann ich kein Loopback o.ä. setzen, ich bin auf die Antworten des Gerätes gemäß dessen Protokoll angewiesen. Mein Code zur seriellen Kommunikation (WinAPI) stammt aus einem anderen Projekt, dort läuft er problemlos. - CreateFile() mit "COM18" ist erfolgreich, der Port kann also geöffnet werden - SetCommState() ist ebenso erfolgreich, die Kommunikationsparameter werden also gesetzt Ich habe DCB.BaudRate schon auf 921600 und 1048576 gesetzt, in keinem der beiden Fälle kommt irgend eine Kommunikation zu stande. Das Übertragungsformat 8N1/keine Flusskontrolle sollte auch passen. Was kann also sonst noch falsch sein? Ich bin für jeden Denkanstoß dankbar :-)
Ich wuerde annehmen, dass 1MBit, 1 MBit ist und nicht 921600 oder 1048576. Eigentlich sollte die Baudrate ja egal sein, da die Uebertragung ja eh USB ist, und auf der anderen Seite des chips parallel. Probier's doch mal mit 19200, oder 115200, ob denn da was kommt. Dem Gerate sollte das auch egal sein, es kommuniziert ja parallel mit dem Chip. Das Handshake des chips wird bedient? Ich habe keine Anhnung was geschieht, wenn der Buffer voll ist, und noch mehr gesandt wird.
Delta Oschi schrieb: > Ich wuerde annehmen, dass 1MBit, 1 MBit ist und nicht 921600 oder > 1048576 Also entweder bin ich jetzt völlig auf dem Holzweg...aber 1 MBit sind 1024 * 1024 = 1048576!? > Eigentlich sollte die Baudrate ja egal sein, da die > Uebertragung ja eh USB ist, und auf der anderen Seite des chips > parallel. Naja, da es über den VCP-Treiber geht, gibt es noch einen ganz gewöhnlichen COM-Port und der will doch immer eine Übertragungsrate haben? > Probier's doch mal mit 19200, oder 115200, ob denn da was > kommt. Nö, da tut sich nix - auch bei 9600 nicht.
1MBit sind 1000000Bit. Wir sind hier nicht bei Festplatten. 1MiBit wäre deine krumme Zahl. Ansonsten ersmal mit nem Terminalprogramm probieren um eigene Fehler auszuschließen im Programm. Wenn du schon selber proggst, sollteste nicht über VCP gehen sondern gleich den D2XX Treiber nehmen ;) Ders auch gut erklärt und ne dll gibs bei FTDI zum DL.
Martin Wende schrieb: > Ansonsten ersmal mit nem Terminalprogramm probieren um eigene Fehler > auszuschließen im Programm. Das habe ich gemacht - da rührt sich auch nix. > Wenn du schon selber proggst, sollteste nicht über VCP gehen sondern > gleich den D2XX Treiber nehmen ;) > Ders auch gut erklärt und ne dll gibs bei FTDI zum DL. Der hat nur einen Nachteil: Unter Linux muss ich dann eine separate Shared Lib mitliefern, die es nur als Binary und für bestimmte Plattformen gar nicht gibt. Den /dev/ttyUSBx sehe ich unter jeder Plattform.
Delta Oschi schrieb: > Eigentlich sollte die Baudrate ja egal sein, da die > Uebertragung ja eh USB ist, und auf der anderen Seite des chips > parallel. Ich habe noch mal ein bissl bei FTDI gegraben, die haben dort ein Demoprogramm ,das den gleichen Weg geht wie ich und bei dem auch die Baudrate für den COM-Port gesetzt wird. Die scheint also in der Tat wichtig zu sein.
Womp! schrieb: > Der hat nur einen Nachteil: Unter Linux... ...mußt du ja auch den eigentlichen Low-Level-Treiber von FTDI benutzen, egal ob du nun mit direktem Zugriff per D2XX-DLL oder über den Umweg eines virtuellen COM-Ports gehst. Wenn du partout den virtuellen COM18 benutzen willst, dann mußt du irgendeine Standard-Baudrate setzen. Welche, ist egal. Wenn du den D2XX-Weg gehst, kannst du direkt nachfragen, ob denn irgendein FTDI-Chip am USB angemeldet ist oder nicht. Vielleicht ist das ein Hardwareproblem oder eines in der Firmware des Gerätes? Mach dir doch einfach mal ne Probierhardware aus einem FT245 und einem uC deiner Wahl (kleiner PIC o.ä.), der einfach nur alles was er empfängt, wieder zurücksendet. Dann kannst du diesen Dummy für das Debuggen deiner Low Level-Routinen benutzen. W.S.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.