Добрый день.

Есть девайс с FT232R<->uC (обмен по УАРТу). АЦП микроконтроллера делает замеры по шести каналам + считывает некоторые данные на плате по I2C. Все эти данные должны передаваться на FT232 и далее на ПК по USB. Разработка девайса складывается из нескольких этапов, после каждого из которых предполагается полноценная работа устройства. На первых этапах скорость передачи не критична, 10-100мс влево-вправо (что называется «+- трамвайная остановка»). Но на последних этапах разработки ожидается нечто приближённое к осциллографическим функциям. Частота сэмплирования АЦП 1.1МГц. Собственно есть несколько вопросов:

1. Какой протокол верхнего уровня выбрать для этих целей? Сразу с прицелом на последние этапы разработки (выдача оцифрованных данных от 6-ти каналов с достаточно высокой скоростью + данные от I2C). Modbus ? Что вообще применяется (какие протоколы) в цифровых осциллографических приставках к ПК ? Что-то стандартное, или производители сами лепят, кто во что горазд?
2. Обработка на стороне ПК (используется драйвер D2XX): мануалы и исходники FTDI предлагают использование Таймеров, заряженных на 50мс: в каждом таком «псевдо»-прерывании читаем буфер и обрабатываем его. Но мне кажется, что использование потоков более стабильно: для потоков Винда выделяет более стабильные промежутки времени, чем на таймер. Или я ошибаюсь? Есть ли какие-то ещё варианты ? Не хотелось бы изобретать велосипед.

Заранее благодарю за любые комменты и предложения.

Если есть АЦП и есть желание сделать осциллограф то нужно в протоколе иметь привязки по времени или порядку следования передаваемых кадров с данными. Еще не понятно как непрерывный поток с 6ти АЦП с неизвестной разрядностью плюс избыточная информация протокола будут передаваться через уарт на такой скорости. Тут USB2 нужен.

По временным привязкам - я так в общем-то и думал. А по скорости передачи - многие цифровые осциллы передают данные "окнами", размер которых зависит от имеющийсся на борту памяти. Поэтому говорить о непрерывном потоке наверное не стоит. Хотелось бы понять структуру этих пакетов-окон. И собственно как это обрабатывается на ПК. Есть ли какие-то более-менее стандартные методы. Даже не столько стандартные, сколько правильные, стабильно и корректно работающие?

Вам нужно что то простое, где будет начало пакета , временные метки, или порядковый номер,данные и контрольная сумма.
Зачем вам модбус, у вас же нет кучи устройств на шине с двухсторонним обменом?
У вас по сути идёт поток в одну стороны и (иногда ) командами в обратную.
Придумайте сами.

Да в общем-то в процессе уже. Просто думал что пока процесс идёт, может кто свежих идей подкинет. В любом случае спасибо

Тут есть статейка кажется в тему:BE-BDN

Протокол Wake. Байт-стаффинг...