Там же книжки есть. Green & Blue Books. Из них все понятно. Но правда в моем опыте были устройства, которые не совсем следовали написанному. Нужна еще документация конкретного устройства. И то, было дело, сталкивался, что ей тоже не следовали.
По книгам которые в свободном доступе вы ничего не реализуете, необходимо приобретать полные книги которые стоят ощутимых денег, в свободном доступе их нет, приобрести тоже не могу. Если на то пошло то необходимо рыть стандарты IEC 62056 (их хотя бы можно найти в торрентах) а по причине того что там не один десяток книг, многие из которых за 200 листов и возникли вопросы. Как я понял вы с этим протоколом знакомы (если так утверждаете). Если задам пару вопросов сможете ответить?
Ну я то откуда знаю, смогу я ответить или нет. Для меня проект с длмс закончился больше года назад. Может чего и помню еще. Может вообще не сталкивался с твой частью. Длмс - это же широчайшая область. Задавай свои вопросы, а там посмотрим.
Не всегда возможно вписать стороннюю библиотеку в проект, особенно когда он большой. Даже если это и возможно то ты становишься зависимым от сторонней библиотеки. В этом как бы нет ничего плохого если мы говорим о таких либах как Qt или Poco т.е. где есть хорошая поддержка. А вот код в котором много чего не реализовано и правки в который вносились год назад поддерживаемый (хотя судя по коммитам уже мертвый) одним человеком энтузиастом, вызывает большие вопросы. Но основная причина это именно зависимость от сторонней библиотеки. В случае отхождения от стандарта придется править чужой код, который во многих случаях лучше свой написать, чем думать что хотел сказать автор той или иной конструкцией.
Собственно вопроса 2.
1. Касательно HDLC
IEC-62056-46
Посылки передаваемые на сервер разбиваются исходя из размера буферов полученных при отправке SNRM фрейма, хотя в пункте 6.4.1.2 указано что 1 посылка может быть разбита на несколько I фреймов имея следующий вид:
| 0x7E | Frame 1 | 0x7E | Frame 2 | 0x7E и т.д.
Не понятно зачем это надо, если можно отправить одним фреймом если позволяет буфер
| 0x7E | Frame 1 | 0x7E |
а в случае если не позволяет то отправить несколько фреймов устанавливая бит сегментации в 1, что собственно все приборы это и делают.
2. Зачем при отправке I фреймов необходим подуровень LLC если значения всегда одинаковы при отправке 0xE6 0xE6 0x0 а при приеме 0xE6 0xE7 0x0
В случае отхождения от стандарта придется править чужой код, который во многих случаях лучше свой написать, чем думать что хотел сказать автор той или иной конструкцией.
т.е. ты еще не смотрел эту либу, но уже отверг? Ну чо, тогда да - и дальше спрашивай как тебе жить и работать на ЛОРе... 8-\
Я думаю что когда ты подрастешь закончишь школу, и начнешь писать программы выходящие за рамки банального hello world, то до тебя дойдет что есть определенные требования к написанию большого ПО (состоящего хотя бы из 1-1,5k проектов и насчитывающих не одну сотню тысяч а то миллиона строк полезного кода) одно из которых независимость от стороннего кода. А пока вытри слюни и садись делать уроки
Разработчики хрома и фаерфокса разрабатывают opensource по, и ни за что не отвечают. Когда в сторонней библиотеке находится ошибка им похер на неё. А когда речь идет о коммерческом ПО, там требования совершенно другие.
А когда речь идет о коммерческом ПО, там требования совершенно другие.
Например, время выхода на рынок. С самостоятельным велосипедингом DLMS COSEM оно отодвигается на неопределённое недостижимое будущее :) И с чего ты решил, что твоя реализация будет менее глючная, чем существующие
А что им мешает эту ошибку исправить и отправить в апстрим?
Ничего не мешает, только делать мне больше нечего как в рабочее время отлаживать и править ещё и чужие библиотеки.
Например, время выхода на рынок. С самостоятельным велосипедингом DLMS COSEM оно отодвигается на неопределённое недостижимое будущее :) И с чего ты решил, что твоя реализация будет менее глючная, чем существующие
Вот это браво конечно, даже не знаю что тебе тут ответить. Скажи честно, ты ведь не работаешь кодером, правда? Если да то не вижу смысла тебе что то объяснять. Если работаешь, да ещё с коммерческим ПО то у меня вопрос почему ты ещё работаешь и почему тебя не выгнали ещё.
Ничего не мешает, только делать мне больше нечего как в рабочее время отлаживать и править ещё и чужие библиотеки.
Исправить чужую быстрее, чем писать свою с нуля
Скажи честно, ты ведь не работаешь кодером, правда? Если да то не вижу смысла тебе что то объяснять. Если работаешь, да ещё с коммерческим ПО то у меня вопрос почему ты ещё работаешь и почему тебя не выгнали ещё.
Конечно работаю. Более того, очередь работодателей выстраивается, жаждущих меня переманить
Вы что, еще и HDLC сами реализуете? Я так глубоко не спускался. Да, помню, у нас тоже были HDLC линки. Но там уровень сам по себе работал, вот чего-чего, а фреймы руками я не собирал.
Ко мне в прошивку приходили уже готовые буферы. Бывало и по частям. Буферы собирал частями, да, но не фрэймы. И как там оно внутри передавалось - вообще дело нижележащих уровней. Наверное библиотека какая-то была.
Так что, наверное я мало могу помочь.
Единственное наверное что. Фрэймы - это же канальный уровень OSI. Значит скорее всего там есть лайтовые способы проверки этиих фрэймов, режекта и запроса пересылки конкретных фреймов. Чтобы не всю сессию еще раз пересылать, или не весь буфер. Потом могут быть ограничения физического канала передачи инфы на размер пересылаемой информации. Буфер устройства может быть большим, а канал например может ограничить размер пересылаемой единицы. Пример - TDM линки, размер кадра ограничен по кванту времени. OSI-модель универсальна, и протоколы в ней тоже стараются быть универсальными.
Про LLC помню только то, что это еще один протокол канального уровня.
Во, вспомнил, у нас FreeRTOS была. Поэтому мы не изобретали велосипеды. Если вам прям реально нужна своя реализация протокола канального уровня, что ж, могу пожелать только удачи ))) да, такое бывает, но не часто )
Ну видимо все уже было до вас реализовано если работало. Как не крути для подключения вам все приходится в HDLC заворачивать (видимо Вы просто с этим не сталкивались, либо это писали другие). В либах что Шпициалисты (ради которых работодатели готовы глотки грызть) скидывали hdlc также реализуется. На самом деле не все так страшно как кажется на первый взгляд.
HDLC он как основа которая служит для создания протокола, в данном случае dlms. В принципе все реализовано и работает просто оставались не понятными эти 2 момента.
А Вы это утверждаете как человек знакомый со стандартом, или как «я где-то слышал что то про это, услышал знакомые слова, и решил вставить свои 5 копеек»? Если вы знакомы со стандартом то мне крайне интересно в чем же он «весьма» отличается от Российского (СПОДЕС если что называется) ?