USB не е мрежа, въпреки че има "bus" в името си... Всичко се движи от хоста, робите не могат да кажат и гък докато Господарят не ги попита. Въобще всичко се командва от хоста и всички трябва да вземат равнис по неговия клок.
Самият клок не е нужно да е супер прецизен, е относително де, щото 500ppm е грубичко, но пък е за целия температурен и изобщо работен режим.


Всичко се движи от стейт машината на хоста, която на всеки 125uS трябва да генерира микрофрейм за high speed портовете, а на 8 микрофрейма или на 1mS фрейм за full spee. Фреймовете се излъчват паралелно, като разликата в закъсненията е минимална щото нямаш 1000 възможни начина на окабеляване. За хъбовете са забили изискване от макс 4ns закъснение, може да имаш макс 5 хъба последователно. По кабела закъснението също е фикснато, щото и дължината на кабела е фиксирана и те така няма как да се получи разминаване. А в случая ако Емо ползва еднакви кабели всички устройства практически трябва да чуват радиото по едно и също време. Аз го смятах ако опне жици и не им компенсира дължините ще има по-голяма грешка отколкото USB-то.


Да, много често SOF може да излиза на пин.
В това отношение STM32L4 отиват и по-далече, там може да го вкараш в евент системата и да управляваш практически всяка друга периферия. А отклоненията които дават между техния клок и клока дето следват просто ме е срам да цитирам... няма такава точност
Това разбира се ако клока на хоста не танцува... но и да танцува, той не може да танцува повече от разрешените му 500ppm. Ще танцува напред, ще танцува назад, средно разминаването е ограничено

Хептен се обърках. Сега стабилноста на клока е 1 ппм или 500 ппм-а? И тоя наносекунден джитер се отнася за рамките на един фрейм или за тайминга между фреймовете? Тогава да вземем да изхвърлим рубидиевите клокове и да наслагаме УСБ-та

1ppm беше моя грешка, той Емо я видя и я изяснихме вече.

и аз

погледнах го това STM-че.
има някакъв 'осцилатор' който възстановява клок (CRS). той се подпира през мултиплексор на външен клок, или на USB пиновете.
съответно вади 48MHz клок (чипа е само FS), който от своя страна отива САМО на USB контролера. не може да клочи таймер.

от USB контролера излиза SOF тригер (понеже се чудех, това е Start Of Frame), явно са онези фреймове на 1ms (в случая FS). таймера се клочи от някой от PLL клоковете.

чуденките са:
- да приемем, че цялата USB жица е синхронна по клок спрямо хоста. дори и много да са се постарали произоводителите на хоста и да са сложили 20ppm кварц, системата няма как да стане с по-стабилен клок от него. а пък той дори няма и нужда да е стабилен, защото 'клиентите' си имат съответния CRS и сепарират клок/данни от стрийма и след сепарацията те вече са синхронни (клок-данни), независимо, че може да имат дори и голям битов джитер. по тази причина и въстановения клок не може да се ползва за друго, освен за USB

- този фрейм на 1ms, който генерира SOF към таймера, дали въобще му се нормира фрейм-джитера? не мога и да преценя до колко е чиста хардуерна функция на USB хоста и дали се влияе от ОС. да, като излезе такъв фрейм и мине прз 1:8 суич към 8 клиента, вероятно SOF събитето ще е с константно propagation delay за всеки клиент.

- като влезе такова събитие в таймера... какво от това?

днес ми дойде много мисленето. или традиционно мисля по най-сложния начин, или не виждам нещо очевидно.

Това единствено може да "спести" синхронизиращите жици между устройствата, които мисля да сложа. Т.е. този SOF кепчнат евент да се използва като синхро клока от "мастер-а" до останалите в моята идея.

Това което не ми е ясно е тази 1mS хардуерно генерирана ли е от USB ХОСТ контролера, илиi ОС-а я клати по някакъв начин. Т.е. до колко може да се вярва, че SOF ще идва "абсолютно" периодично (завидещо САМО от ppm-ите на кварца в хост-а, а не от ОС-а или SW драйвери)

и Емо се чуди дали е 100% хардуерно - да 100% хардуерно се генерира и праща SOF. И тъй като от него зависят съспенда и други неща доста съм се борел против пращането му. Много трудно се спира насилствено Под бозата май беше почти невъзможно, под лайнукс писах в една друга тема как става.
Та SOF-а си тече постоянно и разпространението му е описано в стандарта, барабар с възможно най-лошия случай...

Иначе смисълът е че USB-то трябва да може да се ползва от един куп аудио и други класове дето силно зависят от тайминга. Още повече че концепцията на USB за гарантиран трафик и iso трансфери ще увисне във въздуха без синхронизация. Ако едно устройство очаква фиксиран обем данни по негов си тайминг и от друга страна USB пуска фиксиран обем по друг тайминг - то за отрицателно време фифо-тата ще получат запек. Та затова явно им се наложило малко по-подробно да обмислят варианти за синхронизация и в стандарта има 3 изброени метода.
В случая на Емо би му вършил работа и само SOF, без корекции, без нищо. Грешката от SOF е под 1us гарантирано.

