Datenuebertragung Mikrocontroller -> PC per USB oder TCP/IP

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

Dirk Ruth schrieb:

Ja, 65 Euro :-)

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

Gerald

Aguja schrieb:

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

Gerald

Hallo Michael,

"Michael Eggert" schrieb im Newsbeitrag news: snipped-for-privacy@4ax.com...

Schau Dir mal den Dilnet-PC an.

Gruss, Kurt

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

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.

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 snipped-for-privacy@adams-online.de

;-)

Was für ein Balkendiagramm?

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

--

Hi!

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

Das will auch erstmal implementiert werden.

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

Gruß, Michael.

Hi!

Das ist gut.

Das klingt gut.

^^^ 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.

Hi!

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.

Prima!

Gruß, Michael.

Wieso 12 MBit/s? 480 MBit/s.

Hauptproblem bei USB sind die Latenzen.

Das ist kein Thema.

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

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.

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

Ja, vermutlich als ROM-Code.

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

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.

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

Hi!

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

Gruß, Michael.

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.

USB2 erlaubt Endpointgrössen > 64 Byte.

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.

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

--

Marco Budde wrote in :

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.

Marco Budde wrote in :

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.

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.