Forum: Mikrocontroller und Digitale Elektronik UART per I²C-Nachbau über längere Strecke mit hohem Durchsatz?


von Scholaf Olz (Gast)


Angehängte Dateien:

Lesenswert?

Guten Abend und eine schöne Vorweihnachtszeit.

Vorweg: NEIN, RS485 kommt nicht infrage, weil ich hier die Erfahrung 
gemacht habe, dass ich hier beim Umschalten von Senden auf Empfangen und 
umgekehrt einige Millisekunden warten muss. Das kann/will ich mir nicht 
leisten, weil ich mehrere Slaves mehrmals pro Sekunde abfragen muss.
UART oder I2C wäre nicht schlecht, aber das ist offenbar nicht sehr 
robust und bei großen Pullups langsam.

Deshalb habe ich mir überlegt, was ähnliches wie I2C als 
Transportschicht aufzubauen, aber robuster und Vollduplex.
Ziel wären etwa 115200 Baud über einen Meter. Reserven sind immer 
willkommen.

Schaltplan anbei. Ich bin mir nur nicht sicher, ob der Komparator das 
Vorhaben ausbremst. Der Komparator hat 50 ns Umschaltzeit bei 100 mV 
Unterschied. Die Widerstände drumrum sollen eine Hysterese bilden, damit 
der Komparator bei einem zappelnden Pegelwechsel nicht zweimal schaltet.

Wer mag seinen Senf abgeben?
Danke für konstruktive Kritik! Falls ich auf dem Holzweg bin, ich bin 
auch für andere Schnittstellen offen.

von Stefan F. (Gast)


Lesenswert?

Was ist denn daran besser, als RS232 oder normales UART?

Bist du sicher, dass R7 (33Ω, 100mA) so sinnvoll ist? Viel hilft nicht 
immer viel.

Wenn du das Umschalten der Richtung bei RS485 vermeiden willst, dann 
nimm RS422. Mir ist allerdings ein Rätsel, warum du da einige 
Millisekunden warten musst. Untersuche doch lieber mal das Problem, 
anstatt es mit so einer sehr fragwürdigen Frickelei zum umgehen.

IC4 soll wohl als Schmitt-Trigger wirken. Wie hast du denn die 
Schaltschwellen und die Hysterese ausgelegt? Sie hängt vom 
Leitungswiderstand ab, das war so sicher nicht gewollt.

T1 invertiert das Signal, IC4 nicht. Das kann so nicht funktionieren.

von Falk B. (falk)


Lesenswert?

Scholaf Olz schrieb:
> Guten Abend und eine schöne Vorweihnachtszeit.
>
> Vorweg: NEIN, RS485 kommt nicht infrage, weil ich hier die Erfahrung
> gemacht habe, dass ich hier beim Umschalten von Senden auf Empfangen und
> umgekehrt einige Millisekunden warten muss.

Unfug.

> Das kann/will ich mir nicht
> leisten, weil ich mehrere Slaves mehrmals pro Sekunde abfragen muss.

Ach du Armer!

> Deshalb habe ich mir überlegt, was ähnliches wie I2C als
> Transportschicht aufzubauen, aber robuster und Vollduplex.
> Ziel wären etwa 115200 Baud über einen Meter. Reserven sind immer
> willkommen.

Schuster bleib bei deinem Leisten. Oder auch, erfinde das Fahrrad nicht 
neu!

> Schaltplan anbei. Ich bin mir nur nicht sicher, ob der Komparator das
> Vorhaben ausbremst. Der Komparator hat 50 ns Umschaltzeit bei 100 mV
> Unterschied.

Ob DAS für deine Superschnittstelle reicht?

> Die Widerstände drumrum sollen eine Hysterese bilden,

Sollen. Tun sie aber nicht. Siehe Schmitt-Trigger.

> Wer mag seinen Senf abgeben?

Bitte sehr.

> Danke für konstruktive Kritik! Falls ich auf dem Holzweg bin, ich bin
> auch für andere Schnittstellen offen.

Siehe oben!

von olaf (Gast)


Lesenswert?

> Danke für konstruktive Kritik! Falls ich auf dem Holzweg bin, ich bin
> auch für andere Schnittstellen offen.

Dann nimm doch I3C. Da wird Ihnen geholfen.

Olaf

von Wolfgang (Gast)


Lesenswert?

Scholaf Olz schrieb:
> Das kann/will ich mir nicht
> leisten, weil ich mehrere Slaves mehrmals pro Sekunde abfragen muss.

