Уважаемые,

до этого меня устраивала скорость около 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МБит получится?

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

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

Обсуждалось уже много раз. Поиском что ли не умеете пользоваться?
К примеру почитайте тему https://electronix.ru/forum/index.php?showtopic=144619

У меня в закладках есть вот эта тема: https://electronix.ru/forum/index.php?showt...=92903&st=0

Но я просто мимо проходил - эзернет в "боевом" режиме я так и не использовал, подсказать ничего не смогу..

благодарю за ссылку, но там не ответов на мои вопросы

Каким образом будет реализован прием на компе, в смысле протокол поверх эзернета? Если есть возможность писать драйвер, можно вообще кидать чистыми эзернет кадрами, что заметно ускорит работу, если так не получается, придется пилить IP, затем, хотя бы UDP. Есть стеки более простые, чем lwip, и работают быстрее.

lwip без оси работает, и без сокетов тоже, но в виду буферирования и динамической памяти может оказаться не слишком резв..

на компе BSD сокеты. другие не хочу (в промискис режиме читать не хочу)

у меня задача - отправить по UDP, абы не заморачиваться в подтверждениями rst/ack и т.д . Но отправить хочу сразу много. т.е. стэк должен уметь фрагментировать пакеты. И, желательно, чтобы он (стэк) это делал сам. Желательно, чтобы стэк это делал где-то в прерываниях и тихо, ибо процу тоже есть чем заняться, а ось накручивать на это не хочу.

а какие стэки еще есть, которые разумно ложатся на stm32 линейки f/h7?

через spi пролезет, через ethernet и lwip - вряд ли

CY7C68013A. И он есть в QFN и BGA.

если места мало - без вариантов ставьте bga

а FT2232H не справится ли с задачей забирания данных с двух SPI в комп вообще без наличия МК?
хотя с 48МГц может и не успеть. ну тогда не MPSSE, а FIFO режим + мелкая CPLD. зачем там буфер на 300кБ и соответственно H7 не очень понятно.
а если у МК есть ещё пара SPI, можно поделить поровну на два по 30. и пропихнуть через MPSSE.

и вместо кипариса 68013 уж лучше FT232H, со стороны ПК хотя бы приключений не будет.
как вариант ещё один МК (ну или сменить текущий) чтобы HS PHY на борту был.
кортексы от nxp/atmelmicrochip, PIC32, ADSP-BF70x хоть с мегабайтом памяти.

ну и если MII как и внешний HS PHY раскидан по корпусу, c другой периферией конфликтует и с трудом разводится, есть LAN9250.

А в чём приключения-то? Работает вроде стабильно. Хотя на такой скорости я его не пробовал.


Это несомненно лучший вариант.

драйвера? я на каком-то одном ноутбуке загрузку по USB так и не одолел, хотя и не разбирался особо. но он даже голый МК (совсем без еепрома) вообще никак не видел.
но может мне просто повезло тогда во времена миграции 32->64, xp->w7, а сейчас c унифицированным для всех CyUSB3 всё хорошо. как там с w10 и линуксами?
и если хоть что-нибудь помимо GPIF (который тоже как минимум сконфигурировать надо), для встроенного 8051 только страшненький sdcc?

ну а может просто руки из жопы

Я, тогда, задам вопрос по-другому:

На stm32 (хотя, должно быть, на всех процах одинаково), если я, работая в режиме без оси,
хочу передать 100к с UDP, lwip, то
* надо ли мне несколько раз вызывать sendto() или
* lwip сам, в прерываниях, соберет пакеты и их отправит?

или есть другой IP стэк, который это сделает хорошо и быстро?

UDP протокол настолько фантастически примитивен, что я не понимаю почему для этой задачи нужен LwIP. Может для своей задачи удастся сделать всё максимально оптимально.
Хотя DHCP (если нужен) и прочую настроечную дребедень я бы предоставил LwIP или другим.

Загрузкой по USB я пользовался только во время отладки. Штатно прошивка грузилась с I2C. Проблем не было замечено.


Не понял вопрос...
Диаграммы работы GPIF рисовал в GPIF-редакторе, загружал конфигурацию GPIF - прошивкой. Прошивку компилил/отлаживал в Keil. Даже без эмулятора. Наверняка можно и IAR - чем удобно.


Если Вам просто нужно до компа (который рядом находится), то оптимальнее будет вообще без TCP-стека - чисто Ethernet-уровень.
Не знаю только как под виндой до этого уровня добраться, возможно нужен будет какой-то драйвер.
Но, имхо, USB для вашей задачи - удобнее.


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

ограничения по размеру для "kickstart" версий Keil/IAR 8051 были какие-то сильно злые и не позволяли сделать задуманного, хотя только для GPIF вполне хватит.
вылечить от жадности не позволяла "политика партии", как и покупать ради "единичного" устройства тоже, пришлось обходиться sdcc, а там всё довольно печально начиная от перелопачивания хедера с регистрами и заканчивая ручным распихиванием буферов по разным секциям. хотя как-то работало, да.

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

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

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

самому написать UDP? да, вполне, как уже сказали, там вообще ничего нет. разбираться с чужими стэками / прикручивать свой драйвер для MAC, который всё равно делать надо будет, возможно дольше будете. и прикрутить UDP со стороны МК имхо проще, чем разбирать сырые езернет фреймы со стороны ПК.
ну там ещё ARP, IP, ну и минимальный ICMP чтобы уж ping работал, но они не сложнее.

скажите, а всё-таки FT232H, не сможет спасти гиганта мысли?

У меня полностью свой TCP-стек написан. Не только UDP, TCP, но и ICMP, DNS, DHCP, HTTP, SNTP и SMTP на нём работает(ало). Пользую уже давно во многих проектах на разных МК.

Я просто оставлю это здесь.
Нажмите для просмотра прикрепленного файла

На самом деле это 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% загрузки процессора там очень и очень далеко.

о! то что нужно.

примного благодарен

а как вы представляете себе скрестить lwip с не lwip ?

Ну оно там очень яростно рукожопо выглядит, сделано на очень скорую руку за один час. Без всякого окультуривания, так что пардон. Если будут вопросы - задавайте, я отвечу. Расценивайте это больше как пример, там, например, совсем некошерно с точки зрения загрузки проца смотрятся две функции CopyFromFrame_EMAC и CopyToFrame_EMAC. На самом деле надо заменить вот этот union

на банальные указатели типа ARP_PKT *arp, UDP_PKT *udp, ...., и в основном коде, соответственно, arp.чего-то на arp->чего-то. И работать прямо по месту, в буферах местного MAC-уровня у Вашего процессора.

Я, к сожалению, не знаю, как устроен MAC в STM32 (не разбирался), но все они примерно по одному и тому же принципу - есть какая-то очередь приема, есть какая-то очередь передачи. Вот из одной надо брать пакеты (это самое начало тела цикла for(;;) в моем коде до p=arp.type; switch(p) ...), а в другую - укладывать (это ETH_Out).

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

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

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

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



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



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



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



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



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

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


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


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

Не совсем. Сигнал 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, попадает ко мне в девайс, и после буферизации попадает в ЦАП. Никаких проблем с передискретизацией или еще чем-то. Скорость данных с АЦП точно задает и скорость данных в ЦАП.