Перейти к содержанию
    

Посоветуйте что почитать по реализации протоколов

1 hour ago, mantech said:

А еще бывает так, что реализация настолько запутана, что потратить времени, чтобы понять ее нужно столько, что действительно проще написать свою. 

C протоколами чаще всего проблема в неопределенности угроз. 
Если вы не имеете серьезных помех по RS485 и не имеет жестких требований по времени доставки, то можете там писать поверх него все что вздумается.
И все  равно оно будет работать. 

А вот с модемными протоколами типа PPP или многоканальными типа TCP или mesh протоколами все гораздо сложнее.
И не напишите вы их ни за 3 недели ни за год. Потому что они требуют адекватного моделирования, а адекватная модель требует исследования среды передачи и изучение мат. аппарата. 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

2 часа назад, AlexandrY сказал:

Если вы не имеете серьезных помех по RS485 и не имеет жестких требований по времени доставки,

Если б это было так, то и заморачиваться бы не стал, кинул несколько каналов точка-точка на 232м с гальваноразвязкой, да и делов-то... Как раз использование предполагает наличие помех и управление силовыми нагрузками, средняя задержка вкл\выкл канала не более 10мсек, считывание данных с датчиков обратной связи. Поэтому только мастер-слейв, только минимальные таймслоты для пакетов автодетекта, без всякой анархии навроде csma-cd и пр.

Изменено пользователем mantech

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

5 часов назад, Ruslan1 сказал:

Например, про легкий вариант lwip: нужна действительно очень специальная ниша, если его модульности, доступной через систему дефайнов, не хватает.

Очень специальная?  :russian_ru:  Ну например - требование минимального расхода ОЗУ (так как её дефицит) для нескольких одновременно открытых сокетов - очень специально? Позволяет ли lwIP организовать работу с TCP-сокетами так, чтобы вообще не требовался бы буфер для TCP-сокета? И чтобы, при этом, скорость работы такого сокета не упала ниже плинтуса.

Если это уже - "специальные требования", то тогда у меня все проекты - только "специальные ниши".  :wink2:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

1 hour ago, jcxz said:

Очень специальная?  :russian_ru:  Ну например - требование минимального расхода ОЗУ (так как её дефицит) для нескольких одновременно открытых сокетов - очень специально? Позволяет ли lwIP организовать работу с TCP-сокетами так, чтобы вообще не требовался бы буфер для TCP-сокета? И чтобы, при этом, скорость работы такого сокета не упала ниже плинтуса.

Если это уже - "специальные требования", то тогда у меня все проекты - только "специальные ниши".  :wink2:

Ага. Хороший пример. Да, я считаю что это именно тот особый случай: применен протокол, под буфер которого не предусмотрено аппаратных ресурсов. Тут надо извиваться ужом (между ресурсами и производительностью), и это необычно.

Сейчас ресурсы сильно дешевле чем рабочее время, так что практически всегда рентабельней иначе решать, без выкручивания рук разработчику. Обратная ситуация, конечно, бывает, но лично я с таким давно не сталкивался. История одного байта- это уже давнее прошлое.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

11 минут назад, Ruslan1 сказал:

Сейчас ресурсы сильно дешевле чем рабочее время, так что практически всегда рентабельней иначе решать, без выкручивания рук разработчику.

Это пока вы не сталкиваетесь с разработкой серийных изделий со сколько-нибудь значительной серией. И тогда уже вам будут выкручивать руки снабженцы и отдел продаж. Чтобы впихнуть побольше в МК подешевле.

Или когда надо добавить какой-то функционал в уже готовое изделие, где ресурсы на исходе.

Да и в начале разработки, даже если серия не грозит, всегда есть смысл экономить ресурсы. Чтобы потом, если вдруг окажется, что нужно ещё пару программных фич впихнуть, не пришлось весь проект переделывать с нуля.

А ещё бывает что выбора просто нет, так как есть другие требования: исполнение, температурный диапазон, наличие какой-то периферии и пр. И выбор подходящих МК - раз, два и обчёлся. И тогда работаешь с тем, что есть.

Цитата

Обратная ситуация, конечно, бывает, но лично я с таким давно не сталкивался. История одного байта- это уже давнее прошлое.

