Datenuebertragung Mikrocontroller -> PC per USB oder TCP/IP

[Michael Eggert]

On 28 Jul 2003 14:49:56 -0700, faltkaese@gmx.net (Christian Baldern)
wrote:

Hi..

Wie wäre es mit folgender Kombination:
http://www.braintechnology.de/braintechnology/produkte.html/#20020
und
http://www.braintechnology.de/braintechnology/usb2dll.html

...um auch mal eine einfache USB2-Lösung vorzuschlagen

USB 2.0 und 1.1 Kompatibel
für High Speed 480Mbs USB Bus
kompatiebel zu Full Speed 12Mbs USB Bus
^

Mal abgesehen davon, daß das weh tut.. genauso wehtut wie dieses
schöne Balkendiagramm zum Geschwindigkeitsvergleich im Datenblatt,
das mich irgendwie an die ESCOM-Kataloge aus meiner Jugend erinnert...

....macht der denn echtes USB2.0, oder ist der so kompatibel wie der
ftdi 245?

Gruß,
Michael.

 

[Dirk Ruth]

On Mon, 28 Jul 2003 22:23:14 +0200, Michael Eggert
<m.eggert.nul@web.de> wrote:

On 28 Jul 2003 21:33:50 +0200, Juergen Hannappel
hannappe@lisa2.physik.uni-bonn.de> wrote:

Hi!


Welche Möglichkeiten gibts noch? USB 2.0? Da gibts aber noch keine ICs
zum Spielen für, oder? FireWire? Technisch wohl überlegen, aber leider
kaum verbreitet. Gibts hier ICs zum Spielen?

M30245FC -Entwicklungsboard von Glyn. Kostet glaube ich zwischen 50
und 80 EUR.

Daten mit 8 oder 16bit an die CPU, HOLD anschließen und per DMA auf
den USB-Bus schaufeln. C-Compiler ist das erste halbe Jahr kostenlos.

Tschö
Dirk

 

[Gerald Oppen]

Dirk Ruth schrieb:

M30245FC -Entwicklungsboard von Glyn. Kostet glaube ich zwischen 50
und 80 EUR.

Ja, 65 Euro

Einen Compiler gint e dafür glaube ich auch dauerhaft kostenlos...

Gerald

 

[Gerald Oppen]

Aguja schrieb:

Du könntest es mit einem IPC@Chip versuchen, 66 EUR (Weiß nicht, wie der
Taler gerade steht...). Leider kann ich Dir nicht garantieren, ob der die
1 MBit/s schafft - ich weiß nur, daß er nicht mal das 10 Mbit-Interface
ganz ausnutzen kann.

Der IPC ist ein Multichip-Modul bestehend aus einem AMD 186er, einen I/O-
Chip (mit Netzwerkfunktionen), einem Flash sowie einem RAM-Speicher der
mit DOS-Interruptaufforderungen programmiert wird. www.bcl.de

Weiss nicht, ob das Teil das richtig ist... hinterlässt bei mir immer so
den Eindruck einer Conrad C-Control...

Gerald

 

[Kurt Harders]

Hallo Michael,

"Michael Eggert" <m.eggert.nul@web.de> schrieb im Newsbeitrag
news:hhhaivcqniav3alek2hpe3dvmk08bm2s0p@4ax.com...

Gibt es ein IC/Modul, in das ich in dieser Geschwindigkeit Daten
reinschieben kann, und das diese dann über TCP oder USB überträgt? Der
Mikrocontroller sollte nicht darauf warten müssen, daß er Daten
loswerden darf, folglich müsste schon ein entsprechend großer FIFO
integriert sein.

Schau Dir mal den Dilnet-PC an. http://www.ssv-embedded.de

Gruss, Kurt

--
PiN - Präsenz im Netz GITmbH
Kurt Harders
http://www.pin-gmbh.com
mailto:harders@pin-gmbh.com

 

