Xenia

Удивлена результатами голосования, в которых за запрет на удаление сообщений проголосовало почти 75% народа. Неужели никто не понимает, что разрешение на редактирование фактически тождественно удалению соббщения? Положим, что мне запрещено удалять свое сообщение, но разрешено его редактировать. Так как тогда этот запрет помешает мне удалить текст сообщения посредством редактирования, оставив в нем одну единственную точку или непечатный символ? И кому тогда будет польза от того, что на форуме останутся висеть пустые сообщения? Администрации? Я хочу, чтобы все поняли, что сообщением по сути является его тест, а не рамочка! И если разрешить пользователю удалять текст, но запрещать удалять рамочку, то чего этим достигнем? Порядка? Как бы не так!

Вот такие отладочные платы продаются в Терраэлектронике: Это AVR-IO-16 или AVR-IO. Там четыре релюшки RAS-1215, каждая на ток 10А (при 250V) или 15A (при 120V). Дорожки от контактов реле там толстые и короткие. Так что если токи большие, а скорость реакции высокая не нужна, то может быть лучше реле поставить? Заодно решится проблема с гальваноразвязкой, т.к. последняя в этом случае не нужна. И в применениях типа "умный дом" годится, освещением управлять. Ну, стиральную машину или там электроплиту лучше не подключать - не выдержит, а утюг запросто.

А Тайвань стало быть не Китай? Он что же, отстал от Китая? Ведь вроде бы раньше было наоборот (имею в виду процессоростроение, а не объем ВВП).

Кто-нибудь в курсе, где производит свою продукцию STMicroelectronics? А то у меня волосы дыбом встают :), глядючи на ту скорость, с которой она выбрасывает на рынок всё новые и новые образчики своей продукции. И главное, не на бумаге, но и на прилавке. А теперь вот еще "нагло" встряла в область 8-битников своим STM8, пользуясь тем, что из-за торможения Atmel там образовался дефицит. "Очень жаль, что наш Atmel не догонит их никак" (С) Дядя Степа милиционер :)

UC и AP - это фактически одна и та же архитектура AVR32. А прокол с AP произошел только из-за того, что из него выдрали flash и потащили позиционировать в сферу Linux. А там такой не нужен :), т.к. в сфере Linux: 1) и без него тесно, 2) имеются гораздо более быстрые процессоры по тактовой частоте, среди которых 133 МГц - не ах. А мне казалось, что Intel его Marvell сбагрила.

Любая фирма, которая продвигает СОБСТВЕННУЮ архитектуру, - самобытна по определению! Intel, несомненно, тоже самобытна, а потому не станет делать ARMов :).

Всё в точности до наоборот :). Повальное увлечение наблюдается как раз ARMами, которые на волне моды клепают, кто во что горазд. А уж Atmel'ю стоило бы сохранить самобытность и не пускаться во все тяжкие в догонку за ARM-клепателями.

А что если взять VID/PID от Микрософта? Вот здесь приведен ini-файл http://pastebin.com/mnG8fNVQ "Windows USB CDC ACM Setup File" Берем этот ini-файл, как есть, и вот что получаем: 1. Драйвер виртуального COM-порта USBSER.SYS, входящий в поставку Windows, кто писал? - Microsoft! А стало быть VID и PID указаны в ini-файле правильно. Не подкопаешься. 2. Конфликт устройств не возможен в принципе. Ведь если вдруг найдется иное устройство (не ваше) на том же компьютере, то его драйвер (USBSER.SYS) вам заведомо подойдет. А если ваше устройство будет воткнуто первым, то тогда ваш драйвер (тот же USBSER.SYS) тоже заведомо подойдет для любого чужого устройства, с которым у него VID и PID одинаковы. Здесь игра идет на том, что используются драйверы от Microsoft, входящие в состав операционки (для HID такой тоже вроде бы есть), а потому, используя ini-файл с Микрософтовским VID и PID, мы ничего вроде бы не нарушаем, т.к. ЭТА пара VID и PID уже зарегистрирована Микрософторм на нужный нам драйвер (USBSER.SYS или HIDUSB.SYS). Единственный минус такого решения - нелегальность замены имени Microsoft на имя своей конторы, и изменение имени "Communications Port" на что-то более конкретное.

