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
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.
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.
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
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
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.
