[_pv 79]

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

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

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

[diwil 0]

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

 

 

можно. Но!

1. надо быстро.

2. надо еще заморочиться с драйвером физуровня.

 

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

 

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

[_pv 79]

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

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

ну там ещё ARP, IP, ну и минимальный ICMP чтобы уж ping работал, но они не сложнее.

 

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

[jcxz 242]

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

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

[Rst7 5]

можно. Но!

1. надо быстро.

2. надо еще заморочиться с драйвером физуровня.

 

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

 

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

 

Я просто оставлю это здесь.

Bootcore.zip

 

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

 

[diwil 0]

Я просто оставлю это здесь.

Bootcore.zip

 

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

 

 

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

 

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

[VCucumber 0]

UDP протокол настолько фантастически примитивен, что я не понимаю почему для этой задачи нужен LwIP

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

 

 

[Rst7 5]

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

 

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

 

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

union
{
  ARP_PKT arp;
  UDP_PKT udp;
  ICMP_PKT icmp;
  UINT8 rawpkt[sizeof(UDP_PKT)];
};

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

 

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

[ig_z 0]

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

:bb-offtopic:

А можно несколько вопросов о приборе? По ходу повествованиия:

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

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

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

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

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

 

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

 

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

[Rst7 5]

:bb-offtopic:

А можно несколько вопросов о приборе? По ходу повествованиия:

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 0]

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

Собственно вопрос был как вы решили эту проблему

[Rst7 5]

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