Hey liebes Forum,
wollte mal nachfragen, wie man am Besten mit einem uC Daten parallel &
seriell einliest. Sprich, wenn ich jetzt eine einfache Datenübertragung
von uC 1 nach uC 2 realisieren möchte.
Also Als Beispiel, ich sende von Port A von uC 1 zu uC 2.
Ich kann ja jetzt nicht einfach alle Bytes nacheinander auf die Leitung
geben. Wie stellt der Sender den sicher, das uC 2 das Byte gelesen hat?
Mir wäre dazu sowas wie eine ACK Leitung eingefallen. Quasi bestätigt
der Empfänger jedes mal wenn er ein Byte bekommen hat und erst dann wird
das nächste gesendet. Habe allerdings noch nie so eine ACK - Leitung bei
anderen Parallelbussen gesehen
Das nächste wäre der serielle Empfang. wie wird der am besten
realisiert? Wenn ich jetzt nich gerade 500 UARTS im IC verbaut habe?
Sprich ich will einfach über eine Sendeleitung 2 Byte seriell
übertragen. Quasi auf der selben Platine von Chip a zu Chip b....
Da hab ich wieder den Punkt ich kann ja nicht einfach alle Bits
nacheinander auf die Leitung geben. Ich könnte zwar eine zweite Leitung
nehmen um einen Takt vorzugeben, aber da hab ich dann wieder das
Problem, das der Sender ja nicht wissen kann, ob der Empfänger überhaupt
so schnell reagieren könnte, und mit dem vorgegebenen Takt mithalten
konnte....
Ich mein muss man den jedes mal den UART nutzen für die Übertragung von
Daten größer 1 Bit?... Das klingt für mich wie mit Kannonenkugeln auf
Spatzen schießen....
Also erst mal durchatmen und überlegen was Du willst.
Wenn Du parallel Daten verschicken willst, schau Dir doch mal an, was
Dein Drucker macht. Der hat ja, in aller Regel, auch eine parallele
Schnittstelle. Bei Epson Druckern (zumindest bei meinem) ist die
Schnittstelle sogar sehr schön im Handbuch beschrieben.
Hier ist ein brauchbares Bild mit der Erklärung:
http://www.databooks.com/tecref/parport.gif
Grob gesagt hast Du 2 Leitungen, eine Ack und eine Strobe. Der Sender
legt die Daten auf die Leitungen, gibt dann per Strobe einen Puls raus,
und wenn der Empfänger die Daten empfangen hat, bestätigt er sie mit
einem Puls auf Ack.
Bei seriellen Leitungen brauchst Du, wie schon bemerkt, eine Möglichkeit
den Takt zu übermitteln. Die UART macht das relativ einfach, sie
synchronisiert sich immer am Start Bit. Wenn der UART nichts überträgt
hat er eine 1 am Ausgang. Überträgt er was so kommt zuerst eine 0
(Startbit) dann die Datenbits (z.Bsp. 8 Bits), dann 1-2 Stoppbits die 0
sein müssen. Da die Synchronisation nur am Anfang des Datenwortes
erfolgt müssen beide UARTS mit möglichst gleichen Takten arbeiten.
Sprich mit einem Quarz oder einem Resonator, der RC-Oszillator reicht
nicht zuverlässig aus.
Eine simplere Alternative ist der SPI. Der überträgt den Takt getrennt.
Willst Du mehrere Chips miteinander sprechen lassen brauchst Du 2 Dinge,
die Arbitrierung und die Adressierung.
Die Arbitrierung bestimmt, wer denn im Moment die Leitung belegen kann.
Wenn Du beispielsweise einen Master hat, der die anderen Teile
nacheinander abfragt, dann ich das ganz einfach. Der Master spricht dann
immer dann, wenn er nicht gerade auf eine Antwort wartet. Und die Slaves
sprechen nur dann, wenn sie gefragt wurden. Das kann aber auch
schwieriger sein.
Die Adressierung besteht aus zusätzlichen Daten, die angeben, welches
Teil gemeint ist. Das kann mit zusätzlichen Adressleitungen bestehen,
oder einfach das erste Byte einer Übertragung sein.
Willst Du viele Teile mit mäßiger Geschwindigkeit vernetzen empfiehlt
sich ein Bussystem. Da gibts zum Beispiel:
I2C für die Vernetzung innerhalb von kleinen Geräten, ist in vielen µCs
schon drin
CAN für die Vernetzung innerhalb von etwas größeren Geräten, ist aber
nicht in jedem µC mit drin, und braucht externe Hardware
RS-485 geht über den UART, und ist auch für größere Netze geeignet, Du
musst aber Arbitrierung und Adressierung selber machen
Ethernet skaliert bis zu vielen tausend Stationen und vielen Gigabits,
zusätzliche Hardware notwendig, aber sehr zuverlässig
Christian Berger schrieb:> Wenn Du parallel Daten verschicken willst, schau Dir doch mal an, was> Dein Drucker macht. Der hat ja, in aller Regel, auch eine parallele> Schnittstelle.
Wann war das denn - muss wohl kurz vor Ende des letzten Jahrtausends
gewesen sein. USB ist seriell.
Sebi2020 schrieb:> Er hat ja auch nicht von USB gesprochen, sondern von der> Parallelschnittstelle!
EDIT:
Ich möchte eine Duplex Punkt zu Punkt verbinden, wobei, der, der gerade
Sendet dann natürlich den Takt vor gibt... nur was ich nicht verstehe an
der seriellen Übertragung. Es gibt meistens keine Mechanismen, um
festzustellen, ob das Byte auch vom Empfänger gelesen wurde... Es wird
einfach drauf los gesendet, egal ob Empfangen oder nicht. Wenn nicht
Empfangen ist dem Sender das auch egal... zumindest hab ich bei SPI noch
kein Statuskanal gefunden, der dem Master sagt, super, ich hab das Byte
empfangen!
Was du meinst ist eine Schicht höher.
Nennt sich Protokoll.
Sowas "bastelt" man sich selber.
Z.B.: START|LÄNGE|DATEN...|CRC|STOPP
Der Empfänger kann dann z.B. die CRC als Quittung zurücksenden damit der
Sender weiß, dass der Empfänger etwas empfangen hat.
Werner schrieb:> Wann war das denn - muss wohl kurz vor Ende des letzten Jahrtausends> gewesen sein. USB ist seriell.
Naja, Drucker die man nicht nach einem Jahr weg wirft oder ohne
funktionsfähigen Treiber wo stehen lässt sind entweder alte
Paralleldrucker, oder bei neuen Druckern Netzwerkdrucker. USB ist toll
innerhalb eines Gerätes, aber zwischen unterschiedlichen Geräten ist es
einfach zu unzuverlässig, da es nicht potentialfrei ist.
Die Applikationen auf beiden kommunizierenden Controllern muessen
natuerlich so geschrieben sein, dass hinreichend zeit fuer das Senden
und Empfangen vorhanden ist. Und da ist in der Regel ein UART besser als
SPI, denn es hat je ein Byte mehr Buffer im Sende-, wie im Empfangsfall.
SPI ist auch eher geeignet um mit passiven Komponenten, die die SPI
Hardware an Board haben zu kommunizieren. zB ADC, DAC, ...
Bastler schrieb:> Was du meinst ist eine Schicht höher.> Nennt sich Protokoll.>> Sowas "bastelt" man sich selber.>> Z.B.: START|LÄNGE|DATEN...|CRC|STOPP>> Der Empfänger kann dann z.B. die CRC als Quittung zurücksenden damit der> Sender weiß, dass der Empfänger etwas empfangen hat.
Ja, aber ich kenne kein Protkoll was mit einem Byte auskommt... Und
eigentlich solls ja die Hardware schon hergeben. Warum das in Hardware
so kompliziert realisert ist, versteh ich nicht. Wenn ich es irgendwie
umsetzen würde, würde ich für ne Duplex-Verbindung einfach sagen, der
Empfänger gibt jeweils den Sendetakt vor, dann kann auch nich viel
schiefgehn.
Bastler schrieb:> Was du meinst ist eine Schicht höher.> Nennt sich Protokoll.>> Sowas "bastelt" man sich selber.>> Z.B.: START|LÄNGE|DATEN...|CRC|STOPP>> Der Empfänger kann dann z.B. die CRC als Quittung zurücksenden damit der> Sender weiß, dass der Empfänger etwas empfangen hat.
EDIT: Ein reiner Empfänger (Receiver) kann nichts Senden, der empfängt
nur!
Fabian O. schrieb:> Schau Dir mal I2C bzw. TWI an, das dürfte Deine Anforderungen erfüllen> und ist bei den meisten Mikrocontrollern in Hardware integriert.
Naja, der knackpunkt den ich immer nich verstehe ist. Was macht ein
Receiver wenn die CPU nicht hinterherkommt, weil z.B. zuviel
Programmcode drinne steckt?
Ich meine, ein FIFO Buffer, was bringt der z.B.? wenn ich hinter einem
Ausgangsregister noch mal 8 FlipFlops Schalte, kommt das Signal um 1
Takt verzögert am IC an. Aber wenn er dann das erste Signal gelesen hat,
und dann länger als erwartet braucht, dann hilft der Buffer auch nicht
mehr, dann gehen die Daten trotztdem verloren. Schaltet man mehrere
FlipFlops hintereinander, verzögert sich das eben um die Anzahl um
Takte, aber sobald das erste Byte am Eingang erscheint, ist nach hinten
immer nur 1 Byte Platz.
Also bräuchte man quasi einen Speicher der von hinten nach vorne
aufgefüllt wird, und quasi nach hinten Platz lässt. Frag mich gerade
nur, wie das entsprechend in Hardwäre gelöst ist. Nen einfaches
Shift-Register kanns nicht sein. quasi muss der Receiver von vorn nach
hinten auffüllen, und jedes mal wenn die CPU sagt, hey ich hab gelesen,
dann wird alles eins weiter nach vorne verschoben und hinten ist wie
mehr Platz für mehr daten.
Bei I2C kann der Empfänger die Taktleitung auf low halten, bis er das
Byte verarbeitet hat. Der Sender sendet erst wieder, wenn der Empfänger
die Taktleitung "losgelassen" hat. Damit braucht man keine großartigen
Pufferlösungen.
Ganz allgemein ist ein Puffer aber nur dafür da, dass er (kurze) Bursts
aufnehmen kann, also eine gewisse Anzahl an Bytes, die schnell
hintereinander gesendet werden. Danach muss dem Controller aber immer
genug Zeit gelassen werden, den Puffer abzuarbeiten. Wenn die Daten
ununterbrochen mit zu hoher Geschwindigkeit kommen, hilft auch der
größte Puffer nichts.
In Software nimmt man dafür übrigens gerne Ringpuffer, damit man die
Daten nicht ständig rumkopieren muss.
Fabian O. schrieb:> Bei I2C kann der Empfänger die Taktleitung auf low halten, bis er das> Byte verarbeitet hat. Der Sender sendet erst wieder, wenn der Empfänger> die Taktleitung "losgelassen" hat. Damit braucht man keine großartigen> Pufferlösungen.>> Ganz allgemein ist ein Puffer aber nur dafür da, dass er (kurze) Bursts> aufnehmen kann, also eine gewisse Anzahl an Bytes, die schnell> hintereinander gesendet werden. Danach muss dem Controller aber immer> genug Zeit gelassen werden, den Puffer abzuarbeiten. Wenn die Daten> ununterbrochen mit zu hoher Geschwindigkeit kommen, hilft auch der> größte Puffer nichts.>> In Software nimmt man dafür übrigens gerne Ringpuffer, damit man die> Daten nicht ständig rumkopieren muss.
Naja, ich Frage mich halt, wies beim UART oder bei SPI ist. Bei der
Parallelschnittstelle sagen sich beide Seiten bescheid, ob sie was
erhalten haben oder zu senden haben. Beim UART sendet der Transmitter
einfach (sofern die Steuersignale nicht verwendet werden, und das hab
ich jetzt z.B. beim AVR-GCC Tut gesehen.) drauf los, auf gut Glück ob
der Empfänger das überhaupt verarbeiten kann. Ohne Clear to Send Signal
ist dem Transmitter das egal... frag mich wie so eine Kommunikation
überhaupt fehlerfrei funktionieren kann, da die Schaltung stark davon
abhängig ist, alles in einem Taktzyklus (Baudratentakt) abzuarbeiten.
Wenn ers nicht schafft geht das Byte einfach verloren...
Sebi2020 schrieb:> Naja, ich Frage mich halt, wies beim UART oder bei SPI ist
Bei SPI gibt es 4 verschiedene Optionen.
Basis Version ist die 3 Draht Variante.
1. Clock
2. MasterOut-SlaveIn (MOSI)
3. SlaveOut-MasterIn (MISO odr SOMI)
Dann gibt es dazu 3 mögliche Erweiterungen.
4 Draht Versionen:
1. CS Chipselsect oder auch Slave select gennant. Hiermit signalisiert
der Master welcher Slave jetzt angesprochen ist.
2. Busy oder Enable , Hiermit sagt der Slave dem Master das er
empfangsbereit ist.
5 Draht Version
3. CS und Busy werden beide genutzt
Uart:
Hier gint es auch zusätzliche Signale parallel zu Rx und Tx.
zb DTR, RTS,..... da weiß ich aber jetzt nicht alle und ihrer einzelnen
Bedeutungen im detail.
Aber auch diese Signale dienen der Synchronisation.
>der Empfänger das überhaupt verarbeiten kann. Ohne Clear to Send Signal>ist dem Transmitter das egal... frag mich wie so eine Kommunikation>überhaupt fehlerfrei funktionieren kann, da die Schaltung stark davon>abhängig ist, alles in einem Taktzyklus (Baudratentakt) abzuarbeiten.>Wenn ers nicht schafft geht das Byte einfach verloren...
Lies doch mal im Wiki nach, oder in einem von diesen altmodischen
Büchern, oder in Wikipedia.
Diese einfachen Fragen, die sind doch schon tausendmal beantwortet
worden, alles veröffentlicht und leicht im Netz zu finden. Nur lesen
mußt Du halt selbst.
