usart problem mit ttl-Pegel

Es könnte auch sein, dass Du noch ein Masseproblem hast. Dann würde ich eher zu Optokopplern tendieren.

Karl K. schrieb:

IMG_20241117_093721_1CS.png

Ist es wirklich sooh schwer?

Wichtige Regeln - erst lesen, dann posten! Bitte das JPG-Format nur für Fotos und Scans verwenden! ... Siehe Bildformate.

Zeige den Schaltplan (insbesondere auch vom Adapter). Das Photo vom Drahtverhau deiner Schaltung macht die Beurteilung deiner Schaltung ETWAS mühselig. Wie sieht dein Massekonzept aus? Ist die RS485 irgendwo isoliert?

Rainer W. schrieb:

Wichtige Regeln - erst lesen, dann posten! Bitte das JPG-Format nur für Fotos und Scans verwenden! ... Siehe Bildformate.

Muß denn immer dieser oberlehrerhafte Zeigefinger sein? Ja das zweite Bild wäre im JPG Format vermutlich kleiner, aber die Welt geht deswegen nicht unter.

Rainer W. schrieb:

Zeige den Schaltplan (insbesondere auch vom Adapter).

Davon wird er vermutlich keinen Schaltplan haben. Auf dem Foto sieht das wie was Fertiges aus.

Ansonsten wären mehr Informationen zum Aufbau schon hilfreich. Das Foto des Aufbaus ist hier weniger hilfreich, da man nicht allzuviel erkennen kann. Auch wird hier wohl kaum jemand den schlecht erkennbaren Drahtverhau in einen aussagekräftigen Schaltplan verwandeln. Deshalb:

• mach mal einen Schaltplan, wo man die zusammengeschalteten Komponenten sehen kann. Der darf auch mit der Hand gemalt sein.
• Nenne mal die einzelnen Komponenten mit Name und Hausnummer. Also welcher Wechselrichter, welches Adapterboard?
• Wozu wird das Steckbrett gebraucht? Das und die Dupontkabel sind oft Fehlerquellen.

Irgendwie sind bei Dir alle Pegel schon etwas nach oben verschoben. Bei 4,6Vss sollte auch der HIGH-Pegel etwas kleiner sein. Auf Deinem Screenschot sieht aus als läge der ziemlich genau bei 5V. Ich vermute auch, das Du, wie Lu schon geschrieben hat, ein Masseproblem hast.

Also mach erst mal einen vollständigen Schaltplan (vom Adapter und Arduino reicht Blockdarstellung mit den benutzten Pins) und stelle den hier ein. Ich sehe in dem Drahtverhau auch noch weitere Bauteile (z.B. Widerstände), diese bitte auch einzeichnen. Ein Foto von der Unterseite der Lochrasterplatte wäre auch interessant. Vielleicht sieht man da ja eine schlechte Lötstelle, Zinnbrücke etc.

Rainer W. schrieb:

Wichtige Regeln - erst lesen, dann posten! Bitte das JPG-Format nur für Fotos und Scans verwenden! ... Siehe Bildformate.

Falsche Platte - Dateityp ist PNG.

• mach mal einen Schaltplan, wo man die zusammengeschalteten Komponenten sehen kann. Der darf auch mit der Hand gemalt sein.

Hans schrieb:

Also mach erst mal einen vollständigen Schaltplan (vom Adapter und Arduino reicht Blockdarstellung mit den benutzten Pins) und stelle den hier ein. Ich sehe in dem Drahtverhau auch noch weitere Bauteile (z.B. Widerstände), diese bitte auch einzeichnen.

Der Drahtverhau führt die uc-pins zur Steckerleiste: //m328 //d2 d3 d4 d5 d6 d7 b0 b1 b2 b3 b4 b5 ++ -- rst c1 c2 c3 c4 c5

Die Widerstände sind für i2c + ds1820. Funktioniert bzw. nicht bestückt.

der Anschluss Adapter zu uc hat nur 4 Leitungen:

rs485 GND-----------GND M328 RXD---------->RX TXD<----------TX VCC-----------Vin

alle durchgemessen - alle ok. Status-leds flackern.

Der low Pegel ist zu hoch. Im Netz findet man Vil maximal 0,8V. Da lieg ich ca. 1V drüber. Wenn der uc das Startbit nicht erkennt kann es nicht funktionieren.

