k155la3 26 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 12 hours ago, :-) said: . . . А чем плох непрерывный поток? . . . . 1. Лучше UDP, чем TCP. Хотя и TCP тоже норм. 2. Писать либо свой протокол, либо MQTT. Да ничем он не плох. Смотря какого вида инф-я по нему прокачивается. Если "квант" данных потока умещается в один пакет - то проблем нет. Если же поток - это ПОТОК (байтов) - то . . . . . Получите "Ж". "Ой, а этот байтик откуда (? куда), . . . Это канал связи глючный, синхронизацию не держит " :) Для использования MQTT Вам потребуется евойный сервер, например mosquitto (он есть как для Linux, так и в виде приложения на Win). И Ваше 2-точечное соединение превращается в цепочку из 3 точек. Ну, это как вместо того, чтобы переложить данные с одного стола на другой (UDP, 2 point) Вы "заводите" стол с секретуткой, и на этом столе есть 2 папки - одна для "поставщика", другая - для подписчик(ов). Секретутка никуда не ходит. Ее задача - переложить данные из "входящей" папки в "исходящую". Так что не теряйте время, см. сокеты, UDP - датаграммы для процессора и для PC. Для компилятора PC никаких дополн. библиотек не надо - сокеты давно в "базовом" наборе. Примеров тоже море, в качестве "стартового" посмотрите исходник утилиты ping (раньше они шли в качестве стандартного примера). Если C# - то наверняка тоже есть компоненты для сетевой работы. Но в этом я пас. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба Протестил lwIP на MIMXRT1064 600 МГц с помощью iperf PC client На BM с -O3 в TCM получается не более 70 Мбайт/сек Тему можно закрывать. Тут нужен 8-и ядерный i9 чтоб остались ресурсы для приложения. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 2 hours ago, AlexandrY said: . . . Тему можно закрывать. Тут нужен 8-и ядерный i9 чтоб остались ресурсы для приложения. или мост USB-fifo с параллельной (8 или 16) шиной без всяких Ethernet. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psyhologic 0 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 20 часов назад, k155la3 сказал: За целостность информации отвечает Ethernet и IP/UDP, поэтому даже генерировать - проверять CRC не надо. Пожалуйста, не вводите людей в заблуждение, IP / UDP не обеспечивают полноценного reliability. Для IPv4 даже UDP checksum - опция. Даже если ОС или приложение реализует механизм проверки checksum - не прошедшие проверку пакеты будут просто отброшены (без повторной передачи). А в случае высоких нагрузок (80 MBit/s как раз такой случай) и слабого железа, скажется отсутствие network congestion у UDP. Потери пакетов превысят все разумные пределы. Вот почитайте на досуге - https://habr.com/ru/post/250227/ 2 часа назад, AlexandrY сказал: Протестил lwIP на MIMXRT1064 600 МГц с помощью iperf PC client На BM с -O3 в TCM получается не более 70 Мбайт/сек Что и требовалось доказать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 2 minutes ago, psyhologic said: Что и требовалось доказать. Сорри, ошибся. 70 Мбит/сек (не мегабайт!) - это скорость приема по TCP микроконтроллером. А скорость передачи по TCP у меня получилась 95 Мбит/сек. Но у меня 100Base-T под рукой только. Так что можем обсуждать дальше. Так кто там предложит парсер JSON под ARM Cortex, чтоб он отъел не больше 10% производительности TCP стека? И желательно с пруфами. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psyhologic 0 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 12 минут назад, AlexandrY сказал: Сорри, ошибся. 70 Мбит/сек (не мегабайт!) - это скорость приема по TCP микроконтроллером. А скорость передачи по TCP у меня получилась 95 Мбит/сек. Но у меня 100Base-T под рукой только. Так что можем обсуждать дальше. Так кто там предложит парсер JSON под ARM Cortex, чтоб он отъел не больше 10% производительности TCP стека? И желательно с пруфами. Здесь ещё множество подводных камней скрыто. В случае TCP они разруливаются на уровне самого протокола. Например, TCP остановит передачу, пока получатель не обработает предидущую порцию данных и не пришлёт ACK. Даже если "квантировать" UDP payload (как было предложено выше), чтобы уместить его в один UDP пакет. Где гарантии того, что пока получатель будет парсить / обрабатывать payload на слабом железе, не прилетят ещё 1000 UDP пакетов, из которых 500 попадут в буферы ОС, а остальные будут просто отброшены. Это допустимо в некоторых архитектурных сценариях - ММО сервера, видео поток, etc ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 1 minute ago, psyhologic said: Даже если "квантировать" UDP payload (как было предложено выше), чтобы уместить его в один UDP пакет. А кто тут обсуждает UDP? UDP по любому требует еще какого-то протокола сверху. TC же интересуется конечным прикладным протоколом. И ответ в том, что интересоваться надо на его месте не протоколом, а фреймворком. Потому что их готовых навалом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
psyhologic 0 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба Только что, AlexandrY сказал: А кто тут обсуждает UDP? UDP по любому требует еще какого-то протокола сверху. TC же интересуется конечным прикладным протоколом. И ответ в том, что интересоваться надо на его месте не протоколом, а фреймворком. Потому что их готовых навалом. ИМХО не стоит изобретать велосипеды, час программиста стоит ~35$ Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT. У нас, "славян" прямо беда какая-то с излишней самодеятельностью / изобретательностью, которая потом часто выливается в "горе от ума" ... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 2 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 1 hour ago, psyhologic said: Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT. Я не понял, вроде сошлись, что MQTT не прикладной протокол, сверху также что-то надо лепить как и для UDP. Так к чему его поминать? Час же программиста стоит ~35$ ! Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 3 февраля, 2019 Опубликовано 3 февраля, 2019 · Жалоба 5 hours ago, psyhologic said: Пожалуйста, не вводите людей в заблуждение, IP / UDP не обеспечивают полноценного reliability. Для IPv4 даже UDP checksum - опция. Даже если ОС или приложение реализует механизм проверки checksum - не прошедшие проверку пакеты будут просто отброшены (без повторной передачи). А в случае высоких нагрузок (80 MBit/s как раз такой случай) и слабого железа, скажется отсутствие network congestion у UDP. Не знаю, что такое reliability, я против него "ничего не имею". Но нагло предполагаю что для задачи ТС ОНО и ненадо. А опция потому, что это уже обеспечивается аппаратно, на уровне фреймов физ. уровня, Ethernet CRC32 (или что там сейчас на гигабит, не заю). Соответственно, гонять дополнительные CRC по сети становится "наблюдением за наблюдающим". На прикладном уровне - пожалуйста, проверяйте сколькоугодно, если времени не жалко. Какое "слабое железо" ? Перечитайте внимательно ТУТ, речь идет о соединении ПК и контроллера с Ethernet напрямую или через коммутатор. Какие "Потери пакетов . . . " ? Где ? в куске провода от ПК до контроллера или в свиче ? Все "потери" при таком соединении - в кривом софте или неправильно выбранном тех. решении, когда кнопочки в 3D, а "не работает, наверное свич глючный". Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
:-) 0 4 февраля, 2019 Опубликовано 4 февраля, 2019 · Жалоба On 2/3/2019 at 5:54 PM, AlexandrY said: И ответ в том, что интересоваться надо на его месте не протоколом, а фреймворком. Потому что их готовых навалом. Google по фразе " Run-Time Debugging Tool " вывел на FreeMASTER Run-Time Debugging Tool. Ещё посмотрел на ucProbe. Интересные штучки, не знал о таком. В принципе половину задачи они могут помочь решить. Одна из целей действительно посмотреть как что-то крутится в некоторой программе управления в режиме реального времени. И такими штуками это, как будто, красиво получается. Но есть ещё одна подзадача - это передача тестовых воздействий с ПК в устройство. (Вернее программа на Cortex-a9 должна будет передать данные в память ПЛИС и далее считать результат обработки и сравнить с тем, что должно быть. А всё крутится на Zynq7000). Может, для такого тоже есть что-то готовое? Для изучения и вдохновения... 23 hours ago, k155la3 said: Не знаю, что такое reliability, я против него "ничего не имею". Но нагло предполагаю что для задачи ТС ОНО и ненадо. А опция потому, что это уже обеспечивается аппаратно, на уровне фреймов физ. уровня, Ethernet CRC32 (или что там сейчас на гигабит, не заю). Соответственно, гонять дополнительные CRC по сети становится "наблюдением за наблюдающим". На прикладном уровне - пожалуйста, проверяйте сколькоугодно, если времени не жалко. Какое "слабое железо" ? Перечитайте внимательно ТУТ, речь идет о соединении ПК и контроллера с Ethernet напрямую или через коммутатор. Какие "Потери пакетов . . . " ? Где ? в куске провода от ПК до контроллера или в свиче ? Все "потери" при таком соединении - в кривом софте или неправильно выбранном тех. решении, когда кнопочки в 3D, а "не работает, наверное свич глючный". В общем-то тоже придерживаюсь мнения, что потерь быть не должно. Впрочем потеря пакетов допустима и вряд ли сильно помешает. UDP или TCP - это, скорее, для упрощения реализации программы на ПК. (Можно, наверное, и до голых Ethernet-кадров опуститься. В 1,5 кБ должны умещаться отдельные кванты телеметрии). On 2/3/2019 at 6:05 PM, psyhologic said: ИМХО не стоит изобретать велосипеды, час программиста стоит ~35$ Надо менять архитектуру, ужимать поток до вменяемого и использовать стандартные / общепринятые протоколы типа MQTT. У нас, "славян" прямо беда какая-то с излишней самодеятельностью / изобретательностью, которая потом часто выливается в "горе от ума" ... Так вот я и пытаюсь разобраться какие протоколы существуют и их пригодность. MQTT пугает каким-то непонятным слоем брокер. Вроде бы, для моей задачи ненужная штука. Я уже выше приводил пример альтернативного протокола: Constrained Application Protocol. Он поверх UDP реализуется. И не содержит никакого брокера. ЗЫ Вообще, конечно, чувствую, что изобретаю какой-то велосипед... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
k155la3 26 4 февраля, 2019 Опубликовано 4 февраля, 2019 · Жалоба 1 hour ago, :-) said: (1). . . Одна из целей действительно посмотреть как что-то крутится в некоторой программе управления в режиме реального времени. . . . . . . Может, для такого тоже есть что-то готовое? Для изучения и вдохновения... (2) ЗЫ Вообще, конечно, чувствую, что изобретаю какой-то велосипед... (1) Если для Вас не очень принципиально использование именно Ethernet - посмотрите USB3 у Cypress - не хуже 1G :) Я делал на старом ихнем чипе CY7C68013 устр-во с подобной задачей - контроллера "отстреливал" в fifo образ RAM блоком 64кбайт. Если Вы "снизойдете" до 12 Мслов/с (8 или 16 разрядов) то можете использовать и его. Недостаток - параллельный интерфейс. Достоинство - есть готовые недорогие модули. как ТУТ (2) делая "лисапет" экономим как минимум 200 долл. на ките. Учитывая специфичность задачи и возможность расширения - намного больше. Если кит за счет фирмы - грех не воспользоваться. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
