Bei 9k6 kein Problem, aber bei 115K könnte das schwierig werden.
Ich habe entsprechende Anwendungen mit 2K4 auf nem PIC16C54 bei 2,4576 MHz laufen.
Mit nem ATmega bei 20MHz, kommt man auf einen Leistungsvorteil von 4 *
20/2,4576 = ca. 32...
Hm, könnte klappen. Man müsste mal sehen, ob das bei 4 Kanälen auch noch reicht.
Problem ist wieder die Synchronität zwischen den Kanälen.
Wenn ich das Signal auf eine INT-Leitung lege, auf das Startbit warte, dann einen Timer auf 1,5 Bitlängen programmiere und nach dem 1. Bit auf
1,0 Bitlängen, bräuchte ich 4 Timer und 4 INT-Eingänge um das zu realisieren. Senden mit 500 KBit per Softwareuart dürfte dann auch kein Problem mehr sein.
Eine ordentliche Hardware-UART macht da aber noch einiges mehr: jedes Bit mehrfach abfragen und verschiedene Errorarten erkennen, zudem verwaltet sie eigenständig ihren Ein- und Ausgangspuffer (in µCs meist je 1 Byte tief).
Eine gleichwertige Software-UART würde dazu einen sehr, sehr schnellen µC benötigen. Da hier Störungen bei der Übertragung nicht auszuschließen sind, ist diese Lösung eher nicht optimal.
115kBd sollten über die projektierte Leitung sicher machbar sein (sonst würde es ja heute nicht funktionieren).
5x 115kBd sollte für einen uC keine Probleme darstellen, auch wenn der eine oder andere UART per SW realisiert werden muss (9,2MHz bei 16facher Überabtastung des RS232 Signals und 5 Kanälen). Es müssen ja keine Handshake Signale ausgewertet werden. Leichter tut man sich aber mit einem uC mit mindestens 4 UARTS. Für die Kommunikation zwischen den beiden uC's hat man fast schon zu viele Freiheitsgrade ;) (RS232, RS422, CAN .......)
Protokoll: pro empfangenen RS232 Zeichen werden 2 Zeichen übertragen.
übertragene Zeichen enthält die Kanalnummer (2Bit) mit den restlichen
6Bit kann man z.B. Prüfzeichen und/oder HW-Handshake realisieren.
übertragene Zeichen ist dann das empfangene Zeichen.
Sollten die Zeichen mit voller Geschwindigkeit ankommen, dann muss jeder Kanal natürlich noch einen ausreichenden Puffer bekommen und man muss evtl. doch Handshake Signale einführen. Man kann natürlich auch die Datenübertragungsrate zwischen den uC's erhöhen. Aber man sollte ein System nie schneller machen als gefordert sonder lieber sicherer.
Baut man dann noch Autosensing für die Bauderaten und die Leitungsrichtung der Übertragung ein, dann kann auch in der Praxis nicht viel schiefgehen: zusammenstecken und funktioniert, ohne Parametrierung und Crosskabel (Eine Montage im Ausland, weil kein Crosskabel genommen wurde und durch Übersprechen es doch ab und zu funktioniert... Dafür kann man viel Hardware kaufen).
Für einzeln gesendete Bytes stimmt diese Rechnung. Auf jedem Kanal können aber auch ganze Datenpakete, bestehend aus über 100 Bytes mit jeweils einem Stopbit, gesendet werden. Damit steigt die Datenrate auf der gemeinsamen Übertragungsleitung um mindestens Faktor 4.
Sehe ich auch so. Ich mache sowas nur bei sehr kleinen Anwendungen, z.B. Schaltungen mit nem PIC16C54, die direkt an der seriellen Schnittstelle eines PCs angeschlossen sind, und wo die Stromversorgung des PICs aus den Handshake Leitungen gewonnen wird.
Ich mache das da auch deshalb, weil sonst noch Inverter benötigt würden, um über die COM-Schnittstelle mit dem PC zu kommunizieren.
Ging ja auch nur darum, ob das theoretisch möglich wäre, und da würde ich mal so behaupten, dass das mit einem ATmega128 vermutlich klappen würde, vermutlich sogar ohne INTs.
Der ATmega128 braucht pro einfachem Befehl 50ns bei 20 MHz Taktfrequenz wenn ich mich nicht irre.
Bei 115KBaud habe ich ca. 10us je Bit. Bei 4 Kanälen komme ich da auf
2,5 us je Bit, oder 50 einfache Befehle. Das müsste ausreichen, um das Bit zu erkennen, zu erkennen, ob das Byte fertig ist, und um das Ergebnis an die Senderoutine zu übermitteln.
Dann darf man natürlich nicht mit der zulässigen Durchlaufzeit rechnen und würde somit auf eine Datenrate von 920kBd kommen.
Also ein anderes Protokoll.
- Empfangene Zeichen in Zwischenbuffer.
- Zyklische Übertragung von 5 Zeichen zur Gegenstelle => 5x115kBd = 575kBd.
- 1. Zeichen zeigt an, in welchen der 4 folgenden Zeichen eine gültige Information übertragen wird (4 Bit). Die restlichen Bit können dann frei genutzt werden. Dieses Zeichen hat 2 Stoppbits als Sync (evtl. auch mehr zur sichereren Detektierung). Die freien Bits können auch als Zähler genutzt werden um Sync-Verlust zu erkennen.
- 2. bis 5. Zeichen ist die zu übertragende Information. Also 2. Zeichen für Kanal 1, 3. Zeichen für Kanal 2, ... usw. Bei leeren Zwischenbuffer für diesen Kanal undefiniert. Die Zeichen werden unmittelbar nacheinander ausgegeben (DMA), sodass nur
1 Stoppbit entsteht.
Alternativ:
- 1. Kanal wird mit 1 Stoppbit übertragen
- 2. Kanal wird mit 2 Stoppbit übertragen ... usw. Wir keine Information übertragen, dann wird als letztes Zeichen ein Dummy mit >=5 Stoppbit gesendet. Beispiel:
Kanal mit 1 SB, 3. Kanal mit 3 SB, 1. Kanal mit 1 SB, 4. Kanal mit 4 SB, Dummy mit >5 SB; Ende der Übertragung
Dekodiert wird über eine Zeitmessung der Interrupts für Inputbuffer full bzw. Timout >4 SB
Ich habe zwar bisher nur mit ARM7 von NXP gearbeitet, aber es sollte (so die Theorie ;) ) ja keine so großen Unterschiede geben. Bei ST gibt es z.B. den ST735 mit 4 UARTS. Wenn man einen Eingangs-UART softwaremäßig realisiert, ist eine Schnittstelle für die schnelle Übertragung frei. Der uC läuft zwar nur mit 36MHz, sollte aber genügen. Alternativ könnte man sich auch die CAN-Schnittstelle überlegen. Es kommt hier eben auf die Kabelqualität, Entfernung, Störungen usw. an. Könntest du dazu mal was schreiben? Wenn es ein 5m langes, ordentlich verlegtes CAT7 Kabel ist, dann machen wir uns schon viel zu viele Gedanken :)
Tja, 115kBaud sind für Software ohne Hardwareunterstützung schon ein Problem und dann das alles auch noch 4fach. Den MSP430 gibt es mit 2 SIO's und 3 bzw. 7 Kanal-Timern. Dann kann man mit einem Timer die andren Seriellen emulieren. Machen die mit dem Bootloader sogar schon vom Werk aus. Man hat dann bei jedem Bit einen Timerinterrupt abzuwickeln, also 10fach höhere INT-Last als bei der SIO-Variante. Wenn man 3mal abtastet dann eben 30x höher (wenn man es unbedingt braucht). Gibt nette Applicationnotes dazu , musste mal auszählen, wieviel Takte Rechenzeit er da für jedes Bit braucht, ob er die 3x
115kBaud dann noch schafft. Immerhin gibt es auch schon 16MHz Typen (ist eben auf low-power ausgelegt).
Ansonsten hat da doch in Hersteller den 8-Cell Controller im Programm. Wer war das noch? Microchip? Sinn ist, mit den 7 andren Prozessoren Peripherie nachzubilden. Imho hat man ja bei der reinen Softwarelösung und einem Prozessor das Problem, dass Interrupts da die Bit-Timings beeinflussen können (es sei denn man sperrt die Interrupts; hat dann aber nur sehr wenige Zeit nach dem Byte für andre Sachen); bzw. macht das über einen Timerinterrupt und ne komplizierte Statemaschine, naja imho kann man 4 serielle Schnittstellen, die auch noch asynchron zueinander sind, nicht sinnvoll rein sequentiell fast ohne Hardwareunterstützung gleichzeitig abwickeln.
Leider geht es sehr robust zu: Kabellängen >> 100 m, die Kabel werden schon mal parallel zu Motor- und Anlagenversorgungsleitungen (mit Strömen bis 100 A und schlechter Netzqualität) verlegt, auch können gerichtete Funkstrecken die Kabel treffen, an den Erdungspunkten der Kabelenden sind auch schon mal Differenzspannungen von bis zu 100 V zu messen, starke mechanische Belastungen, Nässe und Temperaturen von kleiner -20 bis größer +60 Grad kommen vor.
Die Gesamtanlage (mit vielleicht über 50 Antrieben und immer ein Unikat) muß oft nach drei Tagen Aufbau- und Inbetriebnahmezeit fehlerfrei funktionieren, wobei eine Verschiebung des Fertigstellungstermins nicht möglich ist.
Hierbei lohnt es sich schon nachzudenken, wie Daten fehlerfrei übertragen werden können und zudem der Handhabungsaufwand möglichst klein bleibt.
bei diesen Bedingungen läge man mit einer Glasfaserübertragungsstrecke mehr auf der sicheren Seite, die sollte die elektromagnetischen Störungen abkönnen.
Man sollte dann vieleicht mal überlegen, etwas grundsätzlich anderes zu machen. Was für Daten liefern denn die seriellen Schnittstellen?
Eine andere Überlegung wäre noch, vor Ort, d.h. da wo die 4 Schnittstellen auflaufen einen PC mit 4 COM-Ports aufzustellen, die Daten einzulesen und über Netzwerktechnik, d.h. CAT-6 Kabel, oder handelsübliche LWL Technik zu verbinden. Durchlaufzeiten von
Die Kabel sind eher unkritisch, solange die Datenleitungen verdrillt und abgeschirmt sind und die Kabeldaten den Anforderungen entsprechen.
Einen wesentlichen Beitrag zur Stabilität leisten die Treiber. Sie sollten schon nach allen Regeln der Kunst aufgebaut sein. RS422/RS485-Treiber auf PC-Karten sind nicht unbedingt das Optimum.
Alles was aus dem Bereich der Bürotechnik kommt ist eher ungeeignet. Wir setzen Industrie-PC-Technik möglichst nur an geschützten Orten ein, trotzdem ist der Anteil an produziertem Schrott in diesem Bereich gegenüber der echten feldtauglichen Elektronik doch sehr groß.
Wird gemacht, es geht hier ausschließlich um den unbedingt notwendigen Datenaustausch in dem System.
Wenn ich wüsste was das ist, würde ich vieleicht zustimmen ;-)
Aber mein Posting sollte eher in folgende Richtung gehen:
Das, was der OP vorhat ist eher ungewöhnlich. Wenn es das nicht wäre, würde man das fertig kaufen können. Da man das nicht kaufen kann, braucht das vermutlich keiner. Wenn es sonst keiner braucht, warum braucht es der OP?
Wobei ich nicht der Meinung bin, dass man sowas nicht bauen kann, aber: macht das überhaupt Sinn?
Vieleicht geht er einfach an das Problem falsch heran, oder an die vorgelagerte Aufgabe.
Warum überhaupt 4 serielle Schnittstellen? Warum 115 KBaud Was hängt da dran? Warum die Vorgabe Durchlaufzeit durch das System < 1 ms, oder müssen nur die Laufzeitunterschiede zwischen den 4 Kanälen < 1 ms sein?
Wenn es um Industrietechnik mit großen Antrieben und viel Strom geht, erscheinen mir solche Anforderungen eher ungewöhnlich zu sein.
Deshalb könnte man dem OP vieleicht bessere Tips geben, wenn man etwas mehr über die Aufgabenstellung wüßte.
Weil der OP Dinge für Anlagen konzipiert, die in Deutschland (ggf. auch weltweit) niemand sonst unter den gegebenen Randbedingungen sicher realisieren kann. Diese Anlagen lassen sich nicht ausschließlich aus Kaufkomponenten aufbauen.
Anlagen mit über 50 Antrieb, die alle exakt positioniert und geregelt werden können und dabei nicht zu vernachlässigende Lasten bewältigen müssen, beinhalten durchaus gewisse technische Anforderungen. Auch dann, wenn sie z.B. innerhalb von drei Tagen (als Unikat) vor Ort aufgebaut werden und fehlerfrei mit vorgegebenen Bewegungsabläufen arbeiten müssen.
Dann kommt es aber möglicherweise nur auf die relativen Laufzeiten zwischen den Signalen und nicht die absolute Zeitverschiebung an. Das würde das ganze erheblich vereinfachen.
Diese Multiplexgeschichte hat einfach den Nachteil, dass man etwas selber konstruieren muss, das in der Praxis nicht ganz so trivial ist, wie es sich zunächst anhören mag.
Da spielen dann die Übertragungsleitungen und Störungen noch eine Rolle und vieleicht noch Dinge, an die wir hier nicht gedacht haben.
Und bevor man da was entwickelt was dann wirklich einwandfrei funktioniert, kann man sicher einige Kiloeuro für Standard- bzw. Industrietechnik ausgeben.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.