Also muss der Pegel runter - aber wie?

Das Steckbrett habe ich zwischengeschaltet, um Dioden, Widerstände, etc ohne Löten testen zu können. War aber bislang nicht erfolgreich.

Hans schrieb:

• Nenne mal die einzelnen Komponenten mit Name und Hausnummer. Also welcher Wechselrichter, welches Adapterboard?

Deye-Wechselrichter, no-name adapter(Bild)

Karl K. schrieb:

Also muss der Pegel runter - aber wie?

Entweder ein Verdrahtungsproblem oder der IC hat einen Treffer. Ist aber eher unwahrscheinlich. Miss mal die Spannung zwischen der Masse auf dem Adapter und direkt am Arduino. Dort sollten 0V rauskommen, vermutlich aber deine 1,5V.

Das Steckbrett habe ich zwischengeschaltet, um Dioden, Widerstände, etc ohne Löten testen zu können. War aber bislang nicht erfolgreich.

Vermutlich was falsch verkabelt und ein paar Dioden in die Masse eingeschleift?

Karl K. schrieb:

• Nenne mal die einzelnen Komponenten mit Name und Hausnummer. Also welcher Wechselrichter, welches Adapterboard?

Deye-Wechselrichter, no-name adapter(Bild)

Das ist aber einer mit TXD und RXD, da gibt es kein Signal zur Richtungsumschaltung!

Falk B. schrieb:

Miss mal die Spannung zwischen der Masse auf dem Adapter und direkt am Arduino.

unter 1mV.

Das ist aber einer mit TXD und RXD, da gibt es kein Signal zur Richtungsumschaltung!

Das ist richtig. Der zweite Adapter ist etwas anders als der erste auch nicht funktionierende.

Sherlock 🕵🏽‍♂️ schrieb:

Messe nach, ob wirklich auf beiden Seiten das gleiche und richtige GND Potential ist.

Ich habe jetzt beide GNDs nochmal direkt verbunden => keine Änderung.

Kann es sein, daß du RXD und TXD falsch verbunden hast? TXD sollte ein Eingang am Adapter sein, der mit RXD am Ardino verbunden werden muss und umgekehrt.

Karl K. schrieb:

Der Drahtverhau führt die uc-pins zur Steckerleiste: //m328 //d2 d3 d4 d5 d6 d7 b0 b1 b2 b3 b4 b5 ++ -- rst c1 c2 c3 c4 c5

Bist Du nicht in der Lage einen vernünftigen Plan zu zeichnen? Ich habe so langsam den Eindruck Du willst keine Hilfe.

Falk B. schrieb:

Kann es sein, daß du RXD und TXD falsch verbunden hast? TXD sollte ein Eingang am Adapter sein, der mit RXD am Ardino verbunden werden muss und umgekehrt.

Hmm, da hab ich wohl Blödsinn geschrieben, wenn die Pfeile der Datenrichtung auf dem Bild vom Adapter korrekt sind.

Sherlock 🕵🏽‍♂️ schrieb:

Lösungsvorschlag: Verwende andere Pins, die nicht doppelt belegt sind, und die SoftwareSerial Klasse.

Man könnte auch die 1k Widerstände zum USB IC und die Vorwiderstände der LEDs auf 2-3k erhöhen, das reicht.

Hans schrieb:

Davon wird er vermutlich keinen Schaltplan haben.

Einen zu zeichnen ist keine Option? Er hat das Modul doch vor der Nase und mehr als 2 Lagen sind mir bei den Modulen aus CN noch nie unter gekommen.

Karl K. schrieb:

Falsche Platte - Dateityp ist PNG.

Ich kann nichts dafür, dass der Hinweis sprachlich so formuliert ist. Lies ihn einfach als: "Bitte für Fotos und Scans das JPG-Format verwenden!". Nach Lektüre des Artikels über die Bildformate sollte die Begründung klar sind. Sonst könntest du deine Schaltung auch als Video hochladen und bei der Aufnahme dazu noch wild mit der Kamera wedeln.

Rainer W. schrieb:

Hans schrieb:

Davon wird er vermutlich keinen Schaltplan haben.

Einen zu zeichnen ist keine Option? Er hat das Modul doch vor der Nase und mehr als 2 Lagen sind mir bei den Modulen aus CN noch nie unter gekommen.

Du meinst das er das hinbekommt? Er kann ja noch nicht einmal einen Schaltplan von seinem Aufbau zeichnen.

