FT245BM

Hi!

Also Anmelden müsste sich der Chip, sobald die Stromversorgung und die Verschaltung des USB-Teils stimmt. Das EEPROM ist nicht notwendig. Was am µC-Datenbus passiert ist erst bei der Datenübertragung interessant.

Wenn möglich solltest du den Chip allerdings erstmal unter Windows testen. Das kann damit nativ umgehen. Bei Linux kann viel vorher schiefgehen. Du musst erst den Treiber als Modul compelieren und den mit modprobe laden. Erst dann kennt Linux das Gerät. Die USB Hardwaremeldungen werden normalerweise auch nicht im Logger sondern bei den Kernel-Messages (dmesg eingeben!) sichtbar.

Viele Grüße

Jan

Ich hab mir auch mal so eine Platine gemacht, original nach der Application Note von FTDI 5V self-powered. Bei mir hat der PC was gemerkt, wenn man die Platine angeschlossen hat und danach den Strom der Platine anschaltet (es kam dieser Ding-Sound von Windows und die Frage nach dem Treiber).

Bei der Schaltung nach App-Note funktioniert es, wenn man alle Interface-Pins einfach offen lässt.

MfG Thomas

Jan Stumpf schrieb:

Da hast Du wohl was verwechselt. Wenn jemand den FT245 nativ erkennt, dann der Linux-Kernel. Windows erkennt nur, daß ein Gerät angestöpselt wurde, und das erkennt Linux auf jeden Fall auch (und zwar auch im Syslog). Einen Treiber brauchen dann sowohl Windows als auch Linux, und Linux bringt ihn schon mit, wenn auch meistens nur in Sourceform.

Gruß Henning

Hi!

Also zumindest bei Windows reicht es, dass der 1K5 Pullup an D+ oder D- nach 3.3V geschaltet wird, dass sich der Hardwareassistent startet (und danach natürlich mitteilt, dass das Gerät nicht reagiert, wenn sonst nichts an den Datenleitungen angeschlossen ist) Wenn also nicht mal das passiert wird wohl was in der Verkabelung nicht stimmen...

Michael

Hi!

ja stimmt. Nur geht bis zum ersten "Hallo" des Geräts meistens mehr schief, weshalb ich die prinzipielle Funktion erstmal unter Windows probieren würde. Ist halt DAU kompatibeler.

Viele Grüße

Jan

Hi,

danke für eure Tipps soweit.

Wenn ich unter Linux ein USB-Gerät anstecke, auch wenn der Kernel es gar nicht kennt, dann erkennt er zumindest daß ein USB-Gerät xyz angesteckt wurde und zeigt das auch in /var/log/messages.

Unter einem Kondensator war eine Leitung durchgeführt und die hatte einen Schluß gegen Masse und den Baustein so im Reset gehalten.

Jetzt sehe ich die Einträge in den Logfiles, die Hardware an sich ist jetzt anscheinend ok.

Jetzt muß ich das gute Stück noch konfigurieren und ein paar Werte ausgeben...

Grüße, Torsten.

Hallo,

ich habe ein Platine mit FT245BM, der von einem AVR ATMega128 angesteuert wird.

Der Baustein ist als "VCOM" konfiguriert und steuere die Daten- und Steuerleitungen per Portpins an, also nicht memory-mapped.

Die PC-Seite des USB ist an einen W2000-Rechner angeschlossen wo ein "HyperTerminal" auf COM4 auf Daten wartet.

Wenn ich auf dem PC eine Taste drücke, dann geht RXF am FT245BM von High auf Low. Rein prinzipiell scheint also eine Kommunikation da zu sein.

Auf dem AVR gehe ich folgendermassen vor:

- Read-Ltg ist High, Write-Ltg ist Low (gehört laut Datenblatt auch so).

- sobald RXF auf Masse geht:

- Port D auf Eingang schalten

- Read-Leitung auf Masse ziehen

- Daten von Port D übernehmen

- Read-Leitung wieder auf High setzen.

=> auch wenn ich vom PC nur ein einziges Byte übertrage wiederholt sich dieser Ablauf unendlich lange, RXF geht immer wieder auf Masse, trotzdem ich das empfangene Byte abgeholt habe.

Das kann ich mir nicht erklären.

Wenn ich Daten vom AVR aus sende, dann kommen die auf dem PC nicht an.

- Port D auf Ausgang schalten

- Byte auf Port D ausgeben

- Write-Leitung auf High

- Write-Leitung auf Low

Zwischen jedem einzelnen Schritt rufe ich eine Warteroutine auf, die von

Wo die Daten bleiben kann ich mir auch nicht erklären.

Hat jemand hier vielleicht einen grundsätzlichen Tipp?

Grüße, Torsten.

Torsten Mohr schrieb:

Keine Lust, wirklich drüber nachzudenken, aber da ich gestern erst mit einer Minimal-Applikation für Matthias Weißers USBisp-Platine gespielt habe, hier das Herz dieser Routine:

#define RD PC1 #define WR PC2 #define RXF PC3 #define TXE PB6

#define LED_RD PB0 #define LED_GN PB1

void ioinit(void) { PORTC = _BV(RD); DDRC = _BV(RD) | _BV(WR);

DDRB = _BV(LED_RD) | _BV(LED_GN); }

int main(void) {

ioinit(); for (;;) { if ((PINC & _BV(RXF)) == 0) { PORTC &= ~_BV(RD); __asm__ volatile("nop"); uint8_t tmp = PIND; PORTC |= _BV(RD);

while ((PINB & _BV(TXE)) != 0) ; PORTD = tmp; DDRD = 0xff; PORTC |= _BV(WR); PORTC &= ~_BV(WR); DDRD = 0;

} }

return 0; }

Die Schaltpläne bekommst du auf Matthias' Homepage, da kannst du ja mal vergleichen.

Super,

danke dafür.

Grüße, Torsten.