www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik FTDI extrem langsam


Autor: P. D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

eigentlich habe ich den Beitrag gestern abend schon mal gepostet aber 
ich finde ihn einfach nicht mehr im gesamten Forum. Vieleicht ist da was 
schief gelaufen oder ich übersehe ihn einfach, also nicht böse sein wenn 
das jetzt das zweite mal ist.

Folgendes Problem.
Ich entwickle mir gerade ein Flash Tool für den PC.
Mit diesem Tool kann ich, wie man es ja kennt, die intel hex file auf 
meinen µC flashen (STR752).
Da ja viele PCs (Notebooks) keine RS232 Schnittstelle mehr haben mache 
ich die Sache per USB mit nem FTDI (FT232R). Ich benutze die D2XX 
Treiber und die FTD2XX.dll.

Das Programm funktioniert wunderbar. Die µCs lassen sich schön flashen.
Einziges problem ist das der FTDI so verdammt langsam ist. Wenn der µC 
ein ACK oder NACK während des flashens rausschickt dauert es ca. 40 bis 
80ms!!! bis dieses ACK/NACK als Bytes To Read im FTDI/FTD2XX.dll 
ansteht. Und solange kann ich nicht weiterflashen da ich ja auf das 
ACK/NACK reagieren muss.

Eine Controllersoftware mit 16k benötigt deswegen fast 4 Minuten bis sie 
in den µC geflasht ist. Wenn ich da mal mit ner 128k Software komme 
braucht das ja 32 Minuten!!!! Das ist doch kein Zustand.

Liegt das am FTDI selbst oder an der *.dll? Und wie kann man das ganze 
schneller kriegen?

Danke.

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Liegt das am FTDI selbst oder an der *.dll? Und wie kann man das
> ganze schneller kriegen?

Das liegt an USB. Die Schnittstelle ist bei so einer Anwendung einfach
so langsam.

Die Loesung kann z.B in einer PCMCI-RS232 Karte bestehen.

Olaf

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kannst du evtl. dein Flash-Protokoll ändern, damit du nicht auf das ACK 
warten musst?!

Autor: P. D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke erstmal,

ne das Flash Tool kann ich nicht ändern. Ich muss ja wissen ob ein ACK 
oder NACK zurückkommt, sonst kann ich nicht entscheiden wie es 
weitergeht.

Obwohl da kommt mir grad ne Idee. Ich pfeiff einfach erstmal auf die 
ACK/NACK Antwort und flashe das Teil einfach immer weiter ohne 
Rücksicht.
Und irgendwo in nem Interrupt oder so überprüfe ich alle ms was denn 
grad als Bytes To Read ansteht. Wenn da immer ein ACK drinsteht ist ja 
gut. Sollte ein NACK drinstehen brech ich ab und geb ne Fehlermeldung 
raus. Was das NACK verursacht hat ist ja egal.

Autor: Christian R. (supachris)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das liegt daran, dass USB auf Block-Übertragung optimiert ist. Dann ist 
es auch schnell. Wenn allerdings immer nur 1 Byte pro Transfer 
übertragen wird, wird´s extrem langsam. Deswegen haben alle USB 
Programmiergeräte einen Controller onBoard.

Autor: Jast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@P. D. (pdiemer):
Flash einfach alles ohne auf ACK/NACK zu warten und lies am Ende alle 
Zellen zurück. Dann kannst du im PC einen Vergleich machen und 
Fehlstellen melder oder erneut flashen oder...

Autor: P. D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jast
Genau so hab ich mir das auch gedacht.
Danke euch.

Autor: P. D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Obwohl das geht ja auch nicht.

Wenn ich das geflashte verifizieren will muss ich ja trotzdem erstmal 
warten bis alle ACKs/NACKs über die Bühne sind, bevor ich die Zellen 
zurücklesen kann. Und die brauchen eben ihre unverschämt lange Zeit.

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du mußt das Übertragungsprotokoll so ändern, das nicht nach jedem byte 
ein ACK kommt, also die von Chris gemeinte Blockübertragung und erst 
nach einem Block ein ACK. Sende also nicht 1 Byte sontern z.B. 256 Bytes 
am Stück.
Natürlich muß der Empfänger das dann zwischenspeichern.
Genau so beim lesen, erst einen Block zurückübertragen und dann 
auswerten.
So wird es schneller.