LAPACK - исчадие ада :), где любой, даже простейший алгоритм, оказывается разбит на огромное множество функций. А уж переводить с Фортрана на С удовольствие маленькое, и хотя это на первый взгляд не очень сложная работа, но ошибки лепятся только так. Лично мне по душе алгоритмы из Справочника. Он так и упоминается везде как Справочник с большой буквы, ибо это есть непревзойденный Уилкинсон Дж., Райнш К. — Справочник алгоритмов на языке АЛГОЛ. Линейная алгебра. То что, там используется язык Алгол, пугать не должно - тот язык интуитивно понятен каждому, кто уже знает С. Зато огромный плюс в том, что матрицы в Алголе имеют двухиндексную адресацию, подобно С, а не идиотскую фортрановскую систему держать матрицы в одномерном массиве, изощряясь исчислением в нем индекса. P.S. Если кто знает, где можно добыть этот Справоник в электронном виде, - отзовитесь! Мечтаю такой иметь, но все, что удается скачать из интернета - под паролем "пошлите SMS-ку", а там деньги списывают, а пароля не дают.

Неправильно понимаете :). Частота никогда не бывает ни только мнимой, но и комплексной. Частота - всегда действительное (реальное) число.

А как вы полагаете, если купить эту лицензию, то можно прописывать название своей компании (в USB_MANUFACTURER_NAME) или все равно придется писать какой-нибудь Objective Development или GNU?

Спасибо за благую весть! :) USB-интерфейс до сих пор еще в полной мере недооценен, как блочный способ передачи. Его все еще продолжают по инерции рассматривать, как модерновую замену RS232, хотя между ними различий больше, чем сходства. Любые варианты реализации обмена, в которых прерывание вызывается по приему/передаче каждого байта становятся не просто неэффективными, а уже расточительными при высоких скоростях передачи. Будущее за аппаратными средствами, которые "сами" пересылают содержимое буфера по флагу готовности или с помощью DMA. Прерывания на каждом байте, типа UARTа или SPI, - прошлый день, а выдача параллельного TTL сигнала шириной в целый порт МК и его стробирование - позапрошлый!

Девайсину проверяет Windows в момент, когда устройство втыкается в USB-порт компьютера. Осуществляется это исключительно на основе сравнения inf-файла с данными, полученными путем опроса устройства (дескрипторов спецификации). Очень сомнительно, чтобы кроме VID/PID что-то еще проверялось на жесткое соотвествие. В том числе и стринги названия устройства и его производителя. Конечно, если бы это было всегда так, то этому надо было только радоваться, только что-то мне в это не верится. Вся эта бодяга с регистрацией VID/PID происходит лишь по той причине, что если эти цифры каждый будет брать с потолка, то может возникнуть ситуация, когда Windows установит для вашего устройства чужой драйвер (это еще пол беды) или установит ваш драйвер для чужого устройства (а это уже беда, т.к. пользователь может обратиться с жалобой к производителю легального устройства, а те в два счета разберутся, кто здесь пират). Причем никакими ухищрениями со "своей программой" или драйверами эту проблему не решить. Даже если ваша программа распознает, что ее запустили на чужом драйвере, то все равно не сможет запустить повторно процедуру распознавания или потребовать смены драйвера. А уж чужое устройство, с которым вы конфликтуете, заведомо не станет этим заниматься, т.к. его производитель купил легальный VID/PID и не станет заморачиваться тем, чтобы достигнуть совместимости с пиратскими изделиями. Есть у меня еще одна идея. Если вы используете не специальный драйвер, а стандартный USBSER.SYS (поддержка режима CDC), входящий в поставку Windows, то тут мог бы по идее годиться VID/PID любого устройства, которое использует стандартный дравер. При этом конфликт бы не возникал даже в том случае, если бы бы несколько USB-устройств имели одинаковые VID/PID. В это случае они бы "разошлись" на том, что получили разные номера виртуальных COM-портов. Тут безальтернативно - Windows никогда не даст одинаковые номера COM-портов разным устройствам, даже если они полные близнецы. В этом легко убедиться, если воткнуть два одинаковых ваших устройств в один и тот же компьютер. Т.е. фактически тут случай полностью аналогичный втыканию в компьютер разных флешек - всем им устанавливает один и тот же стандартный драйвер, не требуя уникального inf-файла. А буквы removable дисков они получат разные. И очень жаль, что для флешек такой механизм сделали, а для CDC-устройств нет. Вот только такой VID/PID я до сих пор не нашла...

