UART parallel

Nach Genuss des Schaltplanes (https://www.arduino.cc/en/uploads/Ma...0Schematic.pdf) habe ich mal eine Frage zum Arduino:

Zwischen RxD am Controller und RxD-Pin an der Stiftleiste/ FTDI-Chip sitzt ein Angstwiderstand, ok.
RxD-Pin an der Stiftleiste und TxD vom FTDI-Chip scheinen aber gebrückt.
Wenn ich jetzt an RxD an der Pinleiste etwas munter Sendendes anschließe, während der Baustein über den FTDI-Chip geproggt wird, kann das doch nicht funktionieren, oder?

Gibt's für den Fall irgendwelche Empfehlungen?

Wo ist da etwas gebrückt? Weil RX auf TX geht?

Das muss so sein. Der TX vom Atmel sendet Daten an den RX des FTDI und der TX vom FTDI sendet Daten an RX vom Atmel.
Rxd => Receive x Data, Txd => Transmit x data

MfG Hannes

Zitat:

---

Zitat von 021aet04

... und der TX vom FTDI sendet Daten an RX vom Atmel.

---

Der TX vom FTDI sendet die Daten aber auch an die Stiftleiste?!?
Respektive die Pegel eines an der Stiftleiste angeschlossenen Gerätes schließen sich doch mit dem Pegel des FTDI kurz.

Selbst wenn der FTDI einen OpenDrain als Ausgang verwendet: wenn ich den Pin an der Stifteiste aktiv belege, kann doch mit dem Proggen nichts mehr gehen?!?

Ach Mist jetzt sehe ich's: Der Angstwiderstand sitzt zwischen FTDI und Controller. Ändert aber nichts an der Tatsache, dass man den Controller nicht programmieren kann, wenn da etwas an der Stiftleiste aktiv den Pegel zieht.

Zitat:

---

.. Ändert aber nichts an der Tatsache, dass man den Controller nicht programmieren kann, wenn da etwas an der Stiftleiste aktiv den Pegel zieht.

---

Vielleicht bin ich zu einfach gestrickt, aber ISP heißt bei mir In System Programming - also nicht Programmable At Runtime . . . Vielleicht sehe ich da was falsch oder zu eng und deswegen auch kein Problem.

Programming at runtime - sozusagen (was ja wohl eh nicht geht, denke ich) - wär interessant das auszuprobieren.

An der Pinleiste darf man nichts anschließen wenn man über die USB Schnittstelle kommunizieren will.

@ oberallgeier
Beim Arduino wird über USB programmiert und nicht über ISP. Ich arbeite aber auch lieber mit ISP, wobei man da auch aufpassen muss das man die Pins auf einen Pegel zieht (VCC bzw GND) über einen Kontakt o.Ä.. Mit Kapazitäten muss man auch aufpassen, die sollten nicht zu groß sein (hatte ich leider selbst erfahren müssen).

MfG Hannes

Zitat:

---

.. Beim Arduino wird über USB programmiert und nicht über ISP ..

---

Na ja, das weiß ich schon, vielleiht aber zu wenig; müsste mich da wohl mal reinvertiefen.

Bisher dachte ich immer, diese USB-Lösung sei nur wie ein "normaler" Bootloader, bei dem über die serielle Schnittstelle (genauer über UART) geflasht wird - und ich dachte weiter (oder dachte vielleicht doch zu kurz), dass die Geschichte mit dem FTDI (oder CH340) nur - lasch ausgedrückt - ne Art Umleitung des UART sei mit dem Vorteil, dass man mit USB-Anschluss flashen kann und keinen separaten Programmer benötigt. Weil die wenigsten Computer heute mit ner RS232 daher kommen *gg*.

Und: Bisher dachte ich immer, diese UARTprogrammierung sei wie ein "normaler" Bootloader - da wird es bei zwei gleichzeitig eingehenden Signalenzügen schlicht zu ner Konfusion des Bootloaders kommen. Sprich: es ist ein Softwareproblem, kein Hardwareproblem ! ?

Beim Arduino ist ein eigener Bootloader geflasht.
Wenn man über über die Arduino IDE ein Programm überträgt wird zuerst mit der DTR Leitung vom FT232 der AVR neu gestartet. Anschließend wird das Anwenderprogramm übertragen.
Wenn kein Programm übertragen wird (bei einem normalen Reset ohne Arduino IDE) startet der Bootloader dann das Anwenderprogramm.
Wie das aber genau funktioniert weiß ich nicht, da ich auch die Arduinos über ISP programmiere. Debuggen kann ich auch über den ISP Anschluss (dW), da muss man aber den Kondensator zwischen DTR und Reset entfernen.

MfG Hannes

Zitat:

---

Zitat von 021aet04

Beim Arduino ist ein eigener Bootloader geflasht.
Wenn man über über die Arduino IDE ein Programm überträgt wird zuerst mit der DTR Leitung vom FT232 der AVR neu gestartet. Anschließend wird das Anwenderprogramm übertragen.

---

Ok, der DTR scheint lt. Schaltplan auch nur einen Impuls auf den RESET zu geben. Dann sollte es ja möglich sein, dem angeschlossenen UART-Gerät über einen zusätzlichen GPIO (gehen im Reset auf tristate) mitzuteilen, dass es interim den Schnabel zu halten hat. Wenn das UART-Gerät an seinem TxD einen Open-Drain-Ausgang mit z.B. 10k verwendet (zieht beim Senden nur aktiv auf Low), sollte der FTDI ja wieder senden können.

Der DTR gibt nur einen Impuls auf RST. Muss auch so sein, weil wenn du RST dauerhaft auf GND legen würdest, würde auch der Bootloader nicht starten. Der Bootloader ist auch nur ein Programm das im Flash liegt.

Ich würde die DTR leitung verwenden um auch die anderen UART Geräte zu steuern (sperren). Also wenn du ein Programm überträgst wird über DTR der AVR neu gestartet und gleichzeitig für eine gewisse Zeit (z.B. 15s) die UART Geräte deaktiviert. Wenn die Zeit abgelaufen ist (diese muss solange dauern bis das Programm übertragen ist) gibst du die Geräte wieder frei.
Statt einer Zeit kannst du einen Ausgang verwenden (sofern einer frei ist). Im Programm schaltest du einen Pin auf high und gibst die UART Übertragung vom Gerät frei. Wenn du eine "Alive-Led" hast, also eine Led die blinkt wenn das Programm korrekt läuft, kannst du auch diese nehmen um die Übertragung freizugeben.

MfG Hannes