RS485 Ende erkennung

ende ist dann wenn die Anzahl von Bytes die im Header stehen empfangen 
wurden. Nichts mit timer.

hei,

habe in diese Richtung auch schon gedacht.

was ist aber, wenn in dem Byte für die Anzahl der Wert falsch übertragen 
wurde ?

z.B.  statt 8  100

schönen Tag

Keyboard schrieb:
> hei,
>
> habe in diese Richtung auch schon gedacht.
>
> was ist aber, wenn in dem Byte für die Anzahl der Wert falsch übertragen
> wurde ?
>
> z.B.  statt 8  100
>
> schönen Tag

Dann erkennst du das an der fehlerhaften Prüfsumme. Für solche Fälle ist 
sie ja da. Aber wie du die berechnest, weißt nur du allein. Die Länge 
sollte auf jeden Fall in die Berechnung mit einfließen, sonst erkennst 
du keinen Fehler im Längen-Byte (logisch).
Kurz gesagt, das Protokoll mußt du so gestalten, daß der Empfänger 
feststellen kann, wenn irgendein Übertragungsfehler passiert ist.

Du hast eine Master-Slave Kommunikation. Daraus ergibt sich ein 
SW-Handshake. Der Master fragtveinen bestimmten Slave ab und nur dieser 
antwortet. Den Aufbau der Antwort kennst du. Im Gutfall also kein 
Problem.
Welche Fehlermöglichkeiten gibt es? Daten Verfälschung, Slave nicht 
verfügbar, ...?
Für alle Fehlermöglichkeiten musst du dir eine Fehlerreaktioin 
überlegen. Die Fehlerfälle sind immer komplexer als die Gutfälle und 
schlucken mehr Entwicklerzeit als diue Gutfälle. Jeder nicht 
behandeltete Fehler lässt das Produkt "alt" aussehern. ;-)
Prüfsumme bhast du schon. Mit einem Timeout gerht auch viel.

üblicher weise verwendet man noch einen Timeout. Wenn du also noch auf 2 
Bytes wartest die innerhalb von einer gewissen zeit nicht kommen, dann 
ist es Fehler. Und du setzte alles zurück.

Normalerweise hat man immer eine Timerlösung, damit sich der Empfang bei 
Übertragungsfehlern wieder "einrenkt". Also Startbyte/Stopbyte bzw. 
Längenangabe und zusätzlich ein Maximalwert für die Lücke zwischen zwei 
Bytes beim Senden, und einen etwas längeren Timeout beim Empfänger als 
Notbremse, falls er anderweitig noch nicht gemerkt hat, daß das Paket zu 
Ende ist. Gesamtzeit kann man notfalls auch machen (wenn z.B. das 
Neustarten des Timers aufwendig ist), ist aber ungünstig, wenn man es 
mit stark unterschiedlichen Paketlängen zu tun hat.

Sich nur auf die Prüfsumme zu verlassen, kann lästig werden, denn wenn 
der Empfänger die Länge als zu groß mißverstanden hat, müssen erstmal so 
viele Bytes kommen, bevor er die "Prüfsumme" auswertet und den Fehler 
aufdeckt. Das kann dauern.

npn schrieb:
> Dann erkennst du das an der fehlerhaften Prüfsumme. Für solche Fälle ist
> sie ja da. Aber wie du die berechnest, weißt nur du allein. Die Länge
> sollte auf jeden Fall in die Berechnung mit einfließen, sonst erkennst

Ahem.
  Was ist aber wenn Länge=100, aber nur 8 Bytes gesendet werden ?
  Selbstverstandlich MUSS ein Timer vorhanden sein, sonst würde
  der Empfänger (Master oder Slave, egal) ewig warten.
  Vielleicht so:
  StartByt (0xAA) - Offset 0x00
  DstAdr          - Offset 0x01
  PcktNr          - Offset 0x02
  PckType         - Offset 0x03 ( ** )
  PcktLen         - Offset 0x04 ( nur NutzDaten)
  NutzDaten       - Offset 0x05..0xnn
  PcktCRC         - Offset 0xnn + 1 (aufs gesammte Paket)
  EndByt   (0xA9) - Offset 0xnn + 2
  ** 1 bit fur Antwort/Bestätigung reservieren, d.h.
  1 = Muss antworten/bestätigen

  In deiner ISR fur Empfang checkst du auf StartByt, Flag setzen,
  Bytes prüfen nach Offset, usw...

  mfg, Bole

