Hallo Leute, ich hab mehrere Atmegas an einem SPI bus. Auf dem SPI bus werden die slaves vom master ständig abgefragt bezüglich ihres status. Manchmal muss ein slave neu programmiert werden via ISP direkt vom master. Leider klappt während dessen die Kommunikation mit den anderen nicht mehr, wenn sich ein slave im Programmiermodus befindet. Hab ich einen Programmierfehler, oder reagiert der Atmega tatsächlich nicht auf ein SlaveSelect = high und lässt mich so zwischen verschiedenen Flash-Seiten den SPI bus für status abfragen von anderen slaves verwenden? Ich würde gerne die paar millisekunden zwischen den flash page write wait times ausnutzen... Grüße
Benutzt du einen Bootloader dafür? Hast du an der Standard-ISP von Atmel schon einen Slave-Select gesehen? mfg mf
>Ich würde gerne die paar millisekunden zwischen den flash page write >wait times ausnutzen... Dummerweis wird bei ISP aber keine Pause zwischen den PageWrites gemacht. Der uC ist die ganze Zeit im Resetzustand und führt überhaupt kein Programm aus.
Hallo, ich flashe ganz normal über das ISP protokoll von meinem master aus. (Also MISO, MOSI, SCK, SS, RESET als Leitungen drann). Meine Frage ist nun nur, ob ein Atmega wenn er via SPI programmiert wird den SPI bus lahmlegt, oder sich passiv verhält, sobald ich das SlaveSelect high setze. Die Wartezeiten sind die Wartezeiten zwischen den page writes. Siehe Datenblatt (Serial programming)
> Dummerweis wird bei ISP aber keine Pause zwischen den > PageWrites gemacht. Der uC ist die ganze Zeit im Resetzustand > und führt überhaupt kein Programm aus. Mein Master führt das Programm aus und ich würde gerne mehrere Slaves gleichzeitig flashen (und dafür eben diese 2,irgendwas millisekunden, die zwischen pagewrites gewartet werden müssen ausnutzen)
Tommi schrieb: > Meine Frage ist nun nur, ob ein Atmega wenn er via SPI programmiert wird > den SPI bus lahmlegt, oder sich passiv verhält, sobald ich das > SlaveSelect high setze. Das SlaveSelect für ISP ist /RESET. Du musst also den /RESET-Pin auf LOW schalten, wenn Du den externen ATMEGA programmieren willst. In dem Moment, wo der ATMEGA den RESET sieht, werden alle seine Pins hochohmig. Die anderen Geräte am SPI-BUS dürfen derweil nicht mittels /SS selektiert sein, sonst sehen sie ebenfalls die Programmierpulse.
Tommi schrieb: > Ich würde gerne die paar millisekunden zwischen den flash page write > wait times ausnutzen... Ob zusätzliches Pinwackeln erlaubt ist, während der zu programmierende ATMEGA gerade flasht, wage ich mal anzuzweifeln. Dadurch verliert die Programmierschnittstelle ihren Sync mit dem Programmer.
Ich glaub es kam noch nicht so ganz rüber was ich machen will: ===== slave1 in programming mode + ss1 auf low + puls auf reset bei sck low + programming enable command senden + ss1 auf high ===== slave2 status abfrage + ss2 auf low + status command + antwort lesen + ss2 auf high ===== slave 1 page1 flashen + ss1 auf low + spi commands für page flash + ss1 auf high ==== slave3 status abfrage ... ==== slave1 page n flashen ...
Tommi schrieb: > Ich glaub es kam noch nicht so ganz rüber was ich machen will: > Doch. Ich denke schon, dass das rüber gekommen ist. Deine Anforderung ist nur ein wenig ... ungewöhnlich. Einen µC neu zu programmieren ist normalerweise ein aussergewöhnliches Ereignis. Sowas kommt selten genug vor. Und wenn, dann stellt man für diese Zeit die Maschine als ganzes ab, programmiert den µC und fährt alles wieder hoch. Den µC neu zu programmieren ist nicht der Regelfall, schon gar nicht im laufenden Betrieb. Das würde mich sehr wundern, wenn das hier schon mal jemand gemacht hätte. Du kannst dich so gesehen gerne als Pionier sehen und uns von deinen Erfahrungen berichten.
Naja, der Regelfall ist das bei mir auch nicht. Ich hab halt nur einen Master mit mehreren steckbaren slave karten. Ich würde ungern die komplette Maschine für 5 sekunden außer Betrieb nehmen, wenn der Master merkt, dass ein slave mit inkompatibler alter software oder falschen fuses gesteckt wurde. Wäre also schön es würde 10 Sekunden dauern und dafür ohne block gehen. Ich schreib rein wenn ich die Funktion oder Fehlfunktion validieren konnte!
Klatsch doch nen Bootloader drauf auf den Slave und der Master programmiert den dann aus irgendeinem Speicher.
Tommi schrieb: > wenn der Master merkt, dass ein slave mit inkompatibler alter > software oder falschen fuses gesteckt wurde. Dazu muss die Kiste doch sowieso ausgeschaltet werden. Oder steckst du die Karten im laufenden Betrieb? Mutig, mutig. Dann bist da auch der Hotplug-Pionier. mfg.
Also wenn ich das richtig verstanden habe hast Du quasi einen Master mit mehreren Slaves, die dann hotplugfähig sind. Da Du mit dem ISP ja eh an die Leiterplatte ran musst, wäre es doch aus mneiner Sicht das Einfachste, Du ziehst den Slave, trennst ihn damit vom Bus, schließst Betriebsspannung an, flashst das Ding und steckst es wieder rein. Bei manchen AVR ist der ISP aud den SPI-Pins, da geht dann eh nichts Anderes, weil der ISP dann den Master macht. Manche AVRs haben den ISP vom SPI getrennt, ATMega128 oder ATMega64 z.B., da könnte im Betrieb geflasht werden, der SPI wäre dann passiv.
Thomas Eckmann schrieb: > Dazu muss die Kiste doch sowieso ausgeschaltet werden. Oder steckst du > die Karten im laufenden Betrieb? Mutig, mutig. Dann bist da auch der > Hotplug-Pionier. Die karten werden im laufenden Betrieb eingesteckt. Der Master merkt, dass ein Slave steckt (Ein /EXIST pin). Dann fängt der Master an mit dem ding via ISP zu reden, checkt die device signatur, schaut sich den aktuellen flash und eeprom an. Wenn ihm was nicht gefällt startet er die Programmierung, programmiert die Software (die er mit offset in seinem eigenen flash trägt) auf den slave, löst danach den reset und bindet den slave als laufendes Gerät ein. Hat bis jetzt schon seit Jahren funktioniert, ich bin nun nur gezwungen von einzelnen software-basierten ISP schnittstellen für jeden einzelnen slave auf einen echten SPI bus zu wechseln.
Ändere den /EXIST Pin in eine UART Leitung womit der Slave dem Master Nachrichten senden kann. Im "Normalfall" sendet der halt kontinuierlich ein Bitmuster um zu sagen "ich bin da". Für Die Programmierung baust du dir einen Bootloader welcher am Anfang für einige Zeit auf dem SPI nach dem "Starte Programmierung" Befehl wartet oder sonst normal das Programm startet, der Ablauf könnte dann so aussehen: 1) Slave da 2) Neue Firmware erforderlich 3) Reset Slave und senden des Startbefehls bis Bootloader über /EXIST "bereit" meldet. 4) Erste Page senden 5) Normal weitermachen bis Bootloader über /EXIST meldet: Nächste Page bitte 6) Wenn Bootloader "fertig" meldet Reset Slave und alles ist gut :-)
Tommi schrieb: > Hat bis jetzt schon seit Jahren funktioniert, ich bin nun nur gezwungen > von einzelnen software-basierten ISP schnittstellen für jeden einzelnen > slave auf einen echten SPI bus zu wechseln. Fakt ist, dass wen Du einen AVR in den Programmiermodus versetzt hast, dieser nur noch auf gültige ISP-Kommandos wartet. Schickst Du auf dem Bus dann irgendwas, geht sowohl das Programmieren in die Hose, als auch die Daten auf dem Bus. Somit kommt diese "Lösung" technisch nicht infrage. Baue Dir einen Bootloader, der SPI-fähig ist.
Knut Ballhause schrieb: > die Daten auf dem Bus. Somit kommt diese "Lösung" technisch nicht > infrage. Baue Dir einen Bootloader, der SPI-fähig ist. Entweder das oder einen abgespeckten Master, dessen einzige Aufgabe es ist, den Update zu machen, wenn ihm ein Modul eingesteckt wird. Die Produktionsanlage kommt dann überhaupt nie in die Verlegenheit einen Hot-Update machen zu müssen.
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.