Hi,
ich habe kürzlich den Bierdeckel-Programmer
Bierdeckel-Programmer
nachgebaut, nur auf Streifenplatine statt Bierdeckel. Fotos anbei.
Und er geht eher schlecht als recht, unter Windows (Parallels VM unter
Mac OS) hat's recht instabile USB-Verbindung, recht zufällig, aber
häufig immer diese Meldung:
1
avrdude: error: usbasp_transmit: usb_control_msg: sending control message failed, win error: Der E/A-Vorgang wurde wegen eines Threadendes oder einer
2
Anwendungsanforderung abgebrochen.
Unter Mac OS X kann er zwar meist erfolgreich ein Fuse Byte auslesen
(avrdude -c usbasp -p m8 -B 3 -P usb -U lfuse:r:fuse.txt:i)
aber wenn ich flashen versuche, dann gibt's diese Fehler, zufällig im
Zeitpunkt, mal gleich, mal beim connecten, mal beim Flashen:
Unter Windows hab ich das flashen noch nicht probiert.
avrdude: error: usbasp_transmit: usb_control_msg(DeviceRequestTO): transaction timed out
oder
1
avrdude: error: could not find USB device "USBasp" with vid=0x16c0 pid=0x5dc
Letzteres kommt nach ein paar Versuchen und dann ist der Programmer ganz
"weg", dann muss ich erst wieder neu einstecken.
So wird's unter Mac OS gelistet:
1
USB 3.0 Hi-Speed Bus:
2
3
Host Controller Location: Built-in USB
4
Host Controller Driver: AppleUSBXHCI
5
PCI Device ID: 0x1e31
6
PCI Revision ID: 0x0004
7
PCI Vendor ID: 0x8086
8
Bus Number: 0x14
9
10
USBasp:
11
12
Product ID: 0x05dc
13
Vendor ID: 0x16c0
14
Version: 1,04
15
Speed: Up to 1.5 Mb/sec
16
Location ID: 0x14100000 / 24
17
Current Available (mA): 500
18
Current Required (mA): Unknown (Device has not been configured)
Und so sieht die ganze Transaktion mit AVRDUDE aus:
Und die % complete sind jedesmal verschieden. Manchmal fängt's gar nicht
erst an (scheitert beim Reading), manchmal geht's bis 70%. Noch kein
einziges Mal erfolgreich geflasht.
Summa summarum: die Schaltung geht, aber da ist irgendwas instabil.
Wackelkontakte oder Kurzschlüsse können's nicht sein, ich hab die
Platine 3x von vorne bis hinten durchgemessen und supersorgfältig
gelötet.
Insgesamt wundert mich das: habe gelesen, dass diese Effekte unter
Windows "normal" sind, weil der Treiber wohl nicht ganz perfekt ist.
Aber unter *nix soll es eigentlich problemlos laufen.
Irgendeine Idee oder Erfahrung dazu?
Vg,
Conny
Wenn ich einen µC in einer Schaltung seh und keinen einzigen
Blockkondensator, dann schau ich gar nicht weiter nach sonstigen
Problemen.
Mittlerweile taucht dieses 'Wo sind deine Blockkondensatoren?' gefühlte
20 mal am Tag auf. Ist das wirklich so schwer, dass an jedes Digitial-IC
ein 100nF Kerko an die Versorgungsspannung muss?
Du hast völlig recht.
Zu meiner "Verteidigung" möchte ich hier vorbringen, dass ich nur diese
Schaltung unmodifiziert nachgebaut habe und sie ja - zumindest bei
manchen - zu funktionieren scheint.
In Schaltungen die ich selber kreiere sind die immer drin.
Meinst das ist hier der Grund?
Conny
Ist das Kupferlackdraht? Hast Du das durchgeklingelt, sprich: auf
Durchgang und Kurzschlüsse geprüft?
Die Lötstelle auf dem zweiten Bild, auf der untersten Leiterbahn, recht
genau mittig, die sieht noch schlechter aus als die anderen auch.
Conny G. schrieb:> Zu meiner "Verteidigung" möchte ich hier vorbringen, dass ich nur diese> Schaltung unmodifiziert nachgebaut habe und sie ja - zumindest bei> manchen - zu funktionieren scheint.
Leider gibt es auch hier eine Vollpfostenfrakion, die meint, diese
Kondensatoren wegdiskutieren zu können. "Bei mir geht es doch auch".
"Der 47µF reicht dicke aus. Wozu braucht man den kleinen 100nF
parallel?"
Das einzige, was man nicht braucht, ist darüber zu diskutieren.
Conny G. schrieb:> Meinst das ist hier der Grund?
Kann sein. Kann aber auch sein, daß der Fehler noch woanders liegt. (Das
ist dann für die Vollpfosten wieder der Beweis.)
Aber wenn etwas nicht funktioniert, beseitigt man erstmal die
offensichtlichen Fehler. Wenn es dann immer noch nicht läuft, kann man
zumindest das ausschliessen.
mfg.
niemand schrieb:> der Verdacht liegt nahe dass MOSI (pin5) verbindung zu GND hat, sieht> für mich zumindest so aus...
Dann würde das Ding gar nicht gehen, nicht einmal die Signatur
auslesen. Es geht aber nur im Betrieb mit größeren Datenmengen
schief.
> supersorgfältig gelötet.
Ein Tip. Isolierter Kupferlackdraht lässt sich wesentlich besser löten,
wenn man die Isolierung erst mal entfernt, ehe das Drahtstück
festgelötet wird.
Wenn es eine durchlötbare Isolierung ist, dann geht das ganz einfach,
indem man am Lötkolben einen Tropfen geschmolzenes Zinn auf der Spitze
hält und dann das Drahtende (Pinzette benutzen! wird heiß) so lange in
diesen Zinntropfen eintauchen lässt, bis die Isolierung weggeschmolzen
ist. Das erkennt man sofort, weil der Draht dann plötzlich das Zinn
annimmt. Und erst dann geht man damit auf die Platine.
Dann gibt es solche Lötstellen (Bild) nicht mehr.
Conny G. schrieb:> hat's recht instabile USB-Verbindung, recht zufällig
Das passt recht gut zu:
Karl Heinz Buchegger schrieb:> keinen einzigen BlockkondensatorKarl Heinz Buchegger schrieb:> Dann gibt es solche Lötstellen (Bild) nicht mehr.
Und es ist i.A. keine gute Idee, mit einem Draht, der nur ein paar µm
Isolation drauf hat, so dicht an einem Scharfkantigen Pins vorbei zu
fahren wie das recht an der 6-poligen Stiftleiste gemacht wurde...
> Und erst dann geht man damit auf die Platine.
Und fährt dann erst mal "nach oben" weg. Aber nicht einfach stramm quer
über die unisolierten Kupferbahnen. Denn beim direkten Anheizen auf der
Platine könnten ja ein paar Zehntel mm zuviel weggebrutzelt worden
sein...
> gfhf schrieb:>> sicher das die drähte unten isoliert sind ?>> Möglich, wenn es Lackdraht ist.> Aber das habe ich mich auch schon gefragt.
Ja, das ist Lackdraht. Hab's auch mehrmals, während dem löten und jetzt
beim Debuggen durchgemessen, da ist alles ok.
Keine Kurzschlüsse oder schlechte Kontakte.
Hab die zu lötenden Enden des Lackdrahts auch immer mit dem Dremel
abgeschmirgelt um ganz sicher zu gehen, dass es sich löten lässt.
niemand schrieb:> der Verdacht liegt nahe dass MOSI (pin5) verbindung zu GND hat, sieht> für mich zumindest so aus...
Nee, das passt ganz sicher, wie gesagt mehrmals durchgemessen.
Karl Heinz Buchegger schrieb:>> supersorgfältig gelötet.>> Ein Tip. Isolierter Kupferlackdraht lässt sich wesentlich besser löten,> wenn man die Isolierung erst mal entfernt, ehe das Drahtstück> festgelötet wird.
Ja, das habe ich gemacht, mit dem Dremel angeschmirgelt.
Das mit dem Lötzinntropfen hab ich schon probiert, das hat bei mir nie
so recht geklappt bei 270/280 Grad und den Lötkolben auf wahnsinnige
Temperatur stellen wollte ich dann auch nicht.
Conny G. schrieb:> bei 270/280 Grad
Normale Kolbentemperatur für Bleilot ist aber eher 320 °C, für
bleifreie dann 350 °C.
Hast du denn inzwischen mal den Kerko drangelötet?
Zur Motivation mal ein Aufbau, der tatsächlich so funktioniert. ;-)
Ich brauchte letztens mal schnell einen USBasp. Allerdings würde
ich ihn nicht im Regelbetrieb benutzen wollen mit diesem Aufbau.
Der Abblockkondensator ist natürlich dran. Alles Unnütze hingegen
wurde weggelassen („Angstwiderstände“ und sowas).
Conny G. schrieb:> Hab die zu lötenden Enden des Lackdrahts auch immer mit dem Dremel> abgeschmirgelt
Offensichtlich nicht ausreichend gut, denn ein richtig verlöteter Draht
(egal welcher Herkunft) ist allseitig von einer schönen Lötstelle
umschlossen...
> Hab's auch mehrmals ... durchgemessen, da ist alles ok.
Dann solltest du unbedingt noch die fehlenden Bauteile anbringen. Dazu
gibt es eine allgemeine Appnote von Atmel:
http://www.atmel.com/images/doc2521.pdfConny G. schrieb:> den Lötkolben auf wahnsinnige Temperatur stellen
320 Grad sind nicht viel, denn das ist ja das Heizelement, das die
Temperatur hat. Mit einer Microminispitze kommt davon nicht viel an der
Lötstelle an...
Sooo, denn 100nF Keko eingelötet, jetzt sind wir ein's weiter und es tut
schon mal bis zum Ende!
Paar mal nacheinander probiert, die USB-Verbindung ist jetzt stabil.
Allerdings gibt's jetzt beim Verify einen Fehler, zuverlässig immer an
derselben Stelle und dieselbe Bytedifferenz:
avrdude: verification error, first mismatch at byte 0x008f
23
0xc0 != 0x40
24
avrdude: verification error; content mismatch
25
26
avrdude: safemode: Fuses OK
27
28
avrdude done. Thank you.
Und ziemlich langsam ist es mit 16 Sekunden, das sind ja 3.500 Baud oder
so....?
Den -B Parameter schein der avrdude auf Mac zu ignorieren, bei der
Windows-Version wurde dann die SPI Clock entsprechend gesetzt.
Anderes .hex probiert, selbe Erscheinung andere Stelle:
(war auch wieder gleich bei 2 Versuchen)
Das sieht so aus als würden bestimmte Byte-Werte betroffen sein oder
sowas?
Mach mal ein Erase und schau nach, ob dann alle Bytes auf 0xff sind...
BTW: was willst du denn mit dem Programmer programmieren?
Ist an dieser zu programmierenden Schaltung auch ein Blockkondensator?
Lothar Miller schrieb:> Mach mal ein Erase und schau nach, ob dann alle Bytes auf 0xff sind...
Jau, wenn man das Auto-Erase mit -D abschaltet, sollte man sich
nicht wundern, wenn Unsinn rauskommt …
Jetzt mit Erase und es ging.
Allerdings ging's ein paar Mal wieder nicht, wieder die Instabilität der
USB-Verbindung wie ich sie ursprünglich hatte, timeout und so.
Nach ca. 5x aus-/einstecken wollte es dann mal, dann "read error" beim
Verify und ein weiteres Mal lief es dann durch und Verify ok.
Sehr seltsam alles, das macht keinen Spass. So kann man nicht damit
arbeiten.
Und es ist ja auch noch mysteriös, warum das Ding unter Mac OS so
langsam ist, während ich unter Windows noch vom Speed total beeindruckt
war.
Ich glaube ich baue das Ding nochmal neu und modifiziert, mit richtiger
geätzter Platine, ich mag die Lochraster und Streifenplatinen eh nicht.
Kann man sich anstrengen wie man will - das wird nie schön. V.a. hat
mich die Planung mit der Streifenplatine auch ordentlich Zeit gekostet,
da ätze ich lieber eine Platine.
Und muss damit den Bierdeckelprogrammer leider als Gurkenlösung
deklarieren.
Das mit dem Erasemodus abschalten dachte ich beim Rumprobieren aus
irgendeinem Grund, dass das eine gute Idee wäre und hatte dann vergessen
den Parameter wieder rauszunehmen.
Conny G. schrieb:> Und es ist ja auch noch mysteriös, warum das Ding unter Mac OS so> langsam ist, während ich unter Windows noch vom Speed total beeindruckt> war.
Klingt nach einem Problem mit dem libusb-API. Möglicherweise wartet
er für jeden (unvollständigen) Block erstmal den Timeout ab.
Wenn ich dran denke, werde ich heute abend mal mein USBasp an einen
Mac stecken und ausprobieren.
Also unter Windows läuft's jetzt auch recht stabil, aber ist auch
langsam, 12s für 6k write und 7s verify.
Hier sagt avrdude nur explizit am Anfang:
1
avrdude: set SCK frequency to 187500 Hz
Vermutlich ist die Version von avrdude auf Windows eine andere als die,
die ich auf Mac habe und nur die Meldung an sich ist ein Unterschied.
Möglicherweise liegt es aber nicht am SPI zwischen Programmer und
Atmega8, sondern am USB zwischen Mac und Programmer.
Conny G. schrieb:> 12s für 6k write und 7s verify
Naja, ein USBasp ist kein Rennauto. Das ist Software-USB, damit
kannst du ja nur Lowspeed-USB schaffen. Ist halt eine Billiglösung.
Schaue mir gerade den Code an, der auf den Attiny des Programmers ging
und kann da auf die Schnelle nichts finden, was eine niedrige
Geschwindigkeit bedeuten würde.
Eine Stelle gibt es:
1
/* set SCK speed */
2
if(slowClockJumper){
3
ispSetSCKOption(USBASP_ISP_SCK_8);
4
}else{
5
ispSetSCKOption(prog_sck);
6
}
slowClockJumper ist aber nicht gesetzt, das ist für Attinys als #define
auf 0 gesetzt.
Ich hab allerdings schon beim compilieren für das Flashen des
Programmers einen komischen Widerspruch gefunden:
Das VUSB, das im Hintergrund eingesetzt wird, hat die eine oder andere
Config, die von 16.500.000 Clock Speed spricht:
Während das Datasheet des Attiny85 sagt der High Speed Mode (weiss jetzt
grad nicht wie der heisst) wäre 16.000.000 und auch der USBASP Code
spricht eher von 16.000.000.
Aber ob das wiederum Ursache für langsame USB-Verbindung sein kann sehe
ich gerade beim Schnelldurchlauf noch nicht.
Jörg Wunsch schrieb:> Conny G. schrieb:>> 12s für 6k write und 7s verify>> Naja, ein USBasp ist kein Rennauto. Das ist Software-USB, damit> kannst du ja nur Lowspeed-USB schaffen. Ist halt eine Billiglösung.
Mal verglichen mit einem Programmer, der seriell arbeitet mit 115k - da
dauert das Flashen von 7k nur 2,7 Sekunden.
D.h. 12 Sekunden ist schon ungewöhnlich langsam, das sind ja kaum 20
kBit/s!?
Jörg Wunsch schrieb:> Zur Motivation mal ein Aufbau, der tatsächlich so funktioniert. ;-)
Sowas ähnliches hab ich gerade auch zusammengebaut :) Streng genommen
kein eigentlicher USBasp, aber ein USBaspLoader ist drauf, also
USB-seitig dieselbe Beschaltung. Das andere ist mein eigentlicher
USBasp, bei Interesse kann ich dir das Layout gerne zur Verfügung
stellen (wobei das auch ziemlich schnell zusammengeklickt ist).
Beide verfügen natürlich über Abblockkerkos.
Hallo,
da will ich meinen Senf auch noch beitragen, 2011 hatte ich einen
atTinyISP mit atTiny85 vorgestellt.
Beitrag "AVR USBtinyISP Programmer mit atTiny85"
Mit Schaltplan und Bilder, da sollte ein Nachbau möglich sein.
Die gesamte Schaltung sitzt nun natürlich in einem Schrumpfschlauch.
Hannes J. schrieb:> Ich frag mich gerade, wieviele meiner ISP-Sticks man in der Zeit> auflöten hätte können ;-)
Damit wäre die Werbung auch untergebracht :-))
(Hast aber nette Sachen!)
Spass beiseite, manchmal geht's ja nicht drum Zeit oder Geld zu sparen,
sondern um was auszuprobieren und wenn's nicht geht zu verstehen warum.
Und man lernt viel mehr wenn es eben nicht geht als wenn es auf Anhieb
funktioniert hätte.
Hatte sonst noch keine Gelegenheit mal per USB Protocol Analyzer zu
spionieren, was da eigentlich abgeht, jetzt bin ich dabei und es ist
interessant.
Die Analyse zeigt aber nur, dass manche Frames extrem lange dauern,
nicht was da dahinter steckt.
Habe ja gerade was gefunden, was die Ursache sein könnte, dass das USB
nicht so recht klappt:
Hier wird recht deutlich gemacht, dass die Frequenz ziemlich gut passen
muss, damit das USB Timing klappt:
http://vusb.wikidot.com/hardware
Und ich fand ja besagten Widerspruch zwischen ATTiny85-Takt von max 16
Mhz und dem 16.5 Mhz-Takt bei VUSB.
Dazu steht jetzt dort, dass man in dem Fall über die Kalibrierung den
Takt des Attiny85 auf die 16,5 Mhz bringt und das alles fein ist.
Ich habe allerdings das entsprechende #define vor dem Compilieren auf 16
Mhz geändert gehabt und damit die Kalibrierung ausgehebelt - und damit
wäre das Timing mehr off als maximal erlaubt.
Ich werde das jetzt mal zurückändern und einen neuen Attiny85 brutzeln -
ist ja leider eine Einmalsache, wenn man (noch) nicht HV programmieren
kann, denn es wird ja das RESET Pin ausgeschaltet.
USBasp benutzt die Oszillator-Kallibrierung, um den Takt von 16 auf 16,5
MHz zu tunen. Das ganze synchronisiert durch den Bus, das spart den
Quarz und v.a. die dafür nötigen Pins.
Genau, und eben das habe ich durch meine Änderung ausgehebelt.
Da müsste man nicht überrascht sein, dass es dann nicht mehr tut.
Grad neuen T85 gebrutzelt, jetzt bin ich gespannt.
Conny G. schrieb:> Dazu steht jetzt dort, dass man in dem Fall über die Kalibrierung den> Takt des Attiny85 auf die 16,5 Mhz bringt und das alles fein ist.> Ich habe allerdings das entsprechende #define vor dem Compilieren auf 16> Mhz geändert gehabt und damit die Kalibrierung ausgehebelt - und damit> wäre das Timing mehr off als maximal erlaubt.
Ganz ehrlich?
Das habe ich nicht verstanden.
Versuche es mal bitte mit einer besseren Grammatik.
http://vusb.wikidot.com/hardware
Which clock rate should I choose?
V-USB can currently handle clock rates of 12 MHz, 12.8 MHz, 15 MHz, 16
MHz, 16.5 MHz, 18 MHz and 20 MHz. These clock rates are precise! A
crystal with 11.9 MHz won't work! Only the 16.5 MHz and 12.8 MHz
variants allow a deviation of up to 1%. They are therefore suitable for
RC oscillators. 16.5 MHz is suitable for devices which can derive a 16
MHz clock from an RC oscillator (e.g. ATTiny25/45/85 and ATTiny26), 12.8
MHz can usually be reached by calibrating the 8 MHz RC oscillator.
Calibration of the RC oscilator is described at examples.
Das bedeutet:
Die ATTinys haben eine maximale Taktfrequenz von 16 Mhz lt. Datasheet.
Aber durch die Kalibrierung können sie auf 16.5 Mhz gebracht werden, was
die spezielle Implementierung der ASM-Routine für die USB-Kommunikation
braucht, die dafür gemacht ist 1% Abweichung zu verkraften.
Und ich habe beim Compilieren Fehler bzw. Warnings gehabt, die an der
Taktfrequenz lagen (Warning: F_CPU redefined) und habe das korrigiert
indem ich den Takt auf 16 Mhz gesetzt hatte. Also habe ich dem VUSB
einen Modus gegeben, wo es exakten Takt voraussetzen würde.
Allerdings funktioniert der "neue" Attiny85 mit der korrigierten 16.5
Mhz Config auch nicht. :-(
(Jetzt hab ich nur noch drei...).
> 12s für 6k write und 7s verify> D.h. 12 Sekunden ist schon ungewöhnlich langsam, das sind ja kaum 20> kBit/s!?
USB low speed schafft maximal 800Bytes pro Sekunde, da die Spezifikation
maximal 8 Bytes alle 10 ms erlaubt. Das wären 6.4kBit/s, dazu kommt wohl
noch Overhead für Steuerinformationen, Fehlererkennung etc. 500 Bytes/s
für's Schreiben sind also gar nicht so schlecht...
Ich sehe das USB Device aber in der Liste des USB Debuggers als "USB
Speed: Low (1,5 Mbit/s)".
Die 8 Bytes sind Packet Size, hab ich grad was gelesen. Und auch hier
steht 1,5 Mbit/s:
http://de.wikipedia.org/wiki/Universal_Serial_Bus#Datenraten
Anbei mal das Signal per Oszi - so ganz sauber im Vergleich zu diesem
hier:
http://forums.obdev.at/viewtopic.php?t=1620
(das 2. nach "by my side")
sieht es nicht aus... was meint ihr?
Wie funktioniert denn USB hier, gibt es unter dem was ich im USB
Protocol Analyzer sehe noch eine Transportschicht, die automatisch
CRC-basiert retransfers macht?
Uwe S. schrieb:> ich habe auch eine Firmware verlinkt. Die läuft bei mir.
Allerdings hast Du andere Pins im Einsatz, genau andersrum nämlich. D.h.
ich kann nicht einfach Deine Firmware auf meine Hardware anwenden...
Natürlich kann ich auch eine neue Schaltung bauen, aber darum geht's mir
grad gar nicht... das Ding muss ja so funktionieren und ich will
rausfinden was falsch ist.
Conny G. schrieb:> Boah, wahnsinn - was ist das in dem 1. Bild denn??? :-D
Das werdende Innenleben hiervon. Eine sinnlose Spielerei, die aus einem
Scherzmitbringsel meiner Kollegen entstand. Habe das Kart von einem
Bonbonspender von kik zum Leben erweckt. Im Heck steckt das Geraffel aus
einem ATtiny85, der sich am Rechner als HID Device anmeldet und dann
nach Befehlen vom PC Scheinwerfer oder Rücklichter ein- oder
ausschaltet, auf- oder abblendet oder mit einem in der Motorhaube
eingebautem Handy-Vibrationsmotor für den passenden Sound sorgt :)
Das Ganze als Indikator für eingehende Mails etc.
Den USBaspLoader hab ich allerdings wieder rausgeschmissen, der wollte
nicht und ich wollte das Ding nur schnell fertig haben. Muss zur Not
also ein ISP dranverkabelt werden.
Dadurch passt es natürlich gar nicht mehr zum Thread...
> Anbei mal das Signal per Oszi - so ganz sauber im Vergleich zu diesem> hier:> http://forums.obdev.at/viewtopic.php?t=1620> (das 2. nach "by my side")> sieht es nicht aus... was meint ihr?
Ich habe vergessen das Bild anzuhängen...
Also hier
http://forums.obdev.at/viewtopic.php?f=8&t=3059
sagt jemand, dass die meisten 7-8 kB/s, also 64 kBit/s an Speed bekämen,
und er selbst sogar 20-30kB / s (160kBit).
Die 64 kBit wären die Hälfte von seriell 115kBaud sein, also dürfte das
Programmieren bei mir dann statt 2.7 Sekunden nur 5-6 Sekunden dauern.
Aber es dauert 12, also habe ich nur 30kBit, also stimmt irgendwas
nicht.
Wenn's noch irgendwo ein fertiges Hex für den guloprog / Bierdeckelprog
gibt, kann ich das nochmal probieren um sicher zu sein, ob oder nicht es
an meiner Compilierung liegt.
Malte S. schrieb:> Das werdende Innenleben hiervon. Eine sinnlose Spielerei, die aus einem> Scherzmitbringsel meiner Kollegen entstand. Habe das Kart von einem
Lol, das ist allerdings witzig :-)
>Ich sehe das USB Device aber in der Liste des USB Debuggers als "USB>Speed: Low (1,5 Mbit/s)".> Die 8 Bytes sind Packet Size, hab ich grad was gelesen. Und auch hier> steht 1,5 Mbit/s> sagt jemand, dass die meisten 7-8 kB/s, also 64 kBit/s an Speed bekämen,> und er selbst sogar 20-30kB / s (160kBit).
Ich glaube, hier liegt ein mangelndes Verständnis des USB-Protokolls
vor. Die Bitrate auf der USB-Bushardware beträgt zwar 1.5Mbit/s, sie ist
aber keinesfalls voll nutzbar sondern wird durch die Spezifikation
erheblich eingeschränkt. Schliesslich handelt es sich bei USB im
Gegensatz zur RS232 um einen Bus und nicht eine Point-to-Point
Verbindung.
Welche Art von USB-Transfers benutzt denn der Baustein? Bei Low Speed
sind nur Control und Interrupt Transfers möglich. Mit letzteren schafft
man tatsächlich nur 800Bytes/s. Mit Control Transfers wären theoretisch
bis zu 24KByte/s drin, allerdings ist hier der Overhead relativ hoch, so
dass die nutzbare Bandbreite deutlich niedriger liegen wird. 30kB wären
nur unter Verletzung der Spezifikation möglich, dann wäre es kein
Wunder, dass es zu Fehlern kommt.
Low Speed ist eben nur für Geräte mit geringem Datendurchsatz wie Mäuse
oder Tastaturen gedacht. Jeder seriöse Programmer nutzt mindestens Full
Speed, wo auch die wesentlich leistungsfähigeren Bulk Transfers zur
Verfügung stehen.
Beste Grüße
Mike
Mike schrieb:> Ich glaube, hier liegt ein mangelndes Verständnis des USB-Protokolls> vor.
Da hast Recht :-) Danke für Deine Erläuterungen.
Es werden Control Transfers von 200 Bytes verwendet, die komischerweise
300ms lang dauern (s.u.)
Deiner Erklärung nach müsste aber die 7-8 kB/s schon erreichbar sein,
das wäre ja auch eine Programming-Zeit von 1-2 Sekunden - aber da bin
ich ja meilenweit von entfernt.
Wer hat denn noch Erfahrungen zum Speed solcher "Bierdeckelprogrammer",
wie lange brauchen Eure für einen Atmega8?
Karl Heinz Buchegger schrieb:> Wenn ich einen µC in einer Schaltung seh und keinen einzigen> Blockkondensator, dann schau ich gar nicht weiter nach sonstigen> Problemen.
Nun ja, ich habe auf dem Steckbrett meistens auch keine
Blockkondensatoren an jedem IC. Allerdings aber an mehreren Punkten
Elkos. Wenn die Taktfrequenzen nicht allzu hoch sind, geht das mal so,
habe das auch mit dem Oszi überprüft. Ich würde aber Blockkondensatoren
hinzu fügen, wenn es nicht fluppt.
Übrigens: Lochraster lassen sich mit richtigem Schaltdraht in Stärke
0,4mm auch wunderbar von der Bestückungsseite her verdrahten. Diese
Drahtstärke paßt oft in das selbe Bohrloch zusammen mit der IC-Fassung.
Ich hatte mal einen Meter 1000-er Telefon-Erdkabel 0,4mm vom Schrott.
Ja, das sind 2000m Drahtstücke, sehr gut für Basteleien.
Ansonsten dem TO mal vielen Dank für den Hinweis mit dem Bierdeckel.
Meine nächste Retro-Prozessorschaltung werde ich auf einem Pappkarton
statt Lochraster bauen. Ich überlege mir aber da auch eine
Verdrahtungsart an der Bestückungsseite. Gewurstele an der Lötseite wird
sehr schnell sehr dreckig unübersichtlich.
Einen 8085 mit seinen Peripheriebausteinen EPROM, RAM, Timer,
I/O-Baustein baute ich so auch mal auf Lochraster auf. Die Drähte Busse
band ich auch schön in Kabelbäume zusammen. Der Sinn und Tick für
Kabelbäume stammt bei mir noch aus einem alten Beruf. ;-)
Thread beobachten
Seitenaufteilung abschalten