[Peter Heitzer]

Bestünde vielleicht die Möglichkeit, die Daten etwas zu komprimieren?
Bei Bilddaten könnte vielleicht ein einfaches RLE Verfahren
funktionieren. Bei einem Faktor von 2 und max. 250 KB/s wäre die
Übertragung via 10Mbit vermutlich auch kein Problem mehr.

 

[Robin Adams]

Hallo Michael,

Michael Eggert wrote:

...macht der denn echtes USB2.0, oder ist der so kompatibel wie der
ftdi 245?

ja, der Chip ist für echtes USB 2.0 High-Speed gebaut. Netterweise
hat Cypress gleich ein wenig programmierbare Logik eingebaut, damit
der Chip die hohen Transferraten auch erreichen kann. Das FIFO-
Interface läuft maximal mit 48 MHz / 16 Bit.

Eine gängige Anwendung dieses Chips sind die neuen USB-Videokarten,
wo dieser Chip unkomprimiertes D1-Video(20 Mb/s) schaufelt.

1 Mb/s sollte damit also realisierbar sein. Das Teil will allerdings,
im Gegensatz zum ftdi 245, der nur USB 2.0 Full Speed schafft, auch
programmiert sein...


Gruß,
Robin Adams
robin@adams-online.de

 

[Christian Baldern]

Michael Eggert <m.eggert.nul@web.de> wrote in message news:<bu9bivo1asrts2jomrq2m8gb7b0rvcfr9o@4ax.com>...

USB 2.0 und 1.1 Kompatibel
für High Speed 480Mbs USB Bus
kompatiebel zu Full Speed 12Mbs USB Bus
^

Mal abgesehen davon, daß das weh tut.. genauso wehtut wie dieses

;-)

schöne Balkendiagramm zum Geschwindigkeitsvergleich im Datenblatt,
das mich irgendwie an die ESCOM-Kataloge aus meiner Jugend erinnert...

Was für ein Balkendiagramm?

...macht der denn echtes USB2.0, oder ist der so kompatibel wie der
ftdi 245?

Sicher macht der echtes USB2.0. Das ganze basiert auf dem
FX2-Controller von Cypress, der ein ECHTER usb2.0 Controller ist...

viele Grüsse,

Christian
--

 

[Michael Eggert]

On 29 Jul 2003 07:17:10 GMT, "Peter Heitzer"
<peter.heitzer@rz.uni-regensburg.de> wrote:

Hi!

Bestünde vielleicht die Möglichkeit, die Daten etwas zu komprimieren?

Wie gesagt, die Bilddaten sind ziemlich chaotisch. Strömungsprofile.

Bei Bilddaten könnte vielleicht ein einfaches RLE Verfahren
funktionieren.

Das will auch erstmal implementiert werden.

Bei einem Faktor von 2 und max. 250 KB/s wäre die
Übertragung via 10Mbit vermutlich auch kein Problem mehr.

Naja, aber wer garantiert die maximal benötigte Datenrate?

Gruß,
Michael.

 

[Michael Eggert]

On Tue, 29 Jul 2003 09:42:48 +0200, Robin Adams
<robin@adams-online.de> wrote:

Hi!

ja, der Chip ist für echtes USB 2.0 High-Speed gebaut.

Das ist gut.

Netterweise
hat Cypress gleich ein wenig programmierbare Logik eingebaut, damit
der Chip die hohen Transferraten auch erreichen kann. Das FIFO-
Interface läuft maximal mit 48 MHz / 16 Bit.

Eine gängige Anwendung dieses Chips sind die neuen USB-Videokarten,
wo dieser Chip unkomprimiertes D1-Video(20 Mb/s) schaufelt.

1 Mb/s sollte damit also realisierbar sein.

Das klingt gut.

Das Teil will allerdings,
im Gegensatz zum ftdi 245, der nur USB 2.0 Full Speed schafft, auch
programmiert sein...
^^^ 1.1 ?

Ja, leider. Das gesamte USB-gedöns ist aber schon in Hardware drin,
oder? Das heißt, ich muss die Daten nur in irgendwelche Register
pumpen und gut ist? Dann könnte ich ja noch ein bissl was nützliches
rein programmieren. FIFO für 500k auf externem Ram zum Beispiel. Oder
gar ein paar Berechnungen drauf laufen lassen. Ich werd mir das mal
genauer anschauen.

Gruß,
Michael.

 

[Michael Eggert]

On 29 Jul 2003 03:15:26 -0700, faltkaese@gmx.net (Christian Baldern)
wrote:

Hi!

schöne Balkendiagramm zum Geschwindigkeitsvergleich im Datenblatt,
das mich irgendwie an die ESCOM-Kataloge aus meiner Jugend erinnert...

Was für ein Balkendiagramm?

http://www.braintechnology.de/braintechnology/dwnld_files/interface2_5.pdf

Seite 3, direkt unter dem timing diagram. Aufgrund der hohen
"Informationsdichte" erinnerte es mich an die ESCOM-"Tachos", damals
mit 386DX40 am linken Anschlag, 486SX20 kurz vorm oberen Ende der
Skala und dem 486DX33, der den Tacho fast zum platzen bringt

Sowas gehört ja nur eigentlich nicht in ein Datenblatt. Pinbelegung
hingegen gehört nicht in einen Verkaufsprospekt. Na mal schauen, was
ich noch an Informationen dazu finde.

Sicher macht der echtes USB2.0. Das ganze basiert auf dem
FX2-Controller von Cypress, der ein ECHTER usb2.0 Controller ist...

Prima!

Gruß,
Michael.

 

[Marco Budde]

Michael Eggert wrote:

Ich weiß, da schaut USB mit 12MBit/s aber auch nicht besser aus.

Wieso 12 MBit/s? 480 MBit/s.

Wobei
ich nicht weiß, wie dort der overhead aussieht.

Hauptproblem bei USB sind die Latenzen.

Immerhin brauche ich ja nur 500kByte/s.

Das ist kein Thema.

Welche Möglichkeiten gibts noch? USB 2.0? Da gibts aber noch keine ICs
zum Spielen für, oder?

Doch, Cypress EZ-USB 2.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-a@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Marco Budde]

Michael Eggert wrote:

Jetzt seh ich grad, das Ding ist "USB 1.1 and USB 2.0" compatible.
Bedeutet das, daß das Teil:
- an USB 2.0 nicht abstürzt, aber trotzdem mit 1.1-Geschwindigkeit
trödelt und dabei genausoviel Buszeit frisst wie am 1.1 Bus?
ODER
- an USB 2.0 zwar auf Dauer auch nicht mehr Daten rüberbekommt, die
aber in kurzen, schnellen Paketen schickt, so daß genug Ressourcen
übrigbleiben?

Das bedeutet, daß mal wieder die Freunde aus der Marketingabteilung
am Werke waren. USB 2.0 ohne Zusatz ist nur ein neuer Name für USB 1.1.
Wenn Du echtes USB 2.0 haben willst, mußt Du auf den Zusatz "USB 2.0
Highspeed" achten.

Und dann
kann es ja auch noch passieren das jemand der deine Schaltung benutzt
auch noch etwas anderes am USB-Port haengen hat oder?

USB wird doch heute fast nur als Punkt-zu-Punkt Verbindung genutzt.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-a@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Marco Budde]

Michael Eggert wrote:

Ja, leider. Das gesamte USB-gedöns ist aber schon in Hardware drin,
oder?

Ja, vermutlich als ROM-Code.

Das heißt, ich muss die Daten nur in irgendwelche Register
pumpen und gut ist?

Diese ICs haben meistens zwei 64 Byte große USB-Buffer, die
man wechselseitig beschreibt und an den Chip signalisiert.

