Datenübertragung Port zu Port in Assembler

Moinsens ...

ich möchte die Datenübertragung optimieren bei meinem Bot, aber mir fehlt die zündende Idee. Vielleicht hat ja jemand von euch einen Geistesblitz oder mehr Background als ich und kann mir helfen. Ich hab mir alles eher aus den Fingern gesogen als das ich irgendwelchen fundierten Hintergrund hätte, darum meine Hoffnung :)

Der Sachverhalt ist wie folgt:

-Zwei Controller sind über 2 Ports verbunden. Es gibt einen Port für das Senden von 8 Bit und einen Port für das Empfangen von 8 Bit.
-Die Controller werden nicht immer mit der selben Geschwindigkeit betrieben (=kein gemeinsames Clock-signal)
-Es gibt keine weiteren Steuerleitungen ausser diesen Busleitungen
-die Leitungen sind arg lang, Störungen sind nicht nur nicht ausgeschlossen, sondern sehr wahrscheinlich ;-)

Derzeit splitte ich das zu übertragende Byte in zwei Nibbles auf und verfahre wie folgt:

- der sendende µC legt das zu übertragende höherwertige Nibble auf bit0-3 des "Send"-Busses zusammen mit einem Marker-Bit4, das es sich um das höherwertige Nibble handelt.
- der empfangende µC schickt das zurück, damit der Sender vergleichen kann, ob es richtig angekommen ist.
- der sendende µC erkennt den richtigen Empfang und schickt das Nibble erneut mit einem gesetzten Bit 5, um dem Empfänger anzuweisen, das er den Wert speichern soll.
- der Empfänger-µc speichert das höherwertige Nibble
- der Sender legt das niederwertige Nibble auf den Bus und löscht das Marker-Bit4
- der Empfangende µC schickt das zurück, damit der Sender vergleichen kann, ob es richtig angekommen ist.
- der sendende µC erkennt den richtigen Empfang und schickt das nibble erneut mit einem gesetzten bit5, um dem empfänger anzuweisen, das er den wert speichern soll.
- der empfänger-µc speichert das niederwertige nibble

- der empfänger setzt höher- und niederwertiges Nibble wieder zu einem byte zusammen

- der sender µC kommt zum nächsten byte ...


In Assembler ist das natürlich schon mit wenigen Schritten bewerkstelligt, trotzdem gehen mir viel zu viele Taktzyklen ins Land, bis z.B. 128 Bytes übertragen wurden.

Maximal liege ich momentan bei ca. 176KBytes pro Sekunde, was ich durch einfachere Routinen gerne noch minimieren würde. Es kommt mir nicht auf Listings an, sondern um die Prinzipien, nach denen es noch schneller gehen könnte.

Manchmal denkt man ja als Laie viel zu kompliziert :)

MeckPommER,

na, das mit dem Hin- und Herschicken des Daten-Nibbles ist ein bisschen umständlich und zeitaufwendig. Am Besten triffst Du die Vorkehrungen zur Fehlerunterdrückung auf der Hardware-Seite: Eine gute Abschirmung des Kabels und, falls erforderlich, zusätzlich ein "twisted pair"-Kabel, wobei von jedem Aderpaar je eins auf Masse liegt.

Auf der Softwareseite gibt's zwei Überlegungen: Durch das Hin- und Herschicken wird die effektive Übertragungsfrequenz halbiert (oder gar gedrittelt?). Da kannst Du die Taktfrequenz genauso gut von vornherein halbieren und dadurch einen besseren Störabstand erreichen. Zusätzlich kannst Du einfache Bitfehler auch mit einem Paritätsbit erkennen und mit einem Acknowledge-Signal an den Datensender melden. Der würde dann das Nibble nocheinmal senden.

Der Zilog Z80-Parallelport (Z80-PIO) ist ein ganz gutes Beispiel für eine asynchrone 8-Bit Schnittstelle. Dazu musst Du Dir von hier
http://www.zilog.com
das Datenblatt "UM0081.pdf" herunterladen. Ab Seite 193 wird die asynchrone Handshake-Steuerung der Z80-PIO beschrieben. Diese Methode verwendet auch 2 Steuerleitungen, so dass noch eine Leitung für die Parität (z.B. Bit #5) verfügbar wäre.

mare_crisium

Kann man zwei µC nicht einfach per I2C verbinden?

LuZ,

ja, über kurze Distanzen und bei geringer Einstreuung geht das sehr gut. MeckPommERs Problem ist die lange Leitung. Was hier im Forum über die Brauchbarkeit von I2C bzw. TWI bei grossen Leitungslängen berichtet wurde, variiert sehr stark. Bei mir läuft der TWI-Bus über Entfernungen von 6m in gering gestörter Umgebung ohne Probleme.

mare_crisium

Nun ja, lang ist relativ ... ich habe zwar nur max. 50-60 cm zu überbrücken, aber auf diesen Leitungen (der Trägerplatine) sitzen 14 Module mit µC.
Zusätzlich sind auf der PLatine noch Leitungen in der Nähe für die Stromversorgung der Elektronik und der Servos.

@mare_crisium:
vielen Dank erstmal für deine Informationen. Mein problem ist halt, das ich wirklich nur die 8 Leitungen habe und keine Clock oder Akn oder sonstwelche Handshake-Leitungen zur Verfügung habe.
Das mit dem Paritätsbit und dessen Prüfung scheint mir momentan nicht wirklich sinnvoll, denn auch das müßte an den Sender geschickt werden - dann kann ich auch gleich zur Kontrolle das ganze Nibble zurückschicken und vergleichen. Das erscheint mir auch einfacher, den ein Paritätsbit müßte ich ja erst noch sender- und empfängerseitig ermitteln.

Gruß MeckPommER

Hi

zur Hardware

wenn du anstatt spannungen einfach strom sendest bekommst du viel weniger störungen.

mach am sender einen treiber der bissl Strom kann zwischen ausgängen und leitung und am empfänger wid parallel zu den eingängen ( gegen masse )


dann muss ein echter Strom durch die Leitung fliesen, damit es eine Spannung am eingang des empfängers gibt.

vielleicht hilfts :-)

jo noch eine idee,

wenn du dein byte in 3 teile teils, kann der sender die 3 bit senden, der empfänger kann sie gleichzeitig zurückschicken und zur selben zeit kann der sender auf einer leitung das ergebnis bestätigen. jetzt bleibt dir noch eine leitung, damit kannst du zwar nicht zwischen 3 zuständen unterscheiden, aber du kannst den 3er Rythmus takten