Hallo,

es gibt eigentlich nur 2 sichere Möglichkeiten:

1. ein Abschlusszeichen, z.B. CR

2. die Übertragung erfolgt ohne grössere Pausen, danach kommt nichts 
mehr -> Timeout = Ende der Message

Das gilt auch bei bekannter Messagelänge, da ja was verlorengehen kann 
und dann neu auf den Messageanfang synchronisiert werden muss.

Georg

Georg schrieb:
> es gibt eigentlich nur 2 sichere Möglichkeiten:
>
> 1. ein Abschlusszeichen, z.B. CR
> 2. die Übertragung erfolgt ohne grössere Pausen, danach kommt nichts
> mehr -> Timeout = Ende der Message

nein.

> 1. ein Abschlusszeichen, z.B. CR
man braucht kein Abschlusszeichen, wenn man die Länge am Anfang mit 
überträgt. Ich kenne kein Protokoll wo mit einem Abschlusszeichen 
gearbeitet wird. Wenn überhaupt wird ein Startzeichen festgelegt.

> 2. die Übertragung erfolgt ohne grössere Pausen, danach kommt nichts
> mehr -> Timeout = Ende der Message
wird auch kaum verwendet, weil es die mögliche Übertragungsrate viel zu 
sehr einschränkt.

Bole aus Serbien schrieb:
> Ahem.
>   Was ist aber wenn Länge=100, aber nur 8 Bytes gesendet werden ?
>   Selbstverstandlich MUSS ein Timer vorhanden sein, sonst würde
>   der Empfänger (Master oder Slave, egal) ewig warten.

Das habe ich ja auch nie bestritten. Klar muß ein timeout vorhanden 
sein.

Peter II schrieb:
> man braucht kein Abschlusszeichen, wenn man die Länge am Anfang mit
> überträgt. Ich kenne kein Protokoll wo mit einem Abschlusszeichen
> gearbeitet wird.

  CAN ?

> Wenn überhaupt wird ein Startzeichen festgelegt.

  Wenn überhaupt ? - Immer, ansonsten musste eine min.
  Frame-Pause vorhanden sein, folglich:
> wird auch kaum verwendet, weil es die mögliche Übertragungsrate
> viel zu sehr einschränkt.

 mfg, Bole

Bole aus Serbien schrieb:
> Wenn überhaupt ? - Immer, ansonsten musste eine min.

bei RS232 gibt es kein extra start und ende zeichen. Dadurch kann es 
aber auch passieren das es sich nicht synchronisiert wenn mal keine 
Pause vorhanden ist.

Bei Profibus wird auch mit Start-/ Stoppzeichen gearbeitet.
Längenangabe natürlich auch.

Aber ein Timeout zum "wieder einrenken" sollte schon vorhanden sein.

Oder man sendet einen kontinuierlichen Stream und der Empfänger sucht 
sich die Nachrichten anhand der passenden CRC raus. Dann sollte man es 
aber vllt auf wenige Framegrößen beschränken, sonst steigt der Aufwand.

Klaus B. schrieb:
> der Empfänger sucht
> sich die Nachrichten anhand der passenden CRC raus

Dann müsste ja man für jedes Bit eine neue CRC-Berechnung starten - ist 
das dein Ernst?

Viele hier scheitern ja schon an einer einzigen...

Georg

Keyboard schrieb:
> was ist aber, wenn in dem Byte für die Anzahl der Wert falsch übertragen
> wurde ?
>
> z.B.  statt 8  100

Selber Schuld, wenn man so große Unterschiede in der erlaubten 
Paketlänge zuläßt.

Blocker schrieb:
> Keyboard schrieb:
>> was ist aber, wenn in dem Byte für die Anzahl der Wert falsch übertragen
>> wurde ?
>>
>> z.B.  statt 8  100
>
> Selber Schuld, wenn man so große Unterschiede in der erlaubten
> Paketlänge zuläßt.

Was hat das mit der Größe des Unterschiedes zu tun?
Das Beispiel geht genauso mit "8 statt 10". Ohne Timeout wartest du da 
genauso wie bei 100.

