SOF е единственият broadcasr, но освен че не можеш да си говориш едновременно, по принцип трудно се говори с повече от едно устройство. Още повече ако разнородни както ти планираш да ползваш FTDI, то е нестандартно устройство изискващо къстъм драйвер. А устройствата ти дето имат USB най-вероятно ще се спреш до стандартен CDC клас.
Ако питаш мен не ти трябва FTDI, доколкото разбирам една част от устройствата ти имат USB, така че за тях ти трябва само таймерче и да видиш как да синхронизираш това таймерче всяка милисекунда с USB-то. Самият SOF съдържа 11-битово време в милисекунди, така че това би трябвало да ти е напълно достатъчно.
Въпросът е другите ти устройства какви интерфейси имат. Едва ли имат нещо достатъчно бързо, а и да имат се опасявам, че много ще ги натовариш със синхронизацията. По-скоро ако не са много типовете евенти, да ги изкараш през пинове примерно или пък когато имаш евент да клатиш, така че външно USB контролерче да прави таймстампове и да ги вмъква в стрийма (евентуално на правилното място).

Миро, благодаря ти много за инфото и идеите !

Не знам какви са контролерите които синхронизираш, варианта да използваш USB може би е ОК, стига те да го имат и да може да го използваш по подходящ начин.

Здравей,
Не можах да прочета подробно всичко писано до тук.
Подобно правим с RS485 полудуплекс. На обща шина са устройствата. Подава се да речем на всяка секунда стартов байт от мастер устройството. Това е добре да се прави хардуерно (FPGA), ако се гони точност освен синхронизация. Ако ги предвидиш таймингите на работа на устройствата да не обработват прекъсвания по това време, плаването по време би трябвало да е 1 такт. Даже си мислех, да нямат кварцове, а да променям корекцията на RC вграденият регулатор, за точност- нещо като софтуерно регулируем PLL. Но не съм го направил за сега, че и така мина тестовете. По-нататък в комуникацията можеш да си направиш да предава от коя периферия иска данни и да ги получи. Аз ги редувам на всяка сек по една бавна. След като свърши комуникацията, да има доста време всички периферии да приключат активна работа и да чакат следващият синхро сигнал. При мен е към 20милисек преди това. RS485 поддържа скорост до 2Мбита поне. При тази дължина- разстояния няма и да ти трябват трансмитери, но ще трябва да им измислиш енейбъли за предаването на ТХ.
Ако ти хареса идеята и ти трябва още нещо- питай.

Това за без трансмитери е опън дрейн. Сега се присетих, че на платката можеш да го реализираш като LIN със съпротивление към захранване. За тези разстояния- скорости, ще стигне.

Идеята на Миро е добра и изглежда да е подходяща за доста случаи. Ще е много полезно ако някой качи резултати от измервания на SoF таиминга в реални ситуации. Предполагам че всичко си е хардуерен тайминг, закачен през буфери и дма-а и като нищо може да се окаже доста real-time. Имам предвид че съвсем реално е хардуера в хоста (ПЦ) да изпълнява нещата достатъчно синхронно за определен кръг приложения.

Едит: това дава детайли на ниско ниво за контролерите, конкретно UHCI. Точка 2.1.6 например ми говори че SoF си е баш хардуерно генериран:
ftp://ftp.netbsd.org/pub/NetBSD/misc/blymn/uhci11d.pdf

Тцъ-тцъ, всичките тези постове за това ли бяха ?
Ми ако е това, връзваш всичките 8 устройства по CAN bus, правиш си един конвертор USB към CAN с HID класа,
намират се и готови решения като open source и open hardware. USB Host изпраща фрейма с часа, конвертора
праща broadcast на всички CAN nodes, след което си програмираш конвертора самостоятелно (без намесата на
USB-то) да праща синхро сигнала (SOF) като CAN message на определено време. По между синхро съобщенията
може устройствата да изпращат по едно съобщение за обратна връзка.

Това работи при едно условие - на протоколно ниво да "резервираш" времевия интервал около SoF-а само за мастъра който праща този фрейм - ако в този момент някой друг (или дори и мастъра) е пуснал вече нещо по бъса "SoF"-а ще закъснее - 1Мбит/с при пълно съобщение може и над 100мкс да закъснее.
Затова в IEEE1588 е мислено физическия слой да знае времето (64битов наносекунден таймер) да може on-the-fly да втъкне таймстампа точно при излизането на фрейма на бъса. Дори да има конфликт на бъса и фрейма да закъснее то таймстамп-а в него ще отразява реалното време на излизане на бъса.
В приемната страна е същото - имаш отделен таймстамп който ти показва какво е пишело в твоя 64-битов наносекунден таймер в момента в който е влязъл фрейма. Така директно, на хардуерно ниво, получаваш стойностите на мастър таймера и на твоя таймер в един и същ момент от времето. Разликата директно е твоя (на слеива) офсет спрямо мастър времето и знае къде и как да се мърдаш докато го докараш да се на едно.
В етеркета има една начална фаза на синронизиране (преди да се влезе в работния режим) при която мастъра бълва фреймове като ненормален - общо взето пълни бъса. Няколко десетки хиляди фрейма например. През това време се измерват закъснения, трупат се статистики и се разплита точно кое как стои едно спрямо друго. За да работи се очаква "switch-овете" (които там обикновено са самите слейвове - входна дупка и изходна дупка - ринг) да има малки и стабилни закъснения. Мери се от вход до изход, което включва двете фи-та и свича. Типично са около микросекунда. Това разбира се няма как да стане със "store and forward" switch-ове, затова са специални. Но то real-time етернет без специален свич няма как да стане.