Rainer W. schrieb:

Karl K. schrieb:

Falsche Platte - Dateityp ist PNG.

Ich kann nichts dafür, dass der Hinweis sprachlich so formuliert ist. Lies ihn einfach als: "Bitte für Fotos und Scans das JPG-Format verwenden!". Nach Lektüre des Artikels über die Bildformate sollte die Begründung klar sind. Sonst könntest du deine Schaltung auch als Video hochladen und bei der Aufnahme dazu noch wild mit der Kamera wedeln.

Laß doch einfach mal das Gemecker über die Bildformate sein. Wenn die Dir zu groß sind mußt Du sie Dir nicht anschauen. Andere Leute hängen ganze PDF's an, obwohl in den Regeln steht so etwas als Link zu machen - da meckert doch auch keiner.

Sherlock 🕵🏽‍♂️ schrieb:

Vermutung: Dein RS485 Board ist nicht defekt sondern zu schwach, das Signal auf LOW zu ziehen. Das Experiment in Beitrag "Re: usart problem mit ttl-Pegel" wird dies bestätigen, wenn ich Recht habe.

ich glaube, du hast recht. Ich habe die rx-rx-Verbindung gelöst und den rx-Pegel beim Adapter gemessen. Zu meiner großen Verwunderung ging er bis auf Null runter. Der Adapter ist also ok.

Nach Anschluss des uc geht der low-Pegel auf 1,5V mit einem 1k-Pulldown bekommt man ihn auf 1,2V runter.

Der M328 hat ja 2Usarts. ich werde also auf den anderen usart umlöten.

Viel gelernt - auch über Bildformate - und alle genervt.

Danke für die Hilfe.

Karl K. schrieb:

Viel gelernt - auch über Bildformate -

Nein. Für Screenshots nutzt man PNG, für Bilder und Scans JPG. Siehe Bildformate.

Und man sollte die Nullinie am Oszi auf eine Line vom Raster einstellen, da kann man die Spannungen besser ablesen.

Hans schrieb:

Laß doch einfach mal das Gemecker über die Bildformate sein.

Halt dich doch einfach an die Formatierungshinweise des Forenbetreibers. Von mir stammen die Regeln nicht.

Falk B. schrieb:

Nein. Für Screenshots nutzt man PNG

Das hängt doch wohl vom Inhalt des Bildschirmes ab. Ein Photo wird nicht zu einem Screenshot, nur weil es vom Bildschirm kopiert wird.

Rainer W. schrieb:

Falk B. schrieb:

Nein. Für Screenshots nutzt man PNG

Das hängt doch wohl vom Inhalt des Bildschirmes ab.

Ok, ein Screenshot eines Digitaloszilloskops.

Ob die Tx & Rx richtig angeschrieben sind, weiss ich nicht. Es gibt solche Leute die machen das so fuer RS232. Tx, dh dort wo die Daten raus kommen hat ein Ruhepotential, dh nicht angeschlossen, + oder -12 V, kann auch + oder -3 V sein. Rx is nicht angeschlossen auf GND. Waehrend RS485 differential ist und als GND, Data+, Data- angeschrieben ist. Ob Rx oder Tx ist die Richtung der Daten, es schalten aber beide Daten. Tx ist auf der Seite, wo ein Potential, oder ein Datenstrom anliegt im Falle von Stecker weg anliegt. Das kann aber die Seite wechseln.

Bei RS485 fuerhre ich GND, Data+, Data- und die Speisung am Stecker und dem Kabel mit, dann kann man auf der anderen Seite galvanisch trennen und den Trenner mit versorgen.

Bei RS232 fuehre ich genauso, GND, Tx, Rx, und die Speisung auf Stecker und Kabel fuer den Trenner auf der anderen Seite

Sherlock 🕵🏽‍♂️ schrieb:

Karl K. schrieb:

Der M328 hat ja 2Usarts.

Wenn ich das Datasheet richtig verstanden habe kann man Miso als rx-uart verwenden. >Using the USART in MSPI mode<

Ist mir aber zu kompliziert. Ich mach das in software:

1

#define rx_bit_delay 48

2

#define rx_pin (PINC & (1<<2))

3

4

uint8_t sub_usart_rx(void)

5

