VCucumber 0 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба нужен какой-то протокол, для uart, быстрый, т.е. с малыми накладными расходами и видимо поэтому с асинхронным подтверждением доставки пакетов что предложите ? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 197 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба нужен какой-то протокол, для uart, быстрый, т.е. с малыми накладными расходами и видимо поэтому с асинхронным подтверждением доставки пакетов Протокол выбирается не из того на чём он будет ходить, а из задачи, которую он должен решать. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gerber 8 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба xmodem Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 15 июля, 2017 Опубликовано 15 июля, 2017 (изменено) · Жалоба Протокол выбирается не из того на чём он будет ходить, а из задачи, которую он должен решать. о да, задача, которую должен решать протокол - передача данных от источника к приёмнику xmodem смотрю Изменено 15 июля, 2017 пользователем Огурцов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 197 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба о да, задача, которую должен решать протокол - передача данных от источника к приёмнику Тогда берите любой - не ошибётесь :laughing: Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 15 июля, 2017 Опубликовано 15 июля, 2017 (изменено) · Жалоба смотрю у него нет асинхронности - будет ждать подтверждение каждого пакета Тогда берите любой - не ошибётесь :laughing: в xmodem написано что-то про sliding window protocol Изменено 15 июля, 2017 пользователем Огурцов Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
conan 0 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба нужен какой-то протокол, для uart, быстрый, т.е. с малыми накладными расходами и видимо поэтому с асинхронным подтверждением доставки пакетов что предложите ? А многопоточность доступна? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба А многопоточность доступна? скорее нет, да и какой смысл ? пусть даже будет несколько потоков, канал-то один, как они будут его вместе использовать ? было бы неплохо в исходниках вот https://www.youtube.com/watch?v=8eLhbOlF44U хотя тут можно даже несколько упростить - сделать окно не в четыре пакета, а в два Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
gerber 8 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба скорее нет, да и какой смысл ? пусть даже будет несколько потоков, канал-то один, как они будут его вместе использовать ? Как это какой смысл? Вы же хотите асинхронности, чтобы не ждать подтверждения каждого пакета. Поэтому логично запустить 2 асинхронных потока - один передает пакеты из очереди, другой принимает подтверждения. Пришло подтверждение - удаляем пакет из очереди на передачу. Таким образом и получится окно, равное размеру TxD-очереди. Обходим очередь по кругу - неподтвержденные пакеты сами будут периодически перепосылаться. Они же все пронумерованы, приемная сторона сама разберется, что к чему. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба один передает пакеты из очереди, другой принимает подтверждения это на прерываниях прекрасно делается Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
conan 0 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба Много лет назад реализовал протокол двусторонней пакетной передачи (по uart) сообщений с гарантированием на основе контрольных сумм, таймаутов и повторных передач. Без адресации -- только два узла. Была самодельная многопоточность. Сперва реализовал на C под DOS на PC, потом просто строчка за строчкой перенес на avr asm Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
x893 41 15 июля, 2017 Опубликовано 15 июля, 2017 · Жалоба SLIP/CSLIP Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
VCucumber 0 16 июля, 2017 Опубликовано 16 июля, 2017 · Жалоба SLIP/CSLIP это вроде бы просто форматирование, подтверждение там не прописано в общем, почитал, подумал и понял, что tcp для кражи не подходит - много чего лишнего для меня, типа поднятия подключения а вот окно или буферизацию пакетов для подтверждения доставки нужно взять Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
blackfin 22 16 июля, 2017 Опубликовано 16 июля, 2017 · Жалоба в общем, почитал, подумал и понял, что tcp для кражи не подходит - много чего лишнего для меня, .. Тогда воруйте RUDP.. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mantech 37 16 июля, 2017 Опубликовано 16 июля, 2017 · Жалоба с малыми накладными расходами и видимо поэтому с асинхронным подтверждением доставки пакетов Чет не понял, неужели так сложно принять N байт и на лету посчитать какую-нить CRC16 из таблицы, и выдать подтверждение правильности приема? Или так далеко нужно передавать, что время передачи сигнала в линии уже секундами измеряется или кол-во ретрансляторов дофига, тогда только нужна асинхронность. В остальных случаях это просто дикость ИМХО. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться