www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik LAN-Bootloader für AVR-NET-IO usw.


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: Tobias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

anbei ein LAN-Bootloader, den ich dieses Wochenende für mein 
Pollin-Board gebastelt habe. Vielleicht kann ja außer mir noch jemand 
etwas damit anfangen. Die Version im Anhang ist für einen Mega644. Nicht 
die Fuses vergessen: BOOTSZ1 = 0, BOOTSZ0 = 0, BOOTRST = 0.
Der Bootloader wartet nach dem Einschalten/Reset 3 Sekunden auf Befehle 
des Flashtools. Bekommt er keine Antwort, wird die Applikation 
gestartet.

Fragen, Kritik und Verbesserungsvorschläge willkommen.

Tobias

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hört sich interessant an, es gab schon mal eine solche Implementierung 
hier im Forum. Möchtest du den Quellcode herausgeben? Ich würde den 
Bootloader gerne per Website aufrufen können.

Grüße,

Peter

Autor: Tobias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
>es gab schon mal eine solche Implementierung hier im Forum.

In der Tat. Jetzt wo Du's sagst hab ich auch etwas entdeckt. Aber halb 
so schlimm.

>Möchtest du den Quellcode herausgeben?

Sobald die Sache etwas gediehen ist denke ich schon.

>Ich würde den Bootloader gerne per Website aufrufen können.

Lässt sich das nicht über einen jmp zu dessen Startadresse oder einen 
Watchdog-Reset erledigen, oder verstehe ich da etwas falsch?

Anbei ein kleines Update mit einer Version für das originale AVR-NET-IO 
mit mega32-Controller. Die Fuse-Settings sind die gleichen wie beim 
mega644.

Tobias

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ohne Quellcodes kan keiner damit wirklich etwas anfangen! Das 
Consolenprogramm ist unzureichend, und verbesserungswürdig!

Zudem benutzt nicht jeder M32 und m644 für den ENC28j60!

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ohne Quellcodes kan keiner damit wirklich etwas anfangen!

Weil?

>Das Consolenprogramm ist unzureichend, und verbesserungswürdig!

Daher auch meine Bitte um Verbesserungsvorschläge :-)

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias wrote:

>
> Weil?
>

Mehr Augen mehr sehen als Zwei!
Programmfehler sind so nur duch "merkwürdige Reaktionen"  feststell aber 
nicht beseitigbar!

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also ohne codes ist sowas ja nahe zu useless, man kan ja nichts manuel 
nach bessert oder sachen adden :/

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dann schieß mal los mit Verbesserungsvorschlägen. Du willst mich doch 
hoffentlich nicht arbeitslos machen? :)

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Naja, "Verbesserungsvorschlägen" ist ewas relative, was ich zB. gerne 
bräuchte wäre dsa der loader auch per Serial port ansprechbar wäre.
Wer anderer würde vieleicht eine PW obtion brauchen, so das nicht jeder 
die firmware flashen kann, usw...
Eine Binnary ist halt unflexibel.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias wrote:
> Dann schieß mal los mit Verbesserungsvorschlägen. Du willst mich doch
> hoffentlich nicht arbeitslos machen? :)

Geht nicht, da ich keinen M32 und M644 benutze!

Dein Windowsprogramm werde ich auch so nicht öffnen, da ich nicht weis 
was im Code alles verborgen liegt!

Du kommst um eine Codeveröffendlichung also nicht rum!