{

6

uint8_t byte=0;

7

while(rx_pin);

8

_delay_us(rx_bit_delay);

9

_delay_us(rx_bit_delay);

10

_delay_us(rx_bit_delay);

11

if(rx_pin)byte+=1;

12

_delay_us(rx_bit_delay);

13

_delay_us(rx_bit_delay);

14

if(rx_pin)byte+=2;

15

_delay_us(rx_bit_delay);

16

_delay_us(rx_bit_delay);

17

if(rx_pin)byte+=4;

18

_delay_us(rx_bit_delay);

19

_delay_us(rx_bit_delay);

20

if(rx_pin)byte+=8;

21

_delay_us(rx_bit_delay);

22

_delay_us(rx_bit_delay);

23

if(rx_pin)byte+=16;

24

_delay_us(rx_bit_delay);

25

_delay_us(rx_bit_delay);

26

if(rx_pin)byte+=32;

27

_delay_us(rx_bit_delay);

28

_delay_us(rx_bit_delay);

29

if(rx_pin)byte+=64;

30

_delay_us(rx_bit_delay);

31

_delay_us(rx_bit_delay);

32

if(rx_pin)byte+=128;

33

_delay_us(rx_bit_delay);

34

return byte;

35

}

wenn ich die Schwierigkeiten vorher geahnt hätte, hätte ich einen moderneren uc genommen. Ich mag aber WIN-AVR.

Karl K. schrieb:

Wenn ich das Datasheet richtig verstanden habe kann man Miso als rx-uart verwenden. >Using the USART in MSPI mode<

Ist mir aber zu kompliziert. Ich mach das in software:

Totaler Unsinn. Und ein Soft-UART geht anders.

Karl K. schrieb:

Viel gelernt - auch über Bildformate

Du kannst noch mehr lernen: JPEG ist als verlustbehaftetes komprimierendes Verfahren optimal für Fotos aus der realen Welt. Und auch für Screenshots von solchen Fotos.

Für computergenerierte flächige und orthogonal einfarbige Bilder wie z.B. Oszilloskopbilder ist PNG die richtige Wahl.

Falk B. schrieb:

Ok, ein Screenshot eines Digitaloszilloskops.

Wenn es ein Foto eines Oszillogramms wäre, dann wäre JPEG richtig. Es wäre aber auch völlig falsch, ein Foto vom Bildschirm eines Oszis zu machen, das eine Screenshotfunktion hat.

Hans schrieb:

Laß doch einfach mal das Gemecker über die Bildformate sein. Wenn die Dir zu groß sind mußt Du sie Dir nicht anschauen.

Es geht darum, seine Werkzeuge zu kennen und richtig auszuwählen. JPEG ist verlustbehaftet und erzeugt deshalb Artefakte an scharfen Kanten.

Andere Leute hängen ganze PDF's an, obwohl in den Regeln steht so etwas als Link zu machen

Das ist mir neu. In welchen Regeln steht das?

Karl K. schrieb:

Ist mir aber zu kompliziert. Ich mach das in software

Siehe dazu den Beitrag "USART tx-timing Problem"

Für computergenerierte flächige und orthogonal einfarbige Bilder wie z.B. Oszilloskopbilder ist PNG die richtige Wahl.

Ist auch kleiner (16k) als das JPEG (100k) wegen der geringeren Farbanzahl, PNG kann auch gut komprimieren, siehe Anhang.

zum Üben des richtigen Bildformats und

Falk B. schrieb:

Totaler Unsinn. Und ein Soft-UART geht anders.

zum Nachweis, dass der Software-Uart zuverlässig die Werte vom WR abholt.

Lesen und Schreiben der WR-Register funktioniert. Vielen Dank für die Unterstützung. Insbesondere bei Sherlock und - ja - auch bei Falk.

Karl K. schrieb:

Falk B. schrieb:

Totaler Unsinn. Und ein Soft-UART geht anders.

zum Nachweis, dass der Software-Uart zuverlässig die Werte vom WR abholt.

Er empfängt welche. Wie zuverlässig das ist, weißt du nicht. Das müßte man messen und testen.

Falk B. schrieb:

Das müßte man messen und testen.

1

uart_str_count = 0;

2

while(uart_str_count<7)

3

{

4

uart_string[uart_str_count++]=sub_usart_rx();

5

}

6

7

    lcd_goto(3,1);//

8

    lcd_int(uart_string[0]);lcd_write(" ");//01

