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МБит получится?

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

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

[diwil]

Обработку IP до уровня UDP можно и самому написать, без сторонних костылей. Без DHCP.

можно. Но!
1. надо быстро.
2. надо еще заморочиться с драйвером физуровня.

на компе, винде, сырые сокеты простыми способами не поддерживаются.

Так кто-нибудь вообще пробовал?

[Rst7]

можно. Но!
1. надо быстро.
2. надо еще заморочиться с драйвером физуровня.

на компе, винде, сырые сокеты простыми способами не поддерживаются.

Так кто-нибудь вообще пробовал?

Я просто оставлю это здесь.
 Bootcore.zip ( 13.33 килобайт ) Кол-во скачиваний: 50


На самом деле это tftp-бутлоадер для LPC1768. В нем есть ARP, ICMP (на пинг отвечает) и UDP (ибо сам tftp по UDP бегает).

Переделываете под свои нужды всякие InitEMAC()/ETH_Out() и отпиливаете все, что в ветке switch(udp.tftp_rq.opcode), ибо это уже TFTP. Крайне сложная цепочка функций SendUDP -> SendIP -> ETH_Out - вот это Ваше все будет. Для красоты не забудьте выбросить там лишнее копирование.

Ну а по поводу настоящего прибора - у меня тут многоканальный аудиоинтерфейс живет на Ethernet'е (проц LPC1768/100МГц), 16 каналов на вход, 16 на выход, 48кГц, 32 бита. Т.е. 25Мбит/с в каждую сторону. По TCP живет, шлет данные в обе стороны один раз в миллисекунду, с полноценной реализацией Fast Retransmit в обе стороны, так что джиттер в случае потери пакета не превышает 500мкс. И до 100% загрузки процессора там очень и очень далеко.

[ig_z]

Ну а по поводу настоящего прибора - у меня тут многоканальный аудиоинтерфейс живет на Ethernet'е (проц LPC1768/100МГц), 16 каналов на вход, 16 на выход, 48кГц, 32 бита. Т.е. 25Мбит/с в каждую сторону. По TCP живет, шлет данные в обе стороны один раз в миллисекунду, с полноценной реализацией Fast Retransmit в обе стороны, так что джиттер в случае потери пакета не превышает 500мкс. И до 100% загрузки процессора там очень и очень далеко.

А можно несколько вопросов о приборе? По ходу повествованиия:
1) 16 каналов обе стороны я полагаю аналоговые, что то типа 16 канального пульта? Как вы их сделали? На кристале только один I2S.
2) Используется TCP, на ум приходит только линуксовый ДЖЕК с возможностью работать по сети. С какой хостовой ос работает ваше устройство? Какой протокол используете?
3) Джиттер меньше 500 мкСек. Т.е. 1 мсек буферизация на передающей стороне, 1-2 мсек буферизация на приемной. В обе стороны латенси около 6 мсек? Вы измеряли реальное значение?
4) Хотелось бы узнать ситуацию со свитчами. Вы наверняка проверяли такую конфигурацию.
5) Как реализовали синхронизацию аудио кварцев? Я время от времени развлекаюсь со своим ЮСБ аудио и в качестве эксперимента делаю синхронный режим. По моим прикидкам время синхронизации с приличным подавлением джиттера ЮСБ СОФ получается около 1-2 сек. Что очень много.

Я пару лет работал на АВИД, пилили АВБ аудио платформу. Избыточное решениея для домашних поделок, к тому же работающее только под макосью, условно работающее под линукс и напрочь отсутствующее в мире виндовс. Механизм синхронизации был черезвычайно сложный, совершенно неподъемный для самоделок.

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

[Rst7]

А можно несколько вопросов о приборе? По ходу повествованиия:
1) 16 каналов обе стороны я полагаю аналоговые, что то типа 16 канального пульта? Как вы их сделали? На кристале только один I2S.

Да, там 8 двухканальных АЦП и 8 двухканальных ЦАПов. 8 штук I2S прекрасно изготавливаются при помощи DMA-пересылки с GPIO (просто 8 бит порта рядом) в ОЗУ с последующим довольно хитрым алгоритмом транспонирования битовой матрицы (не в лоб).

2) Используется TCP, на ум приходит только линуксовый ДЖЕК с возможностью работать по сети. С какой хостовой ос работает ваше устройство? Какой протокол используете?