Dann könnte ich ja noch ein bissl was nützliches
rein programmieren.

Wirklich verarbeiten können diese ICs schon den Datenstrom
von USB 1.1 (also ca. 1 MByte/s) nicht. Eine if-Abfrage
pro Datenbyte kann da schon zuviel sein.

FIFO für 500k auf externem Ram zum Beispiel. Oder
gar ein paar Berechnungen drauf laufen lassen. Ich werd mir das mal
genauer anschauen.

Das mit den Berechnungen kannst Du vergessen.

cu, Marco

--
S: Minolta: Winkelsucher (VN), VC-9

E-Mail: mb-news-a@linuxhaven.de
Deutsches Linux HOWTO Projekt: http://www.linuxhaven.de

 

[Michael Eggert]

On Tue, 29 Jul 2003 20:21:05 +0200, Marco Budde
<mb-news-a@linuxhaven.de> wrote:

Hi!

Wirklich verarbeiten können diese ICs schon den Datenstrom
von USB 1.1 (also ca. 1 MByte/s) nicht. Eine if-Abfrage
pro Datenbyte kann da schon zuviel sein.

Bei 48MHz clock? Is ja ekelhaft!
Sind die so mies, oder verbraucht der echte Rechenzeit fürs USB?

Gruß,
Michael.

 

[Wolfgang Fischer]

On Mon, 28 Jul 2003 20:38:27 +0200, Michael Eggert wrote:

On Mon, 28 Jul 2003 16:08:21 GMT, Olaf Kaluza <olaf@criseis.ruhr.de
wrote:

Hi!

Hm...schau dir mal USBN9603/4 (National Semiconductor) an. Ist ein USB
Controller mit DMA-Support.

Mach ich gleich...

Ich habe beim googlen was von "TCP Stack" gelesen, was auch immer das
ist,

You make my day.

Gern geschehn!

Also Klartext: Ich hab keine Ahnung, was da auf low-level Ebene läuft.
Ich will bloß meine Messwerte loswerden
Auf der Gegenseite (PC) läuft wohl LabView. Momentan arbeite ich mit
Version 6, die bringt einen TCP-Treiber mit (open(adresse,port), read,
fertig). Möglicherweise schon seit etlichen Versionen, weiß ich nicht.
USB kennts nicht. Evtl wird mal Version 7 angeschafft, aber eben nur
evtl. Die hätte dann auch einen USB Treiber, wobei ich nicht weiß, ob
der sich genauso einfach programmieren lässt. Und selbst wenn, dann
wäre der TCP Treiber _mindestens_ eine Version älter (ausgereifter).

Dass das Auswertungsprogramm TCP braucht, heißt nicht, dass das auch der
Microcontroller können muss. Schreibe lieber ein paar Zeilen Perl, um die
Daten vom Controller zu lesen und über TCP an das Programm weitergibt.

 

[Christian Baldern]

Marco Budde <mb-news-a@linuxhaven.de> wrote in message news:<3F26BB11.1AFBBF26@linuxhaven.de>...

Diese ICs haben meistens zwei 64 Byte große USB-Buffer, die
man wechselseitig beschreibt und an den Chip signalisiert.

USB2 erlaubt Endpointgrössen > 64 Byte.

Dann könnte ich ja noch ein bissl was nützliches
rein programmieren.
Wirklich verarbeiten können diese ICs schon den Datenstrom
von USB 1.1 (also ca. 1 MByte/s) nicht. Eine if-Abfrage
pro Datenbyte kann da schon zuviel sein.

Falls sich das auf den FX2 bezieht:
Dank des GPIF-Interfaces (eine in Hardware realisierte konfigurierbare
Statemachine) kann er wie gesagt 1:1 die Daten ohne die CPU zu
belasten Daten zwischen Endpoint(s) und dem Parallelbus transferieren.
Meiner Erfahrung nach liegt eine realistische Datenrate (PC <-> GPIF)
bei ca. 20 MByte/s.

