www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FT245BM Handshake


Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Zusammen,
Ich betreibe den USB zu Parallel Wandler FT245BM von www.ftdichip.com.

Diesen Chip betreibe ich im BitBang Mode(Ohne berücksichtigung der
Handshakeleitugnen). Ist es möglich, trotzdem die Handshakeleitungen
RXF und TXE entsprechend zu setzen? Mein Problem ist, dass ich die
Datenrichtung herausfinden muss. Oder gibt es eine andere Möglichkeit?

danke für eure Hilfe
chrigu

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Chrigu,

ja das Problem kenne ich. Ich bin zum schluss gekomen das dieser FTDI
Chip eher icht das Gelbe vom Ei ist.

Martin

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Antwort! Leider bringt diese mich nicht sehr weiter! Im
Programmers guide DXX2 ist der Befehl ft_SetRTS (Request to send).
Setzt dieser Befehl die RXF Leitung? Und funktioniert das ganze auch im
BigBang mode? Bin schon lange am programmieren, aber ich bekomme das mit
den Handshakeleitungen nicht geregelt!
gruss
chrigu

Autor: Stefan Rautmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Chrigu,

die Angaben, welche Du aus dem Programmers-Guide zitierst, beziehen
sich auf den FT232BM. Der 245 hat ja keine RTS-Leitung. Im
Bit-Bang-Modus sind die Statusleitungen ausgeschaltet. Mit dem
FT2XX-Treiber kann man die Statusleitungen ansteuern. Der
Bit-Bang-Modus stellt nur die 8-Portleitungen zur Verfügung.
Gruß
Stefan

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Stefan,
du hast recht gehabt, man kann die RXF und TXF Leitungen nicht selbst
setzen.
Leider habe ich nun ein weiteres Problem enteckt:
Wenn ich 1 Byte einlesen will, und mit dem KO die Handshakeleitungen
kontrolliere (WR und TXF), wird der Übergabe Zyklus nicht einmal
durchlaufen, sondern ein vielfaches, vieleicht 1000 oder 10000 mal!
Laut FTDI liegt das daran, dass der uC "das signal "too hard"
treibt"(keine Ahnung was sie damit aussagen wollen). Sie empfehlen,
ein Widerstand von  20-40 Ohm in Serie zur RD/WR leitung zu schalten.
Mit dem RD hatte ich keine Probleme, leider jedoch mit dem WR:( Ich
habe das mit dem Widerstand ausprobiert, leider funktionierte das
nicht. Hat jemand ähnliche Probleme mit dem 245 erlebt? Wenn ja bin ich
um jede Hilfe dankbar!
Besten Dank!
chrigu

Autor: Stefan Rautmann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi chrigu,

Du redest aber immer noch vom Bit-Bang-Mode, oder?
In welchem PDF von FTDI hast Du die Empfehlung zu diesem Widerstand
gelesen? Und was ist ein KO?
Gruß
Stefan

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tschuldigung, jetzt rede ich nicht mehr vom BitBang Mode! Tut mir leid,
dass ich mich nicht genug genau ausgedrückt habe.

www.ftdichip.com/Support/Knowledgebase/index.html
->Technical Support
 -> Hardware
   -> General
        -> Why do I get repeated data when I read from the FT245BM?

Das WR Signal das ich erzeuge sieht sauber aus. Das heisst ich habe
kein Überschwingen.
@Stefan hast du eventuell einmal ein Programm für den FT245BM
geschrieben, welches im FIFO Modus ein einzelnes Byte einliest? Ich bin
fast sicher, das meine Software stimmt. Aber so 100% kann man ja nie
sicher sein!
Besten Dank für deine Hilfe!
gruss
chrigu

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
ich glaube ich habe das Problem "gefunden".
Wenn ich den FT_Read befehl schicke, werden immer 62 Byte in den Buffer
eingelesen. Ist das richtig so? Kann ich das irgendwie vermeiden?
Ich habe auch noch die Frage, wie genau das mit der FIFO funktioniert.
Wie sieht der Ablauf aus, die FIFO zu beschreiben und wie werden die
Bytes wider ausgelesen?
Und dann noch die Frage wenn man FT_Purge (RX_Buffer) benuzt, warum
setzt dieser Befehl die Handshakeleitungen?
gruss
chrigu

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Das mit den 62 Byte ist mir nicht bekannt.
Wenn ich den Read-Befehl über den PC ausgebe, dann
habe ich genau so viele Zeichen im Buffer wie der
µC ausgesendet hat.
Auch, dass der FT_Purge-Befehl die Handshakeleitungen
setzt habe ich noch nicht gehört. Es kann aber sein,
dass durch das Löschen des Buffers der Baustein wieder
bereit ist Daten zu empfangen oder zu senden.

Aber ich hatte auch das Problem mit den WR und RD-Leitungen.
Ich erhielt ab und zu mal ein Zeichen doppelt.
Mir wurden Pull-Up und Pull-Down-Widerstände geraten:
Die WR-Leitung erhält einen 10K Pull-Down und die
RD-Leitung einen 10K Pull-Up und alles funktionierte
prächtig.

Tschüss

Martin

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das mit den 62 Bit steht im Kapitel 3.1:
http://www.ftdichip.com/Documents/AppNotes/AN232B-...
Soweit ich das verstanden habe, werden grundsätzlich immer 62 byte in
den Buffer eingelesen.

Bei mir sieht das folgendermassen aus:
1. Ich führe auf Konpfdruck der Befehl FT_Read aus für 1 Byte
wenn ich auf Knopfdruck 1 Byte lese, werden 62Byte inden Buffer
geladen. Danach kann ich noch 55 mal 1 Byte lesen bis dann wider 62
Byte in den Buffer geladen werden. Bei dieser Methode bleibt der Inhalt
des Buffer immer auf 0-> liest also die Daten nicht richtig ein.
2. Ich führe auf Knopfdruck den Befehle FT_Purge (RX) - FT_Read (1Byte)
aus. Dadurch werden am Bildschirm die richtigen Daten angezeigt. Aber
das Problem: FT_Purge liest 63488 byte ein. Und dort liegt das Problem,
ich weiss nicht, warum er so viel Byte einlesen will, und vorallem wo er
damit hingeht.
(ps das handshake Signal generiere ich mit einem Monoflop, das heisst
das WR Signal wird immer erzeugt sobald TXE auf Low geht)
gruss
chrigu

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So, ich habe mich mal an den FTDI Support gewendet.
Ich habe einen groben Denkfehler gemacht! Also soblad ich ein FT_Purge
mache, wird der Buffer gelöscht. Er ist nun leer und kann neu
beschrieben werden. Das sind die 65kbyte die ich eingelesen habe. Mit
dem FT_Read wird dieser Buffer dann ausgelesen. Das heisst die Daten
werden nicht direkt mit FT_Read eingelesen. FT_Read liest die Daten aus
einem Buffer auf dem PC aus.
Ich denke nun, dass wenn man weniger Daten auslesen will, muss man
FT-SetUSBParameters benutzen.
Gruss chrigu

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie Was?

Das ist doch egal, wo der Buffer ist, hauptsache
er ist mit FT_Purge gelöscht.

Ich hole immer so viele Daten ab, wie im Buffer stehen mit:

FT_GetQueueStatus(Handle,RXQueue);

Dadurch weiß ich wieviele Bytes im Buffer sind und
kann sie dann entsprechend mit dem Read-Befehl abholen.

Tschüss

Martin

Autor: chrigu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Standartgrösse für den RXBuffer ist 64KB, das heisst man hat 63488
Bytes nutzdaten. Mit dem Befhel FT_SetUsbParameters kann man den Buffer
anpassen, das heisst verkleingern. Im D2XX Programmers Guide ist sogar
ein Beispiel drin. Ich habe den Befehl ausprobiert, aber die
Buffergrösse hat sich nicht verändert. Hat jemand schon erfolgreich den
Befehl ausführen können? Gibt es tips?
danke
chrigu

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.