[DogPawlowa 0]

В SNMP самое главное MIB файлы, которые грузятся и в дивайс и в SNMP менеджер на компьютере.

Я даже создал специальную программу которая генерировала одновременно и MIB для менеджера и текст на C-и с тем же деревом сущностей для дивайса.

Я не сторонник дополнительного программирования, текст на С генерируется X-макросами, а "MIB-файл" читается с устройства один раз и запоминается "браузером".

Самому интересно было, насколько можно совмещать уровни. Оказалось, что для простых устройств все прекрасно получается в двух уровнях - "физика" и "лирика" :)

[AlexandrY 3]

Первый раз слышу про "контроллер RS-485", в котором адрес передается аппаратно, что его можно даже выкинуть из пакета Modbus.

Просто не могу представить, что бы это могло быть.

Вообще-то, стандарт RS-485 на физическом уровне даже структуру фрейма не оговаривает, хоть манчестер гони, не говоря уже о более высоких протоколах. То есть это тупо дифференциальная линия с оговоренными параметрами сигнала и возможностью переключения в Z-состояние

 

Тогда так - аппаратно-программный контроллер. Так устраивает?

А раз формат не оговорен, то я в своем контексте могу что угодно говорить о формате.

 

Мою реализацию MODBUS можете позаимствовать вот из этой статьи http://www.soel.ru/cms/f/?/311636.pdf

Адрес в MODBUS это не адрес на шине RS485. MODBUS не привязан ни к какой шине.

Также у меня есть свои реализации и MODBUS RTU и MODBUS Over TCP.

 

Но мне не приходит в голову продвигать эти морально устаревшие решения в эпоху IoT.

[=AK= 14]

если уж говорить о кодировании в пакетах, то тогда сразу человека надо отправить к ASN.1 и кодировке BER

 

Вы не поняли, о чем речь. Я ни слова не говорил о кодировании в пакетах. Вы бы открыли приведенную мною ссылку и почитали, прежде чем отвечать. ТС спросил про байт-стаффинг для организации пакетного режима - я ему предложил очень продвинутый и одновременно очень простой вариант байт-стаффинга. А кодирование поверх этого он добавит сам, если ему нужно.

[AlexandrY 3]

Я не сторонник дополнительного программирования, текст на С генерируется X-макросами, а "MIB-файл" читается с устройства один раз и запоминается "браузером".

Самому интересно было, насколько можно совмещать уровни. Оказалось, что для простых устройств все прекрасно получается в двух уровнях - "физика" и "лирика" :)

 

У меня несколько десятков проектов использующих SNMP на промышленных объектах.

И программа в частности поддерживала их все. Так что "X-макросами" никак было не отделаться, тем более что одновременно с этим генерируются и HTML страницы и ini файлы для дивайсов.

[zltigo 1]

Если не лень сделать свой протокол, то советую обратить внимание на элегантный COBS. А уж к нему элементарно добавите все, что вам нужно.

Ну если уж говорить о кодировании в пакетах, то тогда сразу человека надо отправить к ASN.1 и кодировке BER

