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.
:
Bearbeitet durch User
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
Warum nicht Rs485 oder eine größere Menge SPI Uarts mit langen FiFos? mfg Michael
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
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.