www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Kommunikation zweier µC über USB


Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

bei einem bestehenden Projekt in dem wir einen µController von Renesas 
(H8SX/1668P) einsetzten, muss ich eine größere Menge Daten zu einen 
zweiten µController übertragen.

Hierfür möchte ich die im H8SX/1668 vorhandenen USB Schnittstelle nutzen 
(keine OTG Schnittstelle).
Leider hat der zweite µController keine USB Schnittstelle.
Da ich in einem anderen Projekt einen Parallel auf USB Umsetzter FT245BL 
von FTDI im Einsatz habe, war mein Gedanke ob ich diesen nutzen kann um 
die zwei Controller zu koppeln.

Hat hiermit schon jemand Erfahrungen gemacht?

Danke
Michael

Autor: Gasst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat der 2. Controller denn USART oder IIC Schnitstellen?
Das wäre deutlich einfacher als USB. Oder gehe gleich über die parallele 
Schnittstelle.

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,

Michael wrote:

> Hierfür möchte ich die im H8SX/1668 vorhandenen USB Schnittstelle nutzen
> (keine OTG Schnittstelle).

dir ist scheinbar nicht klar, was USB ist und was seine Designziele 
waren:

http://de.wikipedia.org/wiki/USB

Der Witz ist gerade, dass möglichst die ganze Intelligenz beim Master 
sein soll.

Wer soll bei deinen Mikrocontrollern der Master sein?

Da wirst du eine Menge Spaß beim Implementieren haben...

Autor: Matrix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du brauchst einen Host. Dies muss entweder der H8SX/1668P machen oder 
der andere Controller. Da der andere Controller kein USB hat und du dies 
mit einem Umsetzer machen würdest benötigt der H8SX/1668P also eine 
Hostfähige USB Schnittstelle. Wenn er das hat ist es möglich ansonnsten 
nicht (ohne zusäztliche Hardware) möglich.

Am einfachsten fährst du vermutlich über CAN (falls ein Feldbus benötigt 
wird) oder dann mit I2C, SPI. Oder wie schon jemand erwähnt hat die 
Bytes Parallel übertragen (Programmiertechnisch vermutlich am 
einfachsten und relativ schnell)

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Leider ist es nicht so einfach!
Über eine andere Schnittstelle habe ich natürlich auch schon 
nachgedacht.

Es handelt sich hier um eine große Menge an Messdaten, die für eine 
Regelung schnellst möglich abgesetzt und weiterverarbeitet werden 
sollen. Die Ankopplung über CAN-BUS war eigentlich auch mein erster 
Gedanke, aber mit dem von uns berechneten Datendurchsatz könnte es eng 
werden.

Die parallele Ankopplung über einen DPR habe ich mir noch offen 
gehalten.
Da das System aber mit mehreren Modulen erweiterbar sein soll möchte ich 
eine serielle Anbindung.

Aus Kosten- und Design Gründen werde ich die Parallele Lösung erst als 
zweites verfolgen.

Autor: Michael G. (linuxgeek) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael wrote:

> Hat hiermit schon jemand Erfahrungen gemacht?

Solange Dein anderer Controller einen Host-Modus implementiert ist es 
zumindest grundsaetzlich moeglich. Allerdings wirst Du dann auch einen 
passenden Treiber zum Ansprechen des FT232 benoetigen... und das duerfte 
wohl das groessere Problem sein. Host-Controller bringen fuer einige 
Geraetschaften naemlich schon Treiber mit (mass storage z.B.), aber bei 
dem FT232 wohl eher nicht.

Ach ja: USB und schnell sind etwas widerspruechlich. Man hat bei USB 
mitunter sehr grosse Latenzzeiten. Wenn es Dir also um eine moeglichst 
schnelle Weiterverarbeitung geht ist USB ohnehin nicht das Mittel zur 
Wahl. Und "schnell" ist auch bei der Bandbreite relativ, welche Modi 
(fast, high-speed, ...) unterstuetzt denn Dein Host-Controller?

Autor: Olaf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es handelt sich hier um eine große Menge an Messdaten, die für eine
> Regelung schnellst möglich abgesetzt und weiterverarbeitet werden

Du solltest mal definieren was moeglichst schnell heisst. USB ist
ja auch nicht so das Geschwindigkeitswunder wenn du zu bestimmten
Zeiten ein paar Bytes fuer eine Regelung abholen willst weil
du erstmal durch den ganzen Protokoloverhead musst.
Und der Aufwand fuer die Implementierung ist wirklich gross.

> Aus Kosten- und Design Gründen werde ich die Parallele Lösung
> erst als zweites verfolgen.

Es gibt sowieso keinen Grund fuer eine parallele Loesung weil man
auch serielle Sachen schnell bekommen kann.

Olaf