FT232 - фактически второй МК (пусть и специализированный под USB-порт), и стОит он практически столько же, сколько обычные МК. А идею ставить второй МК только затем, чтобы нахаляву использовать чужой VID/PID, трудно назвать слишком удачной. Если бы дело было только в том, что FTDI выдает бесплатную лицензию, то можно было бы попросту воспользоваться ее VID/PID, ибо во внутрь устройства все равно никто не полезет, чтобы проверять в нем присутствие или отсутствие FT232 компонента. Пристрастие к FT232 или прочим переходникам USB-TTL с головой выдают тех типов, которые привыкли решать все проблемы с помощью паяльника :). Видимо схемотехнику они освоили, а программирование нет :).

Имеете полное право, если у вас есть легальные VID/PID. Тем более что они выдаются на устройство, а вовсе не на микроконтроллер. Есть еще одна идея: использовать VID/PID из демо-проектов, сорцы которых выложены на сайтах компаний-производителей МК. Очевидно, что эта пара VID/PID не может быть кому-то продана :), а потому ваше изделие окажется заведомо уникальным по отношению к любым легально производимым устройствам.

Ваше требование некорректно :). В вашем примере FFT применяется для сжатия сигнала (к более компактной форме представления/хранения), а потому о концевых эффектах там просто нет речи - важно лишь, чтобы обратное FFT воспроизводило исходный сигнал достаточно хорошо. Здесь мы имеем тот эффект, что последовательное применение FFT и iFFT (если ничего не обрезать в промежуточном частном образе) тождественно воспроизведет (дискретный) оригинал. И это несмотря на любые краевые эффекты. Но если нам нужно частотное представление само по себе, например, для гармонического анализа анализа или получения свертки, то с "краевыми эффектами" мириться нельзя. Ибо разрыв (ступенька между уровнями) на краях массива порождает при FFT дополнительные частоты, которые на самом деле во входном сигнале отсутствуют. И в этом можно легко убедиться, если использовать обычный метод FT (не Fast). В принципе можно с определенностью сказать следующее: все три метода (зацикливание, дополнение нулями и дополнение линейным трендом) грешат против истины. В самом деле, при вычислении сверки прямым способом в конце массива создается ситуация, когда в результате относительного сдвига двух сворачиваемых функций приводит к неопределенной ситуации - первая функция "кончилась", выйдя за область, где мы знаем ее значения, а вторая функция еще нет. Если в этой ситуации мы решаем довольствоваться частичной суммой произведений, то это будет эквивалент заполнения недостающей части нулями. А если же решим, что "закончившаяся" функция периодична и решаем скопировать недостающие точки из ее начала - это то, что делает FFT. А мой "трегольник" - это попытка обмануть FFT, подсунув ей данные, на которых принудительная "циклизация", которую делает FFT, приносит наименьший вред (в случаях, когда периодичность исходной функции заведомо отсутствует). Величина этого вреда может колебаться в широких пределах, в зависимости от того, насколько совпадают все эти три предположения (о дальнейшних значениях функции) с реальностью. В случае, если исходный сигнал - чистая гармоника, да еще и уложившаяся в интервал целым числом периодов, то, конечно же, FFT тут победит, т.к. ее "преположение" о перирдическом характере сигнала полностью оправдалось. Да вот только не бывает на практике таких удачных совпадений. И если вдруг окажется, что за переделами участка сигнал какой-то другой, то преположение о периодичности и цельно-кратности периодов окажется лажей. В этом случае ошибка может быть очень большой. Заполнение нулями - это согласие на среднюю ошибку. Она окажется больше, если в периолд удалось вписаться, или меньше, если вписаться не удалось. Т.е. здесь мы уповаем на нулевое среднее того сигнала, продолжения которого не знаем. Вообще-то это не такое уж плохое предположение. Ситуация становится из рук вон плохой, когда мы решились на нулевое среднее, но продолжаем использовать метод FFT. Вот тут-то нас и подстерпегают сюрпризы из-за того что FFT-пребразование апроксимирует гармониками те разрывы непрерывности, которые имеют место (в точке перехода крайней точки на нуль и точку перехода нуля на первую точку). И вот именно с этим эффектом борется "метод треугольника", делая этот переход наиболее плавным.

