Cкpипaчпророк (11.08.2026 15:48, просмотров: 86) ответил Make_Pic на Подскажите простой протокол передачи UART последовательных данных
через TCP желательно с восстановлением выходных данных после
эзернет до данных, которые были на входе порта UART MCU? MODBUS TCP
не предлагать.... но не любой ценой.
-
- фрейм имеет размер ~1460 байт данных, данные с UART идут непрерывно
или пакетами переменной длины большей чем frame IP, я об этом и
говорил - восстановить, правильно собрать поток данных - Make_Pic(12.08.2026 07:10)
- Ты решаешь несуществующую проблему. Сколько в сокет запихнулось, столько и будет доставлено. Cкpипaч(452 знак., 12.08.2026 15:43)
- C TCP проблема обратная - это *потоковый* протокол, он не имеет "снаружи" видимых границ пакетов. recv() может вернуть любое количество байт, вне зависимости от того, Samx(45 знак., 12.08.2026 12:33)
- у меня сейчас прошивки при TCP-соединении валятся потоком. Там 500К
файл идет. Глазом видел разницу только при эзернет или вайфай. У
меня байты, что валятся в UART, индицируются светодиодом. Так при
вайфай он на потоке горит непрерывно, а при эзернет вины
периодические паузы. При этом мне собирать у себя ничего не надо.
Просто жду паузы бОльшей длины. Тогда считаю, что всё передано. Как
у меня в МК влезает 500К? Так два буфера. Как только один
заполнился, переключаюсь на Лaгyнoв(35 знак., 12.08.2026 09:39)
- это когда я оттуда принимаю. А вот ТУДА - беда. Там реально (что
вайфай, что эзернет) больше 500-1300 байт скинуть нельзя. Теряются.
Свои большие файлы приходится кусками передавать. - Лaгyнoв(12.08.2026 09:41)
- Когда это работает на микроконтроллере приходится считаться с
ограничениями на доступный объем памяти (кол-во буферов) и с тем
что реализация TCP в чём-то упрощенная, а если ещё и без ОС, то
часть работы которая возлагается на механизмы ОС, приходится
выполнять самому. - ЫЫyкпy(12.08.2026 11:08)
- ограничения, когда я отправляю на сервер, связаны не с моим МК. А с модулем, к которому я подключен. Я бы радостно выкинул туда 5-10-30 кбайт на UART сразу. Но он не пропустит. Самый лучший примет 1300 байт. Худший - 440 байт. Вот к примеру -EBYTE NT1-M Лaгyнoв(1 знак., 12.08.2026 16:44, картинка)
- Я бы упростил: нужно считаться с доками. Где-то это всё наверняка
написано. Но "доки придумал трус"™ :-) - SciFi(12.08.2026 11:13)
- Причем с доками не только на свою реализацию, но еще и иметь представление как это работает на "большом брате" чтобы правильно с ним взаимодействовать. Да еще и сами доки обычно так составлены, что описывают как с этим работать, но старательно замалчивают вопрос почему и из каких соображений сделано именно так. В результате программируя для MCU приходится перелопачивать как минимум двойной объем документации и докапываться до самых основ чтобы все это работало, ЫЫyкпy(225 знак., 12.08.2026 11:51)
- Тогда зачем применять TCP в услових ограниченных ресурсов? - POV(12.08.2026 11:12)
- Когда это работает на микроконтроллере приходится считаться с
ограничениями на доступный объем памяти (кол-во буферов) и с тем
что реализация TCP в чём-то упрощенная, а если ещё и без ОС, то
часть работы которая возлагается на механизмы ОС, приходится
выполнять самому. - ЫЫyкпy(12.08.2026 11:08)
- это когда я оттуда принимаю. А вот ТУДА - беда. Там реально (что
вайфай, что эзернет) больше 500-1300 байт скинуть нельзя. Теряются.
Свои большие файлы приходится кусками передавать. - Лaгyнoв(12.08.2026 09:41)
- Вот для всего этого и придуман TCP. Цитата из вики: "Механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым (в отличие от UDP) целостность передаваемых данных и уведомление отправителя о результатах передачи." ЫЫyкпy(486 знак., 12.08.2026 07:38)
- фрейм имеет размер ~1460 байт данных, данные с UART идут непрерывно
или пакетами переменной длины большей чем frame IP, я об этом и
говорил - восстановить, правильно собрать поток данных - Make_Pic(12.08.2026 07:10)
