Forum: Haus & Smart Home Bootloader - Fortsetzung aus Hauptthread


von Stefan Kleinwort (Gast)


Lesenswert?

Bootloader für die Buskoppler:
------------------------------
Hier geht es um einen Bootloader via CAN für die einzelnen Buskoppler.

Das Thema wurde bereits andiskutiert im Hauptthread. Die
bootload-relevanten Themen habe ich hierher kopiert, damit man nicht
zwischen beiden Threads wechseln muss:

and_ref:
--------
[Firmwareupdate via Bus]
> Die Schwierigkeit sehe ich da drin, dass man einen extra Controller
> bräuchte, um den IC zu programmieren, der dann eine eigene Firmware
> hat, etc...
Haben die ATmegas nicht alle inzwischen die Möglichkeit via Bootloader
programmiert zu werden?

> Aber ich hoffe, ein Firmwareupdate kommt nicht so häufig vor,
> notfalls muss man die Knoten halt mit nem ISP-Adapter flashen...
das machst du genau 1x dann denkst du ganz anders übers Flashen via
Bus. ;-)

Koopi:
------
[Firmwareupdate via Bus]

natürlich können die Mega mit dem Bootloader sich neu programmieren.
Das ist aber recht aufwendig, da das komplette Bushandling bis zur
Anwendungsschicht im Bootloader stehen muss. Das wäre in meiner
Software ca. 40%.
Alternativ ist es viel interessanter die gesamte Konfiguration im
EEPROM zu halten. Damit lassen sich 90% aller Anforderungen an die
Flexibilität abdecken.
Wenn wirklich ein Softwarefehler gefunden wird, liegt er sowieso immer
im Teil der im Bootloader angesiedelt ist.

Dominik:
--------
Also nen CAN Bootloader gehört in jeden Knoten! Das ist
Grundausstattung
von so einem verteilten Bussystem!

Will ich immer die ganzen UPs auseinanderbasteln wenn ich mal was am
Programm ändern will - vielleicht sogar im ganzen Haus?

Kostet doch eh so gut wie nix an Speicher...

Dominik:
--------
Da haben sich die Postings wohl überschnitten. Ich denk eigentlich das
man ohne funktionsfähigen Bootloader den man auf Herz und Nieren
getestet hat, nicht anfangen sollte das System im Haus einzubauen.

Nur meine Meinung.

Koopi:
------
@Dominik,

toll so ein Bootloader. Aber doch nicht an Platz 1 in der Prioliste.
Wenn morgens mein Wecker beim zweiten Weckvorgang, wenn es draußen
hell
ist mein Rollo im Schlafzimmer öffnet alternativ aber das Licht
einschaltet, dann werde ich den Bootloader in der Prioliste vorne
finden!!!

Mario:
------
@Koopi & Dominik,

Das Firmwareupdate via Bootloader sollte von vornherein implementiert
sein. Das macht das Entwickeln und Integrations- bzw. Systemtesten
unheimlich komfortable. Denke nur mal daran deine 50 Lichtschalter im
Haus mit einem zusätzlichen Feature auszurüsten... Das machst du nur
EIN mal...

Ich hab leider auch keine Zeit das Bussystem komplett "im Labor" zu
entwickeln. Es ist schon schwer genug, die Hardware wirklich
ausreichend zu entwickeln und zu verbauen - die kann man schwer
ändern.
Ausserdem kommen die schwierigsten Fehler sowieso erst im Systemtest
oder beim Kunden. Spreche da aus langjähriger Erfahrung ;-)

Der Bootloader wird natürlich recht kompliziert, wenn der ganze CAN
Protokollstack dort implementiert werden muss. Aber vielleicht muss er
das ja gar nicht.

