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
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...
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)
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.
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?
> 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
>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.
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?
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.
>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?
> 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.
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.
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.
