mikrocontroller.net

Forum: Compiler & IDEs Gemeinsame Funktionen für Applikation und Bootloader


Autor: Thomas Schwetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Thomas Schwetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Frank Bußmann (frank13)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter S. (psavr)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian Schwertnitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Joe Die (kosmonaut_pirx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Karl heinz Buchegger (kbucheg)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Thomas Schwetzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

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
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
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.