Autor: Gasst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Da das System aber mit mehreren Modulen erweiterbar sein soll möchte
>ich eine serielle Anbindung.

Dann nimm entweder eine SCI_x mit RS485-Treibern oder je eine SCI_x fü 
jedes Modul.

@Olaf
>Es gibt sowieso keinen Grund fuer eine parallele Loesung weil man
>auch serielle Sachen schnell bekommen kann.

Fragt sich nur, mit welchem Aufwand. 1MByte/s ist deutlich schneller als 
1MBit/s.

Autor: Lupin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie wäre es mit ethernet? Da braucht man aber schon einen ordentlichen 
IC der dann wohl parallel an den Controller angebunden werden muss.

Autor: Karl-heinz Strunk (cletus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Lupin wrote:
> Wie wäre es mit ethernet? Da braucht man aber schon einen ordentlichen
> IC der dann wohl parallel an den Controller angebunden werden muss.

+ Stack + Overhead + x + x auch sehr langsam, wenn es um Latenz geht.

Ich habe das Gefühl, dass der Threadersteller selber kaum Ahnung hat, 
wie schnell er die Daten verarbeiten will.

Es muss einfach nur "Schnell" sein.

Da er eine externe Platte mit USB-Anschluss besitzt, sieht er, dass 20 
MByte / Sekunde realistisch erscheint.

Wenn er mal posten würde, wie viele Daten er mit welcher Latenz 
verschoben braucht; dann könnten wir ihm helfen. Aber so?

Achja: Wie weit sind die Prozessoren auseinander?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl-heinz Strunk wrote:

> + Stack + Overhead + x + x auch sehr langsam, wenn es um Latenz geht.

Man muss nicht unbedingt einen kompletten TCP/IP Stack verwenden. Viele 
Leute, auch oft auch Profis, gehen automatisch davon aus, dass man davon 
profitiert. Und verwenden blind TCP wo das überhaupt nicht nötig ist, 
oder sogar massiv schadet.

Wenn es innerhalb eines Netzes bleibt und daher nicht geroutet werden 
muss, und als Zieladresse direkt eine MAC- oder Broadcast-Adresse 
verwendet werden kann, dann kommt statt TCP/IP auch nacktes Ethernet 
ohne Kinkerlitzchen in Frage. Das ist dann ausgesprochen einfach und 
schnell, weil fast nur noch aus dem Basistreiber des 
Ethernet-Controllers bestehend. Und garantiert viel einfacher als USB.

Autor: Gasst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Und etwas kompletter mit UDP schafft ein 16MHz AVR mit seriell(!)
>angeschlossenen ENC28J60 immer noch 150KB/s.

Und wo nimmt er die 150KB so schnell her? :-)

Über seine SCIs macht der 1668 wohl 1,25MBit/s mit. Per DMA ist diese 
Datenrate auch für größere Datenmengen einzuhalten.
Mit ein bißchen Verschnitt fürs Protokoll sind m.E. 100kB/s zu 
erreichen. Ich würde einen RS485-Bus aufbauen und mit einem 
(Sub-)Protokoll des Profibus betreiben, der CRC-abgesicherte Datensätze 
bis zu 256 Byte Nutzdaten bietet. Einen CRC-Generator hat der 1668 schon 
auf dem Chip.

Die Frage ist nur: wie sieht die Gegenseite aus?

Autor: Micha (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Es handelt sich hier um eine große Menge an Messdaten, die für eine
> Regelung schnellst möglich abgesetzt und weiterverarbeitet werden
> sollen. Die Ankopplung über CAN-BUS war eigentlich auch mein erster
> Gedanke, aber mit dem von uns berechneten Datendurchsatz könnte es eng
> werden.
Wenn es beim CAN mit 1Mbit/s "eng werden könnte", könnte dir SPI dicke 
ausreichen.

Ansonsten solltest du hier mal konkret schreiben wieviel Daten in 
welcher Zeit übertragen werden sollen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Gasst wrote:

> Und wo nimmt er die 150KB so schnell her? :-)

Stimmt, das hatte ich dabei noch vergessen. Aus einem 512KB Dataflash, 
das an gleichen SPI angeschlossen ist.

Um Tempo ging es mir dabei garnicht. Das war einfach nur das, was bei 
UDP über µIP rauskam. Es ging einfach nur um das Auslesen vom 
Protokollspeicher, per PC.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Micha wrote:

> Wenn es beim CAN mit 1Mbit/s "eng werden könnte", könnte dir SPI dicke
> ausreichen.

Nur wenn beide Controller hinreichend grosse Puffer im SPI-Modul sitzen 
haben, oder DMA. Einfache SPIs wie bei den AVRs oder auch den älteren 
LPC2000 haben beim Empfang bei hoher Rate Schwierigkeiten, den Kram 
zuverlässig rechtzeitig aus dem Schnittstellenregister zu fischen.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.