Microcontroller über USB Programmieren (ohne Bootloader)

ISP Prommer kaufen
http://www.ebay.de/itm/51-AVR-Programmer-USB-ISP-USBASP-Programmer-for-ATMEL-/281749081989?hash=item41998dcf85:g:dQ0AAOSwu4BVpNGz
o.ä.

Bootloader rauswerfen

über ISP mit dem Prommer programmieren

Jupp Strupp schrieb:
> nein, da habt ihr (oder du) mich falsch verstanden... ich möchte
> NUR
> über den USB direkt am uC programmieren.

wenn du es nicht verstehst

Der Bootloader muss ja warten ob er gemeint ist!
Wenn dir die Wartezeit nicht genehm ist muss der Bootloader gehen!
Wenn der Bootloader gegangen wurde muss anders programmiert werden!
Das Leben ist nun mal kein Wunschkonzert und wenn die Hardware und das 
Konzept steht, eingebrannt und in PCB gemeisselt dann ist das Konzept 
nicht umzustellen!

Wenn ich Gemüse kaufe kann ich mir in der Pfanne daraus kein Steak 
machen nur weil ich das lieber esse.

Joachim B. schrieb:
> Wenn dir die Wartezeit nicht genehm ist muss der Bootloader gehen!
> Wenn der Bootloader gegangen wurde muss anders programmiert werden!

Du hättest auch einfach schreiben können, daß Atmel keinen Weg 
vorgesehen hat, einen "frischen" Controller über USB zu programmieren.

Jupp Strupp schrieb:
> ich habe das genau so verstanden, doch manchmal gibt es wundersame
> möglichkeiten, die einem gar nicht bekannt waren. deswegen habe ich
> lieber noch mal nachgefragt.

Wie hast du dir den Prozess denn vorgestellt? Wann und wie soll der BL 
aktiv werden und ein Programm akzeptieren?
Es muss auch nicht unbedingt ein "Bootloader" im engen Sinne sein. Also 
der am Anfang erst mal startet. Ich habe eine Anwendung auf vielen 
Controllern, die springen auf Befehl mitten im Programm (auf Befehl von 
aussen) zu einem Programmstück am Ende des Flashs und können dann so den 
restlichen Flash neu programmieren (die Daten kommen auch via UART).

Du bist da doch völlig frei und musst auch keinen BL von der Stange 
nehmen und am Anfang starten muss der auch nicht. Allerdings, sollte 
dein Programm mal zerschossen werden, dann wars das halt, weil in den BL 
kommst du dann nicht mehr.

Jupp Strupp schrieb:
> Kann man einen Atmel uC (mit USB
> Hardware) über USB Programmieren ohne einen Bootloader verwenden zu
> müssen?

Jain. Ich spare es mir, hier ins Detail zu gehen, weil das überhaupt 
nicht dein Problem ist.

> Ich kenne es von einigen Arduinos (mit und ohne FTDI IC), welche
> über USB und Bootloader programmierbar sind. Mein Problem hier ist aber,
> dass der Bootloader eben viel zu lange auf irgendeine Verbindung wartet
> und dadurch das eigentliche Programm erst stark verzögert startet.

Es ist kein Naturgesetz, daß ein Bootloader darauf warten muß ob der 
Nutzer einen Upload startet oder nicht. Der Bootloader kann genauso gut 
testen, ob der Nutzer einen Jumper gesteckt hat. Oder ob eine Taste beim 
Reset festgehalten wird. So ein Test dauert nur Mikrosekunden und ist 
dann sicher nicht zu lang.

Jupp Strupp schrieb:
> ok, also doch. ich habe bis dato nie einen bootloader benötigt und kenne
> lediglich die arduino dinger, welche ich aber immer rausgeschmissen
> habe. was ich wirklich nicht wusste ist, dass ein BOOTloader auch zu
> einem willkürlichen zeitpunkt gestartet werden kann? verstehe ich das so
> richtig?

Ja, was denkst du was ein Bootloader ist? Es auch nur ein Programm 
welches auf deinem Controller läuft. Manche Controller haben zwar fest 
eingebaute Bootloader (Rom-Loader) aber auch die muss man nicht nutzen.

Nur leider war deine Frage:
> über USB Programmieren ohne einen Bootloader verwenden

Und das geht halt nicht. Eindeutig falsch gefragt.

Jupp Strupp schrieb:
> Mein Problem hier ist aber, dass der Bootloader eben viel zu lange
> auf irgendeine Verbindung wartet

Wenn der Bootloader nur über HWB gestartet wird, sollte das nicht der 
Fall sein.

Jupp Strupp schrieb:
> ich bin
> davon ausgegangen, dass der bootloader ausnahmslos als erstes gestartet
> werden muss (und das möchte ich nicht).

Was Du nicht möchtest ist die lange Wartezeit. Daher zur Erinnerung:

Axel S. schrieb:
> Es ist kein Naturgesetz, daß ein Bootloader darauf warten muß ob der
> Nutzer einen Upload startet oder nicht. Der Bootloader kann genauso gut
> testen, ob der Nutzer einen Jumper gesteckt hat.

Daher wäre das "ausnahmslos" auch kein Problem, und Du könntest die 
besondere Hardware-Unterstützung des Bootloaders benutzen: separater, 
geschützter Code-Bereich.