Ob die 10 nicht erreicht werden oder die 100 nicht erreicht werden, ist 
doch völlig egal, meinst du nicht?

>Viele hier scheitern ja schon an einer >einzigen...

Wenn es für eine mal geht, sollte für mehrere auch nicht mehr das 
Problem sein ;-)

>Dann müsste ja man für jedes Bit eine >neue CRC-Berechnung starten - ist das 
>dein Ernst?

Für jedes Byte.
Ja, ist mein ernst.

Der Empfänger berechnet bei jedem empfangenen Byte die CRC über alle 
möglichen Framelängen.
Möglichst bei der niedrigsten anfangen, dann kann man weiter suchen 
falls nichts dabei war.
War was dabei, nimmt er die Daten und verwirft die verwendeten Bytes aus 
seinem Puffer.
War  für alle Framelängen nichts dabei, verwirft er ein Byte und rechnet 
alles von vorne.

hei,

da für mich es die erste RS485 Übertragung zwischen µC ist, werde ich 
gemäß meinen ersten Beispiel folgen.

Mit jedem vom Master empfangenen Byte einen Timer mit Null starten und 
dessen Überlauf abwarten. Nach erfolgtem Überlauf des Timer dann das 
Paket auf Anzahl und Prüfsumme überprüfen. Erst danach, wenn alles ok, 
die vom Slave gesendete Daten übernehmen.

Die Zeit des Timer werde ich so wählen, das der Überlauf 1/3 entsprechen 
der Zeit eines Bytes danach statt findet.

Zusätzlich noch ein Timeout zur Sicherheit.

schönen Tag

1. Du kennst doch die Baudrate
2. Dann kommt ein Startbyte
3. Dann kommt eine ID
4. Dann die Länge
5. Aus der Länge und der Baudrate kannst du nun ausrechenen wie lange 
das Paket voraussichtlich dauern wird, noch die CRC mit einbeziehen in 
die Dauer und +10% Angst dazu. Timer Laden und Starten.
6. Bytes empfangen bis länge erreicht oder Timeout
7. Checksumme Prüfen, wenn nicht stimmt-> Paket verwerfen Fehler melden 
oder erneut anfordern

Keyboard schrieb:
> Mit jedem vom Master empfangenen Byte einen Timer mit Null starten und
> dessen Überlauf abwarten. Nach erfolgtem Überlauf des Timer dann das
> Paket auf Anzahl und Prüfsumme überprüfen. Erst danach, wenn alles ok,
> die vom Slave gesendete Daten übernehmen.

finde ich ein dummes verfahren.

Warum nicht ohne diesen Timer (der Timeout-Timer ist OK) arbeiten. Wenn 
die Anzahl der Bytes empfangen hast, die du erwartest, hast du das ende.

Warum willst du jetzt noch warten?

Dein Timer ist ein Timeout!

Aber warum jedes einzelne Byte überwachen? Du kennst die Framelänge und 
die Zeit für einen ganzen Frame.

Zu Beginn des Empfangs den Timeout für den ganzen Frame aufziehen, dann 
den Frame anhand der Anzahl einlesen. Dann Fehlerprüfung der Daten. Oder 
es hat der Timeout zugeschlagen. Du hasst die Fehlerbehandlung so immer 
nach einem Frame. Bei der Timeoutzeit ist zu berücksichtigen, dass der 
Slave Verarbeitungszeit benötigt und dadurch eine kurze Pause zwischen 
einzelnen Bytes entstehen kann.

Peter II schrieb:
> Wenn
> die Anzahl der Bytes empfangen hast, die du erwartest, hast du das ende.

Du willst einfach nicht begreifen, dass bei einer Übertragung etwas 
schiefgehen kann und dann neu angesetzt werden muss. Deine Vorschläge an 
jemanden, für den das Thema neu ist, sind unverantwortlich.

Georg

Warum nicht Start/Ende-Markierungen. Ich habe das in einer Anwendung in 
der es nicht auf die Geschwindigkeit ankommt einmal so gemacht. Jeder 
Frame bestand aus einem Startzeichen, den Adress und Datenbytes 
(hexadezimal codiert) und einem Endezeichen ('\n').
Timeout für jedes Byte (lässt sich in Interrupts bequem zurücksetzen), 
bei Auftreten eines Timeout wird wieder auf das Startzeichen gewartet.

