stm32 передать в ком поток 49мБит, в какую сторону думать? Опции

[diwil]

Уважаемые,

до этого меня устраивала скорость около 4 мбит на f405 через usb fs.
сейчас возникла необходимость передавать в комп примерно 50-60 мбит.

Я накапливаю эти данные в проц через 2 SPI и система работает следующим образом:
* ОСи нет.
* каждые 16мс по одному SPI накапливается 8*8*16*2 = 4кБайт
* по второму 3*2*960*16 = 92160 байт.
оба SPI синхронизированы, поэтому я знаю когда мне надо данные вычитывать и передавать.
И вот по этому событию (прерыванию от дма) я хочу передавать данные в комп.

Принимать от компа данные... ну может байт 60 раз в секунду.

Поток, который надо (92160 + 4096)*8*62.5 = 48.128 мегабит (теоретически) + еще чуть-чуть.

Необходимо выбрать транспорт.
* USB FS отпадает. Хотя и хорошо работает вплоть (я пробовал) до 4мБит.
* Поскольку мне необходимо использовать двойной буфер + буфер для отправки данных, то мне нужно минимум 300к памяти.
* А это только Н7.
* поскольку у меня места мало, то могу использовать только 100 или (хуже) 144 -х ногие корпуса. А в них нет USB HS.
* Внешний PHY для USB HS у меня плохо влезает, конфликтует с другими девайсами и сильно по корпусу раскидан. За сим:
* Я думаю в сторону изернета.
* из доступных примеров я нашел только реализацию на LAN1820/1842. Там тоже все ноги по корпусу раскиданы, но его я смог его развести.
* но я не нашел внятных примеров как оно работает.

Поскольку у Н7 косяк - нет физики HS, то, похоже, хоть и с внешним MII, ETH выигрывает.

За сим вопросы:
1. LwIP без оси работает? Надеюсь, что да.
2. Если да, то операция записи в сокет сколько за раз данных проглотит? (в BSD машинах оно может втянуть в ядро сразу все за один вызов write() или send() а потом само передавать)
3. Если оно в таком виде работает, то можно ли в LwIP, открыть сразу 2 сокета (разные порты) и типа слушать их чем-то типа select() ?
4. И вообще, 50МБит получится?

Я проискал посмотрел, но кроме общих слов ничего внятного не нашел...

Заранее благодарю.

[Rst7]

То есть частота периферии кратна 48к. Красивое решение.

Не совсем. Сигнал LRCK генерируется банальным счетчиком (74HCчего-то, делитель на 256) от сигнала MCLK, а сигнал MCLK генерируется микросхемой AK4114, это в одном флаконе SPDIF-приемник/передатчик/тактовый генератор. Так исторически сложилось, потому что в качестве первой жертвы для экспериментов была взята карта Tascam US-1800 (ее собственная USB-часть была безжалостно отрезана путем завешивания местного процессора в z-состояние, использовалась только аналоговая часть плюс ЦАП/АЦП и SPDIF). А вот дальше начинается интереснее. Сигнал LRCK заведен на внешнее прерывание у моего процессора. По этому прерыванию процессор запускает собственный генератор BICK (сделаный из PWM), он же является сигналом запуска DMA (при помощи кое-каких извращений через дополнительный таймер), и на каждый фронт BICK происходит передача одного байта с порта в ОЗУ и наоборот (два канала DMA используются). Когда отрабатывается все 32 бита в протоколе I2S (у меня это превращается в 32 байта, ибо в одном байте сразу 8 сигналов данных), генератор BICK останавливается до следующего фронта/спада LRCK. Практически с точки зрения загрузки процессора это все ничего не стоит.

Можно и с аппаратно генерируемым BICK (чтобы он был красивым и синхронным с MCLK, как рисуют в даташитах), просто так, как у меня (со своим генератором), исторически сложилось. А на самом деле к BICK нет требований по синхронности с MCLK/LRCK. Может, конечно, кому-то и надо такое, но AKM'овским АЦП/ЦАПам пофиг.

А как ведет себя система, если нагрузить юзер спейс, к примеру тяжелыми дисковыми операциями? Можно пару слов о вашей аппаратной конфигурации?

Ну вот у меня Cubase в качестве DAW. Я на нем по 16 треков одновременно пишу, причем еще и обрабатываю для выдачи - я так концерты полноценные вживую озвучиваю, с обработкой барабанов, гитар, вокалов, с микшированием каналов мониторинга, всякая автоматизация и так далее, в общем использую DAW в качестве очень продвинутого микшерного пульта с кучей обработки да еще и с одновременной потрековой записью. Так вот, 16 потоков записи 48к/32 бита при попутной загрузке процессора всякой обработкой где-то в районе 50% - это достаточные по тяжести дисковые операции?

При этом комп - достаточно древний Core i7 860, ну какой-то винт (не SSD), 8Г ОЗУ. Все. Ах да, я еще и рулю этим делом по RDP через WiFi.

Вот такой вот стейдж-бокс у меня для выездов получается (на фото еще только начало коммутации):

Там DBX DriveRack PA+ для простоты настройки линейного усиления, обсуждаемый девайс, комп, WiFi-роутер из ближайшего магазина "все по 5 рублей", парочка аналоговых систем радиомониторинга. Все.

Я припоминаю, что сетевой товарищ Никков делал юсб асио драйвер в юзерспейсе и вроде проект размещен на гитхабе. А ваш драйвер доступен для использования?

Да там нет ничего. Открываете ASIO SDK и в примере драйвера функцию sleep(1) меняете на send/recv из сокета.

Асинхронный, когда девайс яслется мастером, а хост подстраивает свой стрим под девайс, используя для синхронизации либо явный канал либо стрим от АЦП. Собственно вопрос был как вы решили эту проблему

ASIO в этом смысле асинхронный интерфейс (хотя правильнее было бы его назвать именно синхронным). Сколько семплов на вход DAW пришло, столько DAW на выход отдало. Так что получив очередные 48 семплов с АЦП, я посылаю их в комп, получаю в буфер при помощи recv, этот буфер размером 48 семплов DAW обрабатывает, затем из буфера посылается через send, попадает ко мне в девайс, и после буферизации попадает в ЦАП. Никаких проблем с передискретизацией или еще чем-то. Скорость данных с АЦП точно задает и скорость данных в ЦАП.