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
@ 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
@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
> 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...
@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.
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
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...
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
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.
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
Okay, ich wünsch dir viel Spass im Urlaub :) Mfg, Simon.
Ü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...
Der Link war falsch. Der hier müsste stimmen: http://www.shop.robotikhardware.de/shop/catalog/product_info.php?cPath=77&products_id=150
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.