Man könnte einfach ein paar (2) Leitungen im Bus für nen UART
missbrauchen und darüber flashen. Bootloader gibts dafür schon...
Vielleicht kann man ja sogar die normalen CAN Leitungen CAN_H CAN_L
zweckentfremden - wenn die anderen Knoten dann nicht gestört werden.
Sollten sie aber nicht, weil sie ja nichts CAN specifischer decodieren
können... Dann einfach nen Schalter vorsehen, der entweder den UART,
oder den CAN Transceiver auf den Bus schaltet - und das
softwaregesteuert. Zu bedenken ist dann aber, dass beim Flashen dann
kein anderer Knoten "telefonieren" darf ;-)

Die Addressierung des Knoten, der geflasht werden soll - würde ich
noch
über CAN machen: signal goToFlashMode(). Der Knoten macht dann ein
(spezielles) RESET und startet den Bootloader, der dann die Leitungen
shaltet, über die das neue Programm kommt...

Die einfachste Lösung wäre natürlich die normalen ISP Leitungen über
den BUS zu ziehen. Ist nur die Frage wie lang die Leitungen für MOSI,
MISO, SCK werden dürfen, und wie man da die Addressierung macht...

Stefan:
-------
Wie bereits gesagt, ich werde demnächst mal meinen CAN-Bootloader
vorstellen, ich feile aber noch an den letzten Ecken und dokumentiert
ist leider noch nichts (-> auch so ein Ding, das man besser vorher
machen sollte ...).


and_ref:
--------
....
Der Bootloader ist aber
jetzt noch nicht drin... (und schon fast alle Knoten 1x umgeflasht)
;-). Das nächste Umflashen findet statt, wenn der Bootloader fertig
ist. Das Problem dabei ist (bei mir), dass das PC-abhängig ist und ich
mich damit nicht so auskenne wie ich gerne würde.

Stefan:
-------
Mein Ansatz beim Bootloader ist:

Der PC schickt eine Datei via USB -> FTDI -> UART -> ATmega -> CAN.

Der ATmega fährt ein Hardware-Handshake-Protokoll auf dem UART. Damit
entfallen alle timingkritischen Sonderlocken auf Seite des PC. Ein
Binärcopy auf den RS232-Port reicht, keinerlei Programm auf dem PC
erforderlich.

Der Atmega, der an den PC via UART angeschlossen ist, gibt die
Programmdaten auf den CAN aus. Als Broadcast oder einzelne Buskoppler
direkt adressiert. Die Pakete werden über den CAN in einer
Geschwindigkeit gesendet, dass im Broadcast jeder Knoten auch
garantiert mitkommt (ohne Handshake), die paar Angstsekunden habe ich
übrig.
Da das Programmier-Timing alles im ATmega-Boot-Master stattfindet, ist
es viel einfacher zu kontrollieren, als wenn man das Ganze im PC
machen
würde. Und es läuft auch in 10 Jahren noch (wenn die PCs nochmal
100-fach schneller sind).

Koopi:
------
@ stefan,

gehst du davon aus, dass immer alle Module gleichzeitig programmiert
werden?
Dann muss den Modulen aber mitgeteilt werden für welchen Controllertyp
diese Software gedacht ist.

Ithamar:
--------
Meine Meinung zum Thema: Einen Bootloader fände ich nicht schlecht,
kenne mich allerdings damit zu wenig aus. Wenn sich jemand damit
gleich
intensiv auseinandersetzen möchte gerne, ansonsten denke ich wäre es
sinnvoller, erst mal ein funktionsfähiges Netzwerk zumindest für den
Laborbetrieb aufzubauen, damit die Grundfunktionen vorhanden sind und
getestet werden können...

----------------------------------------------------------
Das waren Kopien aus dem Haupttread.

So long, Stefan

von Stefan Kleinwort (Gast)


Lesenswert?

@ Koopi,

auch bei Bootload-Broadcast muss nicht jeder Koppler zwangsweise
dieselbe Software haben. Es kann Buskoppler-Gruppen geben, die dieselbe
Software benötigen. Diese können dann per Broadcast gemeinsam geflasht
werden.

