AVR über USB per FTDI-bitbang programmieren

Hi Thomas,

leider ist der Bit-Bang-Modus wirklich sehr langsam und für die
Erzeugung eines I²C oder SPI-Protokolls ziemlich ungeeignet. Da die
USB-Schnittstelle, nicht wie die RS232-Schnittstelle, hardwaremäßig am
Prozessor hängt, wird sie nur in bestimmten Zeitschlitzen vom BS
bedient. Die liegen minimal bei 1ms. Das macht theoretisch maximal 1000
Hz Taktfrequenz und nicht mal die erreicht man. Bei
http://www.ftdichip.com gibts da eine App-Note zum Thema.

Gruß Andreas

Na so langsam ist der Bitbang Mode auch nicht.
Natürlich darf man nicht jedes Bit einzeln lesen/schreiben.

Der FTDI schiebt die Daten Bytweise mit der eingestellten Baudrate raus
und sampled gleichzeitig (leider ständig) die an den Eingängen
anliegenden Daten in den Empfangspuffer. Problem ist nur, dass er
ständig die Daten in den Empfangspuffer schiebt. Wenn ich jetzt z.B.
eine SPI-Schnittstelle programmieren will, dann muss ich zum Lesen den
Takt in den Sendepuffer schreiben, das Paket absenden, den
Empfangspuffer auslesen und den rausgeschobenen Takt im Empfangspuffer
suchen. Die Grenzen liegen darin, dass der Empfangspuffer nicht
überlaufen darf.

Würde der FTDI nur die Daten in den Empfangspuffer übernehmen, wenn
auch ein Byte ausgegeben wírd, dann wäre problemlos eine syncrone
Schnittstelle mit bis zu 1/2 der maximalen Baudrate [Bit/s] möglich.
Aber an so etwas haben die Entwickler wohl weniger gedacht.

Von FTDI gibt es eine Application-Note für SPI, die genau nach dem
Schema vorgeht. Auf Anfrage hatte mir FTDI diese geschickt. Auf der
Homepage ist das Beispiel glaube nicht mit dabei.

Du meintest bestimmt
http://home.t-online.de/home/holger.klabunde/homepage.htm bzgl. der
gesehenen Seite.

Steffen

Was die Geschwindigkeit angeht ist nicht das Problem. Wenn es mir darauf
ankäme würde ich einen uC dazwischenschalten und das Protokoll erledigen
lassen.

Vielmehr zeigt sich, das ich wohl ein paar Eigenheiten des Chips nicht
berücksichtigt habe. Mir war bislang nicht klar, das jeder
Schreibbefehl auch einmal gesampelte Daten im Empfangsbuffer
zurücklässt. Ist mir in der Doku bislang auch nicht aufgefallen. Ich
hatte schon festgestellt, das beim Lesezugriff dann immer Daten gelesen
werden, die tatsächlich nicht anliegen.

Selbiges zeigt sich allerdings auch, wenn ich ein FT_GetBitMode
loslasse ... die gelesenen Daten passen nicht wirklich zu den
anliegenden. Meine Leitungspegel sind stabil, aber ich lese regelmässig
Quatsch. Dabei soll doch das GetBitMode explizit die Leitungspegel
abfragen und nicht irgendwelche (alten) Daten aus dem Empfangsbuffer
lesen, oder ? Vielleicht habe ich auch noch ein generelles
Verständnisproblem beim BitMode.

Wenn Du vielleicht die Application-Note mal posten könntest ?
Vielleicht sehe ich dann auch Fehler in meinen Abläufen ...

Thomas

Der FTDI-Chip liest im Prinzip wie gesagt ständig den Status der 8 I/Os
ein. Egal ob das nun Eingänge oder Ausgänge sind.

Ich nehme mal an, das FTDI nichts dagegen hat, wenn ich das Beispiel
(Delphi 5) anhänge.

FT_GetBitMode sollte eigentlich den aktuellen Leitungsstatus
zurückliefern.

Steffen

Hallo,
ich probiere auch gerade mit dem FT245BM rum in Verbindung mit einem
8051. Ich verwende den VCP Treiber. Den Ausgang RXF# habe ich am INT0
angeklemmt, wo jeweils ein Interrupt kommt und dann werden weitere
Zeichen gelesen, sofern welche da sind. Wenn ich dann vom FT245BM
sende, spricht wieder der INT0 an, obwohl vom PC nichts gesendet wird.
Ist doch merkwürdig. Ihr schreibt ja auch von solchen Problemen. Wenn
ich ein Zeichen zurücksende, kommen 2 Bytes wieder rein. Ich nutze
nicht den Bitbang Modus, habe jedenfalls nichts aktiviert.

Für eine Info wäre ich dankbar.

mfG

Matthias