Das ganze hat auch noch den Vorteil, dass man an einem PC mittels RS485 
Adapter und einem Terminalprogramm(PUTTY) einfach mitlesen kann.

Georg schrieb:
> Du willst einfach nicht begreifen, dass bei einer Übertragung etwas
> schiefgehen kann und dann neu angesetzt werden muss. Deine Vorschläge an
> jemanden, für den das Thema neu ist, sind unverantwortlich.

hä? Was soll denn da schief gehen?

Wenn im Header steht es sollen 5 Byte kommen, dann warten man bis man 5 
Bytes hat oder ein Timeout zuschlägt.

Das ist das übliche verfahren und wird überall angewendet.

Niemand kommt auf die Idee zu sagen, wenn 5 Sekunden nicht gekommen ist 
dann ist das ende reicht. Was ist wenn jemand den Stecker gezogen hat?

Man könnte auch generell keep-alive Frames senden lassen, dann braucht 
man ggf. sogar keinen Timeout. Der Puffer würde dann mit den keep-alive 
Daten gefüllt bis die einzulesende Länge erreicht ist und die Prüfsumme 
nicht passen wird.

Man sollte ggf. auch aufpassen, dass man bei falscher Prüfsumme nicht 
einfach alles bereits empfangende einfach wegwirft, sondern beim 
nächsten potentiellen Header/Startbyte weiterschaut. Sonst kann die 
Kommunikation dadurch auch sehr lange hängen bleiben, wenn man das Pech 
hat dass nie gerade ein Header/Startbyte nach dem "Empfänger-Reset" als 
nächstes reinkommt, sondern man immer irgendwo mitten in den Daten 
anfängt zu lesen.

error handling schrieb:
> Aber warum jedes einzelne Byte überwachen? Du kennst die Framelänge und
> die Zeit für einen ganzen Frame.

Da die Framelänge variabel ist, kennt der Empfänger die Länge (und damit 
die Zeit für einen Frame) erst, wenn der Frame vollständig empfangen ist 
und die Prüfsumme sich als richtig erwiesen hat. Das ist zu spät.

Jedes Byte einzeln überwachen muß man, weil man im ungünstigsten Fall 
(wenn die Längenangabe fehlerhaft ankommt) nicht weiß, welches das 
letzte ist. Das weiß man erst, wenn kein Byte mehr kommt, also wenn seit 
dem letzten Byte eine gewisse Zeit verstrichen ist. Dazu muß der Timer 
beim letzten Byte gestartet worden sein, also bei jedem Byte.

Keep alive ist doch ganz daneben. Da es um Maste Sklave geht. Der Slave 
wird gepollt. Entweder er antwortet vollständig und richtig oder 
Timeout.

Nosnibor schrieb:
> error handling schrieb:
> Aber warum jedes einzelne Byte überwachen? Du kennst die Framelänge und
> die Zeit für einen ganzen Frame.
>
> Da die Framelänge variabel ist, kennt der Empfänger die Länge (und damit
> die Zeit für einen Frame) erst, wenn der Frame vollständig empfangen ist
> und die Prüfsumme sich als richtig erwiesen hat. Das ist zu spät.
>
> Jedes Byte einzeln überwachen muß man, weil man im ungünstigsten Fall
> (wenn die Längenangabe fehlerhaft ankommt) nicht weiß, welches das
> letzte ist. Das weiß man erst, wenn kein Byte mehr kommt, also wenn seit
> dem letzten Byte eine gewisse Zeit verstrichen ist. Dazu muß der Timer
> beim letzten Byte gestartet worden sein, also bei jedem Byte.

Schwachsinn hoch zehn!!!

Anhand der Baudrate und der Framelänge kann ich den Timeout genau 
bestimmen. In der Regel reicht ein TIMEOUT für die maximal im Protokoll 
vereinbarte Framelänge. Der Timeout wird hoffentlich selten zuschlagen.

Also macht es nicht komplizierter als es ist:
Timeout für ganzen Frame aufziehen,
Daten gemäß erwarteter Länge empfangen, oder Timeout,
Kein Timeout, Daten prüfen und bewerten,

Nächster Slave.

error handling schrieb:
> Schwachsinn hoch zehn!!!
nein.

> Anhand der Baudrate und der Framelänge kann ich den Timeout genau
> bestimmen. In der Regel reicht ein TIMEOUT für die maximal im Protokoll
> vereinbarte Framelänge. Der Timeout wird hoffentlich selten zuschlagen.
dann musst du aber festlegen, das der Sender keine Pause zwischen den 
Bytes machen darf - das ist aber nicht üblich. Er kann ja gerade etwas 
besser zu tun bekommen.

Es werden mach mal sogar 2 Timeouts verwendet, einmal der Frame-Timeout 
und einmal ein Byte-Timeout.

Und was ist beim Timeout pro Byte und Sendepause???

Das macht nur bei einer SW-Uart Sinn, sonst ist das Schwachsinn hoch 20.

error handling schrieb:
> Und was ist beim Timeout pro Byte und Sendepause???

man muss die werte sinnvoll festlegen. Wenn jede sekunde 1 Byte ankommt 
dann das durchaus normal sein. Dann hilft ein Frame-Timeout von 5 
Sekunden für ein 100byte packet nicht aus.

Die Übertragungsrate ist das obere Limit, aber sie muss nicht ständig 
ausgenutzt werden

error handling schrieb:
> Keep alive ist doch ganz daneben. Da es um Maste Sklave geht.

Stimmt, ich war in Gedanken schon wieder in die Allgemeinheit 
abgedriftet ;D

Peter II schrieb:
> error handling schrieb:
> Und was ist beim Timeout pro Byte und Sendepause???
>
> man muss die werte sinnvoll festlegen. Wenn jede sekunde 1 Byte ankommt
> dann das durchaus normal sein. Dann hilft ein Frame-Timeout von 5
> Sekunden für ein 100byte packet nicht aus.
>
> Die Übertragungsrate ist das obere Limit, aber sie muss nicht ständig
> ausgenutzt werden

Genau, das obere Limit. Das gilt es auch zu über wachen.
-> Timeout über den ganzen Frame!

 Bei HW-Uart nimmt man keinen Timeout pro Byte. Völlig unnütz.

L. R. schrieb:
> Ich selbst finde den nachgetriggerten Timer am besten, da die Frame
> Länge variabel ist.

 Timer fur die einzelnen Bytes brauchst du nicht, weil:
  a) Bytes in ISR empfangen werden, nicht in einer Schleife.
  b) Sender kann 3 Bytes hintereinander senden, dann 1 Byte Pause
     machen. Wieso ? Na, seine ISR hat zugeschlagen und die hat
    höhere Priorität als LAN (Echtzeit usw.)...

> Zusätzlich noch Timeout für die Sicherheit und um dem Master zu
> signalisieren, du darfst wieder senden.

 Probier es mal so:
 Wenn das Startzeichen erkannt wird, Pointer löschen und Flag setzen
 - nicht mehr und nicht weniger.
 Byte danach muss deine Adresse sein, sonst Flag zurucksetzen -
  (deswegen wird die Adresse als zweites Byte gesendet).
 Wenn das LängenByte ankommt, benötigte TimeFrame ausrechnen, z.B.
  (ByteZahl * ByteTime) + (ByteZahl * MaxInterByteZeit) + ZeitBonus
 ZeitBonus kannst du locker auf 1Sec. stellen, es macht gar
 keinen Unterschied.
 Timer starten, mit Arbeit fortfahren und Bytes in ISR empfangen.
 Wenn CRC empfangen und OK ist, Flag fur MsgOK setzen.

 Nun, warum dann das Endzeichen ?
 Weil es InterFrameTime ersetzt und der Empfanger ausserdem Zeit hat,
 Message auf Fehler zu prufen, evtl. EmpfangsBuffer zu verschieben,
 damit neue Messages empfangen werden können.
 Wenn Antwort verlangt wird, kann die schon vorbereitet werden, usw.
 Wenn das alles OK ist und Endzeichen ankommt, Empfanger ist schon
 bereit, um sofort Befehl auszufuhren oder zu antworten.


Ich hoffe, das wird nicht gelöscht :)

 mfg, Bole

Bole aus Serbien schrieb:
>  Timer fur die einzelnen Bytes brauchst du nicht, weil:
>   a) Bytes in ISR empfangen werden, nicht in einer Schleife.

Was hat das eine mit dem anderen zu tun?

Der Timer, der bei jedem empfangenen Byte neu gestartet wird, ist ja 
nicht für das Byte, sondern für die Pause dahinter (falls eine kommt). 
Einfach eine Möglichkeit, zuverlässig (unabhängig von Bitfehlern) und 
schnell (zügig nach Ende des Frames, egal wie lang der Frame ist, oder 
welche Länge der Empfänger erwartet) das Ende des Frames zu erkennen.

Das ist ein robuster Mechanismus, Framing sicherzustellen, ohne daß man 
sich auf die übertragenen Daten verlassen muß, die ja möglicherweise 
nicht stimmen (solange die Prüfsumme noch nicht geprüft ist). Natürlich 
muß man dazu das Timing festlegen (maximale Lücke zwischen zwei Bytes 
eines Frames und minimale Pause zwischen Frames), und der Sender muß 
sich auch daran halten.
Aber irgendwelche Schätzwerte aus der empfangenen Längenangabe zu 
berechnen ist optimistisch und versagt genau dann, wenn man den Timer 
wirklich braucht, nämlich bei Übertragungsfehlern in der Längenangabe.

Nosnibor schrieb:
>>  Timer fur die einzelnen Bytes brauchst du nicht, weil:
>>   a) Bytes in ISR empfangen werden, nicht in einer Schleife.
>
> Was hat das eine mit dem anderen zu tun?

 Weil der Empfanger lustig seiner Arbeit nachgeht (wie ublich)


> Der Timer, der bei jedem empfangenen Byte neu gestartet wird, ist ja
> nicht für das Byte, sondern für die Pause dahinter (falls eine kommt).

 Lese unter b)

> muß man dazu das Timing festlegen (maximale Lücke zwischen zwei Bytes
> eines Frames und minimale Pause zwischen Frames), und der Sender muß
> sich auch daran halten.

 Und wenn er das nicht kann ?
 (Wichtigere Aufgaben in Echtzeit erledigen) ?
 Master sendet immer vollstandige Frames, in Sistemen die auf
 Sicherheit ausgelegt sind, muss auch jede gesendete Frame bestatigt
 werden.Deswegen sind CAN-Frames so kurz.
 Jetzt aber sendest du eine Frame mit 60 Bytes NutzDaten.Die must
 du komplett rausschicken, weil es RS485 ist, also keine Arbitration,
 deine InterFrameZeit abwarten und auf Bestatigung warten...
 Es war aber eine InterByteZeit 100uS langer als vereinbart.Und was
 jetzt ?
 Die ganze Frame verwerfen, wegen 100uS Verzogerung ?
 Nochmals 60+n Bytes senden ?

 Und ausserdem:
 InterFrameZeit muss mindestens 2 Zeichen betragen, darum ist
 Endzeichen schneller, sicherer und wird meistens verwendet.

 mfg, Bole

Bole aus Serbien schrieb:
> Die must du komplett rausschicken, weil es RS485 ist

Was hat die definition der hardware (rs485) mit dem rausschicken der 
daten zu tun?
rs485 definiert nur die hardware, aber keinerlei softwareprotokoll

hw schrieb:
> rs485 definiert nur die hardware, aber keinerlei softwareprotokoll

 Beim LAN (RS422/485) ist es ist nicht üblich, dass der Sender die
 Logic-Level der gesendeten Daten pruft.Beim CAN ja.

Bole aus Serbien schrieb:
> hw schrieb:
>> rs485 definiert nur die hardware, aber keinerlei softwareprotokoll
>
>  Beim LAN (RS422/485) ist es ist nicht üblich, dass der Sender die
>  Logic-Level der gesendeten Daten pruft.Beim CAN ja.

LAN ist kein rs422.
und rs422 ist kein rs485, sondern nur eine untermenge des 485standards
du schmeist hier alles durchnander.
rs485 definiert nur die hardware, sonst gar nix. da wird nur festgelegt 
dass es zwei differentielle leitungen gibt, auf denen eine bitfolge 
übertragen werden kann. da ist keine anzahl bits definiert, kein start 
und stopbit, kein protokoll, nix dergleichen.

warum schreibst du dann
Bole aus Serbien schrieb:
> Jetzt aber sendest du eine Frame mit 60 Bytes NutzDaten.Die must
>  du komplett rausschicken, weil es RS485 ist

hw schrieb:
> LAN ist kein rs422.
> und rs422 ist kein rs485, sondern nur eine untermenge des 485standards
> du schmeist hier alles durchnander.
> rs485 definiert nur die hardware, sonst gar nix. da wird nur festgelegt
> dass es zwei differentielle leitungen gibt, auf denen eine bitfolge
> übertragen werden kann. da ist keine anzahl bits definiert, kein start
> und stopbit, kein protokoll, nix dergleichen.

    MODERATOR ????
 HIIIILFE !!
 Warum hacken halbgebildete an mir rum ?
 Weil ich aus Serbien bin ?

 Als ich schrieb, dass RS232 ein Standard und kein Protokoll ist,
 wurde das prompt geloscht.
 Ist hier vielleicht username gewechselt, damit weiter unnutze und
 dumme Kommentare gesendet werden ?

Bole aus Serbien schrieb:
>  Es war aber eine InterByteZeit 100uS langer als vereinbart.Und was
>  jetzt ?
>  Die ganze Frame verwerfen, wegen 100uS Verzogerung ?

Ja. Wenn der Sender es nicht schafft, eine protokollkonforme Nachricht 
zu senden, dann kommt eben keine Nachricht beim Empfänger an. Ist 
woanders auch so: wenn einer stammelt und lallt, weil er sich nicht mehr 
genug aufs Sprechen konzentrieren kann, versteht ihn eben keiner.

Das ist eine Frage der Prioritäten. Man kann ein Protokoll definieren 
mit sauberem Framing, basierend auf klar erkennbaren Pausen zwischen den 
Frames (das heiß ja nicht, daß es innerhalb eines Frames keine Pausen 
geben darf. Nur kurz genug müssen sie sein), und dann muß man eben den 
Sender so schreiben, daß er das einhält, z.B. indem er sich einen Frame 
fertig in den Speicher bereitlegt zum Senden, anstatt alles on-the-fly 
zusammenzubauen. Das halte ich für sinnvoll, aber bei einer geeigneten 
Kombination von Voraussetzungen kann es auch günstiger sein, das Timing 
auf dieser Ebene lockerer zu lassen. Dann würde man im Empfänger einen 
Timer mit einer Art Watchdog-Funktion verwenden: "vor zehn Sekunden 
wurde ein Frame begonnen. Wenn der jetzt noch nicht fertig ist, wird das 
nie mehr was, also braucht der Empfangs-Zustandsautomat einen Reset". 
Dann muß man eben auch mit den Nachteilen des gröberen Timings leben: 
bei einem Übertragungsfehler ist die Kommunikation länger gestört.

Bole aus Serbien schrieb:
> MODERATOR ????
>  HIIIILFE !!
>  Warum hacken halbgebildete an mir rum ?
>  Weil ich aus Serbien bin ?

hör auf hier rumzuschreien. lies lieber die beschreibung von rs485. da 
steht unter anderem:
"Im Gegensatz zu anderen Bussen sind bei EIA-485 nur die elektrischen 
Schnittstellenbedingungen definiert."

soviel zum thema halbgebildete
übrigens dieser standard gilt auch in serbien.

Marc Vesely schrieb:
> hw schrieb:
>> hör auf hier rumzuschreien. lies lieber die beschreibung von rs485. da
>> steht unter anderem:
>> "Im Gegensatz zu anderen Bussen sind bei EIA-485 nur die elektrischen
>> Schnittstellenbedingungen definiert."
>
>  Lieber vom Anfang an durchlesen, dumme und unnötige Bemerkungen
>  beiseite lassen.
>
> Keyboard schrieb:
>> hei,
>>
>> bin dabei, mittels RS485 mehrere PIC zu verbinden.

ja, und? das ändert doch überhaupt nichts an der tatsache, daß die rs485 
nunmal keinerlei software definiert, sondern ausschließlich die 
hardware.

und auch mit einem pic kann man beispielsweise 1 bit pro stunde mit 20 
stoppbits übertragen und trotzdem bleibt es eine rs485. war nur ein 
extrembeispiel, aber was man über rs485 überträgt und in welchem format 
und protokoll, ist total egal. rs485 bleibt es trotzdem.