bis jetzt haben bei mir alle Module dieselbe Software. Egal ob diese
Tastereingänge abfragen oder Relaisausgänge schalten. Es gehen sogar
Mischformen. Welche Funktionen der Buskoppler hat, wird ausschliesslich
über die Parametrisierung entschieden.

(Ganz stimmt dsa nicht: mittlerweile verwende ich sowohl ATmega16 als
auch ATmega32. Weil ich für die Displays mehr RAM brauche: der
Displayinhalt (128*64 Graphik) wird komplett im RAM aufgebaut und dann
ans Display übertragen. Geht nur so, weil ich das Display über SPI
angeschlossen habe. Ausserdem stört das zusätzliche Flash bei
Displayansteuerung nicht: Font- und Graphikplatz kann man nicht genug
haben).

Beim Bootloaden (im Broadcast-Mode) kontrolliert jeder Buskoppler, ob
die folgende Software für ihn auch passt. Bei mir also: der
Display-Buskoppler lädt sich nur die zu ihm passende Display-Software
(mega32).

Zusätzlich kann jeder Buskoppler auch exklusiv programmiert werden.

Hört sich vielleicht etwas kompliziert an, ist es aber im Endeffekt
nicht. Gebt mir noch bis Weihnachten Zeit, dann stelle ich den
Bootloader hier rein ...

Viele Grüße, Stefan

von Mario Schwarz (Gast)


Lesenswert?

@Stefan,

ok ich bin gespannt! CAN Bootloader ist natürlich das Beste... Bevor
wir den nicht haben - baue ich nix in das neue Haus ein ;-)

Der Kompatibilitätscheck im Knoten beim Broadcast Update ist auch
sinnvoll.

Man sollte auch darauf achten, dass man eine Versionierung der Firmware
durchhält - die auch auf Kompatibilitäten achtet. Vor allem in der
Entwicklungsphase, wenn sich das Interface (CAN Protocol) noch dauernd
ändert...

Aber bestimmt habt ihr eh schon irgend nen Version Controlling (CVS)
für die Sourcen vorgesehen, die das dann leisten kann...

Naja - toll ist, dass es die Bootloader Idee geschafft hat - ich werd
mich mal auf die Funkanbindung mit dem ZEBRA Modul stürzen. Und auch
nen Global Thread dazu aufreissen...

Gruss
  Mario

von Ithamar G. (antimon)


Lesenswert?

> Aber bestimmt habt ihr eh schon irgend nen Version Controlling (CVS)
> für die Sourcen vorgesehen, die das dann leisten kann...

Webseite, CVS-System (genauer gesagt: SVN), etc. wäre im Prinzip ab
Sofort auf meinem Server einsatzbereit. Allerdings warte ich noch bis
die Entwicklung konkret losgeht, damit man nicht dieses Forum und die
Entwicklungsseite im Auge behalten muss.
Aber wenn jemand jetzt schon für die Entwicklung CVS braucht - ist
sofort eingerichtet...

von Hardy (Gast)


Lesenswert?

@Stefan

Hast du inzwischen deinen Bootloader fertiggestellt oder zumindestens
soweit, dass man ihn hier mal veröffentlichen kann?

Mache mir darüber gerade auch Gedanken und mich würde deine Lösung
interessieren! Vor allen Dingen wie dein CAN-Protokoll aufgebaut ist,
also wie du die Daten vom PC auf die einzelenen Knoten überträgst.
Falls der Code noch nicht fertig ist, würde auch ein
Prinzipablaufdiagramm oder ähnliches nützlich sein.

Danke Vorab.

von MNR (Gast)


Lesenswert?

Ich habe mitllerweile meinen CAN-Bootloader zum fliegen bekommen, und
aus der Erfahrung heraus muß ich sagen, das ganze ist mehr ein
ausgewachsenes Projekt als nur ein Stück Code. Dazu gehört bei mir:

