Hi zusammen,
ich suche eine sehr einfache Lösung ein paar Byte über GPIOs von einem
µC auf einen anderen zu übertragen.
Die Hardware ist vorhanden und ich habe zwei Controller mit jeweils noch
zwei freien GPIOs. Diese haben keine besonderen Funktionen wie IRQ o.ä.
Die zu überwindende Strecke ist etwa 1m, die Geschwindigkeit quasi egal.
Als erstes kam mir Software UART oder Software I²C in den Sinn, aber ich
denke das muss doch noch einfacher gehen.
Wäre nett, wenn ihr mir ein paar Ideen mit auf den Weg geben könntet.
Vielleicht ist eines der beiden bereits "der Einfachste Weg".
Danke vorab
Ok, aber prinzipiell kann man wohl sagen, dass es ratsam ist ein
bestehendes Protokoll zu nutzen?
Ob es nun I2C, SPI, UART oder OneWire wird hängt dann davon ab, was mir
"besser gefällt".
Für was würdet ihr euch entscheiden und weshalb?
Fragender schrieb:> aber ich denke das muss doch noch einfacher gehen.
Geht es auch. Beispiel:
Negative Flanke startet das Bit, für 1 gehts nach 25% der Periode wieder
hoch, für 0 bei 75%. Der Empfänger startet bei negativer Flanke einen
Timer und fragt nach 50% ab.
Ähnelt entfernt 1-Bit UART, mit Synchonisierung pro Bit statt pro Byte.
Erlaubt daher weit grössere Takt-Toleranz als UART. Der Sender kann
dafür einen PWM-Timer verwenden. Für den Empfänger muss man sehen, was
die Timer hergeben (z.B. Input Capture).
Software-i2c.
Weil es völlig unkritisch ist was irgendwelche timings angeht, anders
als UART.
Weil es mit 2 Leitungen bidirektional übertragen kann, anders als spi.
Weil es trivial einfach zu implementieren ist, anders als onewire..
Dunno.. schrieb:> Software-i2c.>> Weil es völlig unkritisch ist was irgendwelche timings angeht
Nö, ist total kritisch. Wenn der Slave nicht innerhalb von 4µs (bei
100kBit) auf die Flanke reagieren kann, hat er verloren.
Du brauchst 2 Flankeninterrupts für SDA, SCL und alle anderen Interrupts
dürfen zusammen nicht >4µs brauchen.
Slave-I2C geht nur zuverlässig mit I2C-Hardware.
Ist das auch kritisch, wenn ich Masterseitig Bit Banging nutze und
Slaveseitig HW i2c?
Hardwaremäßig ware das in der vorliegenden Konstellation nur so möglich.
Die Daten müssen allerdings vom Slave zum Master.
Da die Geschwindigkeit egal ist, wie du schriebest, würde ich mir so
etwas wie die Schnittstelle der PS-2 Tastatur aussuchen. Das braucht
auch nur 2 Strippen und ist bidirektional.
W.S.
Fragender schrieb:> Ist das auch kritisch, wenn ich Masterseitig Bit Banging nutze und> Slaveseitig HW i2c?
Als einzelner Master ist das unkritisch, da der Master den Takt vorgibt.
Er kann sich also beliebig lange Pausen durch andere Interrupts
erlauben.
Als Multimaster muß er aber Kollisionen auflösen können und das geht nur
mit HW-I2C.
Peter D. schrieb:> Als einzelner Master ist das unkritisch
So hatte ich mir das dann auch überlegt, vielen Dank für die Bestätigung
und doch auch Ergänzung zu meiner Überlegung!
Ich würde einen Softuart nutzen. Dann ist es für den Test möglich
einfach einen PC dazuzuschalten, um mitzuschreiben. Mit einem ARM läßt
sich per DMA eine nahezu Prozessorunabhängiger Sender + Empfänger
implementieren - sofern vorhanden. Geht dann problemlos bis 115kBaud und
mehr.
W.S. schrieb:> Da die Geschwindigkeit egal ist, wie du schriebest, würde ich mir so> etwas wie die Schnittstelle der PS-2 Tastatur aussuchen. Das braucht> auch nur 2 Strippen und ist bidirektional.
War das nicht fast das Gleiche wie I²C ?
Stefan ⛄ F. schrieb:> W.S. schrieb:>> Da die Geschwindigkeit egal ist, wie du schriebest, würde ich mir so>> etwas wie die Schnittstelle der PS-2 Tastatur aussuchen. Das braucht>> auch nur 2 Strippen und ist bidirektional.>> War das nicht fast das Gleiche wie I²C ?
Nö, mit I2C hat es eigentlich nur die OC/OD-Technik gemeinsam und die
Tatsache, dass es eine Takt- und eine Datenleitung gibt.
Das Protokoll ist aber auf allen Ebenen völlig abweichend. Im Vergleich
zu I2C ist es für die Zielanwendung des TO jedoch eher schlechter
geeignet. Das Timing ist in vieler Hinsicht kritischer und zwar an
beiden Enden der Strippe. Das wird nur durch die weit geringere Bitrate
entschärft, aber auch I2C kann man ja beliebig langsam betreiben.
Ich würde deshalb für die Aufgabe einer P2P-Kommunikation über GPIOs
eindeutig I2C vorziehen (in einer abgerüsteten Variante ohne
Clock-Stretching und die Möglichkeit für Multi-Master). Das hätte
folgende Vorteile:
1) eindeutige Rollenverteilung zwischen Master und Slave,
timing-kritisch ist dann allein der Slave und es gibt im Prinzip nur
genau eine wirklich kritische Zeit, nämlich die Maximalzeit, innerhalb
derer nach Senden des achten Bits der Adresse der Slave in der Lage ist,
das ACK-Bit korrekt anzusteuern.
2) ein- und derselbe Code läßt sich sehr leicht für unterschiedliche
Gegebenheiten bezüglich der Möglichkeiten der Peers anpassen, ein
bestimmtes Timing zuverlässig zu realisieren. Und zwar einerseits allein
durch die Wahl der Rollen (Slave wird einfach der Peer, der mehr
Reserven hat) und andererseits durch die Anpassung des Taktes an dessen
Möglichkeiten. Die Logik des Codes selber muss dabei niemals geändert
werden.
3) Der vorhandene I2C-Adressierungsmechanismus kann im P2P-Fall des TO
zur "Funktions- bzw. Kanalwahl" genutzt werden (und natürlich sowieso
zur Steuerung der Kommunikationsrichtung). Das erspart es, das auf
höherer Protokollebene implementieren zu müssen.
4) Es sind (bei entsprechenden Kapazitäten wenigstens eines der Peers)
problemlos auch höhere Übertragungsraten als 10kBit/s zu erreichen. Eben
weil es nicht das komplexe Timing mit mehreren, funktional voneinander
abhängigen Constraints von PS/2 gibt, sondern im Kern nur einen
einzigen.
