ich tendier dann eher dazu schnell loszulegen und wenn das scheitert nochmal (automatisch) mit "failsave defaults" zu versuchen. Viele Anwender werden den Parameter nie verwenden und sich über den lahmen Prommer ärgern.
Für die 32khz targets hab ich extra einen Jumper auf dem avrdude.
-- MFG Gernot
Wieso? Benutzen die alle nur gebrauchte AVRs?
Ich mein wenn das langsame defaut währe würden viele immer langsam arbeiten und lästern dass das der Prommer zu lahm ist.
-- MFG Gernot
Ich glaube, wenn das Ding langsamer programmiert als es könnte, ist das bei weitem weniger störend, als wenn es garnicht programmiert.
Und es muß jeder neue AVR mindestens einmal mit der niedrigen Frequenz programmiert werden (nämlich zumindest die Takt-Fuses), um die höhere Geschwindigkeit überhaupt nutzbar zu machen. Bis dahin geht erstmal garnix.
Am 15.07.2011 17:32, schrieb Heiko Nocon:
Hi Gernot,
Ein automatisches Fallback wäre eine ganz simple Möglichkeit.
Definitiv, es ist so. Ich habe es gerade probiert. Den Parameter
-B10 gesetzt und wundervoll gemächlich in 8 Sekunden programmiert, ohne -Birgendwas wiederholt, selbe Zeit, auf -B0.5 geändert und schwups war das Ding in 3 Sekunden durch, ebenfalls wiederholt ohne -Birgendwas, 3 s. Prozessor gewechselt und wiederholt ohne -B geht nix. -B2.01 und schon gehts wieder mit knapp 5 Sekunden.
Offensichtlich merkt sich das wahlweise avrdude oder der USBprog
So long
Marte
P.S. Ich mein sehr wohl, dass das ein Bug ist, wenn ein jungfräuliches Prozessörchen mit einem extraparameter dazu überredert werden muss, überhaupt programmiert werden zu können. Allerdings würde ich sagen, dass der Bug hier bei Atmel liegt. Wie kann man ein Fertigungsdefault so setzen, dass man beim ersten Programmieren nicht mit voller Geschwindigkeit dran kommt!?!
Hallo Marte,
Am 18.07.2011 10:28, schrieb Marte Schwarz:
[...]
Ist so sicher nicht richtig, da die maximale Geschwindigkeit nur mit externem Quarz erreicht wird. Also müsste nach Deiner Interpretation der Default ein externer Quarz sein. (Stimmt, ich bin pingelig :-)). Anzumerken ist noch, dass die Brennsoftware von Atmel einen deutlcihen Hinweis auf diese Problem liefert, wenn die Signatur nicht gelesen werden kann.
Grüße, Kurt
-- KHTronik - Kurt Harders Elektronik, Softwareentwicklung, Opensource-Beratung Leimbacher Str. 36 42281 Wuppertal T +49 202 2 50 11 64 F +49 202 2 50 11 65 M +49 171 8 36 82 33
... was bloed waere wenn man mit nackten CPUs bestueckte Platinen programmieren will die dann hinterher mit RC-Oszillator laufen sollen - und daher gar keinen Quarz drauf haben.
Die Frequenz des Oszillators im Auslieferungszustand und das dazugehoerige Limit der ISP-Schnittstelle sind ja eindeutig dokumentiert. Also Atmel kann man da keinen Vorwurf machen, egal aus welchen Gruenden sie jetzt die 1MHz gewaehlt haben.
Micha
Am 18.07.2011 10:28, schrieb Marte Schwarz:
Der Prozessor braucht keinen Parameter um programmiert werden zu können. Den Parameter braucht der Programmer. Und ich persönlich empfinde es nicht als Bug, dass er sich meine Einstellung merkt, sondern ganz im Gegenteil.
Dazu hat Kurt ja schon was geschrieben. Um die höchste Geschwindigkeit zu erreichen müßte Atmel vorher wissen welche Clocksource Du verwenden möchtest und das dann einstellen. Das ist schwierig.
Nachteilig bei den Atmels ist halt dass der Prozessor immer mit der eingebauten Clocksource arbeitet. Stellt man das versehentlich was flasche ein steht man dumm da. Andere Prozessoren starten immer auf dem internen Oszillator und werden dann von der Software umgestellt.
MfG
Hallo zusammen,
Ja und?
Nee, aber wenn da ein externer Quarz dran ist und der dann nicht verwendet wird, ist das einfach doof.
Es gibt tatsächlich Prozessörchen, die mit einem Uhrenquartz die internen 40 MHz generieren. Wenn kein Quartz da ist, dann fällt das Dingens auf den internen RC-Oszillator zurück, der dann wieder die 42 MHz macht, nur nicht sooo genau. Wenn das Dingens dann läuft, kann man die Taktrate auch lustig absenken, aber beim Start und zum Programmieren hab ich zuerst mal volle Geschwindigkeit, was in der Serie schon sehr angenehm ist, schließlich bedeutet Zeit bekanntlich Geld und ob ich einen Proframmier/Verifizier Durchgang mit 10 Sekunden oder mit 30 Sekunden laufen lassen muss, macht ein Durchsatz vom Faktor 3.
Benutzerfreundlich wäre ein automatischer Fallback, alles andere ist eigentlich Murks.
Sie haben gepfuscht und der unbedarfte Anwender muss in der Doku im Kleingedruckten kramen und den Bug suchen, das ist und bleibt IMHO ein Bug.
Marte
Bei den Mega-AVRs schon, bei den XMegas hat Atmel auch dazugelernt.
Henrik
Bei den ATmega geht das aber nicht weil die keine PLL haben.
Sicher ist Zeit auch Geld, aber ich sehe da kein Problem: Bei einem AVR brennt man halt zuerst die Fuses (mit langsamem ISP Clock), das sind ja nur wenige Byte und der Zeitunterschied ist vernachlaessigbar. Danach hat man den Oszillator nach eigener Wahl und kann so schnell programmieren wie es dieser hergibt. Fast alle ATmega kommen mit dem internen RC-Oszillator wenigstens auf 8MHz, d.h. ganz grob auf halbe Maximalgeschwindigkeit. Erst ganz am Ende setzt man die Fuses dann passend fuers Zielsystem.
Micha
Hi Michael,
Wie die das machen ist mir doch völlig wurscht, nur so wie es ist ist es Murx.
Nenn mir einen Grund, warum diese Geschwindigkeit dann nicht default ist. Ganz abgesehen davon halte ich es für eien ausgemachten Bug im Konzept, dass solch elementaren Funktionen wie die Taktfrequenz und die Quelle via Fuses ausserhalb des Programmcodes definiert werden.
Na super... erst rein inn die Pantoffeln, dann wieder raus... echt überzeugend... für mich liest sich das eher wie eine Anleitung zu einem Würgaround
Marte
Am 18.07.2011 17:06, schrieb Marte Schwarz:
Du solltest Dir mal genau überlegen was eigentlich Bug bedeutet. Der Prozessor verhält sich genau so wie Atmel ihn im Datenblatt spezifiziert hat.
Nur weil es Dir nicht gefällt ist das noch lange kein Fehler. Es steht Dir frei keine AT-Megas zu benutzen.
MfG
Zumindest mein alter markII war ab Werk auf "langsam" eingestellt. Erst nachdem ich die Bitrate manuell hochgedreht hatte, programmierte er schneller.
Bist Du Dir also ganz sicher, daß Du deinen Programmer nicht irgendwann einmal vorher selbst umkonfiguriert hattest?
Gruß, Jürgen
Hi Jürgen,
Sehr, die war genau so jungfräulich wie die neuen Atmels.
Marte
Scheint wohl einfacher zu sein, einfach anzunehmen, Atmel habe gepfuscht, statt selbst über das Problem nachzudenken, oder?
Das ist dir doch jetzt schon mehrfach erklärt worden. Hier also nochmal, ganz langsam und zum mitschreiben: Möglicherweise gibt es Zielsysteme, die eben mit schnellerem Takt nicht können. Wenn zum Beispiel die Quelle, die den AVR speist, nicht so viel Strom liefern kann, z.B. parasitär Bus-powered. Dann funktioniert es halt einfach *nicht* mit
8Mhz (siehe z.B. Figure 28-2 vom Atmega32A Datenblatt), mit 1MHz aber schon.Ein "Bug im Konzept", aha. Vielleicht solltest du dich bei Atmel bewerben, um die ganzen Amateure und Pfuscher mal richtig aufzuschlauen? Dein Rat klingt unbezahlbar.
Gruß, Henrik
Hallo Hendrik,
Je mehr ich darüber nachdenke, desto furchtbarer finde ich dieses Konzept, das den Teilen zugrunde liegt. Furchtbarer aber noch die Umsetzung desselben.
klingt ja schon plausibel. Wenn ich aber mit einem Programmieradapter dran gehe, dann ist es auch ein kleines, damit den nötigen Strom zum Programmieren mitzuliefern. Ob man anschließend im Betrieb mit einer kleineren Frequenz arbeitet sollte mit dem Programmiervorgang wirklich nichts zu tun haben.
Das geht dank funktionierendem Markt deutlich einfacher. Abgesehen von dem AVR-NET-IO, die ich als fertige Kiste einsetze, werde ich um diese Mikrocontroller einen großen Bogen machen, wann immer es geht. Es gibt einfach genug µCs, die bessere Konzepte liefern und auch nicht teurer sind. Ich versteh wirklich nicht, warum sich Hobbyprogrammierer solch komische Teile antun. Abgesehen vom lochrasterfreundlichen Gehäuse sehe ich keinen wirklichen Vorteil.
Marte
Marte
Dann muß du u.U. in der Schaltung wieder Maßnahmen treffen, die diesen Fremdstrom daran hindern, Wege zu gehen, die er nicht gehen darf. Das ist wirklich keine besonders kluge Idee.
Da hast du doch eine einfache Lösung gefunden. Jetzt sind alle glücklich.
Unbeschränkte mächtige Entwicklungswerkzeuge und Unmassen existierender Code für lau, Programmer für ganz kleines Geld. Das sind auch schwerwiegende Vorteile, die viele andere µC nicht bieten.
Dazu noch:
- Gibt es an jeder Ecke
- Lassen sich schoen in Assembler programmieren
- Grosser Versorgungsspannungsbereich (1.8V bis 5V)
- Relativ schnell und trotzdem sparsam im Standby (ohne WDT typical
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.