Hey,
da ich an meinem Rechner keinen freien seriellen Port habe, habe ich mir
einen USB/Seriell-Wandler gekauft. Das Teil wird auch richtig erkannt,
solange man nicht das mitgelieferte Kabel benutut ;) und dann habe ich
die "Schnittstelle" /dev/ttyUSB0 (ja, unter linux) zur Verfügung.
Zum programmieren habe ich bis jetzt immer sone vereinfachte
siprog-Variante benutzt, die ich jetzt an den Wandler angeschlossen
habe.
Wenn ich dann aber avrdude anschmeiße, um etwa fuses auszulesen wird das
zwar gemacht, aber sooo elendig lahm, dass alleine die fuse-Bits 5 sec.
brauchen. Beim Flash schreiben habe ich nach nen paar minuten
aufgegeben.
Hat jemand ne Idee wie man das ganze ein biiiiischen beschleunigen kann?
Baudrate hoch setzen hat iwie nichts sichtbare an "performance"
geliefert.
Vielen Dank, Enrico
Um was fuer einen Wandler handelt es sich denn? Vielleicht ist avrdude
nicht darauf "vorbereitet" und sendet die Daten unguenstig (byteweise)
an die Schnittstelle wodurch auf einem USB-Bus ein sehr hoher overhead
entsteht. Mach mal ein "tail -f /var/log/messages" und steck das Teil
mal ein. Stell die Messages hier mal ein?
Bist du sicher, dass es wirklich am USB-RS232-Wandler liegt oder könnte
das auch der Programmieradapter sein?
Ich verwende am Notebook (ja, unter linux) ausschließlich solche Wandler
(usb 2.0 von digitus). Hatte bisher noch keinerlei solcher
Performance-probleme.
Gruß
Christian
Das ist normal. Der Programmieradapter ist bestimmt der einfachste mit
den 2 Dioden und paar Widerständen. Da hilft nur ein richtiger ISP
Programmer mit "Intelligenz" also der originale AVR ISP oder ein Nachbau
auf Basis der AN910.
Wenn der Rechner noch eine echte serielle Schnittstelle hat, dann häng
den Programmer da dran und das andere Gerät an die USB-Serielle.
USB-Serials sind ganz nett um Datenströme zu übertragen, aber pinwackeln
ist schnarchlangsam.
ISP via RS232 macht ein Port-Bangig, d.h. wackelt "von Hand" an den Bits
des RS232, um das SPI-Signal zu basteln.
Jenachdem, wie gut sowas vom der USB-RS232 Hardware bzw dem Treiber
unterstützt wird, braucht das eben Zeit, weil für jede Flanke zwei
Pakete gesendet werden müssen. Es ist also nicht möglich, ein ganzes
Byte oder sogar mehrer Bytes per BULK zu übertragen, wie bei einer
Standard-RS232 Kommunikation.
Ich habe mit USB->RS232 ähnliche Erfahrungen gemacht. Serielle
Standard-Kommunikation war einigermassen ok, aber für ISP absolut
unbrauchbar.
Ich hab den Adapter denn wieder zrückgeschickt, Hatte den vom Reichelt
und da geht das anstandslos.
Christian R. wrote:
> Das ist normal. Der Programmieradapter ist bestimmt der einfachste mit> den 2 Dioden und paar Widerständen. Da hilft nur ein richtiger ISP> Programmer mit "Intelligenz" also der originale AVR ISP oder ein Nachbau> auf Basis der AN910.
Käse.
Mit nem Billig-Adapter dauert das Lesen/Setzen der Fuses
Sekundenbruchteile.
Und die Übertragungsrate in Bits/(s*€) wird von einem "professionellen"
nicht überboten ;-)
Johann L. wrote:
> Käse.>> Mit nem Billig-Adapter dauert das Lesen/Setzen der Fuses> Sekundenbruchteile.
Nicht richtig mitgelesen, oder?
Mit dem Billig-Adapter geht das Programmieren genau so schnell wie der
Serielle Port mit seinen Pins wackeln kann. Das ist bei einem "echten"
Port "schnell", und bei einem USB->RS232 Wandler "Schnarchlangsam".
Ein Programmierer mit Eigenintelligenz ist hingegen nur von der Baudrate
abhängig, und die ist bei "echtem"- und USB-Seriellport gleich.
Ernst Bachmann wrote:
> Johann L. wrote:>> Käse.>>>> Mit nem Billig-Adapter dauert das Lesen/Setzen der Fuses>> Sekundenbruchteile.>> Nicht richtig mitgelesen, oder?>> Mit dem Billig-Adapter geht das Programmieren genau so schnell wie der> Serielle Port mit seinen Pins wackeln kann.
Ich habe nichts anderes behauptet. Präziser wäre "mit Billig-Adapter
ohne zwischengeschalteten USB-Seriell-Converter" gewesen.
Und genau deshalb ist die Verzögerung nicht dem Billig-Adapter
anzulasten.
> Ein Programmierer mit Eigenintelligenz ist hingegen nur von der Baudrate> abhängig, und die ist bei "echtem"- und USB-Seriellport gleich.
Die Verzögerung beim Setzen/Rücksetzen von Handshake-Leitungen
unterliegt nicht den Baudrate-Einstellungen.
Johann L. wrote:
>> Mit dem Billig-Adapter geht das Programmieren genau so schnell wie der>> Serielle Port mit seinen Pins wackeln kann.>> Ich habe nichts anderes behauptet. Präziser wäre "mit Billig-Adapter> ohne zwischengeschalteten USB-Seriell-Converter" gewesen.> Und genau deshalb ist die Verzögerung nicht dem Billig-Adapter> anzulasten.
Hat das jemand getan? Nein. Christian hat nur darauf hingewiesen, dass
eben die Kombination "USB-Seriell + Billigadapter" Probleme macht.
>> Ein Programmierer mit Eigenintelligenz ist hingegen nur von der Baudrate>> abhängig, und die ist bei "echtem"- und USB-Seriellport gleich.>> Die Verzögerung beim Setzen/Rücksetzen von Handshake-Leitungen> unterliegt nicht den Baudrate-Einstellungen.
Das hat auch niemand behauptet. Diese Programmer (z.B. STK500 +
Kompatible) benutzen die Hanshake-Leitungen garnicht, insofern sind die
Verzögerungen dort komplett irrelevant.
So, jetzt hol ich mir erstmal einen Kaffee, bevor ich nochmehr unnötige
Streitereien vom Zaun breche... Hatte/hab nen stressigen Tag, Sorry
@all.
/Ernst
Hallo Enrico,
war bei mir ähnlich, 8Byte/s mit seriell-USB-Adapter und Pollin-Board,
mit avrdude oder uisp unter Linux.
Ich habe mir dann einen USBProg gekauft.
Wenn's geht dann geht es schnell, aber manchmal hakt die
USB-Datenübertragung.
Jürgen
Ok, danke für die Antworten :)
Werde den Wandler jetzt nur für normale serielle Übertragung nutzen und
zum programmieren den echten Ports nehmen ;) So scheints auf jeden Fall
besser zu funktionieren... :D
Jürgen Stuber wrote:
> Hallo Enrico,>> war bei mir ähnlich, 8Byte/s mit seriell-USB-Adapter und Pollin-Board,> mit avrdude oder uisp unter Linux.>> Ich habe mir dann einen USBProg gekauft.> Wenn's geht dann geht es schnell, aber manchmal hakt die> USB-Datenübertragung.>> Jürgen
Sieht das bei dir dann so aus?
Reading | ################################################## | 100%
0.25s
avrdude: verifying ...
avrdude: 526 bytes of flash verified
avrdude: stk500v2_recv_mk2: error in USB receive
avrdude: stk500v2_cmd(): short reply, len = 0
avrdude: safemode: Verify error - unable to read lfuse properly.
Programmer may not be reliable.
avrdude: safemode: Fuses OK
avrdude done. Thank you.
Tritt bei mir nur bei manchen Hexfiles auf...