boootloader reloaded

[Boot (Gast)]

Hi,

Welcher Bootloader verwendet ihr erfolgreich?

Boot

[Peter R. (pnu)]

Den des BIOS auf meinem Motherboard, beim booten meines PC, sogar 
mehrmals täglich.

Aber das willst Du wahrscheinlich garnicht wissen.

Für genaueres sollte man da schon angeben, auf welchem Kontroller der 
bootloader befindlich ist, und welche Schnittstelle er benutzt. (USB, 
I2C, RS232, ....)

[Boot (Gast)]

Hast Recht, Peter :)

Ich würde gerne die fertige Produkte, die mit entweder AVR ATTiny oder 
ATMega ausgestattet sind, einfach wieder programieren.
Der 6-er ISP Anschulss ist nicht das optimallste.
Als Konsole habe ich  Linux auf Laptop mit USB anschluss.
avrdude hat jeder denke ich. Fremd Software ist nicht das beste.

RS232 - brauch man immer Converter, die Laptops habe keine RS232 
Anschlüsse mehr.
USB - denke ich die einzige option.

Das Protocol ist egal, sollte weniger Drähte haben.
Naturlich galvanisch getrennt wäre es mir lieber - kann nix kaputt 
gehen.
Funk - zu viele Komponente;
I2C - keine Erfahrung - vielleich das beste;
IR - sender/reciever - würde ich gerne verwenden - zuerst als Fantasie;

Laptop->USB->I2C->AVR(tiny|mega) ?

Wir macht ihr das?

[Boot (Gast)]

Zusätlich zu Programme hochladen will man oft mit dem Kontroller reden.
Man will auch weniger Anschlüsse haben - Programme hochladen und Daten 
übertragung könnte deswegen über die gleiche Schnittstelle erfolgen.

[Knut B. (Firma: TravelRec.) (travelrec)]

Ich benutze für jedes Projekt einen eigenen, spezialisierten Bootloader, 
der auch noch Debugfunktionen und System Inits mitbringt. Für mich gibt 
es also nicht "DEN" Bootloader. Vor einigen Jahren habe ich micht amit 
beschäftigt, eigenen Bootloader zu schreiben und das würde ich Dir 
eigentlich auch empfehlen wollen. Vorteil: Du kannst Dir alles selbst 
aussuchen, was das Ding können muss.

[Boot (Gast)]

Ja, Knut, ist eine gute Einstellung. Danke Dir für Deine Meinung.

Main aktuelles Software Problem löse ich mit HW-Mitteln:
- bootloader vergessen
- 6 Löcher unter drunter bohren
- 6-er IPS mit dem richtigen Adapter dran
- ausliefern ;)

Ich werde sowieso höchstens noch 3-4 mal den Software anpassen müssen.

Sonst die IR-Brücke reizt mich - einfach und robust.

[Knut B. (Firma: TravelRec.) (travelrec)]

Für Kundenupdates hat sich eine Schnittstelle bewährt, die der Kunde 
auch zur Verfügung hat. USB hat mittlerweile jeder, sogar an Tablets. 
FTDI-Chipsets zum Beispiel werden von allen Betriebssystemen (nativ) 
unterstützt. Es liegt also nahe, die Geräte mit einer Micro-USB-Buchse 
(so wie die an jedem Smartphone) zu versehen, dann hat jeder Kunde die 
Möglichkeit, ein Firmware-Update mit HTerm oder ähnlichen Tools 
aufzuspielen. Willst Du eine IR-Schnittstelle, musst Du dem Kunden einen 
"USB nach IR" Adapter mitliefern.

[Knut B. (Firma: TravelRec.) (travelrec)]

Alternativ gab es vor einiger Zeit mal ein Projekt, bei dem jemand Töne 
zum Update eines Controllers verwendet hat. Die dafür notwendigen Wave 
oder MP3-Dateien kann man per e-Mail an den Kunden schicken, Bootloader 
mittels Mini-Klinken-Kabel an das Smartphone, Tablet oder an den 
Computer anschließen, Play drücken, abwarten, fetig.


Hier:
http://www.mikrocontroller.net/articles/SOUNDRX

[Bernd K. (prof7bit)]

Knut Ballhause schrieb:
> dann hat jeder Kunde die
> Möglichkeit, ein Firmware-Update mit HTerm oder ähnlichen Tools

Soviel Aufwand im Gerät und dann den Kunden manuell mit hterm 
rumfrickeln lassen? Das ist wie kurz vor dem Ziel stehenbleiben und 
umkehren. Ein zusätzlicher halber Tag Entwicklung wird doch wohl noch 
drin sein um einen schönen GUI-Updater dazuzupacken bei dem man nur noch 
auf "start" klicken muss.

[Oliver J. (skriptkiddy)]

Ich setze für meine privaten V-USB-Projekte gerne einen angepassten 
USBaspLoader ein.

[Knut B. (Firma: TravelRec.) (travelrec)]

Bernd K. schrieb:
> Ein zusätzlicher halber Tag Entwicklung wird doch wohl noch
> drin sein um einen schönen GUI-Updater dazuzupacken bei dem man nur noch
> auf "start" klicken muss.

Sicher doch. Kommt auf den Kunden an.