eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikaOpóźnienie w transmisji USB › Re: Opóźnienie w transmisji USB
  • Path: news-archive.icm.edu.pl!agh.edu.pl!news.agh.edu.pl!newsfeed2.atman.pl!newsfeed.
    atman.pl!goblin1!goblin.stu.neva.ru!newsfeed.neostrada.pl!unt-exc-02.news.neost
    rada.pl!unt-spo-a-01.news.neostrada.pl!news.neostrada.pl.POSTED!not-for-mail
    Date: Fri, 27 Mar 2015 16:29:58 +0100
    From: Adam Górski <gorskiamalpawpkropkapeel_@xx>
    User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101
    Thunderbird/31.5.0
    MIME-Version: 1.0
    Newsgroups: pl.misc.elektronika
    Subject: Re: Opóźnienie w transmisji USB
    References: <2...@g...com>
    <550c1e48$0$2203$65785112@news.neostrada.pl>
    <f...@g...com>
    In-Reply-To: <f...@g...com>
    Content-Type: text/plain; charset=iso-8859-2; format=flowed
    Content-Transfer-Encoding: 8bit
    Lines: 36
    Message-ID: <5515777c$0$8378$65785112@news.neostrada.pl>
    Organization: Telekomunikacja Polska
    NNTP-Posting-Host: 79.190.250.110
    X-Trace: 1427470204 unt-rea-b-01.news.neostrada.pl 8378 79.190.250.110:2806
    X-Complaints-To: a...@n...neostrada.pl
    Xref: news-archive.icm.edu.pl pl.misc.elektronika:679704
    [ ukryj nagłówki ]

    On 2015-03-21 19:32, s...@g...com wrote:
    > W dniu piątek, 20 marca 2015 14:19:06 UTC+1 użytkownik J.F. napisał:
    >
    >
    >>
    >> A predko tam ?
    >> Bo z tego co piszesz to gdzies po drodze mogloby byc 30-80MB
    >> zmagazynowane - a to na pewno nie FT2232, i pewnie nie w FPGA, tylko
    >> gdzies w komputerze.
    >
    > No może nie aż tyle, bo cały mój "frame" zbierania danych to zaledwie 16KB.
    > Z tych zaledwie 16KB muszę zrobić kupę postprocessingu i wyświetlić to jako wykres,
    obraz 2D, cokolwiek... Natomiast układ akwizycji może śmigać na 20MHz, ale cały
    "obraz" akwizycji mogę odebrać zgodnie z portokołem USB (1ms scheduling).
    Podejrzewam, że drajwery FTDI buforują dane na f=60MHz z sobie jedynie znanych
    powodów.
    >
    >>
    >>
    >> Na konwerterze RS-USB mozna sie chyba spodziewac opoznien o pare ms -
    >> raz, ze jesli dobrze udaja 16550, to staraja sie same zbuforowac
    >> troche znakow wejsciowych a nie meczyc systemu przerwaniami, dwa, ze
    >> USB w podstawowym trybie jest przegladane co 1ms ..
    >>
    >
    > A cóż to takiego "tryb podstawowy"? Nie ma nic takiego! Czy ja coś pisałem o
    konwerterze RS-USB? Chyba nie. Protokół USB to nie przerwania! Odpytuje jednak co 1ms
    chęć dostępu do urządzenia/transmisji. Jest to tzw. scheduled protocol, czy jak kto
    woli "planowany". W moim przypadku czas tworzenia kompletnego zestawu danych (16KB),
    to aż 60ms. Dodając do tego 1ms na "dobicie się" do transmisji mamy 61ms, co daje 16
    obrazów/s. Czas postprocessingu i samej transmisji jest pomijalny na byle jakim
    pececie. I faktycznie tak jest! Ale owego "przesunięcia fazowego" za cholerę nie
    rozumiem... Podejrzewam drajwery FTDI, a z tym już nic nie jestem w stanie
    nakombinować. Chyba trza będzie zastosować inne kostki. Tylko jakie, coby nie mieć
    tej samej checy ?
    >
    >
    >
    Czyli jeśli dobrze rozumiem robiąc np. "ping" PC->device->PC (albo
    device ->PC-> device ) dostajesz odpowiedź mierzoną w sekundach ? No
    to jakieś jaja by były.

    Gdybyś tak zechciał zmierzyć czas tego "ping" to coś by się dało
    powiedzieć. Dziwnie 16kB co 60ms i taka latencja ... hm dziwne.

    A jesteś pewien że z kostki na szynę wyłazi ? Podepnij może oscyloskop i
    zobacz.

    Adam

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: