USB Übertragung / Timing (MCP2221 und I²C)

[Mathias]

Ich habe Konverter USB to I²C (MCP2221) welcher ich für Datenübertragung mit einem ADS1115 (Analog->Digital Wandler) brauche.
Nur das Problem, die Datenübertragung ist sehr langsam, im Vergleich der VGA-Anschluss hat auch I²C eingebaut und dort läuft es über 10x schneller.

Kann man irgendwo das Timing des USB-Portes einstellen ?

Unter Win7 gibt es für die COM-Ports unter "Systemsteuerung/System/Hardware/Geräte-Manager/Anschlüsse/USB-Serial/Anschlusseinstellungen/Erweitert/Delay" ein Delay, das sehr hoch eingestellt ist. Wen ich dieses auf 1 stelle, wird der COM-Port sehr viel schneller.

Ich denke, vielleicht gibt unter Linux eine Einstellung, wo man da eingreifen kann.

Ich verwende Mint Cinamon 18 64Bit.

[BetterWorld]

stty -F /dev/ttyDEINDINGENSHIER 115200Und dann halt die gewünschte Baudrate angeben.

[Mathias]

Das ist nicht das was ich suche, es geht da nicht um die Baudrate des COM-Ports, sondern um das Timing des USB.
Mit der Einstellung in der Systemsteuerung habe ich nur als Beispiel genommen, da es diese Einstellung nur bei USB-COM-Ports gibt. Bei den echten COM-Ports, welche fest am Mainboard verbaut sind, gibt es diese Einstellung nicht.

[nopes]

https://johnflux.wordpress.com/2015/10/19/usb-i2c-convertor-chip-a-lesson-in-usb-latency/

[florian0285]

man setserial

ich tippe auf close_delay?

[Mathias]

https://johnflux.wordpress.com/2015/10/19/usb-i2c-convertor-chip-a-lesson-in-usb-latency/

Das einzige was ich da erkennen kann, ist das jemand das gleiche Problem wie ich habe, aber eine Lösung kann ich nicht finden.
Die Python.Script laufen bei mir nicht, aber so wie ich es sehe, sind die nur für einen Test-Laufe.

Oder übersehe ich da etwas ?


man setserial

ich tippe auf close_delay?

tux@tux-To-be-filled-by-O-E-M ~ $ man setserial
Kein Handbucheintrag für setserial vorhanden

[florian0285]

apt-get install setserial -y

[Mathias]

apt-get install setserial -y

Nützt aber nicht viel, das dies nur für den COM-Port und nicht für I²C ist.

[florian0285]

Wo steht das?

setserial -g /dev/ttyACMx

Davon abgesehen möchtest du diese Einstellung für USB (to serial) so wie du das da oben beschreibst. Den I2C Bus musst du dann schon selbst beschreiben. Entweder mit einer Programmiersprache und der passenden Bibliothek oder mit den i2c-tools (i2cset).

Wie dein Chip arbeitet weiß ich nicht, aber wenn du den Takt von deinem ADC selbst ansprechen musst, musst du den selbst von low auf high ziehen. Das sollte aber eigentlich über deinen USB-Adapter mit I2C gehen oder hat das unter Win ggf die Anwendung übernommen?

Wie dein MCP2221 funktioniert ist in der technischen Spezifikation beschrieben.

[nopes]

Das einzige was ich da erkennen kann, ist das jemand das gleiche Problem wie ich habe, aber eine Lösung kann ich nicht finden.
Die Python.Script laufen bei mir nicht, aber so wie ich es sehe, sind die nur für einen Test-Laufe.

Oder übersehe ich da etwas ?



tux@tux-To-be-filled-by-O-E-M ~ $ man setserial
Kein Handbucheintrag für setserial vorhanden

Jein, kurz Fassung: Schrottiges Design, besser auf was ordentliches wechseln, aus dem Artikel die wesentlichen Stellen dazu:
I spoke to the Alan Stern and Greg KH, the Linux kernel USB maintainers, who were not surprised by this 8ms delay at all, and told me:


Why are we seeing such a large latency?
I don’t see anything wrong here, USB isn’t guaranteed to have any specific latency, what you are doing here is the worst-possible-case for a USB system (i.e. send a packet, wait for it to complete, send another one, etc.) There are lots of ways to get much better throughput if that is what you are wanting to do.

Can we make this faster?

For a horrid protocol like this, no, there isn’t any way to make it go faster, sorry. That is designed in such a way to make it the worst possible thing for a USB system, go kick the person who designed such a thing (hint, they have no idea how USB works…)

I strongly suggest going and getting a different sensor chip, don’t encourage such behaviour by actually buying their hardware.

Where is the delay coming from?

Multiple places: time to submit the request, time to reserve bandwidth for the previously unused interrupt endpoint, time to complete the transfer, all multiplied by 2.

You can get more information from usbmon (see Documentation/usb/usbmon.txt in the kernel source). But Greg is right; the protocol you described is terrible. There’s no need for a multiple ping-pong interchange like that; all you should need to do is wait for the device to send the next bit (or whatever) of data as soon as it becomes available.

Sorry vermutlich nicht gerade das was du hören wolltest. Jedenfalls ist MCP2221 wohl nicht so prall, also mal mit einem anderen probieren (There’s no need for a multiple ping-pong interchange like that; all you should need to do is wait for the device to send the next bit (or whatever) of data as soon as it becomes available.), ob es da was gibt kann ich gerade nicht sagen...

[Mathias]

also mal mit einem anderen probieren Kennst du zufällig gerade einen, welcher auch in einem DIP-Gehäuse erhältlich ist ?