Hallo zusammen, ich hoffe, dass es hier mittlerweile einige FTDI-Experten gibt, die mir vielleicht mit ein paar Ratschlaegen zur Seite stehen koennen. Ich habe einen Winkel-Encoder zu bauen, der zu jedem Winkel zwei analoge Messwerte (12bit) aufnimmt und diese zusammen mit der Winkelinformation an den Host-PC sendet. Der Winkelencoder funktioniert bereits .... bis auf die Datenuebertragung. Ich habe hierzu einen ATXmega128A1 eingesetzt. Der hat bereits einen Quadraturencoder (im Eventsystem) und zwei getrennte (nicht gemultiplexte) Analogeingaenge. Die Analogeingaenge werden auch ueber das Eventsystem angesteuert und ziehen deshalb (mit Flanke des Incrementalgebers) synchron die Messwerte ein. Das ganze muss mit einer Aufloesung von wenigstens 0,1° funkitionieren. (Bitte keine Diskussion um Sinn und Unsinn. Das ist eine Kundeforderungund wurde schon ausgiebig mit diesem gefuehrt. :) Ich habe deshalb einen Incrementalgeber mit 4096 Schritten pro Umdrehung geordert. Funktionieren muss das ganze bis 3600 min^-1 (also 60Hz). daraus folgt eine Transfervolumen von: 4096 * 6 Byte = 24576 Byte pro Umdrehung (Ich habe vom stopfen erstmal abgesehen.) 24576 * 60 (Hz) = 1474560 Byte pro Sekunde bei Maximaldrehzahl als etwas mehr als 1,4 MByte/Sekunde Transfervolumen. Da ich mit dem Xmega keine 60MHz fuer den synchronen FIFO-Mode hinbekomme, habe ich mir ueberlegt den CPU-Style FIFO Mode zu nutzen, der fuer meine Anwendung schnell genug sein sollte (man moege mich bitte berichtigen ! :) Leider finde ich keinen Anhaltspunkt, wie ich diesen Mode (CPU-style) vom Host PC aus ansprechen muss. Ueber eine (funktionierende :) Sequenz der d2xx.dll Aufrufe fuer diesen Modus oder einen Vorschlag es besser (sicherer/schneller/...) zu machen waere ich sehr dankbar. Vielen Dank im Voraus, Balze aka AVR Noob
Ich denke, dass Dir Dein USB-Port da eher einen Strich durch die Rechnung machen wird, da es sich hier um ein gepuffertes Protokoll handelt und die Daten nie in Echtzeit verfügbar sein werden. Verzögerungen von 1ms Standard und größer, wenn der PC gerade nicht den USB-Controller pollen kann, sind hinzunehmen. Da ist es schon besser, den Parallelport (ECP mode bis 2000kByte/s) zu verwenden, denn der kann Interrupte auslösen.
Hallo zusammen, danke fuer Deinen Hinweis Travel Rec. Aber Paralleport bekomme ich hier im Haus NIEMALS durch. Hier stehen alle auf USB, und dass muss dann auch sein. Der Support bei FTDI ist wirklich eine traurige Angelegenheit. Ich habe da um Unterstuetzung gebeten und nur ein paar Brocken vorgeworfen bekommen (immerhin von einem "Senior Application Engineer" 80 ) Ich bin mittlerweile einen Schritt weitergekommen. Man braucht den CPU-style Mode "NUR" im EEPROM zu aktivieren. (Waere ja schoen gewesen haette dies irgendwo (!) gestanden. (Ich habe schon gefunden, dass man diesen Modus im EEPROM aktivieren muss, aber dass man keinen BitMode bei der Host Software einstellen muss und sich scheinbar (!) auch um nix anderes kuemmern muss stand leider nirgedwo.) Dann lassen sich die Daten durch einfaches - FT_OPEN - FT_GetQueueStatus (zum ermitteln der Anzahl der zu lesenden Bytes) - FT_Close (nach Abschluss der Leserei) auslesen. UEberraschend einfach ! (Zu einfach fuer meine Vorstellungskraft. Ich habe mit komplizierterem gerechnet.) Aber was soll ich sagen bei hoeheren Drehzahlen bekomme ich nicht alles mit. Bin jetzt auf der Suche nach dem Grund hierfuer. (Vermutung: Puffer im FT2232 voll) UEber weitere Hinweise (schneller/sicherer/...) bin ich nachwievor dankbar. (USB ist wie gesagt Pflicht.) Danke, Balze aka AVR Noob
Optional ginge wohl noch eine Anbindung über PCI oder ATA. Meines Wissenstandes zufolge kannst Du Echtzeitanwendung mit USB vergessen, aber ich lasse mich auch gerne belehren.
Bitte 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.