Forum: Mikrocontroller und Digitale Elektronik UART multiplexen / mit RS-FF Interrupt erzeugen?


von Danie (Gast)


Lesenswert?

Hallo,

ich hab gerade ein Projekt, wo ich sehr viele seriele Module steuern 
will.
Dazu würde ich gern 2x 1:8 Multiplexer verwenden.

Es gibt Module, die ich explizit anspreche, wenn ich was von ihnen will.
Auf der anderen Seite gibt es Module, die mir "recht zuügig" mitteilen 
sollen, wenn etwas passiert ist.

Ich hab mir jetzt gedacht ein FlipFlop/Schmitt-Trigger zu nutzen und das 
an die TX der Module zu hängen, die ich "überwachen" will.
Kommt das Startbit, wird das FF gesetzt. Damit löse ich einen Interrupt 
aus, die Muxxer "Weichen" werden richtig gestellt und dann lese ich 
meine Daten aus.

Ich bin mir nur nicht sicher, ob das FF, der Mux usw. schnell genug 
sind, damit mir keine Bits verloren gehen?
Irgendwie glaub ich da nicht so recht dran. Bei Baudrate 115200 bleibt 
da nicht viel Zeit für alles...

Was gibt es sonst noch für möglichkeiten? Irgendwie Buffer IC´s, die 
alles Empfangen und mit einem IO pin signalisieren, dass neue Daten 
vorhanden sind?
Auslesen kann ich dann, wann ich will?


Vielen Dank!
Gruß Daniel

von Gerd E. (robberknight)


Lesenswert?

Danie schrieb:
> Ich bin mir nur nicht sicher, ob das FF, der Mux usw. schnell genug
> sind, damit mir keine Bits verloren gehen?

vermutlich gehen Bits verloren.

> Was gibt es sonst noch für möglichkeiten? Irgendwie Buffer IC´s, die
> alles Empfangen und mit einem IO pin signalisieren, dass neue Daten
> vorhanden sind?
> Auslesen kann ich dann, wann ich will?

Warum nicht so:

Das Modul, welches Dir was eilig mitteilen will, zieht sein TX-Pin 
dauerhaft auf low. Das kannst Du z.B. machen in dem Du in dem Modul das 
TX nicht mehr der UART-Hardware zuweist, sondern es als GPIO ansteuerst. 
Oder mit nem externen Transistor.

Das Modul wartet, bis Du ihm auf seinem RX Daten sendest, z.B. eine 
Anfrage den Grund des Interrupts mitzuteilen. Jetzt weiß das Modul daß 
der Interrupt erhört wurde und es kann das TX wieder loslassen, auf UART 
umschalten und dann seine Daten senden.

So brauchst Du auch kein Flipflop, sondern kannst einfach auf das 
low-signal reagieren.

von Joe F. (easylife)


Lesenswert?

Können deine Module Hardwarehandshaking (cts/rts)?

ansonsten: deine module könnten als "interrupt" erstmal ein dummy-byte 
senden und dann warten bis der host mit ihnen kommuniziert. das 
verhindert auch race conditions.

: Bearbeitet durch User
von Georg (Gast)


Lesenswert?

Danie schrieb:
> Ich bin mir nur nicht sicher, ob das FF, der Mux usw. schnell genug
> sind, damit mir keine Bits verloren gehen?

Das ist längst nicht das ganze Problem - was machst du, wenn mehr als 1 
Modul zum gleichen Zeitpunkt was sagen will? Die Antwort 
"unwahrscheinlich" gilt nicht, das wird auch i.d.R. durch die Realität 
schnell widerlegt.

Georg

von Michael_ohl (Gast)


Lesenswert?

Warum nicht Rs485 oder eine größere Menge SPI Uarts mit langen FiFos?

mfg
Michael

von Wolfgang (Gast)


Lesenswert?

Danie schrieb:
> Ich bin mir nur nicht sicher, ob das FF, der Mux usw. schnell genug
> sind, damit mir keine Bits verloren gehen?

Das wäre allerdings extrem.

Erstmal muss es so weit nicht kommen. Die Flanke von deinem Startbit 
synchronisiert die Abtastung der folgenden Bits. Durch eine Verzögerung 
verschlechterst du also zunächst die Abtastung der Bits. Erst bei 
kritischen Übertragungsbedingungen bekommst du das mit.

von Falk B. (falk)


Lesenswert?

@Danie (Gast)

>ich hab gerade ein Projekt, wo ich sehr viele seriele Module steuern
>will.

Warum? Kann man das nicht besser als Bus verschalten?

>Dazu würde ich gern 2x 1:8 Multiplexer verwenden.

Das funktioniert nur dann gescheit, wenn die Module immer nur auf 
Nachfrage antworten. Sie dürfen nicht von allein senden.

>Es gibt Module, die ich explizit anspreche, wenn ich was von ihnen will.

Gut.

>Auf der anderen Seite gibt es Module, die mir "recht zuügig" mitteilen
>sollen, wenn etwas passiert ist.

Dann muss man sie halt oft genug abfragen, auf neudeutsch "pollen".

>Ich hab mir jetzt gedacht ein FlipFlop/Schmitt-Trigger zu nutzen und das
>an die TX der Module zu hängen, die ich "überwachen" will.
>Kommt das Startbit, wird das FF gesetzt. Damit löse ich einen Interrupt
>aus, die Muxxer "Weichen" werden richtig gestellt und dann lese ich
>meine Daten aus.

Keine wirklich brauchbare Lösung.

>Ich bin mir nur nicht sicher, ob das FF, der Mux usw. schnell genug
>sind, damit mir keine Bits verloren gehen?

Die FFs und MUXe schon, aber dein uC muss ja auch reagieren. Und was 
machst du, wenn mehrere Module gleichzeitig senden wollen? Vergiss es.

>Irgendwie glaub ich da nicht so recht dran. Bei Baudrate 115200 bleibt
>da nicht viel Zeit für alles...

Das ist Zeitlupe für Digitaltechnik.

>Was gibt es sonst noch für möglichkeiten? Irgendwie Buffer IC´s, die
>alles Empfangen und mit einem IO pin signalisieren, dass neue Daten
>vorhanden sind?

Es gibt Mehrfach-UARTs mit 4 oder 8 Kanälen.

>Auslesen kann ich dann, wann ich will?

Nur solange der Zwischenpuffer nicht überläuft.

Frag die Module regelmäßig ab und gut. Die dürfen nur auf Nachfrage 
antworten. Alles andere macht man besser mit einem passenden Bus ala 
CAN, dort können die Module auch eigenständig senden.

von Theor (Gast)


Lesenswert?

@ Danie

Unter ganz bestimmten Bedingungen geht das. Falk (u.A.) hat das ja schon 
beantwortet. Aber ich denke in zwei Punkten zu spezifisch.

Falls es sicher ist, das niemals zwei Geräte gleichzeitig senden, so 
gehen keine Daten verloren.

Dennoch spielt die Interrupt-Latenz eine Rolle.
Wenn Du dem Kommunikationsinterrupt die höchste Priorität geben kannst, 
wird es funktionieren.

Die Umschaltgeschwindigkeit der Multiplexer könnte man auch steigern, in 
dem man das in Hardware erledigt. In etwa so, dass der Multiplexer von 
den Flip-Flops der Datenleitungen gesteuert wird. Der Prozessor brächte 
dann dafür keine Zeit mehr. Allerdings wäre, je nach Multiplexer noch 
ein Decoder notwendig, der aus den n Eingangssignalen eine binär kodiert 
Zahl von 0 bis (n-1) macht.

An sich aber, wirst Du solche Lösungen so gut wie nicht in freier 
Wildbahn sehen. Das sind eher Sonderfälle, die aus nicht-technischen 
Gründen so gelöst werden.

Der erste Schritt bei so einer Problemstellung ist, meiner Meinung nach, 
immer zusammenzustellen,

1. ob sie "a-kausal" senden (d.h. unabhängig von einem äusseren 
Ereignis, einem Ereignis, dass der Hauptprozessor nicht erkennen kann)
1.b. oder "kausal", d.h. in irgendeiner Weise bestimmbar, dass er 
gleich senden wird.
2. Wie lange die Aussendungen dauern (minimal, maximal). Das hängt auch 
von der Datenrate ab.
3. Diese Ergebnisse für den schlechtesten Fall (minimaler Abstand, 
zeitliche Überschneidung) zusammenzustellen.

Wenn aber danach nicht ausgeschlossen werden kann, dass zwei Geräte 
gleichzeitig senden, und keine Daten verlorengehen können, dann geht die 
Multiplexer-Lösung in keinem Fall; durch keinen Schaltungstrick wie auch 
immer.

-------------------

Dennoch ist Hopfen und Malz noch nicht verloren.

Eine gängige Lösung für solche Fälle (falls die sendenden Geräte nicht 
verändert werden können), wären Puffer. Kleine uCs (oder komplexe 
Schaltungen) welche die Daten zunächst zwischenspeichern und nach 
Abfrage durch den Hauptprozessor weitergeben.

Aber auch dafür sind die obigen Auswertungen wichtig. Es muss nämlich 
dann gegeben sein, dass die Datenmenge der Puffer nicht überschritten 
werden kann (das hängt vor allem davon ab, wie häufig die Daten wieder 
abgeholt werden können) und vor allem das die Gesamt-Datenrate aller 
sekundären Prozessoren weder momentan noch auf lange Sicht (wie man das 
macht, müsste man gesondert  besprechen) die Datenrate des 
Hauptprozessors nicht überschreitet.