Autor: Rufus Τ. Firefly (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zusätzlich dazu, daß USB auf Blockübertragung optimiert ist, sind das 
modernere UARTs auch. Dem aber kann Abhilfe geleistet werden, indem die 
Größen der Sende- und Empfangs-FIFOs reduziert bzw. deren Gebrauch 
deaktiviert wird.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der FT232 sammelt Daten von der seriellen Schnittstelle, bis 62 Bytes (1
USB-Paket) zusammengekommen oder 16ms vergangen sind. Sendet der
Mikroccontroller also immer nur wenige Bytes (ACK u.ä.) wird jedesmal
16ms gewartet.

Dieser Timeout von 16ms kann auf einen beliebigen Wert im Bereich
1..255ms gesetzt werden. Unter Linux geschieht dies einfach durch
Schreiben des gewünschten Zahlenwerts in die Pseudodatei latency_timer
im sysfs. Bei einem Wert von 1 (statt der defaultmäßigen 16) solltest du
schon einen deutlichen Unterschied merken. Den Delay von 1ms hast du
allerdings immer noch.

Alternativ kann ein spezielles Zeichen definiert werden, bei dessen
Empfang von der seriellen Schnittstelle der FT232 das USB-Paket sofort
abschickt, auch wenn die 62 Bytes noch nicht erreicht sind. Die
entsprechende Pseudodatei heißt event_char.

Wie man diese Parameter in Windows einstellt, weiß ich nicht. Die
Dokumentation des FTDI-Treibers enthält sicher einige Informationen
darüber.

Autor: Michael H. (morph1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
geht über den gerätemanager

genaue anleitung dazu findet man auf den diversen seiten zum icd2-clone 
mit ftdi drauf, da der mit den normalen fifo-einstellungen den dienst 
verweigert.

da klappts auch nur brauchbar wenn alle fifo soweit wie möglich 
heruntergestellt werden.

Autor: Sabine (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe mal das Daten-Blatt gelesen.
Diese (STR752). hat ja einen 16 Byte Rx-Fifo Buffer.
Und noch UART an DMA.
Da haben die Entwickler ja mal was praktisches gemacht.

High speed universal asynch. receiver transmitter (UART)
The three UART interfaces are able to communicate at speeds of up to 2 
Mbit/s. They
provide hardware management of the CTS and RTS signals and have LIN 
Master capability.
To optimize the data transfer between the processor and the peripheral, 
two FIFOs
(receive/transmit) of 16 bytes each have been implemented.
One UART can be served by the DMA controller (UART0).

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Da haben die Entwickler ja mal was praktisches gemacht.

???
UART, FIFO, DMA => alte Hüte.

Autor: P. D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jup. Ich hab jetzt die Lösung.
Wie oben schon aufgeführt habe ich immer nur 16byte (also eine Zeile im 
hex file) geschickt und auf das ACK gewartet.
Aber ich hab übersehen das man dem µC 265byte (also 16 Zeilen auf 
einmal) schicken kann und dann aufs ACK warten.

Dann spare ich Zeit um den Faktor 16.

Danke.

Autor: Günter -.. (guenter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
yalu wrote:
...
>
> Dieser Timeout von 16ms kann auf einen beliebigen Wert im Bereich
> 1..255ms gesetzt werden. Unter Linux geschieht dies einfach durch
> Schreiben des gewünschten Zahlenwerts in die Pseudodatei /latency_timer/
> im sysfs. Bei einem Wert von 1 (statt der defaultmäßigen 16) solltest du
> schon einen deutlichen Unterschied merken. Den Delay von 1ms hast du
> allerdings immer noch.

Das ist dann mit dem ftdi_sio Treiber unter Linux?

Ist das auch irgendwo dokumentiert?

Ich hab mal auf der Seite http://ftdi-usb-sio.sourceforge.net/ gesucht 
und nichts darüber gefunden.

Autor: Gerry L. (gerrylenz)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich weiss zwar net wie du das ganze realisiert hast aber nie und nimmer 
benötigt der FTDI 4 Minuten für 16 K. Mein Bootloader saugt sich 18 K in 
4 sec in den MC. ( Allerdings benutze ich den 245 )

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
P. D. wrote:

> Das Programm funktioniert wunderbar. Die µCs lassen sich schön flashen.
> Einziges problem ist das der FTDI so verdammt langsam ist. Wenn der µC
> ein ACK oder NACK während des flashens rausschickt dauert es ca. 40 bis
> 80ms!!!

USB ist fuer "bulk"-Transfer (grosse Datenmengen) ausgelegt. Beim FTDI 
musst Du darauf achten, die Daten so zu senden, dass sie innerhalb von 
etwa 1ms (bin nicht ganz sicher mit dem Wert) zu einem Paket von 512 
Bytes zusammengefasst werden kann. Einzelne Bytes hin und herschicken 
und dazwischen Pausen machen ist immer sehr langsam.

Autor: yalu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Günter -..:

> Das ist dann mit dem ftdi_sio Treiber unter Linux?

Ja.

> Ist das auch irgendwo dokumentiert?

Hmm, gute Frage. Man findet im Netz zwar einige Mailing-Listen und
Patches, worin irgendwelche Bugs zu diesem Thema beschrieben bzw.
korrigiert werden, aber eine klare Aussage, dass es dieses Feature gibt
und wie man es benutzt, habe ich auch nicht gefunden.

Vermutlich ist der Quellcode (wie so oft) die beste Dokumentation ;-)
Tatsächlich findet man dort u.a. folgende Zeilen:
static DEVICE_ATTR(latency_timer, S_IWUSR | S_IRUGO, show_latency_timer,
              store_latency_timer);
static DEVICE_ATTR(event_char, S_IWUSR, NULL, store_event_char);

Mit diesen Makroaufrufen werden die Pseudodateien latency_timer und
event_char im sysfs angelegt und mit den Treiberfunktionen
show_latency_timer (lesen), store_latency_timer (schreiben) und
store_event_char (schreiben) verbunden. In den store- und
show-Funktionen werden die Werte zum bzw. vom FT232 übertragen.

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

nochmal zu Windows XP.
Ich habe einen FT232R verbaut mit 115kBd und der sendet immer ein 
Zeichen mit 1ms Pause dazwischen.
Das machen doch die üblichen Sticks USB-seriell nicht?

Was kann man da machen?

Harald

Autor: Harald (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag:

habe mal mit einem Konverter experimentiert.
Die machen auch 1ms Pause.
Was nun?

Harald

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Harald (Gast)

>habe mal mit einem Konverter experimentiert.
>Die machen auch 1ms Pause.
>Was nun?

Die machen keine 1ms Pause, die übertragen paketweis im 1ms Raster, eben 
weil das der USB Rahmentakt ist. Also alle ankommenden bzw. zu sendenden 
Daten in einem Puffer sammeln und dann alles was im Puffer ist 
abschicken, 1mal / ms.
Teilweise warten die sogar noch länger, kann man beim FT232 einstellen.

MFg
Falk

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.