9

    lcd_int(uart_string[1]);lcd_write(" ");//03

10

    lcd_int(uart_string[2]);lcd_write(" ");//02

11

    lcd_int(uart_string[3]);lcd_write(" ");//00

12

    lcd_int(uart_string[4]);lcd_write(" ");//05

13

    lcd_int(uart_string[5]);lcd_write(" ");//78

14

    lcd_int(uart_string[6]);//

15

wait;

16

wait;

17

wait;

18

wait;

19

lcd_clear(3);//              =

wird alle 4 Sekunden aufgerufen und läuft schon eine ganze Weile ohne dass mir ein Fehler aufgefallen ist. Bei rx-usart geht es ja nur darum, die bits irgendwo im Bereich der 104us zu treffen. Das macht die Funktion mit den delays recht zuverlässig. Für den Fall der Fälle kommt noch ein Abbruch-timer rein aber ich halte das jetzt schon für durchaus brauchbar.

Lothar M. schrieb:

Andere Leute hängen ganze PDF's an, obwohl in den Regeln steht so etwas als Link zu machen

Das ist mir neu. In welchen Regeln steht das?

Da steht bei Bildformaten, Zitat:"Manchmal ist es angebracht, überhaupt nichts anzuhängen. Beispielsweise ist das oft der Fall bei Datenblättern: Statt die möglicherweise hundertste Version des Datenblattes heraufzuladen, wäre ein Link deutlich angebrachter." Das hier gepostete PDF ist von einer Webseite und da hätte der Link durchaus genügt. Am Ende ist das angehängte PDF mit 852kB auch nur ein Bild.

Mir geht einfach das Rumgemoser einiger Blockwarte, die ansonsten nichts zum Thema beitragen, auf den Zünder. Die Dateigröße, um die es ja bei den Regeln geht, ist doch heutzutage eher zweitrangig. Die Zeiten mit GSM und Co. sind lange vorbei.

Karl K. schrieb:

wird alle 4 Sekunden aufgerufen und läuft schon eine ganze Weile ohne dass mir ein Fehler aufgefallen ist.

Nett, aber nur ein einfacher Test. Richtig Stress ist das nicht.

Bei rx-usart geht es ja nur darum, die bits irgendwo im Bereich der 104us zu treffen. Das macht die Funktion mit den delays recht zuverlässig.

Wenn dir keine Interrupts reinhauen. Beim Arduino läuft im Hintergrund noch Timer 0.

Ein UART macht zB 4 fach oder 8 fach oversampling, und schiebt die Werte in einen Buffer rein. 3 von 4 samples muessen richtig sein fuer ein bit. Dann muessen Start und Stop bit stimmen, dass das Byte erkannt wird. Und man darf nicht erwarten, dass die bytes buendig, ohne zwischenraum kommen.

Pandur S. schrieb:

Ein UART macht zB 4 fach oder 8 fach oversampling, und schiebt die Werte in einen Buffer rein. 3 von 4 samples muessen richtig sein fuer ein bit.

Teilweise. Die meisten UARTs versuchen, in Bitmitte abzutasten. Das macht auch die oben gezeigte Funktion. Wie GUT sie das macht, muss man messen.

Dann muessen Start und Stop bit stimmen, dass das Byte erkannt wird.

Nö, nur das Startbit, denn dessen fallende Flanke gibt den Startschuss. Danach ist der Zähler/Oszillator des Empfängers im Freilauf.

Und man darf nicht erwarten, dass die bytes buendig, ohne zwischenraum kommen.

Das macht keiner, auch nicht die Funktion oben. Er wartet auf die fallende Flanke des Startbits.

Karl K. schrieb:

Ist mir aber zu kompliziert. Ich mach das in software:

Was man hier einfach und schnell testen kann. Nach jeder Bitabtastung ein Testpin umschalten. Da kann man auf dem Oszi den Abtastzeitpunkt mit dem Datensignal vergleichen, das geht besonders gut mit dem Muster 0x55 oder 0xCC.

Und wenn die Baudrate sowieso statisch ist, kann man auch ohne Zeilenmarathon sowas schreiben. Der Compiler rechnet das aus und ersetzt die Konstanten.

1

#define RX_BIT_TIME 96

2

#define RX_DATA (PINC & (1<<2))

3

#define TEST_LOW PORTC &= ~(1<<3); 

4

