[Nikkolaj 0]

Добрый день.

У меня такой вопрос.

На плате есть четыре 14 битных АЦП с паралельним выходом.

Каждую микросекунду все 4 АЦП делают измерения, и выдают результаты. Процесс измерений постоянный, пока включено устройство.

Задача, передавать эти результаты 4 АЦП, без обработки, на компьютер, по Ethernet.

Можно передавать результаты в таком же порядке, как они поступают:

АЦП1, АЦП2, АЦП3, АЦП4,   АЦП1, АЦП2..., не формируя блоки измерений для отдельного АЦП.

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

нужно предусмотреть буфер памяти для информации, расчитанный на 1-2 сек.

С Ethernet я ранее не работал, только вчера начал смотреть информацию, и возникает много вопросов начинающего.

1. Постоянный поток информации у меня получается 8 байт за микросекунду, значит 64 Мбит за секунду.

    Контроллеры Ethernet c , близкими скоростями видел на 100Мбит, и 1Gбит.

    Если информация по Ethernet передаётся блоками, и между ними есть какие то промежутки времени,

    тогда скорости 100Мбит наверное может  и не хватить. 

    Контроллер Ethernet для такой задачи нужно выбирать на скорость 1Gбит за секунду? 

2.  Информация по Ethernet на компьютер передаётся только блоками, или есть возможность оранизовать и постоянную передачу?

3.  Можно ли такую задачу решить на контроллере, например серии STM32... на 72МГц,  или только с применением ПЛИС?

4. Возможно уже существуют готовые микросхемы, или устройства, решающие такие задачи,

    на которые можно загружать информацию по паралельной шине, а они передают её по Ethernet на компьютер?

Буду благодарен, за любые дельные советы по этому вопросу.

 

 

 

[gosha-z 2]

Напрашивается очевидное решение - Zynq

[Rst7 5]

8 каналов по 32 бита с частотой дискретизации 192кГц. Поток чуть меньше, чем у Вас (примерно 50Мбит/с чистых данных, брутто - повыше, чуть больше 60). Причем, в обе стороны. Сделано на LPC4078 со стомегабитным подключением. Несколько таких плат включено в тупой дешевый 1G свич, и уже он гигабитным линком включен в комп.

Хост - Windows, без особых напрягов ест все эти данные с характерными доп. буферами на 0.5мс.

[MegaVolt 27]

Если связь точка точка то можно гнать по UDP. Там тоже пакеты но нету квитирования и прочих задержек. 64Мбит реальная цифра даже для 100Мбит сети.

[Rst7 5]

Just now, MegaVolt said:

Если связь точка точка то можно гнать по UDP.

И по TCP можно. Не проблема.

[MegaVolt 27]

Только что, Rst7 сказал:

И по TCP можно. Не проблема.

Если не секрет как снизить накладные расходы? На всякие квитирования и подтверждения?

 

[Rst7 5]

Just now, MegaVolt said:

Если не секрет как снизить накладные расходы? На всякие квитирования и подтверждения?

Так а какие там накладные расходы? ACK на каждый второй пакет с данными? Просто не надо ждать этого самого ACK, а посылать данные дальше, а по ACK'ам удалять данные из буфера и/или организовывать перепосылку утерянных пакетов (но надо, чтобы Ваш стек умел в Fast Retransmit/Selective ACK, иначе любая потеря пакета приведет к затыку).

У меня изначально в девайсе, который на фотографии, был именно TCP. Правда потом я перешел на UDP из-за того, что появилась необходимость реализовать мультикаст и горячее подключение/отключение устройств в систему, но в своем протоколе поверх UDP я реализовал весь необходимый набор для перепосылки потерянных пакетов, примерно так же, как это сделано в TCP.

[dimka76 45]

22 minutes ago, Rst7 said:

Просто не надо ждать этого самого ACK, а посылать данные дальше, а по ACK'ам удалять данные из буфера и/или организовывать перепосылку утерянных пакетов

Я сам не знаю, поэтому хочу уточнить, а это соответствует RFC или это ваш костыль ?

[Rst7 5]

Just now, dimka76 said:

это соответствует RFC

Именно так. Более того, все стеки на больших братьях (win/*nix и прочее) ведут себя именно так.

[dimka76 45]

1 minute ago, Rst7 said:

Именно так. Более того, все стеки на больших братьях (win/*nix и прочее) ведут себя именно так.

Ясно, спасибо.

На вашей фотке разъем Ethernet интересно расположен. Разъем в него вставлять не очень удобно наверное ;-)

[Rst7 5]

3 minutes ago, dimka76 said:

На вашей фотке разъем Ethernet интересно расположен. Разъем в него вставлять не очень удобно наверное ;-)

Он один раз вставляется при сборке, там патчкорд на внутренний свич или на Ethercon на передней панели, если прибор в виде отдельного блока. Конечный пользователь туда ничего не тыкает.

 

[blackfin 22]

8 minutes ago, dimka76 said:

это соответствует RFC ... ?

См: RDP/RUDP (RFC1151)

[Rst7 5]

2 minutes ago, blackfin said:

См: RDP/RUDP (RFC1151)

Лично я вообще именно про TCP говорил.

[blackfin 22]

 

2 minutes ago, Rst7 said:

Лично я вообще именно про TCP говорил.

Значит, я неправильно понял фразу:

41 minutes ago, Rst7 said:

Правда потом я перешел на UDP из-за того, что появилась необходимость реализовать мультикаст и горячее подключение/отключение устройств в систему, но в своем протоколе поверх UDP я реализовал весь необходимый набор для перепосылки потерянных пакетов, ...

 

[Rst7 5]

2 minutes ago, blackfin said:

Значит, я неправильно понял фразу:

Не, изначально фраза про "это соответствует RFC ... ?", которую Вы процитировали - она в контексте поведения TCP. А то, что я потом на UDP перешел - то отдельная история. И да, протокол поверх UDP у меня получился как нечто напоминающее RDP/RUDP, но как бы любой протокол, в котором есть SEQ/ACK будет напоминать TCP и производные.