Autor: Freakshow (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich sehe es genauso: Ohne Sourcecode ist das unbrauchbar!

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Ich sehe es genauso: Ohne Sourcecode ist das unbrauchbar!

Das verstehe ich nicht. Ich habe nur das Hexfile geflasht und es 
funktionierte auf Anhieb.

> Du kommst um eine Codeveröffendlichung also nicht rum!

Um was wetten wir?

Naja, however: Hiermit entschuldige ich mich bei allen für meine 
Dreistheit, etwas, das vielleicht noch jemand außer mir brauchen könnte, 
einfach hier zu veröffentlichen. Kommt nicht mehr vor, versprochen.

Tobias

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was hast Du den gegen eine Codeveröffendlichung?

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm ... und warum willst du den Code nicht veröffentlichen?

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tobias wrote:
>> Ich sehe es genauso: Ohne Sourcecode ist das unbrauchbar!
>
> Das verstehe ich nicht. Ich habe nur das Hexfile geflasht und es
> funktionierte auf Anhieb.
>
>> Du kommst um eine Codeveröffendlichung also nicht rum!
>
> Um was wetten wir?
>
> Naja, however: Hiermit entschuldige ich mich bei allen für meine
> Dreistheit, etwas, das vielleicht noch jemand außer mir brauchen könnte,
> einfach hier zu veröffentlichen. Kommt nicht mehr vor, versprochen.
>
> Tobias

Wenn Du meine Posts so liest wie Du sie zitierst, ist es klar das Du es 
nicht verstehst! Wie soll ich ein M32-Hexfile in nen M128 bringen? Das 
geht doch garnicht!

Autor: ... ... (docean) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leute, nun lasst ihn doch das machen wie er will...

Wenn er den Code nicht veröffentlichen möchte (warum auch immer) dann 
ist das halt so.

Ihr braucht seine Software ja nicht benutzen!

Alle anderen freuen sich das es funktioniert (oder auch nicht) und sind 
auch glücklich...

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hier ist doch ein Forum oder? Wenn er etwas postet, ohne Quelle, 
dann ist das nonsens! Eventuell hat er den Loader garnicht selber 
geschrieben, sondern im Netz gefunden. Solange er die Codes nicht 
offenlegt, erntet er keinen Dank! Alleine das Windows-Programm ist für 
mich verdächtig!

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Diener wrote:
> Hört sich interessant an, es gab schon mal eine solche Implementierung
> hier im Forum.

Wo genau, irgendwie kann ich die grade nicht finden :/

@Tobias
habe das teil man ganz vorsichtig ausprobiert und wen es drauf ist 
funtzt die uart Schnittstelle nicht mehr, kommt nur noch müll an :(

Autor: Peter Diener (pdiener) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Wo genau...

Hier: Beitrag "Atmega via Ethernet flashen"

Ich habe auch mal in dem AVR-Net-IO Thread etwas darüber gelesen, hier 
wurde vorgeschlagen, eboot von Ethernut als Basis dafür zu verwenden:
Beitrag "Re: AVR für wenig Geld im LAN"
Beitrag "LAN-Bootloader"

Siehe: http://www.ethernut.de/en/eboot/index.html

Grüße,

Peter

Autor: Tobias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich beschränke meine Antworten auf die konstruktiven Beiträge:

@docean:
Du schreibst mir aus der Seele :)

@trax:
Der UART wurde nach Verlassen des Bootloaders nicht in den gleichen 
Zustand wie nach einem Hardware-Reset gesetzt. Hätte nicht gedacht, dass 
das ein Problem werden könnte. Hab dies jetzt mal geändert. Das PC-Tool 
führt jetzt zusätzlich nach dem Schreiben noch ein Verify durch.

Tobias

Autor: Jens Mundhenke (dl4aas) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Tobias,

ich habe das Tool ausprobiert und auf Anhieb Erfolg beim Programmieren 
gehabt. Herzlichen Glückwunsch!

Vor ein paar Wochen habe ich eine andere Form von Bootloader 
programmiert: Er benutzt das Standard-Protokoll TFTP, um sich sein 
Hex-File von einem TFTP-Server zu holen. Falls jemand daran Interesse 
hat, ich habe den Stand 'as it is' mal angefügt. Er basiert auf Ulrich 
Radigs Webserver und ist soweit kompatibel zu ihm. Interessant evtl. das 
kleine Modul syslog.c, dass das Versenden von SYSLOG-Nachrichten 
erlaubt. Hiervon gibt es auch noch eine etwas erweiterte Version, die 
eigentlich zur Veröffentlichung bereitliegt.

Beim Programmieren sind mir die Probleme mit dem Verlassen und 
Neustarten der AVR-Applikation auch untergekommen, gelöst sind sie noch 
nicht perfekt: Man sollte wohl am besten alle Interrupts der Applikation 
sicher sperren (also auch die einzelnen Enable-Bits), bevor man den 
Bootloader anspringt. Oder (besser UND) dieser sollte das als erste 
Massnahme auch tun, um Seiteneffekte zu verhindern.

Vielleicht liegt es daran, dass Dein Bootloader bei mir nur nach einem 
Hardware-Reset funktioniert. Wenn ich meine Funktion zum Anspringen des 
meines Bootloaders verwende, geht nichts mehr:

void command_load (void)
{
  char temp;

  cli();      // Disable all interrupts
  temp = MCUCR;      // Get MCUCR
  MCUCR = temp | (1<<IVCE);  // Enable change of Interrupt Vectors
  MCUCR = temp | (1<<IVSEL);  // Move interrupts to Boot Flash section
  asm volatile ( "jmp 0xE000" );// start bootloader
}

Zu meinem / unserem Verständis: Wie läuft die Kommunikation zwischen 
PC-Teil und AVR-Board ab? Da keine IP-Adressen angegeben werden, wohl 
irgendwie über Ethernet-Pakete mit Broadcast. Über Router hinweg kommt 
man da wohl nicht...

Gruß
Jens

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Tobias
Danke, nun funtzt das uart wieder wie es soll :)
Ich benutze das uart zum debugen lase mit da texte und so ausgeben.

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens:
Um von der Applikation aus den Bootloader aufzurufen ist ein 
Watchdog-Reset vermutlich die sicherste Lösung. Eine elegantere 
Möglichkeit wäre vielleicht noch, den Bootloader selber anhand der 
entsprechenden Statusflags erkennen zu lassen wie er aufgerufen wurde 
und ihn ggf. selbst einen Watchdog-Reset auslösen zu lassen. Werde dies 
bei der nächsten Änderung mal umsetzen.
Die Kommunikation läuft tatsächlich nur über Broadcasts und ist auf's 
LAN begrenzt. Ich wollte ein Tool haben, das komplett ohne Angaben von 
IPs/MACs oder der Einrichtung irgendwelcher Server einfach direkt nach 
dem Anstöpseln funktioniert. Im Augenblick fehlt jedoch noch jegliche 
Adressierung - will sagen: Sollten einmal mehr als ein Bootloader zur 
gleichen Zeit aktiv sein, gibt's mit Sicherheit Chaos. Steht aber schon 
auf der ToDo-Liste.

