USART tx-timing Problem

[Karl K. (leluno)]

altes Problem - aber ich finde die Lösung nicht:

(mega328)
serial_read(0x01030000000184ff);


.....


uint8_t status_0tx_1rx = 0;
void serial_read(uint64_t x) {
//for (uint8_t i=14;i-=2;i<254)
  {

  PORTC|=(1<<2);
  ct_tx_isr=0;

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(14*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(12*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(10*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(8*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(6*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(4*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(2*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));
    
    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(0*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

>>>>    _delay_ms(2);  <<<<<

    PORTC &= ~(1<<2);
status_0tx_1rx = 1;

  while (status_0tx_1rx) 
  {
    if ( (UCSR0A & (1<<RXC0)) )
    {
      // Zeichen wurde empfangen, jetzt abholen
      uint8_t c;
      c = uart_getc();
      // hier etwas mit c machen z.B. auf PORT ausgeben
    
    if( 
  //nextChar != '\n' &&
    //    nextChar != '\r' &&
        uart_str_count < UART_MAXSTRLEN ) 
  {
      uart_string[uart_str_count] = c;
      uart_str_count++;
    }
    else {
      uart_string[uart_str_count] = '\0';
      uart_str_count = 0;
      uart_str_complete = 1;
  led1_blink; 
  
  lcd_goto(3,7);//
  lcd_int(c);// 
    lcd_int(uart_string[0]);
    lcd_int(uart_string[1]);
    lcd_int(uart_string[2]);
    lcd_int(uart_string[3]);
    lcd_int(uart_string[4]);
wait;
wait;
wait;
wait;
              
  lcd_clear(3);//              =

    status_0tx_1rx=0;
    }
   
  }
    else
    {
      // Kein Zeichen empfangen, Restprogramm ausführen...
    }
  }
  }
}

Ohne _delay_ms(2); werden Werte beim tx verschluckt.

Was ist bei der Wartefunktion falsch??

    UCSR0A &=~ (1<<TXC0);
    serial_char((x>>(0*4)) & 0xff);
    while(!(UCSR0A & (1<<TXC0)));

Danke für Unterstützung

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Karl K. schrieb:
> Ohne _delay_ms(2); werden Werte beim tx verschluckt.
Wie sieht der Aufbau aus? Wer ist der Sender? Wer ist der Empfänger? 
Welche Werte werden verschluckt? Immer die selben oder beliebige?

Oder kurz: was soll das Programm machen und was macht es stattdessen?

[Rainer W. (rawi)]

Karl K. schrieb:
> altes Problem

Es gibt ein noch viel älteres:

Wichtige Regeln - erst lesen, dann posten!
...
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Rainer W. schrieb:
> Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang
Der Code an sich ist eigentlich gar nicht mal so lang wenn man die 
unnötigen Leerzeilen rauslöscht. Hab ich mal gemacht...

[Karl K. (leluno)]

Das Programm soll - irgendwann - einen Wechselrichter per RS485 - 
steuern.

serial_read(0x01030000000184ff);

Sendet eine bestimmte Zeichenfolge auf die der WR antworten muss.

Zur Zeit ist der Empfänger ein c#-Programm auf dem PC.

Die Zeichenfolge wird im Prinzip richtig gesendet. Nur ohne das delay 
werden die letzten beiden Zeichen mit '0' ausgegeben. D.h. Die 
Übertragung wird durch den auf den Sende-Befehl folgenden Befehl 
vorzeitig abgebrochen.

Eigentlich müsste doch das Setzen des TXCO-Bits abgewartet werden?

[Rainer W. (rawi)]

Lothar M. schrieb:
> Der Code an sich ist eigentlich gar nicht mal so lang wenn man die
> unnötigen Leerzeilen rauslöscht. Hab ich mal gemacht...

Wenn der Code nicht mehr auf eine Seite passt, der Zeilenzähler 
dreistellig wird und damit die Forensoftware die Formatierung nicht mehr 
sauber hin bekommt, fühlt sich das lang an.

Karl K. schrieb:
> Ohne _delay_ms(2); werden Werte beim tx verschluckt.

Wie stellst du das fest?
Was sagt der LA, was sagt der Debugger?

Wieso erwartest du überhaupt, dass eine Funktion namens serial_read() 
irgendetwas mit tx zu tun hat ;-)

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Karl K. schrieb:
> serial_read() .... Sendet
Ja, das ist in der Tat verwirrend...

> Nur ohne das delay werden die letzten beiden Zeichen mit '0' ausgegeben.
1. siehst du die beiden "Nullwerte" auch so mit einem Oszi auf der 
Leitung?
2. was passiert, wenn du nochmal zusätzlich 2 Bytes ausgibst?

> Zur Zeit ist der Empfänger ein c#-Programm auf dem PC.
1. kannst du da mal ein "übliches" Terminalprogramm" verwenden?
2. welche Hardware verwendest du? Es gibt mir zu denken, dass du RS485 
schreibst. Da muss zum richtigen Zeitpunkt der Treiber von "Senden" auf 
"Empfangen" umgeschaltet werden...

[Falk B. (falk)]

Karl K. schrieb:
> altes Problem - aber ich finde die Lösung nicht:

Schon mal was von einer Schleife gehört? Oder wirst du nach 
Programmzeilen bezahlt?

Hat es einen Grund, warum das so äußerst merkwürdig machen willst?
Eine Halbduplex-Sendefunktion baut man anders. Außerdem löscht man das 
TXC0 Flag, indem man eine 1 reinschreibt! Klingt komisch, ist aber so! 
RTFM!

UCSR0A &=~ (1<<TXC0);

Damit wird TCX0 NICHT gelöscht! Eher so.

UCSR0A |= (1<<TXC0);

Ja, so!

Außerdem prüft man für das Senden meistens UDRE0, denn damit kann man 
lückenlos senden. Das ist ja der Witz des Sendepuffers. Nur beim letzten 
Byte prüft man TXC0, um dann den Tranceiver wieder auf Empfangen bzw. 
Tristate zu schalten. Siehe Anhang. Solche Daten übergibt man aber 
besser als Pointer auf ein Bytearray, nicht als 64 Bit Zahl.

[Falk B. (falk)]

So mit einem Pointer auf ein Bytearray.

void serial_read(uint8_t *x)
{
    uint8_t tmp;

    PORTC|=(1<<2);      // Sender aktiv
    ct_tx_isr=0;
    for (uint8_t i=0; i < 8; i++)
    {
        while(!(UCSR0A & (1<<UDRE0));        
        serial_char(*x++);
    }

[Karl K. (leluno)]

Lothar M. schrieb:
> 2. welche Hardware verwendest du? Es gibt mir zu denken, dass du RS485
> schreibst. Da muss zum richtigen Zeitpunkt der Treiber von "Senden" auf
> "Empfangen" umgeschaltet werden...

M328-Nano + RS485-Adapter, ich mach heute abend mal ein Foto.

Mit     PORTC &= ~(1<<2); wird von Senden auf Empfangen umgeschaltet.

Terminalprogramm ist eine gute Empfehlung.

Falk B. schrieb:
> Außerdem löscht man das
> TXC0 Flag, indem man eine 1 reinschreibt! Klingt komisch, ist aber so!
> RTFM!

Das wird es sein - Ich habe extra ins fucking Manual geguckt - aber da 
war wohl noch was an anderer Stelle.

Falk B. schrieb:
> Schon mal was von einer Schleife gehört?

//for (uint8_t i=14;i-=2;i<254)
Hatte ich zuerst probiert - ging aber nicht. Wenn das Ganze erst mal 
funktioniert werde ich das noch layouten - wobei die Auflösung der 
Schleife durchaus Sinn ergeben kann weil die Steuerung der Schleife 
wegfällt.

Danke für alle Hinweise - insbesondere TXC0-Flag. Ich werde das heute 
abend probieren und berichten.

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Karl K. schrieb:
> M328-Nano + RS485-Adapter, ich mach heute abend mal ein Foto.
Wenn du kein Oszi hast, dann teste deine Software mal mit einer normalen 
RS232-Schnitte, da muss der Treiber nicht umgeschaltet werden und du 
siehst was der µC tatsächlich sendet.

Karl K. schrieb:
> Falk B. schrieb:
>> Außerdem löscht man das TXC0 Flag, indem man eine 1 reinschreibt!
> Das wird es sein - Ich habe extra ins fucking Manual geguckt
An der falschen Stelle. Da wunderst es eher, dass überhaupt was 
sinnvolles übertragen wird...

[Rainer W. (rawi)]

Karl K. schrieb:
> M328-Nano + RS485-Adapter, ich mach heute abend mal ein Foto.

Was ist ein M328-Nano? Selbst Google ist da etwas hilflos.

Karl K. schrieb:
> Mit     PORTC &= ~(1<<2); wird von Senden auf Empfangen umgeschaltet.

Karl K. schrieb:
> PORTC|=(1<<2);
> ...
> PORTC &= ~(1<<2);

Magic Numbers machen den Code nicht gerade lesbarer. Spätestens wenn der 
Pin woanders hin gelegt werden soll - viel Spaß in längerem Quellcode.

[Falk B. (falk)]

Karl K. schrieb:
> Das Programm soll - irgendwann - einen Wechselrichter per RS485 -
> steuern.
>
> serial_read(0x01030000000184ff);
>
> Sendet eine bestimmte Zeichenfolge auf die der WR antworten muss.

Ganz schlechter Stil. Eine Funktion sollte nur genau DAS machen, was der 
Name besagt! Bei dir solltest du senden und empfangen in getrennte 
Funktionen packen.

Strukturierte Programmierung auf Mikrocontrollern

[Falk B. (falk)]

Rainer W. schrieb:
> Was ist ein M328-Nano? Selbst Google ist da etwas hilflos.

ATmega328 auf dem Arduino Nano. Ok, diese Wortschöpfung ist unnötig und 
verwirrend.

[Falk B. (falk)]

Rainer W. schrieb:
> Karl K. schrieb:
>> PORTC|=(1<<2);
>> ...
>> PORTC &= ~(1<<2);
>
> Magic Numbers machen den Code nicht gerade lesbarer. Spätestens wenn der
> Pin woanders hin gelegt werden soll - viel Spaß in längerem Quellcode.

Stimmt. Ein Macro ist hier das mittel der Wahl, den es ist 
selbsterklärend.

#define RS485_TRANSMIT PORTC |=  (1<<2)
#define RS485_RECEIVE  PORTC &= ~(1<<2)

...

RS485_TRANSMIT;
RS485_RECEIVE;

Ob man die Semicolons in die Macros packt oder nicht ist eine 
Glaubensfrage.

[Karl K. (leluno)]

Falk B. schrieb:
> Ganz schlechter Stil.

aber trotzdem richtig, denn der Wechselrichter soll ausgelesen werden. 
Die write-Funktion gibt es auch. Da soll in das Register des WR 
geschrieben werden.

[Falk B. (falk)]

Karl K. schrieb:
>> Ganz schlechter Stil.
>
> aber trotzdem richtig, denn der Wechselrichter soll ausgelesen werden.
> Die write-Funktion gibt es auch. Da soll in das Register des WR
> geschrieben werden.

Dann nennt man es aber readRegister oder ähnlich. Und wieso braucht ein 
LESEfunktion einen 64 Bit Parameter? Dort gehört eher eine 
Registeradresse rein.

[Karl K. (leluno)]

Vielen dank für die Hilfe. Fehler war tatsächlich txc0 1 statt 0 zum 
löschen. Ich hatte offenbar nur bis >cleared by writing< gelesen und mir 
den Rest falsch gedacht.

[Karl K. (leluno)]

jetzt bräuchte ich doch noch mal Hilfe:

Ich habe drei rs485-terminals: WR, PC, M328

Senden M328-PC und M328-WR und PC-WR geht.

Empfangen PC-WR, M328-PC(Bild1) geht.

Empfang M328-WR(Bild 2 +3)kommt kein brauchbares Signal.

Woran kann das liegen? Ist der Adapter unbrauchbar?

[Mi N. (msx)]

Karl K. schrieb:
> Empfang M328-WR(Bild 2 +3)kommt kein brauchbares Signal.

Das kann man auf den Fotos ja auch ganz deutlich sehen :-(

[Rainer W. (rawi)]

Mi N. schrieb:
> Das kann man auf den Fotos ja auch ganz deutlich sehen :-(

Wozu mag diese komische USB-Schnittstelle beim Hantek DSO2D15 wohl gut 
sein? ;-)

[Mi N. (msx)]

Rainer W. schrieb:
> Wozu mag diese komische USB-Schnittstelle beim Hantek DSO2D15 wohl gut
> sein? ;-)

In diesem Fall nur, um Krabben- von Feldsalat zu unterscheiden.

[Falk B. (falk)]

Mi N. schrieb:
>> Wozu mag diese komische USB-Schnittstelle beim Hantek DSO2D15 wohl gut
>> sein? ;-)
>
> In diesem Fall nur, um Krabben- von Feldsalat zu unterscheiden.

I shot the sherif, but I did'nt shoot the screeeeeen, ohhh noooooo . . . 
;-)

[Falk B. (falk)]

Karl K. schrieb:
> jetzt bräuchte ich doch noch mal Hilfe:
>
> Ich habe drei rs485-terminals: WR, PC, M328
>
> Senden M328-PC und M328-WR und PC-WR geht.

Wer sagt das? Wie hast du das gemessen?

> Empfangen PC-WR, M328-PC(Bild1) geht.

Glaub ich nicht. Das kann alles Mögliche sein.

Nutze dein Steuersignal für den Tranceiver (PC2) als Trigger zur Messung 
mit dem Oszi (Kanal 1). Dann siehst du die Sendedaten vom Arduino zum 
Wechselrichter und dessen Antwort (Kanal 2). Damit kannst du eine 
systematische Fehlersuche starten.

> Woran kann das liegen? Ist der Adapter unbrauchbar?

Nö. Es ist deine Software.

[Karl K. (leluno)]

Falk B. schrieb:
> Senden M328-PC und M328-WR und PC-WR geht.
> Wer sagt das? Wie hast du das gemessen?

Ich sende die Zeichenfolge (0x010300000001840a) an den Wechselrichter. 
Wenn der Wechselrichter "0x0103020005 + 2byte crc" antwortet, 
funktioniert die Kommunikation in beide Richtungen.

Die Oszi-Bilder 2+3 sehen erkennbar anders aus als Bild 1. Die 
dreieckigen Zacken können nicht als eindeutige digitale rs485-Signale 
ausgewertet werden - Hardwareproblem. Der Adapter ist in der Lage, 
Signale vom PC umzuformen - nicht jedoch Signale vom WR. Die sind 
vermutlich ein bisschen anders und daher in einem Grenzbereich, den der 
Adapter nicht auswerten kann.

Ich hab den Adapter gewechselt und sehe jetzt die richtige Antwort des 
WR - 01-03-02-00-05 zumindest auf dem Oszi (Bild 4/ mangels Kabel per 
Camera). Das Signal kommt jetzt richtig auf dem rx Pin an. Den Rest 
bekomm ich dann - wahrscheinlich - irgendwie hin.

Jedenfalls Danke für die wirklich hilfreiche Unterstützung.

[Falk B. (falk)]

Karl K. schrieb:
> Ich sende die Zeichenfolge (0x010300000001840a) an den Wechselrichter.
> Wenn der Wechselrichter "0x0103020005 + 2byte crc" antwortet,
> funktioniert die Kommunikation in beide Richtungen.
>
> Die Oszi-Bilder 2+3 sehen erkennbar anders aus als Bild 1.

Mal in Ernst. Was soll das? Dein Oszi kann DIGITALE, SCHARFE Screenshots 
auf USB ausgeben. NUTZE DAS! Nicht diesen verwaschenen Mist mit dem 
Handy!

> Die
> dreieckigen Zacken können nicht als eindeutige digitale rs485-Signale
> ausgewertet werden - Hardwareproblem.

Ja welches Signal sehen wird denn da wirklich? An welchem IC an welchem 
Pin wurde gemessen?

> Der Adapter ist in der Lage,
> Signale vom PC umzuformen - nicht jedoch Signale vom WR. Die sind
> vermutlich ein bisschen anders und daher in einem Grenzbereich, den der
> Adapter nicht auswerten kann.

Glaub ich nicht. Ist eher ein Schaltungsfehler deinerseits.

[Karl K. (leluno)]

Noch ne Frage:

low-level ist laut Oszi 1,72Volt bei 4,72 Volt Vcc. Das reicht wohl 
nicht ganz, dass der uc das als low erkennen kann.

Was tun? pull-down? wie groß?

[Falk B. (falk)]

Karl K. schrieb:
> Noch ne Frage:
>
> low-level ist laut Oszi 1,72Volt bei 4,72 Volt Vcc. Das reicht wohl
> nicht ganz, dass der uc das als low erkennen kann.
>
> Was tun? pull-down? wie groß?

Welches Signal an welchem IC? Schaltplan? Siehe Netiquette!

[Karl K. (leluno)]

Signal an der Stelle x gemessen:


adapter GND----x-----GND M328
        RXD----x-----RX
        TXD----------Tx
        VCC----------Vin