hallo! Ich verwende einen Atmega128. Da zwei Pins zum Programmieren am UART liegen und ich diesen UART auch verwende, muss ich die Verbindung zwischen meinem uC und dem an de UART-Pins angeschlossenen IC momentan mittels Jumper trennen (Jumper ziehen, Leitung nicht mehr angeschlossen). Dann lässt sich der uC problemlos programmieren. Anschließen stecke ich die Jumper wieder rein und die normale Funktion wird ausgeführt. nun habe ich folgende Idee und hoffe, Ihr könnt mir Tipps geben, ob das so funktioniert: Ich möchte statt Jumper ein 2 Channel Multiplexer 74hc4053 verwenden. Am Multiplexer schalte ich die "Kanalwahl" direkt an den resetpin des uC. Wird dieser nun auf low gezogen (der uC also resettet), so wird als Kanal die Programmierleitung gewählt. Ist der uC nicht mehr resettet, so wird wieder die ganze normale UART Leitung zugeschaltet. nun meine Fragen: Ich gehe davon aus, dass der uC während des Programmiervorgangs dauerhaft resettet ist. Wird während des Programmiervorgangs der uC überhaupt dauerhaft im Reset gehalten? Kann dies so funktionieren oder wird der Multiplexer nicht rechtzeitig umschalten, bis die ersten daten auf der Programmierleitung kommen? Könnten andere Probleme auftreten? Viele Grüße BD
>Wird während des Programmiervorgangs der uC überhaupt >dauerhaft im Reset gehalten? Ja. >Kann dies so funktionieren Ja. Saubere Lösung.
bd schrieb: > Ich gehe davon aus, dass der uC während des > Programmiervorgangs dauerhaft resettet ist. Wird während des > Programmiervorgangs der uC überhaupt dauerhaft im Reset gehalten? Ist es nicht so (ich weiß es nicht genau beim ATmega128), dass der ATmega nur bei Programmierung mittels SPI-ISP im Reset gehalten wird (ohne Bootloader)? Wenn der Chip sich selbst programmiert ist es so, dass die Fusebits bestimmen, ob nach einem Reset das Anwenderprogramm (also Sprung zum Reset-Vector) oder das Bootloaderprogramm (Bootloader-Vector) ausgeführt wird. Damit das "Selbstprogrammieren" geschehen kann ist dann der ATmega nicht geresetet. Bei einem anderen ATmega sah meine Lösung so aus: Hardware: - "Multiplexer" von RX und TX - Selektierpin des Multiplexers an einen GPIO des ATmega - Reset des Controllers - Sprung in Bootloaderprogramm - ATmega hält über einen GPIO Pin den Multiplexer im Uploadmodus Bei eingehenden Flashdaten: - Flash wird programmiert - am Ende des Flashprogramms GPIO Pin Multiplexer auf "Anwendermodus" - Sprung zum Anwenderprogramm Bei nicht eingehenden Flashdaten: - am Ende des Flashprogramms GPIO Pin Multiplexer auf "Anwendermodus" - Sprung zum Anwenderprogramm Aber wie gesagt, ich hab das mit einem ATmega128 noch nicht gemacht (kann mir aber nicht vorstellen, dass ein Bootloaderprogramm bei geresetetem Chip läuft) Gruß, Ralph
Bei ISP Programmierung, interessiert es dem µC reichlich wenig ob da ein Bootloader drauf ist oder nicht. Bei ISP Programmierung wird der Resetpin dauerhaft auf 0 gehalten. Was mich gerade wundert: Die zwei UARTs liegen doch auf völlig unterschiedlichen Pins als das SPI beim 128?! RXD0 = PE0 TXD0 = PE1 RXD1 = PD2 RXD2 = PD3 MISO = PB3 MOSI = PB2 SCK = PB1
@bd: Ich (wir) haben das mal genau so realisiert. Da war an den ISP-Leitungen allerdings ein DAC dran, was aber am Prinzip nichts ändert. Wenn es Dich interessiert, kann ich die Schaltung mal raussuchen. Gruß Dietrich
Draco schrieb: > unterschiedlichen Pins Auch die Aussage des TO "zwei Multiplexer" deutet darauf hin, dass er den Unterschied zwischen SPI Programmierung und Bootlader nicht realisiert hat.
Ich würde anhand der Beschreibung davon ausgehen, das der µC über UART mit Bootloader programmiert wird. Neben der Lösung von Ralph, die eine anpassung des Bootloaders erfordert, könnte ich mir vorstellen, dass es auch einfacher geht, wenn man den Selektierpin des Multiplexers mit einem pullup an einen IO-Pin hängt. zum Start der Anwendung zieht man den PIN dann auf LOW.
Georg G. schrieb: > Draco schrieb: >> unterschiedlichen Pins > > Auch die Aussage des TO "zwei Multiplexer" deutet darauf hin, dass er > den Unterschied zwischen SPI Programmierung und Bootlader nicht > realisiert hat. Ahhh... jetzt sehe ich es auch. Er hat den UART zum PC und zu einem anderen µC liegen! Dann programmiert auch auch nicht über ISP sondern hat einen Bootloader auf dem 128 laufen. Das ändert die Ausgangssituation natürlich grundlegend. In diesem Fall wird der Resetpin nämlich nicht dauerhaft auf 0 gehalten während des Programmierens. Dann bleibt ja nur Ralph sein Vorschlag übrig.
Hallo, nun melde ich mich auch nochmal kurz zu Wort, da nun viele Spekulationen und nicht ganz richtige Aussagen aufkommen. Folgender Sachverhalt könnte diese jedoch hoffentlich klären: beim Atmega128 ist es so, dass die ISP Signale NICHT an den gleichnamigen Pins liegen, sondern MOSI an PE0 und und MISO an PE1. (siehe http://www.mikrocontroller.net/articles/AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Geh.C3.A4use ) Dieser Sachverhalt führt bei einigen vermutlich daher zu der Annahme, ich wolle einen Bootloader nutzen. Dem ist aber nicht so. @Georg g: Was genau meinst Du damit, wenn Du schreibst, ich hätte von "zwei Multiplexern gesprochen und damit den Unterschied zwischen Bootloader und ISP Programmierung nicht realisiert"? Ich habe einen 2 Kanal Multiplexer erwähnt. Nirgends aber von zwei Multiplexern. @Dietrich L.: Vielen Dank für Dein Angebot! Interessieren würde mich Deine Lösung auf jeden Fall! Viele Grüße BD
Da brauchst du gar nicht viel zu machen.
Haengt an den Pinen vom Controller ein anderer Eingang drauf ist es
egal.
Haengt da ein Ausgang von einem anderen Schaltkreis drauf brauchst du
lediglich da einen Widerstand von z.B. 1K einzuschleifen. Der
Programmieradapter setzt sich dann gegenueber dem 1K durch. Wenn der
fertig ist geht der mit seinen Leitung in den Tristate. Und der
Controller sieht wieder nur seine eigene Pheriferie.
Also so:
RX (uC)-----------+----1K----RS232Treiber Ausgang
|
Programmieradpater
Hier setzte sich der Adapter durch
TX (uC)-----------+----------RS232 Treiber Eingang
|
Programmieradpater
Hier ist es egal ob auch auf der RS232 die Signale rauskommen.
Angehängte Dateien:
-
ATMEGA32-64-pinout.jpg
46 KB
Ich lese den Artikel, studiere das Datenblatt, da ich ihn selbst schon hatte. Aber verstehe nicht wie oder warum der Schreiber dieses Textes auf den Gedanken kommt, das die Pins auf RXD oder TXD liegen?! Weder beim Atmega64 noch beim Atmega128 liegen Miso/Mosi und RXD/TXD auf ein und demselben Pin?! Nichtmal im 40Pin Dip Gehäuse.
bd schrieb: > Ich habe einen 2 > Kanal Multiplexer erwähnt. Nirgends aber von zwei Multiplexern. Was ist deiner Meinung nach der Unterschied zwischen zwei Multiplexern und einem 2-Kanal Multiplexer? Draco schrieb: > liegen Miso/Mosi und RXD/TXD Böse Falle! Ich hatte auch den 1284 im Kopf. Der 128 im 64-poligen Gehäuse hat tatsächlich diese abweichende Belegung. MISO-MOSI sind da nicht die ISP Anschlüsse.
:
Bearbeitet durch User
Doch, das ist schon so. Ich habe den 128 auch im Einsatz. Die ersten Boards hatten ISP natürlich zu MISO/MOSI geroutet... Nix ging. Tja, so ist das mit dem Lehrgeld/-zeit halt. https://www.olimex.com/Products/AVR/Development/AVR-MT128/resources/AVR-MT128-SCH-REV-A.pdf So wird's gemacht. Offiziell nachzulesen in http://www.atmel.com/images/doc2467.pdf p80: PE1 PDO/TXD0 (Programming Data Output or UART0 Transmit Pin) PE0 PDI/RXD0 (Programming Data Input or UART0 Receive Pin) Im aktuellen Board habe ich es auch mit 1k in Serie gemacht. Was macht eigentlich der /PEN-Pin genau. Aus dem bin ich noch nicht schlau geworden... VG Matthias
Ich komme auf die Idee, weil es so ist. Matthias Quade hat ja die richtige Stelle rausgesucht. bin ich anfangs auch drüber gestolpert.
Angehängte Dateien:
-
ISP-mit-4053.png
12 KB
bd schrieb: > @Dietrich L.: Vielen Dank für Dein Angebot! Interessieren würde mich > Deine Lösung auf jeden Fall! Siehe Anhang!
Oh oh oh... tatsächlich böse Falle!!! Ich lese es gerade auf Seite 300 im DB - echt, das is aber die einzigste Reihe die das so handhabt oder?! "Even though the SPI Programming interface re-uses the SPI I/O module, there is one important difference: The MOSI/MISO pins that are mapped to PB2 and PB3 in the SPI I/O module are not used in the Programming interface. Instead, PE0 and PE1 are used for data in SPI Programming mode as shown in Table 127"
Hi >echt, das is aber die einzigste >Reihe die das so handhabt oder?! Das betrifft nur die 64pol. ATMegas. Ist aber schon seit dem ATMega103 so. MfG Spess
Draco schrieb: > Oh oh oh... tatsächlich böse Falle!!! Es lohnt sich immer das Tutorial auf dieser Seite aufmerksam zu lesen: https://www.mikrocontroller.net/articles/AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Geh.C3.A4use
Thomas F. schrieb: > Draco schrieb: >> Oh oh oh... tatsächlich böse Falle!!! > > Es lohnt sich immer das Tutorial auf dieser Seite aufmerksam zu lesen: > > https://www.mikrocontroller.net/articles/AVR_Checkliste#Besonderheiten_bei_ATmega128_und_seinen_Derivaten_im_64-Pin-Geh.C3.A4use Naja, ich programmiere schon seit vielen Jahren AVRs :-D Aber das kannte ich halt noch nicht.
Helmut L. schrieb: > Also so: > > RX (uC)-----------+----1K----RS232Treiber Ausgang > | > Programmieradpater > > Hier setzte sich der Adapter durch > > TX (uC)-----------+----------RS232 Treiber Eingang > | > Programmieradpater > > Hier ist es egal ob auch auf der RS232 die Signale rauskommen. So mache ich das auch. Braucht man nur eine RS-232, dann kann man die UART1 dafür benutzen.
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.