@Trax:
Endlich auch mal positives Feedback :) Freut mich!

Tobias

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was noch cool wäre wäre wen man in der eigenen Anwendung irgendwie ein 
reset machen könnte so das man da das teil progen kann ohne hinzugehen 
und es manuell zu reseten, das wäre dieses Watchdog-teil wen ich das 
richtig verstehe, darauf freue ich mich schon.
Ansonst was noch cool wäre, wären comando zeilen obtionen für
1- wie lange er warten soll incl unendlich
2- kein verify fals man nur schnell was testet

Trax

Autor: Jens Mundhenke (dl4aas) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

an einem handlichen Stück Code zum Auslösen des WD-Resets wäre ich auch 
interessiert. Bisherige Versuche sind da leider gescheitert. Wäre die 
optimale Abrundung zum Bootloader.

Meine Version weiter oben hat allerdings einen Vorteil: Damit kann der 
Bootloader auch gestartet werden, wenn BOOTRST nicht aktiv ist...

Trax Ideen zur Optimierung des PC-Tools klingen auch für mich 
schlüssig...

Jens

Autor: Tobias (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Trax:
Während Deine Applikation läuft hat der Bootloader keine Möglichkeit, 
sich selbst zu starten. Das muss schon Deine Applikation auf ein 
Kommando von Dir hin erledigen. Dazu einfach den Watchdog starten und in 
einer Endlosschleife auf einen Reset warten. Voraussetzung ist natürlich 
- wie Jens schreibt - die aktivierte BOOTRST-Fuse.
Die Kommandozeilenparameter sind in Arbeit.

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oki, soweit klar,
aber wie kann ich nun in der Anwendung ein Reset auslösen, gibst da ne 
fertige C Funktion, oder muss ich in ASM irgendwas aufrufen?

Autor: Dirk Broßwick (sharandac)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens

schau mal unter folgenden Link [1], dort hatte ich schon mal gepostet 
wie man einen WD-Reset auslöst. Steht auch so in der AVR-libc als 
Beispiel.
Funktioniert so auch auf einen ATmega644, auf einen ATmega32 habe ich es 
noch nicht getestet, sollte aber auch gehen.

[edit] Danach könnte man im Bootloader doch abfragen ob es ein WD-Reset 
war oder nicht, und dann entsprechend den Bootloader ausführen?

CAY Dirk

[1] Link: Beitrag "Re: Atmega2561 Watchdog"

Autor: Jens Mundhenke (dl4aas) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Dirk,

danke für Deinen Tip, den ich jetzt mal umgesetzt habe:

Das eigentliche Programm hat dieses Stück Code bekommen, um den WD 
auszulösen:
//------------------------------------------------------------------------------
// jump to bootloader
void command_load (void)
{
  char temp;

  cli();                        // Disable all interrupts

  // changing interrupt vector to bootloader section
  // only needed if BOOTRST is not used
  temp = MCUCR;                 // Get MCUCR
  MCUCR = temp | (1<<IVCE);     // Enable change of Interrupt Vectors
  MCUCR = temp | (1<<IVSEL);    // Move interrupts to Boot Flash section

  // enable watchdog and release it
  do {
    wdt_enable(WDTO_15MS);
    for(;;){}
  } while(0);
}

Und im Bootloader wurde dieses eingefügt:
//----------------------------------------------------------------------------
// wdt_init - Watchdog Init used to disable the CPU watchdog
//         placed in Startcode, no call needed
#include <avr/wdt.h>

void wdt_init(void) __attribute__((naked)) __attribute__((section(".init1")));

void wdt_init(void)
{
    MCUSR = 0;
    wdt_disable();

    return;
}

Es scheint zu funktionieren. Die seltsame for/while-Schleife ist wohl 
für - oder besser gegen - den Optimierer?

@ Tobias,

wenn ich alles richtig verstanden habe, wäre es notwendig, dass auch 
Dein Bootloader den 'Watchdog-Absteller' bekommt, um per WD-Reset 
gestartet werden zu können. Ist das machbar? Denn ich merke schon, dass 
die Handhabung in vielen Fällen wesentlich einfacher ist als bei meinem. 
Zumindest wenn wir über ein kleines Netz reden.

Jens

Autor: Tobias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
> ...dass auch Dein Bootloader den 'Watchdog-Absteller' bekommt...

Gute Idee. Hab ich soeben eingebaut.

Tobias

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wen ich jetzt den code von Jens aufrufe wird der rebooten und eine 
neue FW laden, ist ja supi danke.

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also irgendwie funtzt das bei mir nicht, wen ich den code aufrufe bleibt 
das teil hängen und verbleibt so bis ich es lönger vom strom trenne :/

Autor: Tobias (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, das wird vermutlich mein Fehler gewesen sein. Probier's mal 
hiermit.

Autor: Trax Xavier (trax)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super!
jetzt Funtzt es :D

Autor: Hans Wurst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Moin,
bin Anfänger(µC und C) deshalb meine blöde frage. Is an dem Code was 
auszusetzen? Und kann man das irgendwie besser schreiben? Vorallem diese 
Kopiererei am Anfang gefällt mir nicht wirklich.

if((ip->IP_Destaddr == 0xFFFFFFFF) && ETHERNET_IP_DATAGRAMM )
{
  DEBUG_STACK("Broadcast empfangen...\r\n");
  char str_buf[11];
  for (int a = UDP_DATA_START;a < (UDP_DATA_START+11);a++)
  {
    str_buf[a-UDP_DATA_START] = eth_buffer[a];
  }
  str_buf[11] = '\0';
  if ( strcmp(str_buf, "AVRnetflash") == 0 )
  {
    DEBUG("AVRnetflash -> reset...");

    cli();                // disable interrupts

    char temp;
    temp = MCUCR;

    MCUCR = temp | (1<<IVCE);     // Enable change of Interrupt Vectors
    MCUCR = temp | (1<<IVSEL);    // Move interrupts to Boot Flash 
section

    do {
      wdt_enable(WDTO_15MS);
      for(;;){}
    } while(0);
  }
}

Grüße Hans Wurst

Autor: Johannes Studt (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hab den Bootloader auch gerade mal ausprobiert, völlig problemlos. Jetzt 
wäre es nur hübsch, wenn es das Flashtool auch irgendwie für andere 
Betriebssysteme gäbe...

/Hannes

Autor: Mehmet Kendi (mkmk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johannes Studt schrieb:
> Hab den Bootloader auch gerade mal ausprobiert, völlig problemlos. Jetzt
> wäre es nur hübsch, wenn es das Flashtool auch irgendwie für andere
> Betriebssysteme gäbe...
>
> /Hannes

Falls Du mit "für andere Betriebssysteme" "für andere ATmegas" meinst, 
so spricht du mir aus dem Herzen :)

Autor: Johannes Studt (demofreak)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nää. Ick meen Linux für det Flashtool.

/Hannes

Autor: Jens Mundhenke (dl4aas) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

aus aktuellem Anlaß zwei Ergänzungen zum meinem weiter oben gepostetem 
Bootloader per TFTP:

- bei Files größer 48k gibt es Probleme. Abhilfe: In tftp.c, Zeile 70, 
die Variable tftp_block von Char auf Unsigned Int umstellen (Danke, 
Heiko!)

- bei verschiedenen Compilerversionen wird der Bootloader zu groß. Da 
hilft sparen an den Texten...

Gruß
Jens

Autor: Chris M. (shortie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens,

Mega vielen Dank :-) - mehr kann ich dazu nicht sagen außer dir noch 
Schöne Feiertage zu wünschen.

Autor: xelarep (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bin vor einiger Zeit über diesen Thread gestolpert. Gibt es hier was 
neues? Finde den Bootloader von Jens Mundhenke interessant, habe ihn 
aber noch nicht auf meinem AVR NetIO mit 644P getestet.
Hab nur kurz die Quellen übereflogen. Sehe ich das richtig, dass sich 
der Atmel nach jedem Reset mit dem TFTP verbindet und updatet? Oder hab 
ich was übersehen?

Gruß,
Alexander

Autor: Chris M. (shortie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der TFTP-Bootloader wird mittlerweile von mehreren Personen zusammen mit 
einem ATmega 644 auf dem AVR-NET-IO genutzt und funktioniert meines 
Erachtens hervorragend. Richtig ist daß der Bootloader bei jedem 
Hardwarereset aktiv wird und sich das Bootfile zieht. Vermutlich ist das 
auch nur über das Ablegen einer "Seriennummer" sowohl im EEPROM wie auch 
auf dem TFTP-Server abzustellen, da für eine Überprüfung des Hexfiles 
zuerst eingelesen und mit dem Flash-Inhalt vergleichen werden müßte.

Viele nutzen den Bootloader im Zusammenhang mit dem tftpd32 für Windows 
und starten den tftpd32 nur wenn sie neu flashen wollen. Unter Linux 
verlinke ich avr0.hex (so heißt die angeforderte Datei bei mir) mit der 
entsprechenden WebserverXXX.hex und lösche den Link nach erfolgreichem 
Booten.

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wenn kein TFTP-Server gefunden wird, wird also normal gebootet?

Autor: xelarep (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Info. Gibt es einen aktuelleren Stand als den weiter oben 
(newStack1_1_00_bootloader_console_20090316.zip)?

Gruß,
Alexander

Autor: Chris M. (shortie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dominique Görsch schrieb:
> Wenn kein TFTP-Server gefunden wird, wird also normal gebootet?

Ja bei einem Timeout sprint der Bootloader zum (hoffentlich) 
existierenden Code

Autor: Chris M. (shortie)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
xelarep schrieb:
> Danke für die Info. Gibt es einen aktuelleren Stand als den weiter oben
> (newStack1_1_00_bootloader_console_20090316.zip)?

Nicht offiziell. Ich habe mir eine eigene Version gemacht mit rein 
optischen Veränderungen und enthält sonst nur die hier im Thread 
angesprochenen Änderungen (wegen Hexfilegröße).

Autor: Jens Mundhenke (dl4aas) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

schön, dass sich der eine oder andere für den Bootloader interessiert.

Änderungen gibt es wirklich keine, vielleicht, weil ich ihn derzeit 
selbst gar nicht nutze ;-)

Sollte jemand Wünsche haben, kann er sie ja hier gern schreiben, gibt 
allerdings keine Umsetzungsgarantie, zu viele andere Basteleien auf dem 
Tisch.

Wäre ein Pin, der den Loader dazu bringt, nichts zu tun, ok?

Andere Idee habe ich auf die Schnelle nicht...

Gruß
Jens

Autor: Dominique Görsch (dgoersch)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Pin wäre keine schlechte Sache. Sollte aber konfigurierbar sein 
welcher und im Idelfall auch noch ob er bei High oder Low via TFTP 
bootet.

Autor: Sylwester S. (sylwester)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eine weitere, sehr nette Firmware ist http://ethersex.de/.
Es lässt sich auch ein TFTP-Bootloader bauen: 
http://ethersex.de/index.php/Downloader

Besonders nett ist, dass die Firmware sowohl IPv4 als auch IPv6 
unterstützt.
Dazu unterstützt sie noch diverse Protokolle und Dienste und ist modular 
aufgebaut (erweiterbar).

Gruß

Autor: Andreas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jens, Tobias, *

ich bin schon längere Zeit auf der Suche nach einem wirklich "kleinen" 
LAN Bootloader für den ATmega 644. Vom Platz her bräuchte ich so was wie 
das FastBoot von Peter Dannegger mit 512 Byte, allerdings habe ich wg. 
Pinmangel keine RS232 mehr auf meinem Board. Andererseits ist das Flash 
meine 644ers schon ziemlich ausgelutscht.

Jens' Bootloader wäre eine feine Sache, allerdings sind mir die 8k 
BOOTSIZE definitiv zu viel. Nachdem ich mal in den Code gesehen habe, 
ist mir aufgefallen, daß evtl. Potential für Größenoptimierung im IHEX 
Teil besteht, wenn man direkt binaries + CRC überträgt.

Allerdings ist das Potential sehr beschränkt durch die TFTP-Wahl, da ja 
zumindest ein rudimentärer Protokollstack für Schicht 1-5 implementiert 
werden muss.

Interessanter könnte da der Ansatz von Tobias sein, da hier 
schätzungsweise über Schicht 2 geflashed wird. Ohne Source ist leider 
nicht definitiv zu sagen, wenn man nicht den Wireshark bemühen möchte.

Ohne es getestet zu haben, habe ich mal das HEX File angeschaut und 
komme das auf eine Bootfile-Size von 4k (korrekt ?).

Allerdings hilft mir der AVRnetflash nicht wirklich weiter, da ich 
mangels Source das Programm nicht verwenden möchte. Die Randbedingungen 
auszutesten, z.B. komme ich mit dem Protokoll über Router (schätze mal 
nicht, wäre aber o.k für mich), was passiert, wenn ich mehrere Targets 
im Netz betreibe, Bootkonfiguration, Target nicht 100% 
Funktionskompatibel zu Pollin AVR sind mir zu unüberschaubar.

Deshalb meine Frage: Gibt's neben ethersex und den beiden genannten 
Implementierungen noch andere "kleine" LAN-Bootloader, oder ist Tobias 
Implementierung schon soweit 'gediehen' daß eine Codeveröffentlichung 
möglich/gewünscht ist ?

Viele Grüsse
Andreas

Autor: Jonas (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo,
gibt es für diesen Bootloader eine 644p und 1284p Unterstützung?
gruss
Jonas

Autor: holger (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Sorry fürs aufwecken;)

Hier mal eine erweiterte Version des Bootloaders von Jens.
Der kann jetzt auch ATmegas mit mehr als 64kB flashen.

Getestet mit ATMega1280. Das lesen und flashen einer IHEX Datei
mit Daten größer 64kB funktioniert nach ersten Tests.

ATMega1284P, ATMEga640, ATMega2561 usw. sollten mit evtl.
kleinen Änderungen am Code auch gehen.

Autor: Markus C. (ljmarkus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Jens
@Holger

Vielen Dank für die Umsetung. Was noch schön wäre einen Port für zb. 
xMega128A1.

lg, markus

Autor: Ulrich Radig (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich grabe mal diesen Thread aus. Hier mein AVR Ethernet Bootloader für 
ENC28J60. Der Bootloader ist 4K groß und ist eigentlich für mein AVR Art 
Net Node gedacht (ATmega328). Andere Hardware sollte mit einigen 
Anpassungen auch gehen. Natürlich mit Sourcen ;-)

Gruß
Uli

Autor: sporky (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Uli,
welche änderungen müßte man für einen Atmega1284p im AVR-Net-IO machen?

gruß
sporky

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
sporky schrieb:
> welche änderungen müßte man für einen Atmega1284p im AVR-Net-IO machen?

Erstmal alles, was der Compiler als Fehler auswirft ;)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel




Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.