1. Ein "CAN-USB"- Stick zur Verbindung mit dem PC (ATMega8, MCP2515,
FT232RL) + SW
2. Ein Bootloader im CAN-Knoten
3. Ein PC-Programm, das über den Stick einen CAN-Knoten mit neuer
Firmware versorgt (C# 2005)

Dazu hat man 2 Protokolle (CAN<->CAN, PC<->Stick), und der Bootloader
muß sich natürlich an das bereits implementierte CAN-Protokoll halten.

Man könnte den Stick auf PC-Seite auch ein STK500 Protokoll spendieren,
dann wäre es theoretisch möglich, AVRDude oder AVRStudio zum Update
eines Knotens zu benutzen (mit ein paar Einschränkungen). Das schien
mir aber noch ein bißchen komplizierter als eine komplette
Eigenlösung.

Um so ein Projekt "publizierbar" zu machen, müßte man also
umfangreich dokumentieren, wie die SW für die eigenen Bedürfnisse
(Protokolle/HW) zu ändern ist.

Gruß,
Matthias

von Ithamar G. (antimon)


Lesenswert?

Hi MNR,

das hört sich super an!

Schau doch mal unter http://devel.antimon.de/hausbus, dort hab ich eine
Projektseite eingerichtet. Mit Wiki für die Doku und SVN für Sourcecode
- wenn du Lust hast kann ich dir einen Account einrichten, dann kannst
du den Code hochladen.

Dann könnten auch andere Leute mit am Coden / Dokumentieren mitarbeiten
und du musst die ganze Arbeit nicht allein machen...

von MNR (Gast)


Lesenswert?

Ist z.Zeit noch "Work in progress".

Grundsätzlich habe ich kein Problem mit der Veröffentlichung von
Sourcen, nur wie gesagt, das ist eher ein vollständiges Projekt. Wenn
ich mal wieder etwas mehr Zeit habe, komme ich gerne auf dein Angebot
zurück.

Gruß,
Matthias

von Simon Willmann (Gast)


Lesenswert?

Hallo Matthias,
ich habe sehr großes Interesse an deinem Bootloader, da ich ebenfalls
AtMega8 und MCP2515 nutze und das Flashen meines Projektes so langsam
recht aufwendig wird (es handelt sich allerdings um keinen Hausbus im
eigentlichen Sinne, sondern um CAN-vernetzte und über PC angesteuerte
RGB-LED-Lampen). Würdest du mir, auch wenn du das Projekt noch nicht
publizieren willst, einen Snapshot zukommen lassen? Das es noch keine
Doku gibt ist egal, der Code würde mir schon sehr weiterhelfen, da ich
derzeit noch garkeine Idee zu einem Bootloader habe.
Würde mich freuen wenn du mich anschreibst: simon@lugfl.de.
Mfg, Simon.

von MNR (Gast)


Lesenswert?

Das dauert noch ein bißchen. Mit einem Snapshot kann ich auch erst in
2-3 Wochen dienen (demnächst gehts erst mal in Urlaub).

Gruß,
Matthias

von Simon Willmann (Gast)


Lesenswert?

Okay, ich wünsch dir viel Spass im Urlaub :)

Mfg, Simon.

von Philipp (Gast)


Lesenswert?

abo

von Robi (Gast)


Lesenswert?

Übrigens es gibt jetzt nahezu umsonst schon einen fertigen deutschen
Bootloader der schon für ein Hausbus eingesetzt wird. Er hat die
Möglichkeit bestimmte Boards im Haus zu selektieren. Der verwendete
Protokollheader könnte auch für andere Befehle verwendet werden, wird
in der Doku für mehrere Avr´s beschreiben und am Beispiel gezeigt.
Vielleicht interessant für den ein oder anderen:
http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath...

von Robi (Gast)


Lesenswert?


Bitte 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
Noch kein Account? Hier anmelden.