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.
> 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
Kannst du evtl. dein Flash-Protokoll ändern, damit du nicht auf das ACK warten musst?!
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.
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.
@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...
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.
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.
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.
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.
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.
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).
>Da haben die Entwickler ja mal was praktisches gemacht.
???
UART, FIFO, DMA => alte Hüte.
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.
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.
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 )
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.
@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:
1 | static DEVICE_ATTR(latency_timer, S_IWUSR | S_IRUGO, show_latency_timer, |
2 | store_latency_timer); |
3 | 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.
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
Nachtrag: habe mal mit einem Konverter experimentiert. Die machen auch 1ms Pause. Was nun? Harald
@ 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
Thread beobachten
Seitenaufteilung abschaltenBitte 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.