Make_Pic (11.08.2026 14:17, просмотров: 6165)-
- много букв, что-то прочел, что-то нет. но вроде понял, что задача отправить какую-то толстую инфу, которая может идти беспорядочными кусками и которая на другом конце должна собраться во что-то правильное. LordN(141 знак., 14.08.2026 17:33)
- Боюсь, не в тему ляпну, но в одном девайсе использую COBS кодирование/декодирование. Из плюсов - бинарная передача (не приходится уполовинивать битрейт при преобразовании в текстовый протокол) и независимость от лагов передачи. Минус - короткий пакет. - Argon(13.08.2026 21:24)
- например, у как бы прозрачных мостиков CH9121 вместо MTU дают RX Packet Length (1024 байт) и/или таймаут на разрыв пакета 5 мс. плюс сигналы управления RS485. а абстрактный UART это всё-таки поток (с ограниченной скоростью). определиться бы - Vit(12.08.2026 10:45)
- Еще есть вопрос- какой допустим джиттер в потоке символов? - HeBceTaкПpocтo(12.08.2026 10:22,
)
- Кстати, да. Как обеспечить минимальный джиттер (пусть какой-то но
константа) байт на "выходе" из TCP, по сравнению со входом? boka17(672 знак., 13.08.2026 20:05)
- Принципиально никак. TCP не гарантирует ничего, кроме неискажёного
потока (последовательности) байт. Даже границы между "блоками" в
принципе не только не гарантируются, но даже не обещаются. Для
вашей задачи UDP подходит сильно лучше, но всё равно не на 100% -
задержка пакетов может быть любой. Так что синхронизироваться нужно
с астрономическим временем, а в передаваемых блоках - передавать
это самое астрономическое время. - Samx(13.08.2026 21:05)
- Так и есть. Система относительно "старая", данные содержат условный
"кадровый" синхроимпульс (блок) и далее идут "строчные" блоки.
Данные располагаются на развертке по времени от "строчного" блока. boka17(428 знак., 13.08.2026 22:05)
- Думаю, вам помогла бы аренда оптоволокна с медиаконвертерами RS-232
- с такими, которые не делают пакетов, не делают сложной модуляции.
А просто передают логический уровень в линии светом. Они бы успешно
заменили провод. - Nikolay_Po(14.08.2026 10:51)
- Все так. Даже смогли проложить СВОЁ волокно (~10км через город,
частный сектор, реку, ЖД, исторические памятники...Бррр- сейчас
такое провернуть ни кто не решится). boka17(766 знак., 15.08.2026 08:48)
- На "своём" оптоволокне чё хошь можно сделать. Пара SFP-модулей по концам и приёмо-передатчики на Альтерах. Разрабатывал системы управления для силовой электроники, реальное время - жёстче некуда, так даже датчики токов-напряжений по оптике развязывали. - serge_dem(15.08.2026 11:34)
- Есть конвертеры, которые передают биты как есть, без всяких пакетов. Например, серия Moxa TCF-142. И они точно передадут ваш сигнал по чистой оптике без джиттера пакетизации. Nikolay_Po(251 знак., 15.08.2026 10:11)
- Все так. Даже смогли проложить СВОЁ волокно (~10км через город,
частный сектор, реку, ЖД, исторические памятники...Бррр- сейчас
такое провернуть ни кто не решится). boka17(766 знак., 15.08.2026 08:48)
- Очевидное решение - преобразовать этот поток данных в форму
пригодную для передачи и восстановления на приемном конце в
первоначальный вид. Поток уже побит на блоки, это хорошо. Снабдить
каждый такой блок заголовком с номером строки или меткой времени и
вперёд! Если потеря части блоков допустима, то можно и UDP
использовать. Но с маршрутизацией абстрактного UDP могут быть
проблемы, лучше маскироваться под какой нибудь протокол передачи
аудио/видео или оставить TCP - с ним ЫЫyкпy(15 знак., 14.08.2026 04:41)
- Поздравляю, вы изобрели RTP! :-) Кстати, хорошая штука, для проброса звука я только его и использую. - Samx(14.08.2026 18:59)
- Есть же куча готовых решений RS232 over TCP/IP Бoмж(2 знак., 14.08.2026 10:06, картинка, картинка)
- или вот за совсем смешные деньги - Лaгyнoв(1 знак., 14.08.2026 11:54, картинка)
- Не надо смеяться за деньги, юноша. Иначе таки смеяться будут
другие. И название какое-то стрёмное. - Бapбoc(14.08.2026 12:19)
- У Ебайта самые приличные радиомодули из китайчатины. Они первыми
признались, что вместо NRF24L01+ используют китайские чипы и
опубликовали соответствующие DS. Наряду с чисто китайскими,
предлагают и оригиналы, для ценителей, которые уже подсели на
оригнальный Nordic. - Nikolay_Po(14.08.2026 12:30)
- да, после перебора разных на этой фирме остановились. Конкретно в моем пульте стоят - NT1-M Лaгyнoв(2 знак., 14.08.2026 13:04, ссылка, картинка)
- У Ебайта самые приличные радиомодули из китайчатины. Они первыми
признались, что вместо NRF24L01+ используют китайские чипы и
опубликовали соответствующие DS. Наряду с чисто китайскими,
предлагают и оригиналы, для ценителей, которые уже подсели на
оригнальный Nordic. - Nikolay_Po(14.08.2026 12:30)
- Не надо смеяться за деньги, юноша. Иначе таки смеяться будут
другие. И название какое-то стрёмное. - Бapбoc(14.08.2026 12:19)
- или вот за совсем смешные деньги - Лaгyнoв(1 знак., 14.08.2026 11:54, картинка)
- Думаю, вам помогла бы аренда оптоволокна с медиаконвертерами RS-232
- с такими, которые не делают пакетов, не делают сложной модуляции.
А просто передают логический уровень в линии светом. Они бы успешно
заменили провод. - Nikolay_Po(14.08.2026 10:51)
- Так и есть. Система относительно "старая", данные содержат условный
"кадровый" синхроимпульс (блок) и далее идут "строчные" блоки.
Данные располагаются на развертке по времени от "строчного" блока. boka17(428 знак., 13.08.2026 22:05)
- Забудь о каком-либо "приемлемом джитере". Те же косы на коммутаторе настролили, пошел ещё трафик и хана времянкам. Твои пакеты подвинул более приоритетный трафик. - POV(13.08.2026 20:14)
- Принципиально никак. TCP не гарантирует ничего, кроме неискажёного
потока (последовательности) байт. Даже границы между "блоками" в
принципе не только не гарантируются, но даже не обещаются. Для
вашей задачи UDP подходит сильно лучше, но всё равно не на 100% -
задержка пакетов может быть любой. Так что синхронизироваться нужно
с астрономическим временем, а в передаваемых блоках - передавать
это самое астрономическое время. - Samx(13.08.2026 21:05)
- Кстати, да. Как обеспечить минимальный джиттер (пусть какой-то но
константа) байт на "выходе" из TCP, по сравнению со входом? boka17(672 знак., 13.08.2026 20:05)
- В начале кадра UART, открываешь соединение TCP. И все данные кадра,
передаёшь в этом, открытом соединении, по факту прихода, хоть по 5
байт - не важно, TCP всё стерпит. Nikolay_Po(1045 знак., 12.08.2026 10:04)
- Мне через мост, дарующий белый айпи, приходилось стучаться из
Рязани до спектроанализатора в Хабаровске через кучу влан. Работало
неделями. Не очень мне понятная паранойя такая, не сталкивался. - POV(12.08.2026 10:12)
- Ты с промкой не работал. - Nikolay_Po(12.08.2026 15:13)
- сеть РЖД считается промкой? - POV(12.08.2026 17:00)
- Нет. Вряд ли у тебя много спектроанализаторов, обслуживаемых
умеренной квалификацией персоналомм на сетях тобой не
контролируемых. Например, в ТЗ есть такой пункт: обрыв передачи
данных при наличии физического сигнала на портах Ethernet -
уведомление и реакция системы. Nikolay_Po(121 знак., 12.08.2026 18:50)
- Нужно каждые 100мс слать сигнал Сердцебиение, и как только он
вовремя не придёт - обрыв передачи. - Бoмж(13.08.2026 20:57)
- У меня был сервер с кучей подключённых к нему по Modbus систем. И у каждой системы - ещё и по нескольку отдельно адресуемых компонентов, к которым у сервера должен быть доступ. Самым эффективным решением оказалось открывать TCP-сессию на каждую транзакцию. Это позволило не вводить кучу таймеров сердцебиейний в ПО сервера. - Nikolay_Po(14.08.2026 11:04)
- Нужно каждые 100мс слать сигнал Сердцебиение, и как только он
вовремя не придёт - обрыв передачи. - Бoмж(13.08.2026 20:57)
- Нет. Вряд ли у тебя много спектроанализаторов, обслуживаемых
умеренной квалификацией персоналомм на сетях тобой не
контролируемых. Например, в ТЗ есть такой пункт: обрыв передачи
данных при наличии физического сигнала на портах Ethernet -
уведомление и реакция системы. Nikolay_Po(121 знак., 12.08.2026 18:50)
- сеть РЖД считается промкой? - POV(12.08.2026 17:00)
- Ты с промкой не работал. - Nikolay_Po(12.08.2026 15:13)
- Мне через мост, дарующий белый айпи, приходилось стучаться из
Рязани до спектроанализатора в Хабаровске через кучу влан. Работало
неделями. Не очень мне понятная паранойя такая, не сталкивался. - POV(12.08.2026 10:12)
- Слово "восстановлением" размыто. Можно сделать преамбулу бит так 128. Сопало? Восстанавливаем. - BlackMorda(11.08.2026 22:02)
- я тоже думал, что там какой-то протокол (после установления ТСР-соединения). Оказалось - что на входе, то и на выходе. Пришлось самому придумывать. :-) - Лaгyнoв(11.08.2026 20:10)
- Не понятен вопрос. TCP не искажает данных, просто гарантированная
передача. Что значит "с восстановлением"? - Cкpипaч(11.08.2026 15:48)
- фрейм имеет размер ~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)
- Moxa RealCOM для NPort. Официальной спецификации нет, но есть неофициальная. Или RFC2217 bodis(2 знак., 11.08.2026 15:45, ссылка, ссылка)
- TCP - это прозрачный канал. Как провод в котором байтики шмыгают. - POV(11.08.2026 14:29)
- TCP - это и есть тот протокол, который прекрасно может передавать данные UART. - SciFi(11.08.2026 14:21)
- Обычный текстовый протокол. Я устройства на USB и прочих последовательных интерфейсах спокойно по сети пробрасываю: хоть моим самописным "прокси" (он умеет в много клиентов), хоть socat. - Eddy_Em(11.08.2026 14:20)