Где-ж давняя? Разница в ценах между жирными МК и более простыми никуда не делась и сейчас.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

45 minutes ago, jcxz said:

Это пока вы не сталкиваетесь с разработкой серийных изделий со сколько-нибудь значительной серией. И тогда уже вам будут выкручивать руки снабженцы и отдел продаж. Чтобы впихнуть побольше в МК подешевле.

Абсолютно согласен. Я догадываюсь что такое масс-продакшн и понимаю, что там подходы другие. Если Вы именно там крутитесь и выживаете- то честь Вам и хвала. Серьезно, без сарказма. Я б наверное уже не смог.

Когда-то каждый дизайн делал, как будто завтра миллион выпустим и сэкономим на этом аж миллион денег. Но потом прошло. Будет такой тираж- тоже буду байты считать, даташиты с китайского переводить и про массу затраченного припоя думать.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Начали за здравие, как говорится.....

Изначально был вопрос о реализации протоколов, которые уже разработаны и все мат.модели выверены.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

14 minutes ago, sigmaN said:

Изначально был вопрос о реализации протоколов, которые уже разработаны и все мат.модели выверены.

Ну так сразу надо было ясно вопрос задать - 
как сделать реализацию по готовой спецификации типа PPP (Point-to-Point Protocol; RFC-2716, -2701, -2688, -2687, -2686, -2615, -2516, -2509, -2508, -2507, -2484, -2472, -2433, -2420, -2419, -2364, -2363, -2290, -2284, -2153, -2125, -2097, -2043, -1994, -1993, -1990, -1989, -1979, -1978, -1977, -1976, -1975, -1974, -1973, -1969, -1968, -1967, -1963, -1962, -1915, -1877, -1841, -1764, -1763, -1762, -1663, -1662, -1661, -1638, -1619, -1618, -1598, -1570, -1552, -1378, -1377, -1334, -1332, -1331, и STD-51,) ? 

И бы вам пожелал долгих лет чтобы просто прочитать эту спецификацию до конца. :bye:  

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

36 минут назад, AlexandrY сказал:

И бы вам пожелал долгих лет чтобы просто прочитать эту спецификацию до конца.

Дык там все эти РФС наверно уже давно устарели и никто их не поддерживает давно, протокол-то чуть позднее интернета родился...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

20 hours ago, AlexandrY said:

И бы вам пожелал долгих лет чтобы просто прочитать эту спецификацию до конца. :bye:  

Ну я ваш стиль нагнетания ситуации и наведения ужаса уже понял, да. Спасибо )

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

21 hours ago, sigmaN said:

все мат.модели выверены

Какие матмодели протоколов? Опять никакой связи с реальностью.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

7 hours ago, rkit said:

Какие матмодели протоколов? Опять никакой связи с реальностью.

Можете подробнее описать вашу мысль?
Как проектируют?
Вот вы параметры CRC(не только длину, разумеется) как выбираете?
А может быть нужно не только детектировать ошибки, но и восстанавливать(избыточное кодирование).
А какие ошибки восстанавливать нужно? Сколько бит избытка будет нормально по вашему?

Ну и ещё там по мелочи что-нибудь расскажите немного об этом, если можно.
Очень интересно как оно в реальности делается....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

On 7/22/2020 at 9:04 AM, Ruslan1 said:

должны быть более другие аргументы, чем "хочу более правильный", "этот некрасивый", или "свой хочу".  Ну и опять же, чтобы писать свое с чистого листа- нужны очень весомые аргументы.

это в чистом виде синдром неприятия чужой разработки (not invented here — «изобретено не нами»),  https://en.wikipedia.org/wiki/Not_invented_here

у российсих ИТ-гигантов это прям как опухоль.

On 7/23/2020 at 10:28 PM, sigmaN said:

Вот вы параметры CRC(не только длину, разумеется) как выбираете?
А может быть нужно не только детектировать ошибки, но и восстанавливать(избыточное кодирование).

по CRC вот тут можно почитать: http://idoka.ru/who-is-better-than-crc32/

либо более подробьно на языке оригинала: Philip Koopman, Cyclic Redundancy Code (CRC) Polynomial Selection For Embedded Networks

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...