FIFO für 500k auf externem Ram zum Beispiel. Oder
gar ein paar Berechnungen drauf laufen lassen. Ich werd mir das mal
genauer anschauen.
Das mit den Berechnungen kannst Du vergessen.

Das ist wohl wahr...

weil es bedeuten würde Datenbytes einzeln zu übertragen. Damit wäre
der zwar schon optimierte 8051'er Kern schon stark überfordert -
wenigstens bei höheren Datenraten.

viele Grüsse,

Christian
--

 

[Matthias Weingart]

Marco Budde <mb-news-a@linuxhaven.de> wrote in
<3F26BA4C.651B2613@linuxhaven.de>:

Und dann
kann es ja auch noch passieren das jemand der deine Schaltung
benutzt auch noch etwas anderes am USB-Port haengen hat oder?

USB wird doch heute fast nur als Punkt-zu-Punkt Verbindung genutzt.

Mhh, naja sobald da ein USB-Hub dahinterhängt, dann teilt sich ja
der Verkehr auf die Geräte die da dran hängen auf (sofern die in
betrieb sind). Und meistens sind auch 2 USB-Verbinder auf dem
Motherboard einem USB-Controller zugeordnet, also 2 Geräte
nebeneinander angesteckt teilen sich ebenfalls die Bandbreite. Zum
Glueck haben moderne Chipsätze gleich 2..3 USB-Hosts onchip. So das das
mit der Punkt-Punkt Verbindung fast stimmt. Man (DAU) muss nur drauf
achten, da er seine Geräte so verteilt ansteckt, das jedes die max.
Bandbreite bekommen kann ...

M.

 

[Matthias Weingart]

Marco Budde <mb-news-a@linuxhaven.de> wrote in
<3F26BB11.1AFBBF26@linuxhaven.de>:

Wirklich verarbeiten können diese ICs schon den Datenstrom
von USB 1.1 (also ca. 1 MByte/s) nicht. Eine if-Abfrage
pro Datenbyte kann da schon zuviel sein.

Ist schliesslich nur ein guter alter 8051 (beim Ezusb) der
lediglich den USB-Verkehr "steuern" soll. Naja wie auch immer,
64 kbit/s (eine kleine INT-Pipe) habe ich schon per Interruptroutine
(also Software im 8051) füllen können. Sehr viel mehr ist aber nicht
drin.

M.

 

[Stefan Wagner]

Michael Eggert <m.eggert.nul@web.de> wrote:

Ich dachte eigentlich eher an was kleines als an dicke Systeme. In das
dicke System müssen die Daten auch erstmal rein. Ich sag mal,
Schmerzgrenze wäre so bei 1 extra Ram für Datenübertragung + 1 AVR für
Protokoll und Datenschieben + 1 Spezial-IC. Wobei ich das Programm im
AVR (TCP-Stack, weiteres Protokoll) nicht neu erfinden wollte, sondern
hoff(t)e, daß das schonmal jemand getan hat.

Hallo Michael,

auch wenn du dich vielleicht schon für USB entschieden hast:
Eventuell solltest du dir mal den TCP-Stack aus NOS aka KA9Q ansehen.
Das ist ein kompletter TCP/IP-Stack mit diversem Drumherum (alles in
einem großen Executable versteckt), der viel für Amateurfunkzwecke
verwendet wurde.

Interessant ist, dass allen in C gebaut ist und im Prinzip ohne jede
Runtime-Umgebung auskommt (bzw. sie selbst enthält). Ich habe lange
nicht mehr in die Sourcen hineingeschaut, würde sie aber grundsätzlich
für portierbar halten.

Grüße

Stefan

PS: Die mir vorliegenden Sourcen sagen zu einer gewerbliche Nutzung
nichts aus, die Frage wäre also noch offen.