Gruß Dietrich

<edit> Da war ich zu LAAAAANNNGGSAM;-)


Jupp Strupp schrieb:
> ich bin
> davon ausgegangen, dass der bootloader ausnahmslos als erstes gestartet
> werden muss (und das möchte ich nicht)

Meistens ist das schon so. ABER der Bootloader kann doch gleich als 
erstes checken, ob er gebraucht wird -> siehe Axels Post ...

Axel S. schrieb:
> Es ist kein Naturgesetz, daß ein Bootloader darauf warten muß ob der
> Nutzer einen Upload startet oder nicht. Der Bootloader kann genauso gut
> testen, ob der Nutzer einen Jumper gesteckt hat. Oder ob eine Taste beim
> Reset festgehalten wird. So ein Test dauert nur Mikrosekunden und ist
> dann sicher nicht zu lang.

Dann wird er eben praktisch sofort wieder beendet wenn der Taster oder 
Jumper ... und das User-Programm (Application) wird gestartet. Wenn das 
in der Application vorgesehen wird, kann der Bootloader auch von dort 
wieder aufgerufen werden, ohne einen Hardware-Reset.

Jupp Strupp schrieb:
> welche über USB und Bootloader programmierbar sind

Das sind eigendlich alle AVR mit USB-Hardware ab Werk. Sieh Dir mal FLIP 
an.
Allerdings ist das auch ein Bootloader.

Rufus Τ. F. schrieb:
> aß Atmel keinen Weg
> vorgesehen hat, einen "frischen" Controller über USB zu programmieren.

Doch, haben sie. Der Flip-Bootloader ist zumindest bei den -U-Typen an 
Werk drauf.

Jupp Strupp schrieb:
> ok, jetzt würde ich meine frage auch etwas anders formulieren. ich bin
> davon ausgegangen, dass der bootloader ausnahmslos als erstes gestartet
> werden muss (und das möchte ich nicht).

Stimmt doch gar nicht. Du möchtest keine Wartezeit. Der Bootloader kann 
deswegen trotzdem als erstes starten. Normalerweise will man das auch 
genau so. Und zwar aus zwei Gründen:

1. der Bootloader funktioniert auch dann noch, wenn der Anwendungscode 
kaputt ist. Z.B. nach einem fehlgeschlagenen Update.

2. Bootloader-Unterstützung im µC will man (wenn vorhanden) einschalten, 
denn dann ist der Bootloader vor dem Überschreiben geschützt. Allerdings 
wird dann der Bootloader i.d.R. auch automatisch gestartet.

Der Freiheitsgrad besteht darin, was für einen Bootloader du verwendest. 
Du mußt weder den vom Hersteller schon reinprogrammierten verwenden noch 
den Arduino-Bootloader. Es gibt für die AVR gefühlt 1000 verschiedene 
Bootloader mit ganz verschiedenen Features.

Lass den Bootloader prüfen ob eine Taste gedrückt ist. Wenn sie nicht 
gedrückt ist dann soll er ohne Umwege sofort in die Anwendung springen. 
Wenn sie gedrückt ist dann dreht erstmal der Bootloader seine übliche 
Runde bevors in die Anwendung geht. Brauchst nur nen freien Pin für die 
Taste. Pragmatisch, simpel und effektiv.

Pro-Tip: Warte ein paar dutzend NOPs nach dem Einschalten des Pullup für 
die Taste bevor Du sie abfragst, sonst kommt immer low raus.

Stefan U. schrieb:
> mit
> internem Pullup ca. 5 Takte

Die werden nicht reichen, BTDT.

1 Takt um den Pullup einzuschalten,
etliche Takte (sagen wir mal sicherheitshalber 10) warten bis die 
parasitären Kapazitäten über den dünnen Pullup aufgeladen sind.
1 Takt um den Pin abzufragen
2 Takte um zu springen.

Jupp Strupp schrieb:
> Hallo!
>
> Wie die Überschrift schon sagt... Kann man einen Atmel uC (mit USB
> Hardware) über USB Programmieren ohne einen Bootloader verwenden zu
> müssen? Ich kenne es von einigen Arduinos (mit und ohne FTDI IC), welche
> über USB und Bootloader programmierbar sind. Mein Problem hier ist aber,
> dass der Bootloader eben viel zu lange auf irgendeine Verbindung wartet
> und dadurch das eigentliche Programm erst stark verzögert startet.

Beim Arduino gibts welche, die einen Mega16U2 als USB-Seriell-Wandler 
haben. Dieser 16U2 kann genauso gut zusätzlich ISP-Programmer spielen. 
Damit hast Du das beste aus beiden Welten: keinerlei zusätzliche 
Software auf dem Haupt-AVR, und Programmieren ist jederzeit und unter 
allen Umständen möglich.

fchk

https://www.mikrocontroller.net/articles/AVR_Bootloader_FastBoot_von_Peter_Dannegger#Bootloader_anpassen_.28Angepasste_Version_f.C3.BCr_AVR-GCC-Toolchain.29

Dort wird ein Fastboot mit 0.33 Sekunden angepeilt.
Unter Anpassen steht zum Beispiel das man auch einen Pin konfigurieren 
könnte.