Make_Pic (Вчера, 14:17, просмотров: 1247)-
- например, у как бы прозрачных мостиков CH9121 вместо MTU дают RX Packet Length (1024 байт) и/или таймаут на разрыв пакета 5 мс. плюс сигналы управления RS485. а абстрактный UART это всё-таки поток (с ограниченной скоростью). определиться бы - Vit(Сегодня, 10:45)
- Еще есть вопрос- какой допустим джиттер в потоке символов? - HeBceTaкПpocтo(Сегодня, 10:22,
) - В начале кадра UART, открываешь соединение TCP. И все данные кадра,
передаёшь в этом, открытом соединении, по факту прихода, хоть по 5
байт - не важно, TCP всё стерпит. Nikolay_Po(1045 знак., Сегодня, 10:04)
- Мне через мост, дарующий белый айпи, приходилось стучаться из
Рязани до спектроанализатора в Хабаровске через кучу влан. Работало
неделями. Не очень мне понятная паранойя такая, не сталкивался. - POV(Сегодня, 10:12)
- Ты с промкой не работал. - Nikolay_Po(Сегодня, 15:13)
- сеть РЖД считается промкой? - POV(Сегодня, 17:00)
- Ты с промкой не работал. - Nikolay_Po(Сегодня, 15:13)
- Мне через мост, дарующий белый айпи, приходилось стучаться из
Рязани до спектроанализатора в Хабаровске через кучу влан. Работало
неделями. Не очень мне понятная паранойя такая, не сталкивался. - POV(Сегодня, 10:12)
- Слово "восстановлением" размыто. Можно сделать преамбулу бит так 128. Сопало? Восстанавливаем. - BlackMorda(Вчера, 22:02)
- я тоже думал, что там какой-то протокол (после установления ТСР-соединения). Оказалось - что на входе, то и на выходе. Пришлось самому придумывать. :-) - Лaгyнoв(Вчера, 20:10)
- Не понятен вопрос. TCP не искажает данных, просто гарантированная
передача. Что значит "с восстановлением"? - Cкpипaч(Вчера, 15:48)
- фрейм имеет размер ~1460 байт данных, данные с UART идут непрерывно
или пакетами переменной длины большей чем frame IP, я об этом и
говорил - восстановить, правильно собрать поток данных - Make_Pic(Сегодня, 07:10)
- Ты решаешь несуществующую проблему. Сколько в сокет запихнулось, столько и будет доставлено. Cкpипaч(452 знак., Сегодня, 15:43)
- C TCP проблема обратная - это *потоковый* протокол, он не имеет "снаружи" видимых границ пакетов. recv() может вернуть любое количество байт, вне зависимости от того, Samx(45 знак., Сегодня, 12:33)
- у меня сейчас прошивки при TCP-соединении валятся потоком. Там 500К
файл идет. Глазом видел разницу только при эзернет или вайфай. У
меня байты, что валятся в UART, индицируются светодиодом. Так при
вайфай он на потоке горит непрерывно, а при эзернет вины
периодические паузы. При этом мне собирать у себя ничего не надо.
Просто жду паузы бОльшей длины. Тогда считаю, что всё передано. Как
у меня в МК влезает 500К? Так два буфера. Как только один
заполнился, переключаюсь на Лaгyнoв(35 знак., Сегодня, 09:39)
- это когда я оттуда принимаю. А вот ТУДА - беда. Там реально (что
вайфай, что эзернет) больше 500-1300 байт скинуть нельзя. Теряются.
Свои большие файлы приходится кусками передавать. - Лaгyнoв(Сегодня, 09:41)
- Когда это работает на микроконтроллере приходится считаться с
ограничениями на доступный объем памяти (кол-во буферов) и с тем
что реализация TCP в чём-то упрощенная, а если ещё и без ОС, то
часть работы которая возлагается на механизмы ОС, приходится
выполнять самому. - ЫЫyкпy(Сегодня, 11:08)
- ограничения, когда я отправляю на сервер, связаны не с моим МК. А с модулем, к которому я подключен. Я бы радостно выкинул туда 5-10-30 кбайт на UART сразу. Но он не пропустит. Самый лучший примет 1300 байт. Худший - 440 байт. Вот к примеру -EBYTE NT1-M Лaгyнoв(1 знак., Сегодня, 16:44, картинка)
- Я бы упростил: нужно считаться с доками. Где-то это всё наверняка
написано. Но "доки придумал трус"™ :-) - SciFi(Сегодня, 11:13)
- Причем с доками не только на свою реализацию, но еще и иметь представление как это работает на "большом брате" чтобы правильно с ним взаимодействовать. Да еще и сами доки обычно так составлены, что описывают как с этим работать, но старательно замалчивают вопрос почему и из каких соображений сделано именно так. В результате программируя для MCU приходится перелопачивать как минимум двойной объем документации и докапываться до самых основ чтобы все это работало, ЫЫyкпy(225 знак., Сегодня, 11:51)
- Тогда зачем применять TCP в услових ограниченных ресурсов? - POV(Сегодня, 11:12)
- Когда это работает на микроконтроллере приходится считаться с
ограничениями на доступный объем памяти (кол-во буферов) и с тем
что реализация TCP в чём-то упрощенная, а если ещё и без ОС, то
часть работы которая возлагается на механизмы ОС, приходится
выполнять самому. - ЫЫyкпy(Сегодня, 11:08)
- это когда я оттуда принимаю. А вот ТУДА - беда. Там реально (что
вайфай, что эзернет) больше 500-1300 байт скинуть нельзя. Теряются.
Свои большие файлы приходится кусками передавать. - Лaгyнoв(Сегодня, 09:41)
- Вот для всего этого и придуман TCP. Цитата из вики: "Механизм TCP предоставляет поток данных с предварительной установкой соединения, осуществляет повторный запрос данных в случае потери данных и устраняет дублирование при получении двух копий одного пакета, гарантируя тем самым (в отличие от UDP) целостность передаваемых данных и уведомление отправителя о результатах передачи." ЫЫyкпy(486 знак., Сегодня, 07:38)
- фрейм имеет размер ~1460 байт данных, данные с UART идут непрерывно
или пакетами переменной длины большей чем frame IP, я об этом и
говорил - восстановить, правильно собрать поток данных - Make_Pic(Сегодня, 07:10)
- Moxa RealCOM для NPort. Официальной спецификации нет, но есть неофициальная. Или RFC2217 bodis(2 знак., Вчера, 15:45, ссылка, ссылка)
- TCP - это прозрачный канал. Как провод в котором байтики шмыгают. - POV(Вчера, 14:29)
- TCP - это и есть тот протокол, который прекрасно может передавать данные UART. - SciFi(Вчера, 14:21)
- Обычный текстовый протокол. Я устройства на USB и прочих последовательных интерфейсах спокойно по сети пробрасываю: хоть моим самописным "прокси" (он умеет в много клиентов), хоть socat. - Eddy_Em(Вчера, 14:20)
