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