Где ж это в практических случаях бывает, чтобы изменяемая гармоника да уложилась бы что в целое число периодов в массив данных? Вы привели выгодный для себя пример :). А давайте я вам приведу пример, когда гармоника (предположим, косинусоида) заканчивается "неудачно". Скажем начала косинусоида значение +1, а занончилась -1 (минус один), пол периода ей не хватило. Знаете, как гадость тогда получается? Одной палкой даже не пахнет :). А вот мой метод с такими случаями отлично справляется. И пусть там не чистая палка, но боковых липествов посчи нет. И что из того, что нелинейно? Откуда у вас такая приверженность к линейности и отвращение к нелинейности? Линейным преобразованием из сигнала даже большую гадость можно сотворить, чем линейным :). Опять же сейчас речь идет не об усилительных каскадах, где нелинейные искажения почитаются грехом, а о совершенно иной задаче. Основания моих слов имеются, причем они примерно такие же, как причины выбора формы окна при фильтровании в частотной области. Ведь никто же не режет отсечкой с некоторой частоты, поскольку знает, что за этим поледует. А последует "зашумленность" той самой граничной частой (при обратном FFT), по которй обрезали. Поэтому если и давят частоты, то осторожно - так, чтобы коэффициент подавления сходил к нулю плавно. И тут кто во что горазд: и треугольное окно, и косинусоидное, и гауссовый профиль, и т.п. Дополнительный треугольник, достоенный в исходной области данных - наименьшее зло, по сравнению со всеми остальными случаями, когда краевые точки массива сильно отличаются по величине. Причем сам треугольник ведет себя на редкость смирно. Можно построить "домик" (линейное возрастание до середины массива с убыванием его во второй половине массива к начальному значению). Тут "мусор", порождаемый таким треугольником слаб, а амплитуды частот изменяются непрерывно, без каких либо максимумов. Анализировать спектральные данные (наложенные на этот треугольник) это не мешает. Опять же естественные процессы линейного дрейфа сигнала есть ни что иное, как добавление аналогичного трегольника. Поэтому такую форму искажения тоже можно считать естественной, присущей реальным задачам обсчета временных трендов.

Попытка не пытка! Тогда уж я еще одно новое слово скажу :) В чем, собственно, недостаток FFT в практическом смысле? В прежде всего в его циклическом характере. FFT преобразует массив так, как будто он закольцован, хотя на самом деле этого нет. Вот практический тому пример. Положим, мы преобразуем массив данных, полученных от АЦП. Причем измеренный сигнал имеет некий линейный тренд, выражающийся в том, что уровень сигнала в первой точке массива не совпадает с уровнем в конечной (например, база сигнала постоянно повышается со временем). Такое поведение входного сигнала довольно обычно и называется дрейфом. Однако FFT-алгоритм нам на зло станет рассматривать этот массив, как свернутый в кольцо, а потому усмотрит в нем чудовичный разрыв непрерывности в том месте, где происходит склейка в кольцо. Из этого "уступа" в частотном образе сигнала появятся большие вклады не только высокочастностных составляющих, но и низкочастотных. И все лишь для того, чтобы этот уступ воспроизвести. Можно, конечно, окнами с ними бороться - это традиционный путь. А вот я "изобрела" совсем простой путь, но исключительно эффективнный. Он состоит в том, что надо дополнить массив (примерно в два раза до следующего размера, кратного степени числа 2), но только не нулями! Вместо нулей следует в этом месте провести НАКЛОННУЮ ПРЯМУЮ ЛИНИЮ, которая одним свои концом исходит из последней точки исходных данных, а другим концом должна дойти до конца рассширенного массива именно на тот уровнь, соотвествующий первой точке исходных данных. Тогда при склейке в кольцо окажется, что переход получился максимально плавным. Такой метод практически не дает паразитных вкладов в частотный спектр, возникающих из-за перепада уровней на концах массива данных, а потому и не нуждается ни в каких окнах или дополнительных фильтрах.

Цикличность свертки это и есть причина краевых эффектов :)

Есть еще участник с ником "Горбачев" (это его второй ник, т.к. под первым он был забанен), который ... не любит нашего Zitigo! Вот за это таких, как Горбачев, надо банить навечно! :) :) :)

Если вы достигните своего желания получить FFT на 768-точечном массиве, то у вас получится циклическая свертка. А вам оно надо? В большинстве практических случаев нужна простая свертка, а не циклическая, поскольку образ, находящийся в массиве 768, вряд ли периодический. Дополнение же нулями до 1024 здесь очень удачно еще и тем, что как раз добавляет к исходному массиву данных нулевой кусок той же самой длины, как и длина функции, с которой станут сворачивать. Такое добавление является как раз минимальным для того, чтобы вместо циклической свертки получить нормальную. Более того, даже если бы ваш массив был длиной 512, что позволило бы легко преобразовать его в FFT-образ, то и в том случае стоило бы подумать о целесообразности дополнения его нулями до 1024, чтобы избавиться от циклической свертки. А у вас длина массива просто идеальна для получения нормальной свертки, т.к. 768+256=1024.

