Moin. Inzwischen ist der AN2135 wohl schon ein Fossil, aber ich habe noch ein paar von denen rumliegen; inzwischen ungenutzt. Vor ein paar Jahren hatte ich mit dem AN2135 einen Meßbus aufgebaut, mehrkanaliges 16-Bit Analog-IO und ein paar digitale Peripheriefunktionen. Das ging auch nett, die Daten kamen sauber über den USB-Chip auf die DACs und auch zurück über die ADCs. Unter Win98SE zumindest. PC Software ist in VisualBasic6 geschrieben, die AN2135 Software in C (Keil). Der Treiber ist von Cypress (V1.3, V1.3_NT); man kann ihn noch von der braintechnology-Webseite runterladen. Die Probleme fingen bei Win2000 an. Ab und zu funktionierte das Lesen vom AN nicht richtig. Ab und zu bedeutet, je nach Rechner. Nicht richtig bedeutet, es wurden immer dieselben Daten gelesen (random Bufferwerte, aber unverändert), obwohl der AN2135 frische Werte von den AD-Wandlern bekam. Das Problem liegt also beim Lesen vom AN. Nun gibt es einen Hinweis im Inet, daß der Aufruf von DeviceIOcontrol (aus VB6) nicht richtig funktioniert, wenn ein Parameter dieser Funktion statt auf byte auf value referenziert. Habe ich geändert -> keine Besserung. Mit WinXP geht nun gar nichts mehr mit Lesen, Schreiben auf den AN funktioniert dagegen nach wie vor wunderbar. Man kann die ADCs auslesen und seriell über Portpins ausgeben, die Daten ändern sich (ADC-Rauschen), das bedeutet, der AN tut seinen Job. Nur die USB Engine nicht - oder eben Windows. Ich hab alles (was in meiner Macht steht) durch. Win2k neu aufgesetzt, alle möglichen Treibervarianten durchprobiert, immer wieder das frische Win2k Image ohne Treiber aufgespielt, um sicherzugehen, daß nichts in der Registry hängenbleibt - niente. An XP habe ich mich neulich auch verlustiert, nichts kam raus dabei. Die Platine(n) mit dem AN2135 haben außerdem kein Eeprom drauf, das heißt, der kann sich gar nix merken. Weiterhin tritt genau das gleiche Problem bei einem FX2-Modul auf. Die DeviceIOcontrol liefert inzwischen grundsätzlich den Wert false zurück; kein Wunder, daß das Lesen nicht geht. Warum haben die Dinger mit Win98SE funktioniert? Soll ich das nochmal gegenchecken, oder die AN2135 und den FX2 gleich mit einem Schweißbrenner, Bohrhammer und C4 Sprengstoff bearbeiten? g Vielleicht habt ihr aber noch eine andere Idee, woran's klemmt. Das Internet habe ich bis zum Ende durch.
Warum probierst du nicht einfach mal einen anderen Treiber aus? LibUsb oder WinUsb z.B..
Ich habe eigentlich keine Ahnung von USB, deswgen habe ich mir die Story mit dem EZUSB überhaupt erst zugetraut. Die andere Libraries kenne ich nicht - ich wüßte nichtmal, ob die mit EZUSB zusammenarbeiten, und was ich auf VB6 Seite ändern müßte. Gibt's dazu Erfahrungswerte, zu LibUSB und WinUSB in Verbindung mit dem An2135? Notfalls würde ich mich dahinterklemmen und die Funktionen neu programmieren, aber für eine komplette USB Implementierung bin ich zu dämlich.
Hast du mal probiert, den CyUSB Treiber statt des alten EzUSB Treibers zu benutzen? Der geht eigentlich für alle USB Chips von Cypress.
Ja, den hatte ich auch schon. Soweit ich recht erinnere, ging mit dem auch das Schreiben nicht. Aber da müßte ich nochmal genau schauen. Mich wundert es halt, daß es ausgerechnet ;) mit Win98SE ging. Irgendwas war doch bei den NT-Windows mit gekapselten Kernel-Versionen, und daß man nicht mehr ohne weiteres auf Hardware zugreifen kann. Kann es sein, daß man so ein IO-Port-Öffner-Programm benutzen muß (wie z.B. das, was man für TwinAVR zum freischalten des LPT-Ports unter Win2k braucht)? Irgendwie schwebt mir sowas als Ursache vor..
Neenee, mit dem passenden Treiber kann man problemlos aus dem User Space auf das USB Device zugreifen. Wir benutzen die aktuellen FX2 von Cypress, das geht wunderbar. Komisch ist das schon. ich könnte mir eher vorstellen, dass die Firmware nicht 100% standard konform ist, und 98SE da sehr lax damit umgeht. Wie werden die IN Daten denn übertragen? BULK, ISO oder Interrupt?
Nicht lachen, keine Ahnung g Ich schreibe mit der C-Firmware im AN2135 in einen Buffer, der 512 Byte groß ist, an eine feste Adresse. Diesen Adressbereich hole ich von VisualBasic aus mit der ReadRamBytes-Funktion. That's it. Tatsache ist aber, daß ein VB6-Beispiel-Programm von braintechnology, das die DeviceIOControl-Funktion ebenfalls benutzt und deren Wert listet, bereits den Fehler zeigt. Das heißt doch, daß es am Treiber liegt. Denn mit diesem Programm kann man beliebige Speicherzellen im AN2135 beschreiben und wieder rücklesen. Aber beim Rücklesen gibt DeviceIOcontrol eine Fehlermeldung aus.
Vielleicht hängts mit USB 2.0 / 1.1 Umschaltung zusammen. Win 98SE kanne ja noch überhaupt kein 2.0 Was sagt denn USBView? Kannst du das mal hier her kopieren? Normal stellt man diese Daten im Endpoint Buffer bereit.
Device Descriptor: bcdUSB: 0x0200 bDeviceClass: 0xFF bDeviceSubClass: 0xFF bDeviceProtocol: 0xFF bMaxPacketSize0: 0x40 (64) idVendor: 0x04B4 (Cypress Semiconductor) idProduct: 0x8613 bcdDevice: 0x0004 iManufacturer: 0x00 iProduct: 0x00 iSerialNumber: 0x00 bNumConfigurations: 0x01 ConnectionStatus: DeviceConnected Current Config Value: 0x01 Device Bus Speed: High Device Address: 0x01 Open Pipes: 0 Unter XP: Das ist der FX2 (alte Version (nicht LP) 56-pin, 8k RAM)zusammen mit dem CyUSB-Treiber Version cyusb18120. Ich kann nicht einmal mit EzMr arbeiten - der sagt, kein Cypress USB-Device present. Mit EzMr lade ich normalerweise die *.hex-Files in den 8051. Außerdem nimmt EzMr die Bulk, Isochron und In/Out Endpoint Einstellungen automatisch vor ... so, daß sie bisher gepaßt haben ;) Für den AN2135 paßt der Treiber gar nicht; XP weigert sich, den cyusb zu nehmen. Später versuche ich es nochmal mit dem driver13_nt, da müßte wenigstens EzMr wieder funktionieren.
Danke erstmal für die Hilfe. Ich habe grade nach Jahren nochmal auf einem frischen XP-Rechner die devtools von Cypress 261700 installiert, den Keil-Compiler, und versucht, alle erdenklichen Treiber, die ich dort gefunden habe, für den AN2135 zu installieren. Geht nicht. Na, dann halt nicht. Wer nicht will, hat schon. Dieser eingangs erwähnte Messbus hatte ein STM (Scanning Tunneling Microscope) gesteuert. Das XY-Rastern übernahmen 2 x 12Bit DACs, das Einlesen des Tunnelstroms und die Regelung ein 16Bit ADC bzw. DAC. Damit ist es gelungen, atomare Auflösung auf Graphit zu bekommen (ist ein Standard-Test, aber für so einen kleinen Käfer wie den AN2135 gar nicht schlecht, was der so kann. Bzw. konnte). Das VB6-Frontend war auch ganz nett. Leider habe ich nicht mehr soviel Zeit, mich an den Treibern weiter aufzuspulen. Wenn der Scheiß nicht geht, mach ich's halt mit dem FT245 und einem XMEM-Mega (das funktioniert gut) und stampf die Cypress-Dinger ein. Der FX2 ist schon klasse, sauschnell und die 96 Mhz am GPIF .. olalala. Aber wenn es schon an den einfachsten Anfangsbedingungen scheitert, lasse ich's lieber.
Also mit dem CyUSB geht dann der EzManager nicht mehr richtig. Dafüer aber diese CyConsole, damit spielt man die hex Files auf und testet den Datenverkehr. Wenn er den Treiber nicht will, stimmen vielleicht nur die VID/PID nicht? Der FX2 ist wirklich nett, allerdings auch oft etwas eigen. 96MHz schafft der nicht, höchstens 96MB/s im Burst-Modus am Slave FIFO, wenn man 16 Bit mit 48MHz anliefert. Aber dann auch nur, bis der Puffer voll ist. Zum Host gehts mit maximal 41MB/s dann. Allerdings bekommt man mit 48MHz bissl Schwierigkeiten mit dem Timing, das ist nur noch Harrakiri dann auf dem Bus.
# Nicht lachen, keine Ahnung g # Ich schreibe mit der C-Firmware im AN2135 in einen Buffer, der 512 Byte # groß ist, an eine feste Adresse. Diesen Adressbereich hole ich von # VisualBasic aus mit der ReadRamBytes-Funktion. # That's it. Hallo ich kenne den AN2135 nicht, aber ich arbeite mit dem AN2131 unter Windows XP und Vista in Verbindung mit VB6 ohne Probleme, wie oben beschrieben Verwende folgende Treiber: ezmon.sys vom 18.07.2000 ezusb.sys vom 29.05.2002 ezusbw2k.inf vom 28.05.2002 Gruß Walter
Also ok, Christian, ich schau mir nochmal die VID/PIDs im inf-file vom cyusb-Treiber an, aber der Hammer liegt gleich daneben ;) Nach der CyConsole schaue ich auch mal, immerhin mag ja der FX2 mit dem cyusb-Treiber spielen. Die CyConsole kenne ich aber noch nicht. Walter, diese Treiber liegen den devtools bei, nicht?. ezmon.sys hatte ich früher mal verwendet, der läßt sogar eine LED an einem Port aufleuchten, wenn ein Programm überspielt wird (oder so). Das waren die Anfänge, es müßte aber danach schon der ezusb.sys gewesen sein, der funktioniert hatte. Echt übel. Man konnte einfach auswählen, ob man den AN oder den FX2 nimmt, im EzMr einfach umstellen und flupp, lief das Zeug. Keine Ahnung, was da jetzt schiefläuft. Ich probiere die auch nochmal, vielleicht ist es ja doch der ezmon ... . Übrigens hatte ich den AN2131 auch am Anfang, aber da ich einen Datenbus wollte, bin ich auf den 2135 umgestiegen. 3 Muster von einem FX2 mit 128Pin hatte ich mir übrigens im Größenwahn aus San Jose schicken lassen, eines davon habe ich wegen einem defekten Spannungsregler zerschossen (5V anstatt 3.3), eines ist mir beim Löten draufgegangen, und das letzte - auf eigens geätzter Platine - ging nicht. Plopp. Unbekanntes Gerät. Bis heute. Wahrscheinlich doch ein bißchen lässig gewesen beim Layouten der Quarz-Umgebung. Dabei wäre der FX2 mit 64k RAM und der vollen Kontrolle über die Handshakes wohl das Nonplusultra für Imaging. Hach, was soll's, jetzt bin ich erstmal 2 Wochen weg g
Ps.: Den 44Pin AN2131SC hatte ich, nicht QC. Wobei der QC auch nett ist, aber halt nur USB1.1.
Ich habe das Verhalten mit den im Kreis laufenden Daten auch schon mehrmals beobachtet. Es tritt nach meiner Beobachtung dann auf, wenn die Datenübertragung zwischen Host und Gerät elektrisch gestört wird. Wir verwenden auch den EZUSB.SYS in der letzten bekannten Version 1.3 und den isochronen Modus. Ich glaube, die Ursache dafür liegt im EZUSB.SYS. Anchor bzw. Cypress hat immer davon abgeraten bzw. gewarnt, diesen für Produktionszwecke einzusetzen. Obwohl der mitgelieferte Quelltext ausdrücklich nur als Beispiel zu verstehen ist, gibt es viele Geräte, die diesen unveränderten Treiber verwenden.
Auch wenn die Chips schon lange EOL sind. Die haben schon ganz gut funktioniert. Vermutlich hast du ganz einfach ein Firmware Problem. Wie kommt deine Firmware denn auf den Chip? Es gibt verschiedene Wege... B0 Download B2 Download B6 ... .... Da USB View die Cypress ID meldet meldet, ist das Problem wohl da zu suchen. Zusätzlich sind die W98 Treiber und W2000/XP Treiber zwei komplett verschiedende Dinge. Ich habe die AN Chips viele 1000 mal eingesetzt und sowohl mit eigenen als auch mit ezusb.sys nie ein Problem gehabt. Allerdings habe ich auch nie VB6 benutzt sondern C. Buffer an fester Adresse hört sich für mich schon mal komisch an. Generell ist zu den Cypress Teilen noch zu sagen, dass sie deutlich komplexer sind als so ein einfacher FTDI Chip. Zeig doch mal den Firmware code für den Bulk Out Endpoint und den Bulk In Endpoint. Ohne passende Firmware sind die Teile fast nicht zu nutzen. Brain läd übrigens beim Start eine spez. Firmware auf den Chip. Thomas
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.