www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik AVR-UART -> Erkennen ob momentan Daten empfangen werden


Autor: dayton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

gibt es eine Möglichkeit zu erkennen ob der UART eines AVR gerade ein 
Zeichen empfängt, das aber noch nicht zur Abholung bereit liegt???

Gruß

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nein, wenn du nur über die UART auswerten willst.
Ja, wenn du noch eine externe Beschaltung drumrum bastelst.

Autor: dayton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke für die Antwort.
ich selbst hatte auch schon keine Info darüber im Datenblatt de AVR 
gefunden. Bin gerade dabei ein Interruptpin mit dem RXD parallel zu 
schalten.
gruß

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was soll denn in der verbleibenden 1ms (bei 9600Baud) bis die Bits 
komplett sind passieren?

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gäbe noch die Möglichkeit einer SW-UART, die bastelt sich die Bits 
selbst zusammen und weiß demzufolge auch, dass grad was am Laufen ist... 
;-)

Autor: Reinhard Kern (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dayton schrieb:
> Hallo,
>
> gibt es eine Möglichkeit zu erkennen ob der UART eines AVR gerade ein
> Zeichen empfängt, das aber noch nicht zur Abholung bereit liegt???
>
> Gruß

Hallo,

schalte das serielle Signal zusätzlich auf einen Interrupt-Eingang, dann 
bekommst du Nachricht (bzw. einen IRQ) wenn sich was tut.

Gruss Reinhard

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Reinhard Kern schrieb:
> dayton schrieb:
>> Hallo,
>>
>> gibt es eine Möglichkeit zu erkennen ob der UART eines AVR gerade ein
>> Zeichen empfängt, das aber noch nicht zur Abholung bereit liegt???
>>
>> Gruß
>
> Hallo,
>
> schalte das serielle Signal zusätzlich auf einen Interrupt-Eingang, dann
> bekommst du Nachricht (bzw. einen IRQ) wenn sich was tut.
>
> Gruss Reinhard

Manchmal hilft es, wenn man alle Beiträge liest..

Autor: dayton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Problem liegt am Busprotokoll. Es heißt, dass wenn Master einen 
String in variabler Länge sendet muss innerhalb einer 1ms das nächste 
Byte folgen, ansonsten ist die String zu ende.
gruß

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dayton schrieb:
> Das Problem liegt am Busprotokoll. Es heißt, dass wenn Master einen
> String in variabler Länge sendet muss innerhalb einer 1ms das nächste
> Byte folgen, ansonsten ist die String zu ende.
> gruß

Wo liegt das Problem? Wenn 2ms nix mehr kommt, dann ist der String zu 
Ende.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  dayton (Gast)

>Das Problem liegt am Busprotokoll. Es heißt, dass wenn Master einen
>String in variabler Länge sendet muss innerhalb einer 1ms das nächste
>Byte folgen, ansonsten ist die String zu ende.

Dazu muss man aber nicht wissen, ob der UART gerade ein Byte empfängt. 
Das macht man mit einem Timeout. Wird ein Zeichen empfangen, wird eine 
Timer zurück gesetzt, sagen wir auf den Wert 5. Der zählt jetzt mit 5 
kHz runter. Nach 1ms löst er einen Interrupt aus, was bedeutet, dass 
1ms kein weiteres Zeichen empfangen wurde. Wird aber in der Zeit ein 
weiteres empfangen, wird der Timer wieder zurück gesetzt. Das ganze ist 
eine Monoflop in Software.

MFG
Falk

Autor: dayton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Pause zwischen STOP-Bit von Byte(n) und nachfolgendem Start-Bit von 
Byte(n+1) ist max. 1ms.

Ich starte den Timer wenn das Zeichen komplett empfangen ist und aus 
UDR-Register gelesen wurde.
Wenn nun nach 1ms noch kein Start-Bit empfangen wurde ist Übertragung 
beendet und die Auswertung des Empfangs beginnt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rechne zu den 1ms noch die Übertragungszeit eines Zeichens dazu und du 
hast die Zeitdauer nach der das nächste Zeichen von der UASAT als 
empfangen gemeldet werden müsste.

Dazu muss man immer noch nicht den Start eines Zeichens mitkriegen.


(Ich hasse solche Protokolle, bei denen ein Timeout ein integraler 
Bestandteil ist)

Autor: dayton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider fehlt mir dann die Zeit für die Auswertung sowie für die Antwort, 
denn laut Busspez. muss innerhalb 5ms geantwortet werden. Nun ziehe ich 
die 1 ms Pause ab, dann habe ich noch 4ms. Wenn ich noch warten würde ob 
gerade ein Byte empfangen wird, liegt meine Restzeit bei 9600 Baud bei 
3ms, d.h. 25% weniger Zeit für Auswertung und Antwort.
Gruß

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dayton schrieb:
> Leider fehlt mir dann die Zeit für die Auswertung sowie für die Antwort,
> denn laut Busspez. muss innerhalb 5ms geantwortet werden. Nun ziehe ich
> die 1 ms Pause ab, dann habe ich noch 4ms. Wenn ich noch warten würde ob
> gerade ein Byte empfangen wird, liegt meine Restzeit bei 9600 Baud bei
> 3ms, d.h. 25% weniger Zeit für Auswertung und Antwort.
> Gruß

So ein Käse. Wer hat sich das denn ausgedacht?
Das Beste ist immer, wenn mit der Übertragung auch die Anzahl der Bytes 
übertragen wird. Dann weiß der Empfänger, wann alles komplett ist und 
kann auch sofort erkennen, ob da was fehlt.
z.B. sowas:
http://www.ibrtses.com/embedded/longmsgprotocol.html

Autor: dayton (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>So ein Käse. Wer hat sich das denn ausgedacht?

Kein Käse!!!
Wird seit Jahren international genutzt. Das ganze nennt sich MDB - 
Multi-Drop Bus und wird als Schnittstelle in Verkaufsautomaten(z.B. 
Getränkeautomaten, Zigarettenautomaten, etc) eingesetzt.

http://www.vending.org/technology/MDB_Version_4.pdf

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dayton schrieb:
>>So ein Käse. Wer hat sich das denn ausgedacht?
>
> Kein Käse!!!

Jedes Protokoll, welches darauf beruht, das Ende eines Datenstroms mit 
einem Timeout anzuzeigen ist IMHO Käse. Und zwar ganz gewaltiger Käse.

> Wird seit Jahren international genutzt. Das ganze nennt sich MDB -
> Multi-Drop Bus und wird als Schnittstelle in Verkaufsautomaten(z.B.
> Getränkeautomaten, Zigarettenautomaten, etc) eingesetzt.

Das machts auch nicht besser.

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
dayton schrieb:
>>So ein Käse. Wer hat sich das denn ausgedacht?
>
> Kein Käse!!!
> Wird seit Jahren international genutzt. Das ganze nennt sich MDB -
> Multi-Drop Bus und wird als Schnittstelle in Verkaufsautomaten(z.B.
> Getränkeautomaten, Zigarettenautomaten, etc) eingesetzt.
>
> http://www.vending.org/technology/MDB_Version_4.pdf

Hmm.. ich hab mal kurz reingeguckt, vor allem in die Timings. So richtig 
RS232 ist das ja nicht.
Wie erkennst du denn einen BREAK oder SETUP über RS232? Das geht doch 
gar nicht.
Im Prinzip ist das ein Bitprotokoll, das noch am einfachsten bei der 
SoftUART aufgehoben ist, da du da auf einzelne Bits reagieren kannst 
(und das Byteformat an das RS232-Format angelehnt ist).
RS232 wird auch in der Spezifikation nie erwähnt...

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielleicht kann man ja auch anhand des gesendeten Befehls erkennen, 
wieviele Bytes noch folgen müssten und dann einen Zähler laufen lassen. 
Ist der abgearbeitet, dann muss jetzt geantwortet werden (einen 
Timeoutprüfung würde somit entfallen, es sei denn es kommt nicht die 
gewünschte Anzahl an Bytes)

Autor: Tropenhitze (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>(Ich hasse solche Protokolle, bei denen ein Timeout ein integraler
>Bestandteil ist)

Jede Übertragung kann gestört sein und braucht daher immer ein timeout.
Soweit ich mich erinnere, braucht der Profibus auch timeouts fürs 
Protokoll.

Und dann sollten "Wir" doch über solche Protokolle auch froh sein: 
einfach noch einen Timer verwurschtelt und die Sache läuft. Dat kannste 
mit'm PC nicht so einfach machen :-)

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tropenhitze schrieb:
>>(Ich hasse solche Protokolle, bei denen ein Timeout ein integraler
>>Bestandteil ist)
>
> Jede Übertragung kann gestört sein und braucht daher immer ein timeout.
> Soweit ich mich erinnere, braucht der Profibus auch timeouts fürs
> Protokoll.
>
> Und dann sollten "Wir" doch über solche Protokolle auch froh sein:
> einfach noch einen Timer verwurschtelt und die Sache läuft. Dat kannste
> mit'm PC nicht so einfach machen :-)

Richtig. Aber man sollte schon erkennen, wann eine Übertragung zu Ende 
ist, und nicht das Timeout bestimmen lassen, ob's das jetzt war oder 
nicht. Insbesondere, wenn innerhalb 5ms geantwortet werden muss.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tropenhitze schrieb:
>>(Ich hasse solche Protokolle, bei denen ein Timeout ein integraler
>>Bestandteil ist)
>
> Jede Übertragung kann gestört sein und braucht daher immer ein timeout.

Davon war nicht die Rede.
Die Rede ist davon, dass das Ende eines Textes dadurch definiert ist, 
dass der Sender eine gewisse Zeit lang einfach nichts sendet.

Wie willst du denn da eine Störung von einem regulärem Textende 
unterscheiden?

Ich hatte auch mal mit solchen Spezialisten zu tun: Eine dt. 
Arbeitsgemeinschaft wollte ein firmenübergreifendes, einheitliches 
Datenformat für Graphikdaten + Variantenbeschreibungen haben. Gab das an 
einer Uni in Auftrag. Was da rauskam, hätte meinem Prof für Datenbanken 
den Schweiß auf die Stirn getrieben. So ziemlich alles was man in einer 
relationalen Datenbank verbocken kann wurde dort gemacht. Das hab sogar 
ich erkannt, und ich bin beileibe kein DB-Spezi. Nach intensiven 
Nachforschungen fanden wir (ich hab mich mit den Entwicklern der anderen 
Firmen zusammengetan) heraus: Die Leute die das verbrochen haben, waren 
Maschinenbauer. Ihre Qualifikation war, dass sie schon mal mit Access 
gearbeitet hatten.

Unnötig zu sagen, das jeglicher Einspruch sinnlos war. Die DB blieb so, 
mit all ihren Ungereimtheiten und Aufbaufehlern. Um die mussten wir uns 
dann eben rumprogrammieren.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.