#define TEST_TOG PORTC ^=  (1<<3); 

5

6

uint8_t sub_usart_rx(void)

7

{

8

    uint8_t data=0;

9

    TEST_LOW;

10

11

    while(RX_DATA);      // Warte auf fallende Flanke vom Startbit

12

    _delay_us((RX_BIT_TIME*1.5);

13

    if(RX_DATA) data |= 1<<0;

14

    TEST_TOG;

15

    _delay_us(RX_BIT_TIME);

16

    if(RX_DATA) data |= 1<<1;

17

    TEST_TOG;

18

    _delay_us(RX_BIT_TIME);

19

    if(RX_DATA) data |= 1<<2;

20

    TEST_TOG;

21

    _delay_us(RX_BIT_TIME);

22

    if(RX_DATA) data |= 1<<3;

23

    TEST_TOG;

24

    _delay_us(RX_BIT_TIME);

25

    if(RX_DATA) data |= 1<<4;

26

    TEST_TOG;

27

    _delay_us(RX_BIT_TIME);

28

    if(RX_DATA) data |= 1<<5;

29

    TEST_TOG;

30

    _delay_us(RX_BIT_TIME);

31

    if(RX_DATA) data |= 1<<6;

32

    TEST_TOG;

33

    _delay_us(RX_BIT_TIME);

34

    if(RX_DATA) data |= 1<<7;

35

    TEST_TOG;

36

    _delay_us(RX_BIT_TIME);    // Stop Bit abwarten

37

38

    TEST_LOW;

39

    return data;

40

}

Falk B. schrieb:

_delay_us(RX_BIT_TIME); if(RX_DATA) data |= 1<<7; TEST_TOG; _delay_us(RX_BIT_TIME); // Stop Bit abwarten

guter Vorschlag - wobei "TEST_TOG;" beim letzten bit reicht.

wenn es funktioniert macht es richtig Spass:

1

v u8 wr_status_0off_1on=0;

2

#define wr_soc   0x010300D6000165f2

3

#define wr_pvolt 0x010302A600016591

4

#define wr_onoff 0x010300500001841b

5

6

void wr_on(void)

7

{

8

wr_status_0off_1on=1;

9

wr_write(0x011000, 0x5000010100019bc0);

10

}

11

12

void wr_off(void)

13

{

14

wr_status_0off_1on=0;

15

wr_write(0x011000, 0x5000010100005a00);

16

}

17

18

void wr_read_reg()

19

{

20

  lux=1024-Read_ADC();

21

      lcd_goto(1,10);//              

22

      lcd_int4(lux);//              

23

  //soc auslesen

24

  soc=wr_read(wr_soc);

25

      lcd_goto(1,15);//              

26

      lcd_int4(soc);//              

27

28

  pvolt=wr_read(wr_pvolt);

29

      lcd_goto(2,1);//              

30

      lcd_int4(pvolt/10);//   

31

32

  wr_status_0off_1on=wr_read(wr_onoff);

33

      lcd_int4(wr_status_0off_1on);//   

34

35

//Anschalten:

36

  if(hou>4 && hou<16 && soc>20 && pvolt>300 && wr_status_0off_1on==0) wr_on();

37

  if(hou>5 && pvolt>500 && wr_status_0off_1on==0) wr_on();

38

39

//Abschalten

40

  if((hou>16 || hou<6) && pvolt<400 && soc<41 && wr_status_0off_1on==1) wr_off();

41

}

Einmal hat es jetzt funktioniert. (Einmal ist der uc hängen geblieben).

Ich möchte das ganze jetzt ausfallsicher machen. Eine crc-Überprüfung soll noch rein.

Weiter möchte ich den uc über den PC steuern. D.h. statt auf dem LCD sollen die Systemwerte auf den PC übertragen werden und die An- und Abschaltbedingungen sollen mittels RS485 auf dem uc-eeprom abgespeichert und von dort abgerufen werden.

Hans schrieb:

Laß doch einfach mal das Gemecker über die Bildformate sein.

wenn du Hilfe möchtest solltest du die Helfewilligen nicht verprellen!

Die Regeln haben einen Sinn auch wenn die nicht jeder verstehen muß.

Falls jemand das gleiche Problem hat:

Auf der Rückseite des nano befinden sich zwei 1k-Widerstände zu rx/tx-ft232. Wenn man den oberen/rx ablötet funktioniert der rx-uart.