Hallo, ich habe mir hier mal per Suche alles zum Thema Bootloader zu gemüte geführt. Die meisten raten dazu, Bootloader und Applikation komplett zu trennen, sprich separat zu entwicklen, linken und flashen. Nun habe ich aber ein (privates) Projekt für meine Modelleisenbahn mit zwei Mega64 und zwei Mega8. Soviele, weil ich massig I/O brauche. Alle vier kennen jeweils die Eingängszustände der jeweils anderen und jeder kann auch die Ausgänge der anderen schalten. Dazu tauschen sich die vier kontinuierlich per TWI aus. Dazu ist im Laufe der Zeit eine nette kleine Laufzeitumgebung entstanden, wobei an einem der Mega64 (TWI-Master) per RS-232 ein Terminal zwecks Steuerung und Debuggen hängt. Jetzt würde ich gerne über diese Leitung die Controller updaten können, sprich der Mega mit der Schnittstelle nimmt die Daten entgegen und flasht dann per TWI den jeweiligen Controller. Problem sind die Mega8, diese sind trotz -O3 schon ziemlich voll. Einen kompletten Bootloader und ein (redundantes, zweites) TWI-Slave- Interface bekomme ich da nicht mehr unter. Auf den Mega64 ist noch massig Platz. Hat jemand einen Tipps, wie ich Teile des Apllikationscodes, insbesondere die TWI-ISR und sonstigen Routinen fürs TWI für Apllikation und Bootloader gemeinsam nutzen kann? Schon klar, daß sich bei Änderungen im Code Offsets verschieben, aber das könnte man ja über eine Sprungtabelle lösen, oder? Gruß Thomas
Hi, wenn Du statt TWI das SPI Interface verwenden könntest, dann würdest Du auf den Mega8 gar keinen Bootloader benötigen. Die könntest Du dann direkt vom Mega16 aus per SPI flashen. Das ist im Datenblatt unter "Memory Programming --> Serial Downloading" beschrieben. Gruß Frank
Hallo, ja, schon klar. Aber ersten sind die Platinen schon lange bestückt und zweitens war die Möglichkeit des Generall Call so nett zu programieren. Gruß Thomas
Hallo, ok, das hatte ich mir schon fast gedacht. Ja es sollte schon gehen die Funktionen gemeinsam zu nutzen. Allerdings müssen die Funktionen im RWW Bereich des Flash liegen (Bootloader Bereich) und die Adressen müssen für die Applikationssoftware bekannt sein. Die Adressen kannst Du dir aus dem Mapfile des Bootloaders holen und damit eine Tabelle mit Funktionszeigern im RAM aufbauen. Was Du dann noch brauchst sind geeignet definierte Funktionszeiger auf die Du dann in der App. casten kannst (wegen Parameter/Return Value). Gruß Frank
Thomas Schwetzer wrote:
> Problem sind die Mega8, diese sind trotz -O3 schon ziemlich voll.
Versuchs mal mit -Os (Optimierung der Größe), das gibt in der Regel den
kleinsten Code. -O3 optimiert nach Geschwindigkeit.
Peter
Thomas Schwetzer wrote: > Die meisten raten dazu, Bootloader > und Applikation komplett zu trennen, sprich separat zu entwicklen, > linken und flashen. Aus gutem Grund. Der Linker der Application hat doch keine Ahnung, welche Ressourcen die Bootloaderfunktionen belegen. Spätestens bei Interrupthandlern oder globalen Variablen krachts gewaltig. Wenn die Platine unverändert bleiben soll, update doch auf den ATmega168. Ich nehme ja für Steuerungen lieber serielle Expander (74HC165, TPIC6B595), da hat man die Leistungstreiber gleich mit drin. Und so schnell fahren die Züge ja nicht, daß z.B. ne Lichtschranke nur wenige µs unterbrochen wird und dann beim Pollen der Eingänge durch die Lappen geht. Die Zeiten sind ja alle im mehrstelligen ms-Bereich, also aus CPU-Sicht schnarchlahm. Peter
Hallo! Nur eine kurze Zwischenfrage: Wo gibt es den TPIC6B595 in SMD (wenn überhaupt)? Möglichst auch von privat zu bestellen (Segor hat nur die DIP-Version, bei Reichelt konnte ich ihn nicht finden). Bis denne Frank
Ein Tip, für Dein nächstes Design: Wenn Du zuwenige IO's hast, aber schon I2C-Bus verwendest, dann verwende doch gleich I2C-Bus IO Expander, statt zusätzliche Prozessoren. Zum Beispiel den PCF8574 von Philips bzw. nun von NXP MfG Peter
Die Antworten auf die Fragestellung von Thomas zum Thema gemeisame Verwendung von Resourcen für Bootloader und Applikation gehen bisher wohl eher am Thema vorbei. Wenn man z.B. einen Bootloader über CAN realisieren will und gleichzeitig CAN in seiner Apllikation verwenden will, ist es doch recht sinnvoll die CAN Driver (z.B. für MCP2515) nur einmal flashen zu müssen. Gint es beim AVR wirklich keine Möglichkeiten gemeinsame Flash-Bereiche für Bootloader und Applikation zu verwenden?
hallo, natürlich gibt es die möglichkeit dazu. aber wie peter schon schreibt, kann der linker der applikation per se nciht wissen, wo die bootloaderroutinen denn nun rumschwirren. oder umgekehrt, der bootloader kann nicht wissen, wo die applikationsroutinen liegen. über gemeinsame adressen, wo sections liegen, könnte man sich imho da zunächst behelfen. bye kosmo
Ich würde den Ansatz benutzen: Im Bootloader gibt es eine Tabelle in der die Einsprungspunkte zu den 'exportierten' Funktionen liegen. Die Applikation kennt nur die Adresslage dieser Tabelle und kann sich von dort die Adressen der Funktionen holen. Solange ich dafür sorgen kann, dass sich die Adresslage der Tabelle nicht ändert, kann ich dadurch auch im Bootloader noch Korrekturen machen, die die Adressen der Funktionen etwas verschieben.
Hallo, sorry, ich meinte -Os, nicht -O3. Ansonsten danke schon mal für die Anregungen und ja, mir ist klar, daß I/O-Expander und andere Prozessoren gibt, aber das Design ist nun mal wie es ist und bereits fertig gelötet. Ein Bootloader stand nicht im "Pflichtenheft" und soll jetzt quasi ein Sahnehäubchen sein. Gruß Thomas
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.