Я, мягко говоря, хренею :(. BER и иже с ним, хоть и увидели Вы в описании слово "кодировка", ни сном ни духом к фреймингу, ака COBS, SLIP и прочие не имеет. Это абсолютно другой уровень протоколов уже лежащих выше того-же TCP.

Вы зачем-то выкидаваете сюда много слов и букв значения которых просто не понимаете :(.

 

 

[AlexandrY 3]

Вы не поняли, о чем речь. Я ни слова не говорил о кодировании в пакетах. Вы бы открыли приведенную мною ссылку и почитали, прежде чем отвечать. ТС спросил про байт-стаффинг для организации пакетного режима - я ему предложил очень продвинутый и одновременно очень простой вариант байт-стаффинга. А кодирование поверх этого он добавит сам, если ему нужно.

 

А чем же является стаффинг как не кодированием?

 

В том же lwIP есть и PPP, там этого стаффинга сколько хош.

Зато это законченный протокол который понимает Windows.

 

Но только надо же понимать какую пользу оно принесет хотя бы оценочно.

А слышу только - "бэдлокод" в качестве аргумента.

 

Я, мягко говоря, хренею :(.

 

Ладно, еще для расширения вашего кругозора.

Чтобы так сказать открыть глаза - протокол MAVLink

Для сведения это очень популярный протокол у беспилотных систем.

Обратите внимание на его структуру.

Не упадите со стула, от избытка эмоций.

[zltigo 1]

В том же lwIP есть и PPP, там этого стаффинга сколько хош.

Зато это законченный протокол который понимает Windows.

Так-же, как и линукс, и windows понимают SLIP

А слышу только - "бэдлокод" в качестве аргумента.

а, хоть ДЛЯ меня "понимание видовсом" НЕ аргумент, предложеный Вами "быдлокод" вместо нормального фрейминга, не понимает.

 

 

[AlexandrY 3]

Так-же, как и линукс, и windows понимают SLIP

 

а, хоть ДЛЯ меня "понимание видовсом" НЕ аргумент, предложеный Вами "быдлокод" вместо нормального фрейминга, не понимает.

 

О! Понеслись перлы.

 

Ну-ка напомните мне где там в сетевых подключениях Windows 7..10 настроить SLIP?

[zltigo 1]

Ладно, еще для расширения вашего кругозора.

Чтобы так сказать открыть глаза - протокол MAVLink

Для сведения это очень популярный протокол у беспилотных систем.

Обратите внимание на его структуру.

Это только уж в который раз :(, подтверждает Ваше полное непонимание места конктетных протоколов в системе. По глупости Вы начали очередной раз размахивать пакетом протокола (причем уже доморощенным) верхнего уровня который до этого был передан по какму-то физическому каналу, как-то ОФОРМЛЕН ВО ФРЕЙМ, возможно было обеспечена и его перепередача... С таким-же "успехом" Вы можете размахивать, напимер, UDP протоколом - там все по любимой Вами "структуре", только в отличие от "быдлокодовского" подхода к делу,

UDP не запихивается канал передачи непосредственно, а сначала оборачивается в IP, а потом во фреймер, кторый в случае асинхронного байтового UART реализуется СОФТОВО, и во всех стандартно ПРОФЕССИОНАЛЬНО сделаных реализациях (SLIP, PPP ) этот фреймер сделан не по "быдлокодовски":

Короче формулы: [хидер][длина][данные][CRC] хватит выше крыши и на все случаи жизни.

, а на базе байстаффинга.

[AlexandrY 3]

, а на базе байстаффинга.

 

Кстати забыл самый важный аргумент.

Длина пакета должна идти в хидере чтобы автоматически загружаться в DMA. И хидер всегда должен быть фиксированной длины.

 

А стаффинг ставит крест на приеме с использованием DMA. Поэтому стаффинг в топку.

[zltigo 1]

Кстати забыл самый важный аргумент.

Длина пакета должна идти в хидере чтобы автоматически загружаться в DMA. И хидер всегда должен быть фиксированной длины.

 

А стаффинг ставит крест на приеме с использованием DMA. Поэтому стаффинг в топку.

Вы своим постом поставили очередной крест на своей репутации :(. Есть определеное железо. В случае UART оно очень простое и по определению НЕ поддерживает пакетный интерефейс.

По этой причине оформление фрейма нужно делать программно. И эту задачу надо решить надежно и качественно, и совершенно НЕ важно, что программисту удобнее наплевать на все, и сделать фрейминг хреново, но с ему привычно-простейшим использованием DMA, как он делал при взаимодействии с пакетными интерфейсами, которые, как минимум, задачу фрейминга берут на себя. Увы, надо считаться и с реальностью и с железом, и не смотря на неидеальность мира делать свою работу не по радиолюбительски, в стиле - у меня есть DMA и я буду делать так, как ЕМУ нужно.

[ViKo 1]

Мне для пересылки прошивки из компа в прибор не нужны ни хидер, ни длина. По таймауту заканчиваю прием, тогда же и размер определяю. Проверяю по CRC, что в конце прошивки приписана. Если что, пересылаю еще раз. Всё.

Для работы использую SCPI. http://www.ivifoundation.org/docs/scpi-99.pdf

То есть, шлю по большей части ASCII команды. Кроме массивов, там уже в двоичном виде. Но длина известна.

В-общем, на каждый случай нужен свой велосипед.

[AlexandrY 3]

у меня есть DMA и я буду делать так, как ЕМУ нужно.

 

Ставлю пять!

А ОН это кто?

Вы уверены что знаете ЕГО?

 

[zltigo 1]

Мне для пересылки прошивки из компа в прибор....

Ну это уже совсем отдельная задача.

У меня традиционно, если с терминала, заливается текстовый файл по по мотивам HEX формата до 512 байт прошивки в строке , но шифрованный, с сигнатурами, контрольными суммами, зашумлением.

То есть все-же построчно стуктурированный и содержащий в себе и команды (пропуск зоны адресов, конец прошивки, стирание, запуск программы, сброс...)тоже. В этом тестовом файле есть и комментарии и сразу скриптовые команды, по которым, контроллер из терминального режима переходит в загрузчик.

 

//----------------------------------------------------------------------------

$aesfile

:212C00A8C8DB469CB1B7138B633F2A642B9232E4940DE3F6CDADF8CADD309DF45F01F97D997D927

....

[jcxz 224]

Кстати забыл самый важный аргумент.

Длина пакета должна идти в хидере чтобы автоматически загружаться в DMA. И хидер всегда должен быть фиксированной длины.

А стаффинг ставит крест на приеме с использованием DMA. Поэтому стаффинг в топку.

"Смешались в кучу люди кони"......

Какая связь между байт-стаффингом и DMA??? Точно такая-же как между круглым и сладким.

Кодер передаваемого фрейма, обрамляет кадр символами границ кадра, тело кадра кодирует с помощью байт-стаффинга. Получившийся массив байт кодер записывает в выходной буфера драйвера канала (в нашем случае - UART) канального уровня протокола. Всё - на этом работа фрейм-кодера заканчивается. Далее он ждёт следующего tx-кадра на своём входе. Который опять-же кодирует и дописывает в выходной буфер потока байт нижележащего драйвера канала.

Ну не знает фрейм-кодер ничего о реализации механизма транспорта канального уровня - по прерываниям тот будет байты передавать или задействует DMA или и то и другое или вообще голубиной почтой отправит. Не его это дело. Для этого придумано деление на уровни протокола обмена. Так же как и грамотное ПО должно делиться на уровни и службы: прикладная часть, ядро стека протокола, драйвер физического канала связи и т.п.

А уже драйвер канала связи, если ему нужно DMA, определит кол-во байт в своей входной очереди и если нужно запрограммирует DMA на пересылку части этого массива байт в UART.

Такой стиль позволяет абстрагироваться от аппаратуры и аппаратной реализации драйверов канала нижнего уровня и сделать ПО переносимым между разными платформами, просто переписав драйвер канала нижнего уровня. Также можно легко перенести это ПО на другой тип канала, заменив канальный драйвер нижнего уровня.

 

У вас же всё намешано в кучу. Малейшее изменение свойств канала передачи, потребует полной переделки не только всего ПО связи, но и самого протокола обмена.

А представляете - люди пишут такие протоколы обмена, которые работают поверх различных как физических так и логических каналов передачи, не важно - по нижнему уровню идёт обычный RS-485, или же потоковый TCP/IP или же пакетный ZigBee...