DogPawlowa 0 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба В SNMP самое главное MIB файлы, которые грузятся и в дивайс и в SNMP менеджер на компьютере. Я даже создал специальную программу которая генерировала одновременно и MIB для менеджера и текст на C-и с тем же деревом сущностей для дивайса. Я не сторонник дополнительного программирования, текст на С генерируется X-макросами, а "MIB-файл" читается с устройства один раз и запоминается "браузером". Самому интересно было, насколько можно совмещать уровни. Оказалось, что для простых устройств все прекрасно получается в двух уровнях - "физика" и "лирика" :) Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба Первый раз слышу про "контроллер 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= 17 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба если уж говорить о кодировании в пакетах, то тогда сразу человека надо отправить к ASN.1 и кодировке BER Вы не поняли, о чем речь. Я ни слова не говорил о кодировании в пакетах. Вы бы открыли приведенную мною ссылку и почитали, прежде чем отвечать. ТС спросил про байт-стаффинг для организации пакетного режима - я ему предложил очень продвинутый и одновременно очень простой вариант байт-стаффинга. А кодирование поверх этого он добавит сам, если ему нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба Я не сторонник дополнительного программирования, текст на С генерируется X-макросами, а "MIB-файл" читается с устройства один раз и запоминается "браузером". Самому интересно было, насколько можно совмещать уровни. Оказалось, что для простых устройств все прекрасно получается в двух уровнях - "физика" и "лирика" :) У меня несколько десятков проектов использующих SNMP на промышленных объектах. И программа в частности поддерживала их все. Так что "X-макросами" никак было не отделаться, тем более что одновременно с этим генерируются и HTML страницы и ini файлы для дивайсов. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба Если не лень сделать свой протокол, то советую обратить внимание на элегантный COBS. А уж к нему элементарно добавите все, что вам нужно. Ну если уж говорить о кодировании в пакетах, то тогда сразу человека надо отправить к ASN.1 и кодировке BER Я, мягко говоря, хренею :(. BER и иже с ним, хоть и увидели Вы в описании слово "кодировка", ни сном ни духом к фреймингу, ака COBS, SLIP и прочие не имеет. Это абсолютно другой уровень протоколов уже лежащих выше того-же TCP. Вы зачем-то выкидаваете сюда много слов и букв значения которых просто не понимаете :(. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба Вы не поняли, о чем речь. Я ни слова не говорил о кодировании в пакетах. Вы бы открыли приведенную мною ссылку и почитали, прежде чем отвечать. ТС спросил про байт-стаффинг для организации пакетного режима - я ему предложил очень продвинутый и одновременно очень простой вариант байт-стаффинга. А кодирование поверх этого он добавит сам, если ему нужно. А чем же является стаффинг как не кодированием? В том же lwIP есть и PPP, там этого стаффинга сколько хош. Зато это законченный протокол который понимает Windows. Но только надо же понимать какую пользу оно принесет хотя бы оценочно. А слышу только - "бэдлокод" в качестве аргумента. Я, мягко говоря, хренею :(. Ладно, еще для расширения вашего кругозора. Чтобы так сказать открыть глаза - протокол MAVLink Для сведения это очень популярный протокол у беспилотных систем. Обратите внимание на его структуру. Не упадите со стула, от избытка эмоций. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба В том же lwIP есть и PPP, там этого стаффинга сколько хош. Зато это законченный протокол который понимает Windows. Так-же, как и линукс, и windows понимают SLIP А слышу только - "бэдлокод" в качестве аргумента. а, хоть ДЛЯ меня "понимание видовсом" НЕ аргумент, предложеный Вами "быдлокод" вместо нормального фрейминга, не понимает. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба Так-же, как и линукс, и windows понимают SLIP а, хоть ДЛЯ меня "понимание видовсом" НЕ аргумент, предложеный Вами "быдлокод" вместо нормального фрейминга, не понимает. О! Понеслись перлы. Ну-ка напомните мне где там в сетевых подключениях Windows 7..10 настроить SLIP? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 22 сентября, 2015 Опубликовано 22 сентября, 2015 · Жалоба Ладно, еще для расширения вашего кругозора. Чтобы так сказать открыть глаза - протокол MAVLink Для сведения это очень популярный протокол у беспилотных систем. Обратите внимание на его структуру. Это только уж в который раз :(, подтверждает Ваше полное непонимание места конктетных протоколов в системе. По глупости Вы начали очередной раз размахивать пакетом протокола (причем уже доморощенным) верхнего уровня который до этого был передан по какму-то физическому каналу, как-то ОФОРМЛЕН ВО ФРЕЙМ, возможно было обеспечена и его перепередача... С таким-же "успехом" Вы можете размахивать, напимер, UDP протоколом - там все по любимой Вами "структуре", только в отличие от "быдлокодовского" подхода к делу, UDP не запихивается канал передачи непосредственно, а сначала оборачивается в IP, а потом во фреймер, кторый в случае асинхронного байтового UART реализуется СОФТОВО, и во всех стандартно ПРОФЕССИОНАЛЬНО сделаных реализациях (SLIP, PPP ) этот фреймер сделан не по "быдлокодовски": Короче формулы: [хидер][длина][данные][CRC] хватит выше крыши и на все случаи жизни. , а на базе байстаффинга. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 23 сентября, 2015 Опубликовано 23 сентября, 2015 · Жалоба , а на базе байстаффинга. Кстати забыл самый важный аргумент. Длина пакета должна идти в хидере чтобы автоматически загружаться в DMA. И хидер всегда должен быть фиксированной длины. А стаффинг ставит крест на приеме с использованием DMA. Поэтому стаффинг в топку. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 23 сентября, 2015 Опубликовано 23 сентября, 2015 · Жалоба Кстати забыл самый важный аргумент. Длина пакета должна идти в хидере чтобы автоматически загружаться в DMA. И хидер всегда должен быть фиксированной длины. А стаффинг ставит крест на приеме с использованием DMA. Поэтому стаффинг в топку. Вы своим постом поставили очередной крест на своей репутации :(. Есть определеное железо. В случае UART оно очень простое и по определению НЕ поддерживает пакетный интерефейс. По этой причине оформление фрейма нужно делать программно. И эту задачу надо решить надежно и качественно, и совершенно НЕ важно, что программисту удобнее наплевать на все, и сделать фрейминг хреново, но с ему привычно-простейшим использованием DMA, как он делал при взаимодействии с пакетными интерфейсами, которые, как минимум, задачу фрейминга берут на себя. Увы, надо считаться и с реальностью и с железом, и не смотря на неидеальность мира делать свою работу не по радиолюбительски, в стиле - у меня есть DMA и я буду делать так, как ЕМУ нужно. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
ViKo 1 23 сентября, 2015 Опубликовано 23 сентября, 2015 · Жалоба Мне для пересылки прошивки из компа в прибор не нужны ни хидер, ни длина. По таймауту заканчиваю прием, тогда же и размер определяю. Проверяю по CRC, что в конце прошивки приписана. Если что, пересылаю еще раз. Всё. Для работы использую SCPI. http://www.ivifoundation.org/docs/scpi-99.pdf То есть, шлю по большей части ASCII команды. Кроме массивов, там уже в двоичном виде. Но длина известна. В-общем, на каждый случай нужен свой велосипед. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
AlexandrY 3 23 сентября, 2015 Опубликовано 23 сентября, 2015 · Жалоба у меня есть DMA и я буду делать так, как ЕМУ нужно. Ставлю пять! А ОН это кто? Вы уверены что знаете ЕГО? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
zltigo 1 23 сентября, 2015 Опубликовано 23 сентября, 2015 · Жалоба Мне для пересылки прошивки из компа в прибор.... Ну это уже совсем отдельная задача. У меня традиционно, если с терминала, заливается текстовый файл по по мотивам HEX формата до 512 байт прошивки в строке , но шифрованный, с сигнатурами, контрольными суммами, зашумлением. То есть все-же построчно стуктурированный и содержащий в себе и команды (пропуск зоны адресов, конец прошивки, стирание, запуск программы, сброс...)тоже. В этом тестовом файле есть и комментарии и сразу скриптовые команды, по которым, контроллер из терминального режима переходит в загрузчик. //---------------------------------------------------------------------------- $aesfile :212C00A8C8DB469CB1B7138B633F2A642B9232E4940DE3F6CDADF8CADD309DF45F01F97D997D927 .... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
jcxz 234 23 сентября, 2015 Опубликовано 23 сентября, 2015 · Жалоба Кстати забыл самый важный аргумент. Длина пакета должна идти в хидере чтобы автоматически загружаться в DMA. И хидер всегда должен быть фиксированной длины. А стаффинг ставит крест на приеме с использованием DMA. Поэтому стаффинг в топку. "Смешались в кучу люди кони"...... Какая связь между байт-стаффингом и DMA??? Точно такая-же как между круглым и сладким. Кодер передаваемого фрейма, обрамляет кадр символами границ кадра, тело кадра кодирует с помощью байт-стаффинга. Получившийся массив байт кодер записывает в выходной буфера драйвера канала (в нашем случае - UART) канального уровня протокола. Всё - на этом работа фрейм-кодера заканчивается. Далее он ждёт следующего tx-кадра на своём входе. Который опять-же кодирует и дописывает в выходной буфер потока байт нижележащего драйвера канала. Ну не знает фрейм-кодер ничего о реализации механизма транспорта канального уровня - по прерываниям тот будет байты передавать или задействует DMA или и то и другое или вообще голубиной почтой отправит. Не его это дело. Для этого придумано деление на уровни протокола обмена. Так же как и грамотное ПО должно делиться на уровни и службы: прикладная часть, ядро стека протокола, драйвер физического канала связи и т.п. А уже драйвер канала связи, если ему нужно DMA, определит кол-во байт в своей входной очереди и если нужно запрограммирует DMA на пересылку части этого массива байт в UART. Такой стиль позволяет абстрагироваться от аппаратуры и аппаратной реализации драйверов канала нижнего уровня и сделать ПО переносимым между разными платформами, просто переписав драйвер канала нижнего уровня. Также можно легко перенести это ПО на другой тип канала, заменив канальный драйвер нижнего уровня. У вас же всё намешано в кучу. Малейшее изменение свойств канала передачи, потребует полной переделки не только всего ПО связи, но и самого протокола обмена. А представляете - люди пишут такие протоколы обмена, которые работают поверх различных как физических так и логических каналов передачи, не важно - по нижнему уровню идёт обычный RS-485, или же потоковый TCP/IP или же пакетный ZigBee... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться