Bitrate der UART-Kommunikation

Ich habe ein Setup, das mit UART zwischen PC (Windows) und Atmega2560 kommuniziert. Auf PC-Seite verwende ich Pyserial. Vom PC sende ich Byte für Byte einen Textabschnitt an Atmega2560. Die UART-Konfiguration ist: 2400 Baudrate; 8-Bit-Daten; 1 Stoppbit; Keine Parität; Der pyserielle Code lautet wie folgt:

string = "some sample text" strobe = serial.Serial('com3',baudrate = 2400) for x in string: strobe.write(x) sleep(0.001)

Ich habe ein Oszilloskop verwendet, um das UART-Signal am RX-Pin der MCU zu überprüfen, und festgestellt, dass zwischen zwei Datenrahmen eine Lücke von 15 ms bestand. Meine Fragen sind:

  1. Werden die Datenframes im UART nacheinander übertragen, dh nach einem Stoppbit beginnt das Startbit des nächsten Frames?
  2. Wenn die Antwort auf die obige Frage ja ist, ist dann die Datenübertragungsgeschwindigkeit gleich der Baudrate?
  3. Bei der Datenübertragung (vom PC zur MCU) werden die Daten ohne die Verzögerung von 1 ms beschädigt. Warum passiert das? Wie kann ich ohne Verzögerung erfolgreich übertragen?

Außerdem sende ich Daten von der MCU zum PC zurück. Als ich den TX-Pin der MCU mit dem Oszilloskop sondierte, gab es eine vernachlässigbare Verzögerung zwischen den Datenframes. Ich glaube, das liegt daran, dass ich Interrupts zum Senden auf der MCU verwende.

Ich füge hier Atmega2560-Code hinzu:

volatile uint16_t address; volatile char incoming; uint8_t in_buffer[2000]; void eeprom_write(uint16_t add,uint8_t val){ while(((EECR)&(0x02)) != 0);//EEPE bit cli(); EEAR = add; EEDR = val; EECR |= 0x04;//EEMPE EECR |= 0x02;//EEPE sei(); } ISR(USART0_RX_vect){ incoming = UDR0; in_buffer[address]=incoming; address++; } int main(void){ /*initialization of uart*/ address = 0; incoming = 1; while(incoming!='#'){} for(uint16_t i = 0 ;i<address;i++) eeprom_write(i,in_buffer[i]); }

Das Beenden von Daten wird durch '#' angezeigt.

Windows-PCs und Python sind nicht sehr zeiteffizient, diese Verzögerung könnte einfach durch den Overhead des Betriebssystems oder der Sprache verursacht werden. Aber warum fügen Sie eine Verzögerung von 1 ms hinzu?
Ohne Hinzufügen einer Verzögerung von 1 ms werden die Daten beschädigt, wenn sie von der MCU empfangen werden.
Das klingt entweder (1) nach einem Codierungsproblem auf der MCU oder (2) nach einer SEHR langsamen MCU. Ich verwende fast immer 115 kbps ohne Probleme. ~ 400 µs zwischen Bits, > 3,5 ms zwischen Bytes ist eine eisige Geschwindigkeit.
Diese Verzögerung ist erträglich. Aber wie kann ich die Live-Datenrate auf der PC-Seite überwachen?
Verwenden Sie eine serielle Terminalanwendung? Verbinden Sie Tx mit Rx, damit Sie alle Übertragungen sehen können? Holen Sie sich einen Buspiraten? Verwenden Sie einen billigen Logikanalysator? Das Oszilloskop? Ohne weitere Informationen darüber, was genau Sie "überwachen" möchten, ist es schwierig zu wissen, welches das geeignete Tool ist.
@shubhamsharma - Hallo, Ihr Kommentar lautet " Wie kann ich die Live-Datenrate auf der PC-Seite überwachen ". Was meinst du mit " Live-Datenrate "? Meinst du damit, dass du eine unbekannte Datenrate finden musst? Aber nein, das können Sie nicht meinen, da Sie uns bereits gesagt haben, dass es 2400 bps sind. Vielleicht meinen Sie also, dass Sie die Live- Daten überwachen müssen ? Aber nein, das kannst du nicht meinen, denn sag immer Datenrate . Bitte bearbeiten Sie Ihre Frage, um weitere Details zu klären und hinzuzufügen. Danke.
@SamGibson Von der Baudrate verstehe ich, dass es die Rate ist, mit der der MCU / PC das UART-Signal abtastet, um die seriellen Daten in ein Byte umzuwandeln. Da ich gesehen habe, dass zwischen zwei aufeinanderfolgenden Datenrahmen eine Lücke von 15 ms besteht, denke ich, dass die tatsächliche Bitrate von der Baudrate abweichen würde. Obwohl, wenn die MCU sendet, es eine vernachlässigbare Lücke zwischen zwei aufeinanderfolgenden Datenrahmen gibt, glaube ich, dass ich in diesem Fall sagen kann, dass die Bitrate gleich der Baudrate ist. Bitte korrigieren Sie mich, wenn ich die Baudrate falsch verstehe.
Ich stimme dafür, diese Frage als nicht zum Thema gehörend zu schließen, da es sich um ein XY-Problem handelt. Der eigentliche Fehler ist ein Softwarefehler im MCU-Code, der verhindert, dass Daten ohne Verzögerung akzeptiert werden, und die Lösung besteht darin, das zu finden und zu beheben, und nicht zu versuchen, ein Desktop-Betriebssystem dazu zu bringen, sich wie ein hartes Echtzeitsystem zu verhalten.
UART verwendet keine Frames.
Warum müssen Sie die "Live-Datenrate" überwachen, was auch immer das ist? Ich denke, wenn Sie Ihre Frage ändern, um mehr Dinge zu erklären, kann Ihnen vielleicht jemand helfen. Es scheint, als könnten Sie die Anzahl der von beiden Enden in Echtzeit gesendeten oder empfangenen Bytes leicht überwachen. Ich kann mir also nicht vorstellen, was Sie zu tun versuchen oder warum Sie es tun müssen.
@ChrisStratton Ich habe MCU-Code hinzugefügt.

Antworten (1)

2400 Baud sind 240 Zeichen (Oktette) pro Sekunde bei 10 Bit pro Frame (was dem Standard "8N1" entspricht). Eine Millisekunde lang zu schlafen wird den Abstand nicht stark beeinflussen, sicherlich nicht auf vorhersehbare Weise, da jedes Zeichen 4 ms zum Senden benötigt.

Es könnte sein, dass der Python-Schlaf nicht so kurz wie 1 ms schlafen kann,

Wenn Sie die Daten überwachen möchten, benötigen Sie dennoch ein Oszilloskop (oder verbinden Sie die Datenleitung über einen Widerstand mit einem Soundkarteneingang, machen Sie eine Aufnahme und sehen Sie sie in einem Sounddatei-Editor an - die Spannung wird wahrscheinlich etwas schwanken, aber Sie sollten die Kanten jedes Bits deutlich sehen.)

Könnte es etwas geben, das Ihren Mikrocontroller so beschäftigt, dass er nicht 240 Zeichen pro Sekunde verarbeiten kann?

Es ist nicht Python, das für kurze Zeit nicht schlafen kann, sondern dass das Host-Betriebssystem solche kurzen Verzögerungen normalerweise nicht berücksichtigt - Sie erhalten Ihre Verzögerung, aber Sie werden nicht erneut ausgeführt, bis sich der Scheduler bei Ihnen meldet . Und dann muss in der Regel auch die USB-Latenz hinzugefügt werden.