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
Schätze mal, dass SPI die beste Lösung ist. Die ist schnell, bidirektional und einfach zu verbinden.
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.
Er hat ja auch nicht von USB gesprochen, sondern von der Parallelschnittstelle!
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!
Schau Dir mal I2C bzw. TWI an, das dürfte Deine Anforderungen erfüllen und ist bei den meisten Mikrocontrollern in Hardware integriert.
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.
Thread beobachten
Seitenaufteilung abschalten
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.