Nikkolaj 0 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба Добрый день. У меня такой вопрос. На плате есть четыре 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 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба Напрашивается очевидное решение - Zynq Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 8 каналов по 32 бита с частотой дискретизации 192кГц. Поток чуть меньше, чем у Вас (примерно 50Мбит/с чистых данных, брутто - повыше, чуть больше 60). Причем, в обе стороны. Сделано на LPC4078 со стомегабитным подключением. Несколько таких плат включено в тупой дешевый 1G свич, и уже он гигабитным линком включен в комп. Хост - Windows, без особых напрягов ест все эти данные с характерными доп. буферами на 0.5мс. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MegaVolt 29 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба Если связь точка точка то можно гнать по UDP. Там тоже пакеты но нету квитирования и прочих задержек. 64Мбит реальная цифра даже для 100Мбит сети. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба Just now, MegaVolt said: Если связь точка точка то можно гнать по UDP. И по TCP можно. Не проблема. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MegaVolt 29 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба Только что, Rst7 сказал: И по TCP можно. Не проблема. Если не секрет как снизить накладные расходы? На всякие квитирования и подтверждения? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба Just now, MegaVolt said: Если не секрет как снизить накладные расходы? На всякие квитирования и подтверждения? Так а какие там накладные расходы? ACK на каждый второй пакет с данными? Просто не надо ждать этого самого ACK, а посылать данные дальше, а по ACK'ам удалять данные из буфера и/или организовывать перепосылку утерянных пакетов (но надо, чтобы Ваш стек умел в Fast Retransmit/Selective ACK, иначе любая потеря пакета приведет к затыку). У меня изначально в девайсе, который на фотографии, был именно TCP. Правда потом я перешел на UDP из-за того, что появилась необходимость реализовать мультикаст и горячее подключение/отключение устройств в систему, но в своем протоколе поверх UDP я реализовал весь необходимый набор для перепосылки потерянных пакетов, примерно так же, как это сделано в TCP. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 61 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 22 minutes ago, Rst7 said: Просто не надо ждать этого самого ACK, а посылать данные дальше, а по ACK'ам удалять данные из буфера и/или организовывать перепосылку утерянных пакетов Я сам не знаю, поэтому хочу уточнить, а это соответствует RFC или это ваш костыль ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба Just now, dimka76 said: это соответствует RFC Именно так. Более того, все стеки на больших братьях (win/*nix и прочее) ведут себя именно так. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
dimka76 61 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 1 minute ago, Rst7 said: Именно так. Более того, все стеки на больших братьях (win/*nix и прочее) ведут себя именно так. Ясно, спасибо. На вашей фотке разъем Ethernet интересно расположен. Разъем в него вставлять не очень удобно наверное ;-) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 3 minutes ago, dimka76 said: На вашей фотке разъем Ethernet интересно расположен. Разъем в него вставлять не очень удобно наверное ;-) Он один раз вставляется при сборке, там патчкорд на внутренний свич или на Ethercon на передней панели, если прибор в виде отдельного блока. Конечный пользователь туда ничего не тыкает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 8 minutes ago, dimka76 said: это соответствует RFC ... ? См: RDP/RUDP (RFC1151) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 2 minutes ago, blackfin said: См: RDP/RUDP (RFC1151) Лично я вообще именно про TCP говорил. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 25 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 2 minutes ago, Rst7 said: Лично я вообще именно про TCP говорил. Значит, я неправильно понял фразу: 41 minutes ago, Rst7 said: Правда потом я перешел на UDP из-за того, что появилась необходимость реализовать мультикаст и горячее подключение/отключение устройств в систему, но в своем протоколе поверх UDP я реализовал весь необходимый набор для перепосылки потерянных пакетов, ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Rst7 5 10 марта, 2020 Опубликовано 10 марта, 2020 · Жалоба 2 minutes ago, blackfin said: Значит, я неправильно понял фразу: Не, изначально фраза про "это соответствует RFC ... ?", которую Вы процитировали - она в контексте поведения TCP. А то, что я потом на UDP перешел - то отдельная история. И да, протокол поверх UDP у меня получился как нечто напоминающее RDP/RUDP, но как бы любой протокол, в котором есть SEQ/ACK будет напоминать TCP и производные. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться