hei, bin dabei, mittels RS485 mehrere PIC zu verbinden. Das senden vom Master zum Slave funktioniert, auch vom Slave zum Master Ein Paket besteht aus: ID Anzahl der Byte Paket Type n Nutzbyte Prüfsumme wie erkennt der Master, das Ende des vom Slave gesendete Paket ? nimmt man hier einen Timer, der bei jedem empfangen Byte auf Null gesetzt wird und das Paket nach Überlauf des Timer ausgewertet wird oder gibt man einem Timer eine feste Zeit, größer als die gesamtzeit für den Empfang aller Bytes, vor und nach Überlauf des Timer dann die Auswertung schönen Tag
:
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.
LIN arbeitet zB mit einem BREAK als Startsignal. Ein BREAK ist ein dominanter Pegel mit einer Länge von mindestens 13 Bitzeiten, quasi ein überlanges Startbit. Warum 13? 1 Startbit plus maximal 9 Datenbits plus maximal 2 Stoppbits sind 12 Bits insgesamt. Das ist bei einer asynchronen Verbindung die Parameterkombination mit der längstmöglichen Dauer. 13 Null-Bits können also normal niemals vorkommen. Viele PICs (u.a. alle PIC24/dsPIC33 und PIC32) haben Hardware-LIN-Unterstützung und erkennen damit ein BREAK und lösen dann einen Interrupt aus. fchk
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.
:
Wiederhergestellt durch Moderator
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.
hei, Vielen Dank für alle Info. Die Praxis wird es zeigen, war am besten geeignet ist. Ich selbst finde den nachgetriggerten Timer am besten, da die Frame Länge variabel ist. Zusätzlich noch Timeout für die Sicherheit und um dem Master zu signalisieren, du darfst wieder senden. schönen Tag
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.
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.
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.