Hallo zusammen, ich muss auf der Arbeit des Öfteren mehrere Geräte mit ATmega238/A/P/PA chip programmieren. Ein Gerät hat 2 ATmega Mikrocontroller, die auch beide die gleiche Firmware haben. Aktuell besitze ich nur einen Kanda Handheld AVR Programmer und kann deswegen nur einen Chip nach dem anderen programmieren. Gleichzeitiges programmieren beider Mikrocontroller würde mir dabei viel Zeit sparen. Ich hätte gerne einen Programmer mit folgenden Eigenschaften: - 2 Geräte gleichzeitig programmieren - Statusanzeige für jeden beide Verbindungen (einfache LED oder Display) - Taster zum starten - Firmware einfach als Datei in einen Ordner legen (per USB oder SD Karte) - Akku und Ladefunktion - ATmega328/A/P/PA - ISP Clock 175kHz - Fuses programmieren (Low Fuse, High Fuse, Ext Fuse und Lockbits) - Skip 0xFF in EEPROM Gibt es das vielleicht als fertiges Gerät oder ein DIY Projekt? Natürlich könnte man das auch mit 2 Programmern lösen, aber ein kompaktes Gerät würde mir die Arbeit definitiv erleichtern, da die zu programmierenden Geräte schwer zugänglich sind und ich dorthin nicht viel mitnehmen kann.
Einen Doppelprogrammer braucht niemand außer dir, aber ein einfach mitzunehmendes kleines Dings gibt's: das PICKit 5. Das kann man so voreinstellen, das es auf Tastendruck ratzfatz ein festgelegtes Programm in den Controller beamt. Nur ein Taster und eine LED, Power per USB-C, fertig. Kann seit der Hochzeit der beiden Firmen auch AVRs, sollte also gehen.
Patrick schrieb: > Ein Gerät hat 2 ATmega Mikrocontroller, die auch beide die gleiche > Firmware haben. Was ist das denn für ein Gerät, das zwei gleiche MCUs mit identischer Firmware hat? Kann mir gerade nicht vorstellen, wozu sowas sinnvoll sein könnte.
Johannes F. schrieb: > Patrick schrieb: >> Ein Gerät hat 2 ATmega Mikrocontroller, die auch beide die gleiche >> Firmware haben. > > Was ist das denn für ein Gerät, das zwei gleiche MCUs mit identischer > Firmware hat? Kann mir gerade nicht vorstellen, wozu sowas sinnvoll sein > könnte. Redundante Safety Anwendungen verwenden sowas. Die Antwort auf die Frage hat sich der TE schon gegeben: Einfach 2 Geräte nutzen. Alles andere ist Un- und Wahnsinn.
Cyblord -. schrieb: >> Was ist das denn für ein Gerät, das zwei gleiche MCUs mit identischer >> Firmware hat? Kann mir gerade nicht vorstellen, wozu sowas sinnvoll sein >> könnte. > > Redundante Safety Anwendungen verwenden sowas. Aha, danke für die Info. Mit sowas hatte ich noch nicht zu tun bisher.
Cyblord -. schrieb: >> Was ist das denn für ein Gerät, das zwei gleiche MCUs mit identischer >> Firmware hat? Kann mir gerade nicht vorstellen, wozu sowas sinnvoll sein >> könnte. > > Redundante Safety Anwendungen verwenden sowas. "Die Software von redundanten Systemen sollte sich möglichst in den folgenden Aspekten unterscheiden: Spezifikation (verschiedene Teams), Spezifikationssprache, Programmierung (verschiedene Teams), Programmiersprache, Compiler."
Angehängte Dateien:
-
is_it_worth_the_time.png
63 KB
Cyblord -. schrieb: > Die Antwort auf die Frage hat sich der TE schon gegeben: Einfach 2 > Geräte nutzen. Alles andere ist Un- und Wahnsinn. Vor allem sollte man mal kurz überschlagen, was man WIRKLICH rausholen kann? Wenn es zwei identisch zu programierende ICs sind, steckt man einfach um. Das dauert ein paar Sekunden. Fertig. Erst wenn man das hunderte mal am Tag jeden Tag machen würde, lohnt es sich, über nennenswerte Optimierung nachzudenken.
H. H. schrieb: > Cyblord -. schrieb: >>> Was ist das denn für ein Gerät, das zwei gleiche MCUs mit identischer >>> Firmware hat? Kann mir gerade nicht vorstellen, wozu sowas sinnvoll sein >>> könnte. >> >> Redundante Safety Anwendungen verwenden sowas. > > "Die Software von redundanten Systemen sollte sich möglichst in den > folgenden Aspekten unterscheiden: Spezifikation (verschiedene Teams), > Spezifikationssprache, Programmierung (verschiedene Teams), > Programmiersprache, Compiler." "sollte" und "möglichst" sind deine Stichworte. Es gibt viele verschiedene Ansätze und viele verschiedene SIL und Perfomance Klassen dafür.
Solche Dinger nennen sich "Gang-Programmer" und einige kann man aus einer Powerbank betreiben. Die sind aber eigentlich nicht für den mobilen Einsatz gedacht sondern für die Produktion, haben deshalb meist auch keinen Akku und können häufig weit mehr als 2 Targets. Preislich vermutlich indiskutabel. Alternativ kannst Du beide Controller bis auf MISO parallel an einem Programmer verschalten. Nur MISO des 1. Controllers geht auch an den Programmer. Variante A: MISO des 2. Controllers bleibt offen und man muss hoffen, dass bei ihm (auch) alles gut geht. Variante B: MISO des 2. Controllers wird mit einem XOR mit MISO des 1. Controllers verschaltet und über ein Latch mit dem SPI-Takt verknüpft auf ein Monoflop gegeben. Eine dadurch angesteuerte LED zeigt dann an, wenn die Controller unterschiedlich reagieren. Gruß Jobst
H. H. schrieb: > Software von redundanten Systemen sollte sich Ist aber je nach geforderter Safety gar nicht so unüblich wenn das binary identisch ist, aber für beide Einheiten verschiedene Verzweigungen laufen. Patrick schrieb: > Ich hätte gerne einen Programmer mit folgenden Eigenschaften: Wir haben das anfangs mit einem eigenen Aufsteckprogrammer gelöst, also selbst etwas entwickelt und gebaut. Später gab es dann einen bootloader, wobei nur einer mit dem Host verbunden war und dieser seinen Programmcode 1:1 auf den zweiten Controller spielte über die sowieso vorhandene Interkommunikation.
:
Bearbeitet durch User
H. H. schrieb: > Cyblord -. schrieb: >>> Was ist das denn für ein Gerät, das zwei gleiche MCUs mit identischer >>> Firmware hat? Kann mir gerade nicht vorstellen, wozu sowas sinnvoll sein >>> könnte. >> >> Redundante Safety Anwendungen verwenden sowas. > > "Die Software von redundanten Systemen sollte sich möglichst in den > folgenden Aspekten unterscheiden: Spezifikation (verschiedene Teams), > Spezifikationssprache, Programmierung (verschiedene Teams), > Programmiersprache, Compiler." So pauschal ist das nicht der Fall. An allen Projekten an denen ich mitarbeitete für die ISS und mehreren Satelliten war das nicht der Fall. Das redundante System war einfach eine Kopie. Auf diese wurde automatisch oder auch per Kommando vom Boden umgeschaltet. Auch die Firmware lag redundant im Flash. Bei einem Update wurde dann die neue FW gebootet. Schlug das fehl (z.B. boot Loop) wurde das von der HW oder dem Bootloader erkannt und die alte SW automatisiert wieder gestartet. Das alles von unterschiedlich Teams gemacht wurde, ist mir nie begegnet. Was aber nicht heißen soll, dass es das nicht gibt. In anderen Anwendungen gibt es das sicher.
900ss schrieb: > Das alles von unterschiedlich Teams gemacht wurde, ist mir nie begegnet. > Was aber nicht heißen soll, dass es das nicht gibt. In anderen > Anwendungen gibt es das sicher. Es gibt dort alles. Deshalb schrieb ich auch, es kommt auf den Fall an, auf das gewünschte Level und wofür man überhaupt Redundanz braucht. Wirklich Safety ala SIL oder nur Verfügbarkeit. Selbst bei SIL4 Geräten gibt es identische Binaries. Es gibt viele Möglichkeiten einen SIL zu erreichen und nachzuweisen. Kenne aber auch Sicherheitsschaltgeräte (Pilz) wo wirklich auf 2 Controllern, mit 2 Toolchains und sogar 2 unterschiedlichen Debugger-Hardware entwickelt wird.
Vielen Dank für die Antworten bisher. Witzig, dass es immer Leute gibt, die die Sinnhaftigkeit hinterfragen, aber nichts zum Thema beitragen. Trotzdem hier ein paar zusätzliche Infos, ohne zu viel zu verraten (flashen auf einem anderen weg wäre nicht nach Herstellervorgabe). Die Geräte befinden sich ein einem geschlossenem System. Ich kann also nur bei Stillstand zu den Geräten. Das bedeutet, dass ich nur außerhalb der Produktion des Kunden Zutritt bekomme (Pausenzeiten, Nachtschicht oder Wochenende). Somit bleibt wenig Zeit. Im Zweifel hängt davon ab, ob ich nochmal anreisen muss, ob ich noch eine Nachtschicht machen muss etc. Die Anzahl der Geräte hängt dabei von der Größe der Anlage ab (von 10 bis mehrere hundert). Die Arbeit umfasst für diesen Anlagenteil: Gehäuse öffnen, flash 1, flash 2, reboot, Gehäuse schließen wenn kein Fehler ansteht. Eine Lösung, die mir bis jetzt gut gefällt, wäre ISPnub. Das ist so klein und leicht, dass ich nicht mal ein weiteres Kabel mitnehmen muss, sondern es mit einer 6 Pin Buchsenleiste direkt aufstecken kann. Schöner wäre es noch mit einer SD-Karte, aber man kann ja nicht alles haben.
Schräg, das so wichtige Teile a) kein Dual/Safeboot können, b) nicht einfacher einen Update bekommen können und c) überhaupt einen Update in der Menge brauchen.
Patrick schrieb: > Witzig, dass es immer Leute gibt, die die Sinnhaftigkeit hinterfragen, > aber nichts zum Thema beitragen. Witzig, daß es immer Leute gibt, die in Diskussions(!)foren kostenlose anonyme Hilfe zu seltsamen Problemstellungen wollen, aber sich über Nachfragen wegen fragwürdiger Anforderungen beschweren.
Patrick schrieb: > Die Anzahl der Geräte hängt dabei von der Größe der Anlage ab (von 10 > bis mehrere hundert). Die Arbeit umfasst für diesen Anlagenteil: Gehäuse > öffnen, flash 1, flash 2, reboot, Gehäuse schließen wenn kein Fehler > ansteht. Damit kommen wir dem Problem schon näher. Wie lange dauert so ein Arbeitsschritt? öffnen flash 1 flash 2 reboot Gehäuse schließen wenn kein Fehler
Patrick schrieb: > Eine Lösung, die mir bis jetzt gut gefällt, wäre ISPnub. Das ist so > klein und leicht, dass ich nicht mal ein weiteres Kabel mitnehmen muss, > sondern es mit einer 6 Pin Buchsenleiste direkt aufstecken kann. Schöner Kannst Du die AVRs ISP Programmieren in dem Gerät? Das wäre ja eine völlig neue Option! Kabel aufstecken, programmieren und fertig. Theoretisch kannst Du da dann zwei ISP Programmer anstecken und gleichzeitig programmieren. Als Quelle geht alles von einem normalen Notebook bis hin zu einem Raspi oder NanoPC basierten Cyberdeck. Alternativ kann man auch ein spezielles Kabel bauen, mit ISP parallel auf beide AVRs aber getrennte Resets, die kannst Du dann avrdude per script mitgeben. Das kann man komplett scripten in bash oder sh oder python. Da reichen auch ganz kleine Raspis wie die OrangePi Zero. UPS Platine drunter mit 2 LiPo oder LiFePo4 Zellen und das sollte einen Tag durch halten. Wäre sicher zwei Wochenenden Basteln, aber dann erspart es das ganze Umstöpseln der AVRs.
Hallo Patrick, Ich würde das hier als Anlaufpunkt vorschlagen: https://www.kevindarrah.com/wiki/index.php?title=AVR_Programmer Er hat die Basis von hier benutzt: https://github.com/nickgammon/arduino_sketches/tree/master Und da finden sich eindeutige Hinweise auf standalone Betrieb mit SD-Karte . https://www.gammon.com.au/uploader Gruß Sven
:
Bearbeitet durch User
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.