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
Fragender schrieb: > Als erstes kam mir Software UART oder Software I²C in den Sinn, aber ich > denke das muss doch noch einfacher gehen. Morsecode
Walter Tarpan schrieb: > Wenn unidirektional SPI Brauche ich da nicht CS, CLK und MOSI? Oder kann CS entfallen, wenn ich nur einen Slave habe?
CLK und MOSI oder MISO. Letzteres hängt davon ab, wer die Initiative haben soll. CS ist verzichtbar, wenn man einen timeout-Mechanismus vorsieht.
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).
:
Bearbeitet durch User
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.
Also, es wird nun so laufen, dass ich bei einem Gerät HW i2c und beim anderen Bitbanging nutze. Vielen Dank an alle.
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: > War das nicht I²C ? https://www.marjorie.de/ps2/ps2_protocol.htm
:
Bearbeitet durch User
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.
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.