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:> 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.
(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.
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.
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
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.
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?
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.
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.
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.
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.
(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.
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.
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:
(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.
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.
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.
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.