ASIO-драйвер я написал, так что любой Windows-хост с любой DAW. Причем, т.к. транспорт там TCP, все катается в user-space без всяких драйверов в ядре. Два сокета открывается и без лишних обрамлений в каждом льются данные в нужную сторону. Хотел сначала один сделать, но оказалось, что в винде Fast Retransmit правильно работает только если данные идут только в одну сторону. Потому два сокета.

3) Джиттер меньше 500 мкСек. Т.е. 1 мсек буферизация на передающей стороне, 1-2 мсек буферизация на приемной. В обе стороны латенси около 6 мсек? Вы измеряли реальное значение?

Именно так и есть. 1(вход)+1(обработка в DAW)+2(вывод)=4мс чистая цифровая задержка плюс задержки в фильтрах АЦП/ЦАП, набегает еще почти миллисекунда в сумме. Задержка измерена и рапортуется в DAW для точного позиционирования треков при записи через LoopBack-кабель.

4) Хотелось бы узнать ситуацию со свитчами. Вы наверняка проверяли такую конфигурацию.

Главное в этом деле - применять самые тупые свичи. Тогда задержка в нем всего лишь на время передачи пакета в сети. В моей инфраструктуре сейчас так - комп гигабитом в свич, а в него - два таких устройства, одно - 16in/16out, второе - просто 8out, сами устройства, понятное дело, 100М. Что гигабитная карта, что гигабитный свич - обычная дешевка, купленная в первом попавшемся компьютерном магазине.

5) Как реализовали синхронизацию аудио кварцев? Я время от времени развлекаюсь со своим ЮСБ аудио и в качестве эксперимента делаю синхронный режим. По моим прикидкам время синхронизации с приличным подавлением джиттера ЮСБ СОФ получается около 1-2 сек. Что очень много.

Я пару лет работал на АВИД, пилили АВБ аудио платформу. Избыточное решениея для домашних поделок, к тому же работающее только под макосью, условно работающее под линукс и напрочь отсутствующее в мире виндовс. Механизм синхронизации был черезвычайно сложный, совершенно неподъемный для самоделок.

Я не очень понимаю, о каких аудио-кварцах Вы говорите. В конкретно моем устройстве, которое 16/16, АЦП и ЦАПы тактируются одним и тем же MCLK/BICK/LRCK. В другом устройстве (которое чисто вывод) - просто цифровая PLL, причем с довольно малой постоянной времени в фильтре. Если никому не говорить, то никто из окружающих меня на студии золотоухих дьяволов не слышит никакого джиттера.

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

У меня нет полномочий именно в этом разделе. Надо попросить штатного модератора раздела, пусть разрежет ветку на две.

[ig_z]

Да, там 8 двухканальных АЦП и 8 двухканальных ЦАПов. 8 штук I2S прекрасно изготавливаются при помощи DMA-пересылки с GPIO (просто 8 бит порта рядом) в ОЗУ с последующим довольно хитрым алгоритмом транспонирования битовой матрицы (не в лоб).

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

ASIO-драйвер я написал, так что любой Windows-хост с любой DAW. Причем, т.к. транспорт там TCP, все катается в user-space без всяких драйверов в ядре. Два сокета открывается и без лишних обрамлений в каждом льются данные в нужную сторону. Хотел сначала один сделать, но оказалось, что в винде Fast Retransmit правильно работает только если данные идут только в одну сторону. Потому два сокета.

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

Именно так и есть. 1(вход)+1(обработка в DAW)+2(вывод)=4мс чистая цифровая задержка плюс задержки в фильтрах АЦП/ЦАП, набегает еще почти миллисекунда в сумме.

Я не очень понимаю, о каких аудио-кварцах Вы говорите. В конкретно моем устройстве, которое 16/16, АЦП и ЦАПы тактируются одним и тем же MCLK/BICK/LRCK.

Я имею ввиду, что на устройстве есть аудио кварц -> 48к умноженное на что то. Это определяет MCLK и скорость выборки буфера для ЦАП. Очевидно, что сетевая подсистема должна поставлять данные в выходной буфер размером 48*2 семпла так, чтобы не было недопереполнения. Т.е. нужна система синхронизации хоста и девайса. Например в юсб есть три приличных способа синхронизации: синхронный - когда хост ведущий, а девайс синхронизирует свою частоту по СОФам. Асинхронный, когда девайс яслется мастером, а хост подстраивает свой стрим под девайс, используя для синхронизации либо явный канал либо стрим от АЦП.
Собственно вопрос был как вы решили эту проблему