Profibus Telegramm

Alex S. schrieb:
> 0x41 (0b 0100 0001).
>
> Die Musterlösung ist
>
> 0100 0001 001

Ich glaube, die Musterlösung ist anders zu verstehen:
0 1000 0010 01

Davor steht das Start-Bit, dann kommt das Byte (kleinstes Bit zuerst), 
dann kommen Parity & Stop-Bit

--> hat also nocht nichts mit der Protokoll-Definition des Profibus zu 
tun, sondern behandelt erstmal nur den UART.

Damit wäre schonmal die Bit-Darstellung deiner Payload im UART geklärt, 
musst Du Dir nur noch überlegen, welches Profibus-Telegramm Du benutzt, 
um diese Payload zu übertragen.
Es würde sich wahrscheinlich ein Telegramm anbieten, dass 
Payload-transport anbietet ;-) ... kleiner Tip: ist im Link mit "PDU" 
gekennzeichnet

http://www.profibus.felser.ch/telegrammformate.htm

Hallo Kay,
vielen Dank für die Antwort, nun wie ich verstanden habe, wenn man das 
Byte getrennt von Startbit, Parity - bit & stop sieht, dann reduziert 
sich das eigentliche Databyte zu ..1000 0010 .. wäre das dann nicht mehr 
ein anderes Zeichen nicht mehr 0x41, sondern 0x82 ?

Alex S. schrieb:
> Hallo Kay,
> vielen Dank für die Antwort, nun wie ich verstanden habe, wenn man das
> Byte getrennt von Startbit, Parity - bit & stop sieht, dann reduziert
> sich das eigentliche Databyte zu ..1000 0010 .. wäre das dann nicht mehr
> ein anderes Zeichen nicht mehr 0x41, sondern 0x82 ?

MSB wird zuletzt übertragen, lies die Bitfolge rückwärts.

ach soo jetzt ist es klar, vielen Dank! :)

aber was ist dann mit anderen Bits? SOF, Parity und Stop Bit? werden sie 
ganz normal übertragen oder auch rückwärts? Ist das so, dass nur 
Nutsbyte rückwärts gelesen werden soll?

Bis dahin macht das übrigens noch alles die Hardware in so ziemlich 
jedem gängigen Microcontroller komplett eigenständig, darüber muss man 
sich also nur dann den Kopf zerbrechen wenn man mal das Oszi dranhängt 
um zu überprüfen  ob die Theorie mit der Praxis in Einklang steht (z.B. 
bei der Fehlersuche), da ist es hilfreich deuten zu können was die 
einzelnen Bits bedeuten, ob man vergessen hat das Parity-Bit 
einzuschalten, ob die Baudrate stimmt, ob A und B vertauscht sind (alles 
invertiert), da ist es wichtig in der Lage zu sein kurz draufzuschaun 
und sagen zu können: "Hier ist das Startbit, dort ist das Stopbit, sieht 
gut aus, oh warte, das letzte Byte des Telegramms fehlt jedesmal".

Der wirkliche "Spaß" wird beginnen wenn Du Dich durch die 
Protokolldokumentation wühlst und die höheren Schichten implementieren 
musst.

Alex S. schrieb:
> aber was ist dann mit anderen Bits? SOF, Parity und Stop Bit? werden sie
> ganz normal übertragen oder auch rückwärts?

Bei dieser asynchronen seriellen Datenübertragung wird immer das 
niederwertigste Bit zuerst übertragen, es wird immer von einem Startbit 
eingeleitet und Parity (falls vorhanden) kommt immer vor dem Stopbit und 
ganze endet immer mit einem (oder mehreren) Stopbits. Das ist ein 
de-facto Standard, Du kannst davon ausgehen daß wenn in deinem 
Microcontroller ein UART verbaut ist daß der per default das genau so 
macht.

Das stammt noch aus alten mechanischen Fernschreiber-Zeiten. Wenn Du mal 
betrachtest wie man das beim Empfang decodieren würde dann siehst Du daß 
man eigentlich immer nur auf die erste fallende Flanke warten muss und 
dort einen Timer starten kann der nur für die nächsten 9 oder 10 Bit 
ausreichend genau laufen muss. Beim nächsten Startbit kann man wieder 
synchronisieren. Das ist so bestechend simpel und einfach daß man es 
sogar in reiner Mechanik implementieren konnte und auch in 100 Jahren 
wird man es noch verwenden.

Die Anzahl der Datenbits kann jedoch variieren, das muss vorher 
festgelegt werden. Manche Protokolle verwenden zum Beispiel 9 Bit und 
unterscheiden über das höchste Bit zwischen Daten und Steuerbytes. Das 
macht aber nicht jede Hardware mit, vor allem bei USB/Seriell-Adaptern 
oder grundsätzlich bei seriellen Schnittstellen im PC muss man diese 
Einschränkungen beachten.

Hallo, Bernd, ich danke Ihnen ganz herzlich für diese umfangreiche 
Erklärung, das hat mir ganz doll weitergeholfen! Noch mal vielen Dank!