In der Praxis ist die gesamte Empfangsdatenrate des Hauptprozessors 
(also einschliesslich der Zeit für die sonstigen Aufgaben und der 
Verarbeitung der Daten) oft nicht genau zu beziffern. Daher wird man mit 
Schätzungen und Sicherheitsfaktoren arbeiten.


Für einen Anfänger (falls Du einer bist) ist das, wegen der Menge der zu 
berücksichtigenden Fakten, eher ein schwieriges Unterfangen, wenn auch 
nicht unmöglich. Man muss ihm daher eher abraten. Aber machbar wäre es.

von Danie (Gast)


Lesenswert?

Hallo,

vielen Dank für die vielen Antworten.
Im Grunde hab ich mehrere seriele Sensoren/Module, die ich aber an einem 
µC betreiben möchte. Ich habe 3 Hardware UARTS zur Verfügung. Max. 1 
zusätzlichen Software Serial.

Das Problem, dass hiervon mehrere Module von sich aus senden können, 
ohne das der Hauptprozessor erahnen kann, wann das in etwas passiert.

Ein Touchcontroller (-> taktile Rückmeldung).
Diesen muss ich eigentlich immer auswerten.

- Ein Modul sitzt weiter weg, dieses überwacht eine Spannungsversorgung.
  (Spannungs, Strommessung usw...)
-> das würde auf Anforderung reichen. Ich dachte nur, wenn irgendein 
Fehlerfall auftritt, wäre es schön, sofort darauf zu reagieren.

- Das nächste Modul ist ähnlich aufgebaut, kann aber zusätzlich noch 
Sachen "ausführen" -> auch hier dachte ich, es wäre schön, "sofort" auf 
gewisse Bedingungen zu reagieren.

- Ein Serial Fingerprint Sensor Modul. Muss zu jeder Zeit senden können.

- Eine Verbindung zum Computer
(Einstellungen vornehmen, Messwerte von den Modulen holen usw...)
-> Wäre auch switchbar. Wichtig ist aber, dass die Verbindung PC ->
FingerPrint Sensor möglich ist. Hier wird nämlich das Anlernen und
Verwalten der Finger-Abdrücke erledigt. Der µC später kümmert sich nur 
um
das verifizieren.

- Und zu guter letzt: Ein Bluetooth Modul (Dachte an RN52). 
Einstellungen sollen auch über Bluetooth machbar sein.


- Was noch schön wäre: GPS und GSM. -> Bei GPS dauert es teilweise sehr 
lang, bis ein gültiger String da ist. Außerdem "hauen" die meisten 
Module den NMEA String einfach ohne Aufforderung per UART raus...
GSM sollte dann wieder kein Problem sein.


Ich dachte mir schon: Statt dem Mux einen Atmega328 mit Software-Serial 
zu nutzen. Leider kann man da auch immer nur auf einen der Ports 
"lauschen".
Wenn ich das nacheinander mach, weiß ich nicht, ob mir wieder was durch 
die Lappen gehen kann?


Gruß Daniel

von Joe F. (easylife)


Lesenswert?

Die Frage, ob die Module Hardware-Handshaking können ist noch offen.
Das wäre die einfachste Möglichkeit sie am Quatschen zu hindern, ohne 
dass Daten verloren gehen.

Das Modul setzt RTS (request to send), daraufhin setzt du die MUX und 
signalisierst dem Modul über CTS (clear to send), dass du jetzt bereit 
bist.
Wenn die Daten übertragen sind, deassertest du CTS wieder, und kannst 
dich um die anderen Module kümmern.
Simpel und effektiv.

von Danie (Gast)


Lesenswert?

Hallo,

leider hat keines dieser Module Handshake.
Nichtmal ein IO, der sagt, "hey ich will was senden. Hör zu!"...

Ich weiß nicht, wie schnell man sowas pollen kann. Wie oft man da bei 
jedem Gerät irgendwelche Daten empfangen kann.
Wenn ich aber am PC bin sollen die Spannungs und Stromwerte schon recht 
flott kommen, ohne das ich beim aktualisieren der GUI einschlafe :)

Gerade hier ist die Gefahr. Ich frage mit meinem PC die Module an und 
das immer wieder. Dann spring ich immer in die Routine, die den Mux 
stellt und verpasse meine anderen sachen vermutlich.

Fest angebunden müssten eigentlich nur der Fingerprint Sensor, das 
Bluetooth Modul, der Touchcontroller und evtl. der PC sein...
Dafür hab ich aber leider 2 UARTS zu wenig.

von Danie (Gast)


Lesenswert?

Hallo,

hab es jetzt so gemacht:
https://www.sparkfun.com/products/retired/9981

Das IC gibt es auch als TSSOP16.
Die Module, die nur nach Anfrage etwas senden, werden über den Muxer 
gemacht.
Die Module, die von sich aus Senden können, werden über das "SC16IS750" 
IC angesprochen.

Läuft 1a!

Gruß Danie

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.