Warum können die Slaves nicht selber ihre Daten schicken?

> Wer mag seinen Senf abgeben?

CAN

von tut nix zur sache (Gast)


Lesenswert?

Scholaf Olz schrieb:
> Vorweg: NEIN, RS485 kommt nicht infrage, weil ich hier die Erfahrung
> gemacht habe, dass ich hier beim Umschalten von Senden auf Empfangen und
> umgekehrt einige Millisekunden warten muss. Das kann/will ich mir nicht
> leisten, weil ich mehrere Slaves mehrmals pro Sekunde abfragen muss.

485 geht auch vollduplex mit 4 strippen.

> UART oder I2C wäre nicht schlecht, aber das ist offenbar nicht sehr
> robust und bei großen Pullups langsam.

Was kennzeichnet denn ne robuste Verbindung für dich? Bzw. was genau 
spricht dagegen, mit dem Master einfach nen 0815-I²C-Treiber 
(pca-irgendwas) anzusteuern?

> Deshalb habe ich mir überlegt, was ähnliches wie I2C als
> Transportschicht aufzubauen, aber robuster und Vollduplex.
> Ziel wären etwa 115200 Baud über einen Meter. Reserven sind immer
> willkommen.

Wie gesagt: für 10kByte/sec RS485 oder CAN neu zu erfinden - muss man 
schon auch wollen irgendwo. Ob sich's lohnt, musste selber wissen.

> Schaltplan anbei. Ich bin mir nur nicht sicher, ob der Komparator das
> Vorhaben ausbremst. Der Komparator hat 50 ns Umschaltzeit bei 100 mV
> Unterschied. Die Widerstände drumrum sollen eine Hysterese bilden, damit
> der Komparator bei einem zappelnden Pegelwechsel nicht zweimal schaltet.

Feldbusse sind gut dokumentiert, spezifiert und kein großes 
Pioniergelände für deinen Anwendungsfall. Wenn's dir aus 
Not-Invented-Here-Gründen darum geht, das selber zu bauen (bzw. um's 
besser zu verstehen), dann bau eben deine Selbstbauschaltung auf und 
probier's aus.

von Frank K. (fchk)


Lesenswert?

CAN als Protokoll mit der optionalen Erweiterung CAN-FD wird für solche 
Zwecke immer gerne genommen. Es gibt ja mehr als genug Microcontroller, 
die einen CAN-Controller eingebaut haben. Dazu einen Transceiver Deiner 
Wahl, und los gehts. 125kbit/s ist dabei am unteren Ende von HighSpeed, 
1MBit/s das Maximum von Standard CAN, und CAN-FD kann bis zu 8MBit/s in 
der Datenphase.

Manche Leute verwenden auch einen RS485-artigen Aufbau, nehmen aber 
CAN-Transceiver statt RS485-Transceiver, um die Ansteuerung des 
DriverEnables loszuwerden.

Für höhere Ansprüche gibts dann Single Pair Ethernet in den 
verschiedenen Ausprägungen, wobei Du Dir vielleicht 10Base-T1S anschauen 
kannst. Oder gleich Standard Ethernet, da gibts ja genügend Lösungen.

fchk

: Bearbeitet durch User
von A. S. (Gast)


Lesenswert?

Scholaf Olz schrieb:
> Ziel wären etwa 115200 Baud über einen Meter. Reserven sind immer
> willkommen.

Uart geht da auch 100m bei entsprechenden Signalpegeln.

I2C schaltet auch um und hat mit clockstretching 2 potentielle Treiber 
gleichzeitig. Bei can ebenso

Can und I2C sind sinnvoll in ihrem Gesamtkonzept, sie sind nicht für 
schnell oder lang optimiert.

von Klaus S. (kseege)


Lesenswert?

Scholaf Olz schrieb:
> Vorweg: NEIN, RS485 kommt nicht infrage, weil ich hier die Erfahrung
> gemacht habe, dass ich hier beim Umschalten von Senden auf Empfangen und
> umgekehrt einige Millisekunden warten muss.

Wer die Umschaltung nicht inerhalb einer microsekunde hinkriegt, der hat 
was falsch gemacht. Wenn er den Fehler nicht finden kann, läßt das auch 
für zukünftige Projekte viele interessante Anfragen erwarten.

Just my 2 cents

Bitte 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
Noch kein Account? Hier anmelden.