Hallo, ich bin auf der Suche nach einem synchronen halbduplex Kommunikationsprotokoll für 2 Adern. Im Prinzip würde ich einfach eine UART nehmen und gut, allerdings haben beide Kommunikationsteilnehmer keinen präzisen Takt (und außerdem auch keine Hardware UART), daher scheidet das aus. Mir ging eine Art Software-SPI durch den Kopf, nur mit CLK und mit geteilter MISO/MOSI Leitung, die von beiden Seiten immer im Wechsel genutzt wird. Oder eben I2C wobei ich da die ganze Adressierung nicht brauche, da es nur eine Verbindung zwischen 2 Teilnehmen ist. Grundsätzlich ist mir Verlässlichkeit viel wichtiger als hohe Datenraten, da würde mir prinzipiell auch 1 kBit/s reichen. Irgendwelche Ideen?
Tim T. schrieb: > ich bin auf der Suche nach einem synchronen halbduplex > Kommunikationsprotokoll für 2 Adern. GND mitgerechnet?
Tim T. schrieb: > Irgendwelche Ideen? Offensichtlich ist die Leitungslänge nicht relevant. Dann ist es auch nicht wichtig welche Schnittstelle, welches Protkoll und welche Datenrate du verwendest.
Oh, sorry, sehe gerade dass Datenrate angegeben ist. Was spricht gegen I2C? Adressierung ist doch egal, wenn Du sie nicht benötigst stört sie aber doch auch nicht.
CAN, LIN? Oder ganz neu: I3C. Half duplex SPI sollte aber auch gut funktionieren. Siehe SWD.
(prx) A. K. schrieb: > Tim T. schrieb: >> ich bin auf der Suche nach einem synchronen halbduplex >> Kommunikationsprotokoll für 2 Adern. > > GND mitgerechnet? Nein, GND und Vcc sind noch extra. Hermann Kokoschka schrieb: > (prx) A. K. schrieb: >> GND mitgerechnet? > > UND: > Welche Entfernung? > Welche Datenrate? Leitungslänge ist weniger als 50 cm und die Datenrate wie bereits gesagt in weiten Strecken egal. Hintergrund ist einfach, normalerweise werden die Leitungen mit 12V Pegeln genutzt (pro Leitung sind sowohl ein µC Pin als Ausgang als auch einer als Eingang geschaltet), aber es sind nur 2 Leitungen (sowie VCC und GND) herausgeführt. Die Leitungen gehen ausgangsseitig über einen entsprechenden Treiber und eingangsseitig über einen Spannungsteiler und Schutzbeschaltung, also nichts was schnelle Pegeländerungen zulassen würde, darum auch nur eine geringe Datenrate.
Beitrag #7165289 wurde vom Autor gelöscht.
Tim T. schrieb: > Irgendwelche Ideen? Welche Hw hast Du denn? Wenn SPI vorhanden ist, nimm es. Wenn gar nix, dann kombiniere Takt und Bits. Z.b. mit kurzen und langen Peaks. Wenn Du Zähler hast, gehen auch bursts von bis zu 256 Impulsen für 1 Byte und Pause dazwischen. Wobei uC ohne UART schon selten sind, wenn es nicht grad auf den Cent oder mm² ankommt.
Tim . schrieb: > CAN, LIN? Oder ganz neu: I3C. > > Half duplex SPI sollte aber auch gut funktionieren. Siehe SWD. CAN, LIN, I3C scheiden aus diversen Gründen aus, nicht zuletzt weil sie für eine einzelne Punkt zu Punkt Verbindung unnötig aufgebläht sind. Aber danke für den Hinweis auf SWD, hatte die Lösung mit halbduplex SPI irgendwie als zu gefrickelt angesehen, aber da SWD es ja im Prinzip auch so macht, kann es ja nicht so schlecht sein.
Tim T. schrieb: > Die Leitungen gehen ausgangsseitig über einen entsprechenden Treiber und > eingangsseitig über einen Spannungsteiler und Schutzbeschaltung, also > nichts was schnelle Pegeländerungen zulassen würde, darum auch nur eine > geringe Datenrate. Was ist denn die eigentliche Aufgabe der Leitungen? Und was für Treiber? 12V sind erstmal kein Hindernis um 1MBaud zu erreichen.
A. S. schrieb: > Tim T. schrieb: >> Irgendwelche Ideen? > > Welche Hw hast Du denn? Wenn SPI vorhanden ist, nimm es. Wenn gar nix, > dann kombiniere Takt und Bits. Z.b. mit kurzen und langen Peaks. > > Wenn Du Zähler hast, gehen auch bursts von bis zu 256 Impulsen für 1 > Byte und Pause dazwischen. > > Wobei uC ohne UART schon selten sind, wenn es nicht grad auf den Cent > oder mm² ankommt. Da ist wieder das Problem, die Hardware steht schon (fest) und es ist nichts brauchbares herausgeführt, alles muss in Software gemacht werden und ich kann kein verlässliches Timing garantieren da immer irgendwas dazwischen grätschen kann, darum ja die Idee mit sparater Clock und Daten.
A. S. schrieb: > Tim T. schrieb: >> Die Leitungen gehen ausgangsseitig über einen entsprechenden Treiber und >> eingangsseitig über einen Spannungsteiler und Schutzbeschaltung, also >> nichts was schnelle Pegeländerungen zulassen würde, darum auch nur eine >> geringe Datenrate. > > Was ist denn die eigentliche Aufgabe der Leitungen? Und was für Treiber? > > 12V sind erstmal kein Hindernis um 1MBaud zu erreichen. Ansteuerung von externer Hardware oder als Eingang, jeweils mit so viel Kapazitiver Schutzbeschaltung das keine schnellen Pegeländerungen möglich sind.
Tim T. schrieb: > darum ja die Idee mit sparater Clock und Daten. Deshalb die Frage, was die Pins können. Wenn Du an der Gegenstelle 2 Eingänge hast und auf Clock reagieren sollst, dann musst Du sicher sein, dass Du eine Flanke der Clock in einer Zeit X sicher erkennst. Mit Change-interrupt oft schneller als per pollen. Vielleicht hast Du aber auch einen 1ms Timerinterrupt, dann sind 300Baud kein Problem.
A. S. schrieb: > Tim T. schrieb: >> darum ja die Idee mit sparater Clock und Daten. > > Deshalb die Frage, was die Pins können. Wenn Du an der Gegenstelle 2 > Eingänge hast und auf Clock reagieren sollst, dann musst Du sicher sein, > dass Du eine Flanke der Clock in einer Zeit X sicher erkennst. Mit Das ist mir natürlich klar. > Change-interrupt oft schneller als per pollen. Vielleicht hast Du aber > auch einen 1ms Timerinterrupt, dann sind 300Baud kein Problem. PCINT geht nicht aber einen ~1ms Timerinterrupt habe ich. Werde mir noch mal PS/2 anschauen, sieht auf den ersten Blick nicht uninteressant aus und irgendwann hatte ich da auch schon mal was zu in VHDL gebaut. Auch wenns letztlich was anderes wird, gibts ja eventuell das ein oder andere was ich davon übernehmen kann. Danke für die Anregungen.
Alternativ zum UART gäbe es auch den Biphase–Mark Code, quasi UART (XOR) Clock. Damit geht dann Vollduplex, musst nur zuverlässig zwischen langen und kurzen Pulsen unterscheiden können.
Tim T. schrieb: > Das ist mir natürlich klar. Aber uns nicht. Also wenn Da ein CC oder ein Zähler oder irgend eine Special-Eingang ist, dann könnte das helfen. Hans schrieb: > musst nur zuverlässig zwischen langen und kurzen Pulsen unterscheiden können. Falls es wired or sind (also beide Leitungen treiben und lesen können und 1 oder 2 high ein high zurücklesen), dann hier ein Handshake dass ohne Timing auskommt. Allerdings 7 interaktionen pro Bit. 0: hörend, 1: treibt high, D: Signal-Bit (0 oder 1), !=invertiertes Signal-Bit (1 oder 0). Es ändert sich bei jedem Schritt eine Leitung, um der Gegenstelle etwas mitzuteilen. Was sich ändert, zeige ich mit *. Der Vorteil: Es kann beliebig schnell ausgeführt werden, ohne dass ein Bit verpasst wird. Selbst wenn ein Partner 20ms nicht reagieren kann. Timing braucht man nur zwischen den Bits, um ein "Start" zu erkennen oder einen Konflikt aufzulösen, wenn beide gleichzeitig senden möchten.
1 | A-B |
2 | |
3 | 0-0 Ruhestellung |
4 | 0-0 |
5 | |
6 | 0-0 A->B: request to send |
7 | *1-0 |
8 | |
9 | 0-1* B->A: ja, sende |
10 | 1-0 |
11 | |
12 | D-1 A->B hier mein Bit |
13 | *0-0 |
14 | |
15 | D-0* (Sample in B. A kann das nicht erkenne) |
16 | 0-0 |
17 | |
18 | D-0 B->A hab ich gesampelt |
19 | 0-1* |
20 | |
21 | *!-0 A->B OK, hab ich erkannt |
22 | 0-1 |
23 | |
24 | !-0 B->A OK, weiter |
25 | 0-0* |
26 | |
27 | ?0-0 Ausgangslage, nächstes Bit möglich. |
28 | 0-0 |
Hallo, ich kenne das einfacher. (mit 4 Schritten) (war irgendwann mal ein Übertragungsprotokoll zwischen Grafik-Schul-Rechnern mit klinken-Steckern). Ruhezustand beide Leitungen High (Open Drain Ausgänge und Pull-ups). Die Leitungen sind Null-Bit und Eins-Bit. Der Sender zieht beim Senden eines Bits die entsprechende Leitung auf low. Der Empfänger quittiert die fallende Flanke auf der anderen Leitung. Der Sender nimmt als Reaktion die Anforderung zurück. Der Empfänger quittiert mit steigender Flanke auf der anderen Leitung. Natürlich gab es auch Fehlerbehandlung (Timeouts) und Rücksetzen der Übertragung durch ziehen beider Leitungen gleichzeitig für eine bestimmte Dauer. Bis auf die Fehlerbehandlung ist keinerlei Timing erforderlich. Gruß Anja
CAN ist in den meisten Fällen die klare Wahl, weil:
Die Signalisierung auf niedrigem Niveau ermöglicht ein
Kollisionserkennungsschema. Wenn ein Knoten den rezessiven Zustand auf
den Bus "schreibt" und sieht, dass er sich tatsächlich im dominanten
Zustand befindet, weiß er, dass ein anderer Knoten den Bus antreibt. Der
Knoten, der versucht, den rezessiven Zustand zu schreiben, zieht sich
zurück und wartet auf das Ende der Nachricht. Der Knoten, der den
dominanten Zustand schreibt, weiß nie, dass dies passiert ist. Seine
Nachricht wird von allen anderen Knoten normal gesendet und empfangen.
Diese Kollisionserkennungsfähigkeit ermöglicht
Peer-to-Peer-Netzwerkarchitekturen ohne zentrale Arbitrierung. Knoten
senden einfach Nachrichten, halten sich jedoch zurück, wenn eine
Kollision erkannt wird, und versuchen es dann erneut, nachdem das
aktuelle Paket abgeschlossen ist. Schließlich werden diese anderen
Nachrichten gesendet, der Bus ist verfügbar und die zuvor kollidierten
Nachrichten werden ohne Kollision gesendet.
CAN spezifiziert viel mehr als nur die physikalische Schicht,
während Sie mit RS-485 nur das bekommen. Bei RS-485 gibt es keine
Standardmethode, um zu entscheiden, wer senden darf, was gesendet wird,
woran man erkennt, dass es intakt angekommen ist usw. CAN spezifiziert
vollständige Pakete auf dem Bus, die eine 16-Bit-CRC-Prüfsumme
enthalten.
Da bei CAN mehrere Protokollschichten über der physikalischen Ebene
spezifiziert sind, kann die Logik zu ihrer Implementierung in
handelsübliche Hardware eingebaut werden. Sie finden kleine und günstige
Mikros mit Hardware, die ganze CAN-Pakete sendet und empfängt. Diese
Hardware kümmert sich automatisch um Paketstart/-ende-Erkennung,
Kollisionserkennung, Backoff, Wiederholung, Prüfsummengenerierung und
-überprüfung sowie einige weitere Funktionen im Zusammenhang mit
Hardwarefehlern.
Im Gegensatz dazu erhalten Sie mit RS-485 einen UART und der Rest
ist Ihr Problem. Während es sicherlich möglich ist, ein robustes
Protokoll über RS-485 zu implementieren, ist es nicht so einfach, alle
Grenzfälle richtig zu behandeln.
Anja schrieb: > Der Sender zieht beim Senden eines Bits die entsprechende Leitung auf > low. > Der Empfänger quittiert die fallende Flanke auf der anderen Leitung. > Der Sender nimmt als Reaktion die Anforderung zurück. > Der Empfänger quittiert mit steigender Flanke auf der anderen Leitung. Ja, das ist deutlich besser und doppelt so schnell: der Sender kann auf beiden Leitungen "starten" und darin ist schon das Daten-Bit codiert. Da könnte es noch ein Problem geben, wenn der eine mit 0 und der andere mit 1 gleichzeitig startet, aber klingt gut.
Georg H. schrieb: > CAN ist in den meisten Fällen die klare Wahl, weil: ... es einen leidlich genauen Takt benötigt. Tim T. schrieb: > allerdings haben beide Kommunikationsteilnehmer keinen präzisen Takt
Danke Anja, das sieht sehr gut aus. Hat dieses Protokoll irgendeinen Namen?
:
Bearbeitet durch User
Hier der 124Bus, einfach zu implementieren. Beitrag "mehrere MC seriell über Datenbus verbinden (1Draht)"
Tim T. schrieb: > Hat dieses Protokoll irgendeinen Namen? Nicht das ich wüßte. Habe nochmal nachgeschaut: der Rechner war Sharp EL9650. Das dazugehörige PC-Interface + SW hieß Sharp CE-LK1 Gruß Anja
Anja schrieb: > Nicht das ich wüßte. > Habe nochmal nachgeschaut: der Rechner war Sharp EL9650. > Das dazugehörige PC-Interface + SW hieß Sharp CE-LK1 Das Protokoll ist ziemlich nett, hat aber doch noch einen Nachteil: bei potentiell gleichberechtigten Peers tut sich der Abgrund der race condition auf. Sprich: für diesen Fall muss es einen weiteren Timing-Constraint geben. Wenn allerdings eine eindeutige Master-Slave-Struktur vorgegeben ist, dann passt das schon wie beschrieben.
Tim T. schrieb: > Grundsätzlich ist mir Verlässlichkeit viel wichtiger als hohe > Datenraten, da würde mir prinzipiell auch 1 kBit/s reichen. Tim T. schrieb: > alles muss in Software gemacht werden > und ich kann kein verlässliches Timing garantieren da immer irgendwas > dazwischen grätschen kann, darum ja die Idee mit sparater Clock und > Daten. Tim T. schrieb: > PCINT geht nicht aber einen ~1ms Timerinterrupt habe ich. Deine Anforderungen passen nicht zu zusammen. Wenn Du alles in Software machen musst und nicht mal ein garantiertes 1ms Timing hast, dann kannst Du froh sein, wenn Du auf 100 Baud kommst. Auch die Taktleitung will gesampelt werden. Ich vermute mal, du wirst in Deiner Empfangsroutine nicht ewig "rumpollen" können? Wenn es wenigstens einen Interrupt auf den Pins gäbe. Es wird nur ein Protokoll mit Handshaking funktionieren, und das vermutlich wesentlich langsamer als von Dir gewünscht, der Empfänger muss ja auch zu dem Zeitpunkt hören können. Schon die Grenzfrequenzen Eurer Treiber und Eingangsfilter bestimmt?
Achja, ansonsten würde ich es über Pulsdauer Kodierung versuchen: Idle: High, Für ein Bit dann immer Low für "t_low" und High für "t_high". "0" mit t_low << t_high und "1" t_low >> t_high übertragen. Der Empfänger misst die Längen der "Low" und der "High" Periode mit seiner eigenen Uhr und vergleicht einfach nur beide Zeiten miteinander. Die Nutzdaten evtl. noch per COBS kodiert um die Datenpakete abzugrenzen.
Tim T. schrieb: > Hallo, > ich bin auf der Suche nach einem synchronen halbduplex > Kommunikationsprotokoll für 2 Adern. Im Prinzip würde ich einfach eine > UART nehmen und gut, allerdings haben beide Kommunikationsteilnehmer > keinen präzisen Takt (und außerdem auch keine Hardware UART), daher > scheidet das aus. Mir ging eine Art Software-SPI durch den Kopf, nur mit > CLK und mit geteilter MISO/MOSI Leitung, die von beiden Seiten immer im > Wechsel genutzt wird. Oder eben I2C wobei ich da die ganze Adressierung > nicht brauche, da es nur eine Verbindung zwischen 2 Teilnehmen ist. > Grundsätzlich ist mir Verlässlichkeit viel wichtiger als hohe > Datenraten, da würde mir prinzipiell auch 1 kBit/s reichen. > Irgendwelche Ideen? Software UART mit folgendem Telegrammaufbau: STX bzw. Startbyte, Längenbyte, Daten ... Daten, CRC16 keine Quittierung vom Empfänger wenn CRC falsch ist, dann wiederholt Sender.
:
Bearbeitet durch User
Anja schrieb: > Habe nochmal nachgeschaut: der Rechner war Sharp EL9650. > Das dazugehörige PC-Interface + SW hieß Sharp CE-LK1 Danke, werde bei Gelegenheit mal schauen ob ich irgendwas darüber raus bekomme. c-hater schrieb: > Das Protokoll ist ziemlich nett, hat aber doch noch einen Nachteil: bei > potentiell gleichberechtigten Peers tut sich der Abgrund der race > condition auf. Sprich: für diesen Fall muss es einen weiteren > Timing-Constraint geben. Das ist klar, aber es ist wie gesagt eine Absolut klare Master/Slave Struktur mit klaren Reihenfolgen in der Kommunikation. Werde das Ganze noch mit einem Parity und ACK/NACK Bit sowie einem längeren Watchdog Timeout verknüpfen um die sonstigen Probleme abzufangen. Andreas M. schrieb: > Deine Anforderungen passen nicht zu zusammen. Wenn Du alles in Software > machen musst und nicht mal ein garantiertes 1ms Timing hast, dann kannst > Du froh sein, wenn Du auf 100 Baud kommst. Auch die Taktleitung will > gesampelt werden. Ich vermute mal, du wirst in Deiner Empfangsroutine > nicht ewig "rumpollen" können? Wenn es wenigstens einen Interrupt auf > den Pins gäbe. Nein, ewiges "rumpollen" ist kein Problem solange es den sonstigen Fluss nicht blockiert. Wie gesagt es steht kein Interrupt oder sonstwas zur Verfügung. Aber 100 Baud wären auch noch ok. > Es wird nur ein Protokoll mit Handshaking funktionieren, und das > vermutlich wesentlich langsamer als von Dir gewünscht, der Empfänger > muss ja auch zu dem Zeitpunkt hören können. Schon die Grenzfrequenzen > Eurer Treiber und Eingangsfilter bestimmt? Das Protokoll von Anja hat diese Einschränkung nicht und ist momentan meine erste Wahl, was die Grenzfrequenz angeht, werde ich das morgen/übermorgen damit mal austesten. Andreas M. schrieb: > Achja, ansonsten würde ich es über Pulsdauer Kodierung versuchen: Idle: > High, Für ein Bit dann immer Low für "t_low" und High für "t_high". "0" > mit t_low << t_high und "1" t_low >> t_high übertragen. Der Empfänger > misst die Längen der "Low" und der "High" Periode mit seiner eigenen Uhr > und vergleicht einfach nur beide Zeiten miteinander. Die Nutzdaten evtl. > noch per COBS kodiert um die Datenpakete abzugrenzen. Auch hier wieder der Verweis auf "Anjas" Protokoll, was diese Umstände eben nicht hat. Gerald K. schrieb: > Software UART mit folgendem Telegrammaufbau: > > STX bzw. Startbyte, Längenbyte, Daten ... Daten, CRC16 > > keine Quittierung vom Empfänger wenn CRC falsch ist, dann wiederholt > Sender. Das mit dem nicht garantierten Timing hattest du aber gelesen, oder?
:
Bearbeitet durch User
Falls du auf den input verzichten kannst gibt es sowas wie SENT (SAE J2716). Für UART gibt es sowas wie PDI. Das kommt mit einem Daten-Leiter aus.
Tim T. schrieb: > Das mit dem nicht garantierten Timing hattest du aber gelesen, oder? Die Frage wie groß die Abweichnungen sind. Statische Abweichung können angepaßt werden können. Dann bleiben 3% bleiben für dynamische Abweichungen übrig.
Anja schrieb: > Tim T. schrieb: >> Hat dieses Protokoll irgendeinen Namen? > > Nicht das ich wüßte. > Habe nochmal nachgeschaut: der Rechner war Sharp EL9650. > Das dazugehörige PC-Interface + SW hieß Sharp CE-LK1 > > Gruß Anja So etwas wurde auch hier probiert: https://www.roboternetz.de/community/entries/317-Steppender-Linienfolger-SW-serieller-Transfer-im-Zwangslaufverfahren-mit-zwei-Adern?s=c320560ba4f1c383212d231fa9fb9cc6
Gerald K. schrieb: > Statische Abweichung können angepaßt werden können Da der UART in Software realisiert ist, könnte beim Startbyte die Bitbreite ausgemessen werden. Die Generierung der Impulszeiten muss, so wie beim Empfang, interrupt-gesteuert ausgeführt sein.
Gerald K. schrieb: > Tim T. schrieb: >> Das mit dem nicht garantierten Timing hattest du aber gelesen, oder? > > Die Frage wie groß die Abweichnungen sind. Statische Abweichung können > angepaßt werden können. Dann bleiben 3% bleiben für dynamische > Abweichungen übrig. Beide Teinehmer haben keinen Quarz und laufen mit dem internen RC-Oszillator in einem möglichen Temperaturbereich von -40 bis +80 °C, dazu wird der Programmfluss zumindest einer Seite immer wieder mit verschieden langen ISR unterbrochen. Von daher bin ich mit einem Protokoll, was prinzipiell gar keinen Takt braucht sehr zufrieden, jede andere Variante hätte eh einen sehr langsamen Clock erfordert um bloß nicht den Sample Zeitpunkt der Datenleitung zu verpassen. Ein Asynchrones Protokoll kommt darum auch nicht infrage.
:
Bearbeitet durch User
Tim T. schrieb: > Beide Teinehmer haben keinen Quarz und laufen mit dem internen > RC-Oszillator in einem möglichen Temperaturbereich von -40 bis +80 °C, > dazu wird der Programmfluss zumindest einer Seite immer wieder mit > verschieden langen ISR unterbrochen. Der RC-Oszillator wird zumindest eine relativ stabile Frequenz besitzen. Die könnte man fein bei jedem Startbyte abgleichen. Also sollte dies kein Problem sein. Bei den ISRs kann man sich mit den Prioritäten helfen. Die Timerinterupts für das UART-Timing sollte die höchste Priorität besitzen und alle anderen ISRs unterbrechen. Bei 1000Baud ist die Schrittbreite 1ms. Diese sollen für Interrupt mit höchster Priorität kein Problem sein. Man könnte eine Korrektur des Timings auch auf Schrittebene, bei jedem Flankenwechsel, durchführen. So können sich Abweichungen über ein Byte nicht aufsummieren. Und sollte einmal etwas schief gegen, dann sollte der Fehler mittels CRC erkannt werden und das Telegramm in der Folge wiederholt werden. Generell sollten bei einer guten embedded Implementierung die ISRs möglichst kurz sein.
Gerald K. schrieb: > Der RC-Oszillator wird zumindest eine relativ stabile Frequenz besitzen. > Die könnte man fein bei jedem Startbyte abgleichen. Also sollte dies > kein Problem sein. Aber nicht über den kompletten Temperaturbereich und ein Startbit Abgleich geht aus den unten genannten Gründen nicht. > Bei den ISRs kann man sich mit den Prioritäten helfen. Die > Timerinterupts für das UART-Timing sollte die höchste Priorität besitzen > und alle anderen ISRs unterbrechen. Bei 1000Baud ist die Schrittbreite > 1ms. Diese sollen für Interrupt mit höchster Priorität kein Problem > sein. Man könnte eine Korrektur des Timings auch auf Schrittebene, bei > jedem Flankenwechsel, durchführen. So können sich Abweichungen über ein > Byte nicht aufsummieren. Nein, die Kommunikation hat die geringste Priorität und bekommt nicht einmal einen IRQ. > Generell sollten bei einer guten embedded Implementierung die ISRs > möglichst kurz sein. Jaja, sollte. Die Realität hat da oft andere Prioritäten. Aber wie gesagt, die Kommunikation hat gegenüber dem Rest keine Priorität.
:
Bearbeitet durch User
Tim T. schrieb: > da würde mir prinzipiell auch 1 kBit/s reichen. Wenn per Aufgabenstellung von vorneherein alles ausgeschlossen wird, was ein Zeit- und Reaktionsverhalten genauer als 1ms hergibt, und es sich nicht um eine analoge Leitung handelt, scheint mir eine Übertragung mit 1 kb/s kaum möglich zu sein. Allenfalls die Hälfte bis ein Drittel sehe ich als machbar an, z.B. mit PWM auf beiden Leitungen. Das sollte der Timer-Tick hergeben.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Tim T. schrieb: >> da würde mir prinzipiell auch 1 kBit/s reichen. > > Wenn per Aufgabenstellung von vorneherein alles ausgeschlossen wird, was > ein Zeit- und Reaktionsverhalten genauer als 1ms hergibt, und es sich > nicht um eine analoge Leitung handelt, scheint mir eine Übertragung mit > 1 kb/s kaum möglich zu sein. Allenfalls ungefähr die Hälfte sehe ich als > machbar an, z.B. mit PWM auf beiden Leitungen. Im Grunde nicht, mit Anjas Protokoll kann die Übertragung (bzw. die Abarbeitung der Übertragung) mit vollem CPU Takt laufen und wird halt einfach auf die Geschwindigkeit der erzwungenen Bestätigung gebremst. Was ich noch schauen muss ist ob sich die Beschaltung der Leitungen selber einbremst oder ob ich dafür noch extra Delays einfügen muss.
:
Bearbeitet durch User
OK, ich bezog das auf Verarbeitung ausschliesslich über den Timer-Tick. Allerdings setzt ihre Methode zwar kein genaues Timing voraus, aber genug Luft für aktives Polling ausserhalb vom Timer.
:
Bearbeitet durch User
Tim T. schrieb: > Was ich noch schauen muss ist ob sich > die Beschaltung der Leitungen selber einbremst oder ob ich dafür noch > Delays einfügen muss. Nein. Da die Reaktion ja immer auf dem "anderen" Kanal mit einem Pegelwechsel erfolgt, ist das "Laufzeit-sicher". Hier als verbesserte Version von Anja, wo das Datenbit ja schon im Kanal codiert ist (und 3 der 7 Takte entfallen) A. S. schrieb:
1 | 0-0 Ruhestellung |
2 | 0-0 |
3 | |
4 | 0-0 A->B: request to send (Bit = 0) |
5 | *1-0 |
6 | |
7 | 0-1* B->A: ja, erkannt |
8 | 1-0 |
9 | |
10 | 0-1 A->B OK, over |
11 | *0-0 |
12 | |
13 | 0-0* B->A over and out = Ruhestellung |
14 | 0-0 |
(prx) A. K. schrieb: > Allerdings setzt ihre Methode zwar kein genaues Timing voraus, aber > genug Luft für aktives Polling ausserhalb vom Timer. Oder Bursts im Timer, aber das ist dann wieder eine Frage, inwieweit die entstehende Laufzeit zulässig ist.
(prx) A. K. schrieb: > OK, ich bezog das auf Verarbeitung ausschliesslich über den Timer-Tick. > > Allerdings setzt ihre Methode zwar kein genaues Timing voraus, aber > genug Luft für aktives Polling ausserhalb vom Timer. Im Mittel sollte da genug Zeit für nicht blockierendes Polling sein, auch für mehr als 1 kbit/s. Wenn es dann zwischendurch mal etwas langsamer läuft macht das ja nichts, die Geschwindigkeit muss ja nicht konstant gehalten werden.
A. S. schrieb: > Tim T. schrieb: >> Was ich noch schauen muss ist ob sich >> die Beschaltung der Leitungen selber einbremst oder ob ich dafür noch >> Delays einfügen muss. > > Nein. Da die Reaktion ja immer auf dem "anderen" Kanal mit einem > Pegelwechsel erfolgt, ist das "Laufzeit-sicher". Ja, so habe ich es auch schon in meiner Statemachine gemacht. Die Frage ist nur ob ich nicht doch einen kleinen Moment warten muss bis die Pegel vom Gegenüber auch sicher erkannt worden sind. Die Leitungen sind IDLE Low und die Eingänge sind durch eine Diode mit der Leitung verbunden, dahinter ist aber noch etwas Kapazität und Widerstände. Eine steigende Flanke ist bei mir dadurch sehr steil, die fallende Flanke hingegen sieht aus wie eine RC-Entladekurve.
(prx) A. K. schrieb: > Klassische Mainloop-Programmierung? Nein, nur müssen aus Unzulänglichkeiten der Hardware für viel zu viele Sachen Flags in verschiedenen ISR gesetzt werden die dann mit Delays in der Mainloop abgearbeitet werden müssen. Die ISR sind dabei schon zeitkritisch und eigentlich würde ich so ein Projekt grundsätzlich anders aufbauen, angefangen bei der Pinbelegung und Auswahl des Controllers. Leider musste wegen Verfügbarkeitsproblemen schnell auf einen anderen Controller (andere Controllerfamilie) gewechselt werden und es wurde alles viel zu schnell durchgepeitscht. Jetzt ist es meine Aufgabe die Fehler dieses Vorgehens irgendwie soweit auszubügeln, dass es trotzdem funktioniert. Weiter möchte ich hier aber nicht darauf eingehen.
Hallo, mit dem Sharp habe ich mich wohl geirrt. Das Protokoll beim Sharp fängt zwar gleich an wird innerhalb des Bytes aber dann doch zeitkritisch. Das oben genannte Protokoll gehört zum TI-85 (auch ein Grafik-Rechner). die Beschreibung ist hier zu finden: https://www.ticalc.org/pub/text/calcinfo/ https://www.ticalc.org/pub/text/calcinfo/ti_protocol.zip siehe: "protocol_hard.txt" im Archiv. Gruß Anja
Tim T. schrieb: > Nein, die Kommunikation hat die geringste Priorität und bekommt nicht > einmal einen IRQ. Dann dürfte eine sichere Kommunikation eine untergeordnete Rolle spielen. Pollen ist die schlechteste Lösung, da dies den Systemstress unnötig erhöht. Man muss mindestens zweimal schneller als die Schrittweite pollen. Bei Interrupts schlimmstenfalls bei jedem Schritt. Sparsamste Lösung in der Codeausführung ist, wenn man, beim Senden mit Timerinterrupts und beim Empfangen mit Flankeninterrupts arbeitet. Jeder gute MC unterstützt Portinterrupts.
:
Bearbeitet durch User
Tim T. schrieb: > Die ISR sind dabei schon zeitkritisch und eigentlich würde ich so ein > Projekt grundsätzlich anders aufbauen, angefangen bei der Pinbelegung > und Auswahl des Controllers. Was sind bei dem Projekt zeitkritische Interrupts? Welche Reaktionszeiten sind bei diesen Interrupts einzuhalten? Man kann zeitkritische Funktionen auch in die Hardware auslagern oder auf mehrere MCs verteilen. Man sollte bei der Planung nicht alle Resourcen ausreizen.
:
Bearbeitet durch User
LIN wäre passend. Durch das sync frame ist kein genauer Takt notwendig. 12V Pegel und bis zu 19200 Baud möglich.
Warum das Rad zweimal erfinden? HDLC-Prozedur in Verbindung mit dem CSMA/CD-Algorithmus.
Gerald K. schrieb: > Man kann zeitkritische Funktionen auch in die Hardware auslagern oder > auf mehrere MCs verteilen Meine Fresse, ist verstehendes Lesen heute eigentlich zu viel verlangt? Er hat doch nun mehrfach Durchblicken lassen, das wer anders die Hardware verbockt und er der Blöde ist der ne Lösung mit dem Vorhandenen finden muss. So wie es halt oft läuft, keiner spricht mit dem anderen und am Ende muss der Softwerker die Kuh vom Eis holen. Auch wenn das für mich mit ISRs und Flags auch noch nach ganz anderen Problemen schreit. Kann man nur hoffen, das der TO ne funktionierende Lösung findet und dann nie wieder was mit dem Projekt zu tun bekommt. Das werden nämlich Fässer ohne Boden.
Tim T. schrieb: > Gerald K. schrieb: > >> Der RC-Oszillator wird zumindest eine relativ stabile Frequenz besitzen. >> Die könnte man fein bei jedem Startbyte abgleichen. Also sollte dies >> kein Problem sein. > > Aber nicht über den kompletten Temperaturbereich Sag doch einfach wie groß die Abweichung ist. Es gibt genug Controller, die über den kompletten Temperaturbereich ausreichend genau für uart sind. Asynchrone Kommunikation kann dann per dma zeitlich komplett unkritisch im Hintergrund laufen.
ich würde das auch so machen das jeder µC eine Leitung zum Senden bekommt eine 0 ist ein kurzer Impuls z.B. 100 µSek und eine 1 ein langer Impuls 200µSek. Eine erkannte High Flanke starten den Timer welcher nach 150 µSek auswertet ob High anliegt je nach Ergebnis schiebt man einen 0 oder 1 in eine Register oder man zählt direkt die High Zeit mit. So kann man Pikes rausfilter die zu stark von 100 oder 200µSek abweichen. Als Quittung kann der Empfänger z.B. mit 300µSek High antworten.
Tim T. schrieb: > Die Frage ist nur ob ich nicht doch einen kleinen Moment warten muss bis > die Pegel vom Gegenüber auch sicher erkannt worden sind. Nein. Jedes Signal wird vom Gegenüber auf der anderen Seite "bestätigt". Ein Tau von 1ms oder mehr wäre egal. Etwas anderes sind Doppelimpulse. Durch fehlende Hysterese und schlechte Abschlüsse. Das kann man berücksichtigen, indem man erst nach deren maximaler Zeit erneut erstmals pollt. Beispiel: für 100us sind Doppelimpulse möglich. Dann kannst Du trotzdem sofort reagieren, wenn Du einen Flankenwechsel erkannt hast (also Dein Signal ändern), darfst aber frühestens nach 101us erneut samplen. Danach gerne auch schneller. Bei Uarts spielen Doppelimpulse keine Rolle, bei SPI sind sie tödlich.
Andreas M. schrieb: > Meine Fresse, ist verstehendes Lesen heute eigentlich zu viel verlangt? > Er hat doch nun mehrfach Durchblicken lassen, das wer anders die > Hardware verbockt und er der Blöde ist der ne Lösung mit dem Vorhandenen > finden muss Er hat auch durchblicken lassen, dass er nicht gewillt ist der Kommunikation eine höhere Prioriät zukommen zulassen. Er hat auch nicht erklärt warum das nicht möglich ist. Fehlt vielleicht der Durchblick? Wichtig bei komplexen Projekten ist, die Softwareentwicklung beim Konzept mitarbeiten zu lassen. Dann entstehen solche Probleme nicht. "Man kann zeitkritische Funktionen auch in die Hardware auslagern oder auf mehrere MCs verteilen" hat sich auf zukünftige Projekte bezogen und ist nur möglich wenn es eine gute Teamarbeit zwischen HW und SW gibt.
:
Bearbeitet durch User
Gerald K. schrieb: > Er hat auch durchblicken lassen, dass er nicht gewillt ist der > Kommunikation eine höhere Prioriät zukommen zulassen. Er hat auch nicht > erklärt warum das nicht möglich ist. Weil die HW schon fix ist. Neben "kein Quartz", kein Interrupt, auch: Tim T. schrieb: > Die Leitungen gehen ausgangsseitig über einen > entsprechenden Treiber und eingangsseitig über einen Spannungsteiler und > Schutzbeschaltung, also nichts was schnelle Pegeländerungen zulassen > würde, darum auch nur eine geringe Datenrate. Selbst mit allerhöchster Priorität und Was auch immer wirst Du die bisherige Lösung kaum mit ausgemessenen Impulsen oder sowas schlagen können. Gerald K. schrieb: > "Man kann zeitkritische Funktionen auch in die Hardware auslagern oder > auf mehrere MCs verteilen" hat sich auf zukünftige Projekte bezogen. Ich glaube, es ist müßig zu diskutieren, wie man mit 2 Leitungen Daten austauscht, wenn man HW und SW beliebig gestalten kann. Egal ob mit oder ohne Quartz. 2 wired OR-Leitungen ohne Interrupt- oder HW-Unterstützung sind jetzt auch nicht so exotisch. Und die gefundene Lösung ist um Größenordnungen einfacher, robuster und schneller als irgendein gebitbangeder UART oder SPI, solange es keine HW-Unterstützung dafür gibt.
Um welchen Mikrocontroller handelt es sich - ev. ist ja Hardware mäßige Unterstützung vorhanden. / welche Pins den Mikrocontrollers werden für die Kommunikation verwendet. sorry falls ich das überlesen habe.
- 2 Adern + GND + VCC - syncron - 50 cm Entfernung - Master/Slave vorgegeben Wie ware es mit 1-Wire, oder etwas darauf Basierendem? Hauptproblem sind die 1kBit/s bei einer Pulsbreite von 1ms, denn das geht nur mit digitaler Kompression oder "Multilevel". Aber vielleicht kann es ja auch langsamer sein...
Da ja zwei Datenleitungen zur Verfügung stehen, können in einem Takt ja 4 Bit übertragen werden. Dann wären das theoretisch 4kBit/s, damit dürfte genügend Reserve für den Overhead bestehen.
svensson schrieb: > Wie ware es mit 1-Wire, oder etwas darauf Basierendem? Übertragen werden immer bits. Ob mit ein(1wire), zwei(i2c) oder drei(spi)Leitungen. Das Protokoll ist im Prinzip von der Art der Übertragung unabhängig. Protokolle gibt es viele. Kommt halt drauf an, wie sicher die erfolgreiche Übertragung festgestellt werden muss - keine Rückmeldung/ Übertragung erfolgt/Übertragung richtig erfolgt.
Das 1-Wire ist ein Protokoll und definiert doch auch eine physische Übertragung. Als Besonderheit könnte hier eben eine zweite Datenleitung dazukommen, die aber den Takt von der 1. Datenleitung übernimmt. Die Slaves lassen sich adressieren, was aber hier offenbar nicht erforderlich wäre. ACKN ist auch implementiert. Die Korrektheit der übertragenen Daten könnte durch Prüfsummen, z.B. CRC, sichergestellt werden; so machen das u.a. die DS1820. > Übertragen werden immer Bits. Muß nicht zwingend so sein (habe vielleicht nicht ganz klar gemacht, was ich meinte). Da hier VCC offenbar 12V ist, könnte man mehrere Level definieren. Beispiel: 0V=0 6V=1 9V=2 12V=3 somit könnten also über die beiden Datenleitungen 4^2 = 16 unterschiedliche Zustände in einem Takt übertragen werden, das wären dann vier Bit.
Wenn der Takt nicht passend ist, kann man auch z.B. dreimal senden mit leicht unterschiedlicher. Baudrate. --- Muß ja das allerbilligste Projekt sein. Gruselig. Und wir müssen das dann kaufen? Grr.
A. S. schrieb: > Tim T. schrieb: >> Die Frage ist nur ob ich nicht doch einen kleinen Moment warten muss bis >> die Pegel vom Gegenüber auch sicher erkannt worden sind. > > Nein. Jedes Signal wird vom Gegenüber auf der anderen Seite "bestätigt". > Ein Tau von 1ms oder mehr wäre egal. Nein, ich meinte eher wenn ich als Empfänger(Gegenüber) mein ACK von der 2. Leitung nehme, und danach direkt wieder einlese aber die 2. Leitung noch nicht unter den Schwellwert des Schmitt-Triggers gefallen ist und ich damit dann praktisch einem Phantom nachjage. > Etwas anderes sind Doppelimpulse. Durch fehlende Hysterese und schlechte > Abschlüsse. Das kann man berücksichtigen, indem man erst nach deren > maximaler Zeit erneut erstmals pollt. Genau das meinte ich mit kleinem Moment warten. Für alle Anderen die mit diversen Ideen um die Ecke kommen die eine Änderung der Hardware (µC, Pin, Beschaltung) erfordern, möchte ich an dieser Stelle sagen, dass dieses zwar (fast) alles richtig ist, aber das Kind bereits in den Brunnen gefallen wurde und jetzt nur noch Schadensminimierung von mir betrieben wird. Das ist so ein Projekt wo ich direkt nachdem ich den Schaltplan gesehen habe am liebsten was Anderes gemacht hätte und nachdem ich den vorhandenen Quelltext überflogen habe, den ganzen Tag gar keine Motivation mehr hatte irgendetwas zu machen.
:
Bearbeitet durch User
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.