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
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.
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.
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
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.
@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.
@ 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.
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
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.
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.
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