miro_atc знаеш ли какво става със Start Of Frame SOF като мине през USB HUB? Повечето евтини хъбове са 7 портови. Вътре има 2 COB с GL850G или фейк на GL850G. Към единия порт на GL850G каскадно е свързан втория GL850G. И реално сигнала на 3 от устройствата минава през един чип GL850G, а 4 минават през два GL850G. Освен това мисля, че и в самия чипсет, където е USB контролера има допълнително 1-2 хъба дето разпределят USB1.1 и USB2.0 сигналите към различни "контролери" в чипсета.

Ако не се лъжа в USB хъбовете има "Transaction Translator" и USB1.1 сигналите се транспортират с USB2.0 скорост. Това може ли да омаже Start Of Frame SOF сигнала?

В смисъл? Ако намекваш че може би има устройства, които не следват стандарта... със сигурност има! И даже устройствата аз дето правя сигурно имат бъгове (софтуерни, щото другото не зависи от мен).

Това че вместо един 8-портов продават два четирипортови по принцип не касае стандарта, всичко е ОК стига да го спазват като такива. Що се отнася до закъсненията на SOF, разбира се че всеки хъб добавя закъснение и влошава джитера. Но като цяло не е нещо фатално щото закъснението през хъба трябва да е няколко наносекунди максумум. Даже и 5 хъба един след друг не би трябвало да е проблем.
Ето кво пише в стандарта:

Глава 7 (electrical specification)



7.1.19 Maximum End-to-end Signal Delay - дадени са максималните закъснения от хост до устройство и обратно (важат за какъв да е пакет)

В 7.3.2 Bus Timing/Electrical Characteristics има точни времена:
За full speed:
Frame Interval T FRAME 0.9995 ... 1.0005 [ms]
Consecutive Frame Interval Jitter max 42ns

В глава 11 има много писано за хъбовете и SOF...

че аз хъбове от магазина не ползвам от дестина години бре...
отделно, имах проблеми и с GL чип - някои флашки не се чуваха/разпознаваха през него, други (по-стари и малки) си бичеха.

С USB-то има само един проблем.... че Емо ще го подкара, ще го подкара, даже и китайските хъбове няма да го бъркат. Обаче как цяла седмица ще прави логове без да забие нещо не знам...

Е, ако нещо забие - забие. Какво да се прави .

Една част от SoC-овете имат USB, други нямат.

Гледам чипове на FTDI - например FT231x, които да се използват за USB to UART конвертори за вариант със SoC без USB.
FTDI- то има програмируеми изходи, на които може да се изкара сигнал при евент SOF.
Този сигнал ще се свърже към инпут кепчър в SoC-а.

Въпроса е може ли да се разчита на SOF сигнала от FTDI чипа? Т.е. дали софтуерно го клатят или хардуерно от USB контролера?
Не е проблем ако FTDI-я клатва този си изход с някакво закъснение спрямо детектването на SOF, стига обаче това закъснение да е константно.

Въпроса е дали закъснението е константно и дали е "хардуерно" ? някой задълбавал ли е в такава посока?

Няма логика да не е хардуерно, но...

Виж чаршафите, една сериозна фирма би го специфицирала като джитер и т.н. (без значение дали хардуерно или софтуерно клатене).

Не знам защо изобщо го мислите самото usb да синхронизира, ясна е идеята usb като източник а не медия но не при всички контролери нужните сигнали са достъпни. А относно генераторите и 500 ppm да са и 1000 да са не е толкова страшно, аз поне не го виждам така. Същата синхронизация я имам но с порядък два голямо време, обаче не виждам проблема вместо 100 да е 1 us, поне не и като разчет на ppl, температурна нестабилност и разминавабия в клоците, дори за конкретното нещо това може да става абсолютно автоматично, така че да се държи семпъл рейт с точност 1 us между всички у-ва.

Емо каза че предпочита USB като интерфейс за логването (май заради захранването... ).

От там насетне най-простото му решение за синхронизация са бъс циклите. Всякакво други решение изисква или допълнителни жици или софтуер на хоста или друго усложняване, което не носи никакви ползи (предимства спрямо SOF).

Миро, ако мина на вариант SoC + FTDI USB->UART, има ли в USB стека / протокола в PC-то възможност да се изпрати фрейм - нещо като бродкаст фрейм до висчки, който гарантирано да се приеме от всички преди следващият SOF (т.е. между два SOF пакета?
Целта е еднократно в такъв фрейм да се изпрати до всички устройства времето на комп-а "чч:мм:сс" и по следващият SOF всички синхронно да си сверят часовниците (еднократно). След това на всеки SOF ще си изчисляват само грешката...

(Кофтито в случая е, че ще се минава през FTDI, който ще буферира и препредава фрейма приет по USB-то и ще има някакво закъснение )

(Не съм се заровил все още в USB документацията, но това няма да ми се размине като се започне с имплементацията, та въпроса ми е по-скоро принципен)

Какви варианти има за да се направи началнoтo сверяване само през USB?