Быть может здесь было бы проще дополнить массив 768 нулями до массива 1024 и действовать обычным образом?

Мое мнение по поводу "утилизации младших разрядов" категорично - их ни в коем случае не следует обрезать, а тем паче сглаживать в момент сбора. Все должно "доехать" до главного компьютера в целости и сохраности. Фильтрация данных - это особая статья, которая, как правило, требует учета ВСЕЙ имеющейся информации. В то время, как МК, работающий непосредственно с АЦП, не должен заниматься этой работой, поскольку on-line фильтрация на порядки уступает по качеству тому, что можно достигнуть при полном анализе данных. Встроенный МК, будь он хоть DSP, не имеет доступа ко всему массиву данных (вследствие его большого объема), а вынужден работать в окне, ограниченного размера. Это обстоятельство резко снижает число способов, которыми может осуществляться фильтрация. Впрочем, такой подход возможно и был бы допустим, если бы в задаче был только один канал, но не множество подобных. В последнем случае используются гораздо более эффективные фильтры, построенные на принципе многомерной регресии. В общих словах этот метод основан на том обстоятельстве, что "полезный сигнал" (биотоки мозга) очень сильно коррелируют между собой, а в соседних отведениях (близко расположенных друг к другу электродах) почти одинаковы. Это дает очень эффективный способ фильтрации, основанный на взаимной корреляции полезного сигнала во всех отведениях, когда как случайный шум (тот самый, из-за который дрожат младшие разряды) практически не коррелирован. Благодаря этому можно понизить (редуцировать) размерность матрицы 256xN, урезав ее ранг. При этом случайный шум пропадает и оказывается, что младшие разряды тоже несли полезный сигнал, который скрывал наложенный шум. А слабые по амплитуде ритмы мозга, как правило, можно выделить только так. Вот только чтобы применять такие методы нужна если не вся матрица 256xN, то хотя бы квадрат 256x256 (с квадратными матрицами часто бывает проще работать), в то время как встроенный МК "гонит поток" (столбцы этой матрицы), что мешает работать со строками. Кроме того, исходный массив данных всегда желательно сохранять, чтобы иметь возможность применить разного рода алгоритмы фильтрации и выбрать из них те, что лучше всего подходят. Поэтому фильтровать данные аппаратно (здесь алгоритмом, заданным прошивкой МК) крайне не желательно. Тем более что сырая информация позволяет легче разобраться со всевозможными неполадками типа выбросов, которые на отфильтрованной картинке могут быть уже не видны. К сожалению, 50-герцовая помеха не может быть отфильтрована таким способом, т.к. на всех каналах она скоррелирована, но для этого существуют свои методы, основанные на фурье-преобразовании и фильтрации по частотному спектру. А на самодельной установке фильтрация - это самое последнее, чем стоит заниматься. Главное обеспечить две вещи: 1) Чтобы сигнал не уходил за границы шкалы АЦП (не зашкаливал). Между тем тенденция к зашкалу здесь очень сильная из-за того, что сигнал приходится сильно усиливать (чтобы разглядеть мелочевску), а при этом область полной шкалы в миливольтах сужается. И чуть что - база сигнала уезжает то вверх, то вниз. Опять же в точках соприкосновения металлического электрода с кожей, намоченной пОтом, возникает микро-элемент со собственной ЭДС, весьма не хилой. Поэтому раздобыть заводские электроды крайне желательно. 2) Чтобы сетевая наводка 50 Гц не зашкаливала. Пока она находится в пределах шкалы - не страшно, цифровые методы фильтрации с ней в последствии справятся. Но вот как только она "войдет в насыщение", задев своим краем край шкалы, то тогда дело плохо. Такой участок ЭЭГраммы точно испорчен и никакой математикой его не исправишь. Поставить на входе фильтр-пробку на частоту 50 Гц достаточно сложно, т.к. такой фильтр должен быть исключительно избирательным, т.к. на 40 Гц уже находится бета-ритм.

В "гигабайты" автор топика, сокрее всего впишется. Как, впрочем, вписались в USB-трафик создатели промышленного прототипа. Тут есть та особенность, что АЦП зачастую гоняют на большей скорости, чем это необходимо. Причина в последовательном обслуживании каналов, посредством встроенного мультиплексора. Поэтому с каждым тактом пребразования мы получаем не все 256 значений, а в несколько раз меньше. В принципе это плохо, т.к. все данные по каналам дожны быть синхронными, однако технически невозможно поставить 256 АЦПов на каждый из каналов. Те микросхемы квадро- и окто-АЦП, которые предлагает TI, на мой взгяд, просто замечательные, т.к. они вроде бы обеспечивают синхронную оцифровку всех каналов. Как это у них реализовано, сказать трудно. Может быть они на входе "защелкивают" входные напряжения, а потом оцифровывают их по очереди? Точный ответ мне не ведом, но только их конструкция действительно работает. В частности квадро-АЦП используется для определения сдвига фаз для контроля за перекосом фаз в сетях трехфазного тока. При этом 3 канала АЦП измеряют фазы, а 4-ый канал - общую точку относительно земли. Причем всё работает на удивление хорошо, чего бы никак не могло случиться, если бы АЦП обслуживал каналы по очереди через входной мультиплексор. Реально каждый из 256 каналов должен опрашиваться не чаще 2-3 КГц. Это где-то 10-15 Кбайт/с на канал (из расчета 5 байт на точку), и того в сумме - 2.5-3.5 Мбайт/с. Вроде бы не страшно, USB2.0 должен с этим справиться.

Всех проблем с сетевой наводкой активные электроды не решают, поскольку источник помех - не повода, а само тело человека. Если не верите - дотроньтесь пальцем до щупа осциллографа и посмотрите насколько вы "газите". Тот же эффект получится, если дотронуться пальцем до входа звукоснимателя радиоприемника. Синфазную помеху, естественно, давят, однако большой вопрос, насколько это удается качественно сделать. Конечно, если амплитуда входного сигнала достаточна, то здесь подавление помехи проходит удовлетворительно. Например, кардиограмму снимать не мешает. Однако потенциалы мозга на порядок меньше импульсов сердечных сокращений, а потому на субмикровольтовом диапазоне помеха не просто велика, а явно доминирует над полезным сигналом. Проблема усугубляется еще тем, что вход должны быть достаточно высокоомными, т.к. от головы измеряются именно потенциалы, а не электрический ток. Будь входное сопротивление поменьше, то помеха не так бы сильно мешала. Лично я "синфазный" электрод в рот брала :), но и то не очень помогало. Уже интересно. Поделитесь входной (аналоговой частью), где брали схему? Что же касается перехода от 16 бит на 24, то тут все просто и тривиально - берете другой АЦП и всего делов. Это когда-то прежде многоразрядные АЦП были медлительными, а нынче скорости у них большие (по меркам ЭЭГ конечно). Нет здесь сложности - 24-х битные измерения ничем существенным от 16-битных не отличаются. Только лишний байт данных получите. А вот быстрый микроконтроллер вам понадобится, хотя вовсе не обязательно DSP, т.к. вам вычислять скорее всего ничего не придется, а придется шустро передавать, и при этом успевать формировать посылки. Тут дело такое, что просто кидать эти 3 байта в поток нельзя: малейший сбой - и вы не разберетесь потом, где первый байт, а где последний. Кроме того, ошибка нарушения синхронизации распространится на всю дальнейшую цепочку байт. Поэтому вам придется отказаться от идеи передачи нативных данных, а осуществлять формирование блоков (посылок), которые будут содержать в себе признаки синхронизации и, возможно, контрольную сумму. Помимо того, в блоке придется, по-видимому, указывать номер канала, к которому относится измерение. Из-за этого объем передаваемых данных увеличится еще в 1.5-2 раза против чистых данных. Тем более что АЦП вам придется обслуживать по прерыванию от сигнала готовности, а такой сигнал может поступить первым от любого из АЦП. Сами АЦП, сколько бы их ни было, запускать от одного и того же кварцевого генератора - это обязательно, т.к. все каналы должны быть строго синхронизированы, иначе кросс-кореллограммы получатся дефектными (будет решено, что задержка происходит в мозгу, когда как она от неодновременной работы АЦП). А данные опять же придется буферизировать, нужна память и скорее всего внешняя. Отсюда вытекает, что ваш микроконтроллер должен обязательно иметь USB на борту и очень желательно c DMA поддержкой. И копаться со всем этим придется вам самим, а это ох как не просто! И даже не рассчитывайте, что поставите какой-нибудь Линух или RTOS и будете на дурика побайтно в порт писать. Нет, тут уж вам самому придется все это делать, причем на самом низком уровне. И это лишь малая толика тех трудностей, через которые вам предстоит пройти...