Проект контроллера монтировки RUMOUNT

[Максим M]

И еще.. про протоколы. Из изтории программных протоколов.

Когда то была эпоха жестких протоколов  (мир им). Потом появились *ML и иже с ними. Настраиваемый протокол. Все бросились туда. Но это оказалась не панацея. Трудоемкость и избыточность. Теперь выяснилось, что DSL, то есть язык писывающий только предметную область идеально подходит для описания предметных областей. Вот такая тавтология. Придумайте язык который опишет вашу задачу и задача станет тривиальной.

Преобразование float на лету это такой мизер ресурсоемкости. Да что мешает получать в обоих форматах и тексте и бинаре. Отдавайте в бинаре и получИте в бинари. Это на самом деле вообще не имеет значения.

Основной акцент в том, чтобы любое устройство вписалось в него. Органично, без костылей.

Пока я вижу только то что описал - это адерсованный блок, адресованное свойство, значение (с единицей измерения). Универсальнее не знаю.

CAN делает ТОЖЕ САМОЕ только у него блоки цифровые адреса цифровые. + задел на проверку целостности.

[Денис Никитин]

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

[Максим M]

Канову каново. Там без вопросов - ТО, в чем разговаривают микросхемы и без гвоздей.

[Максим M]

2 Aslamov Ilya :: Хм. Что то я почитал 2 раза и не дошло. В первом абзаце вы говорите они все текстовые. Во втором - спрашиваете зачем слать текст когда можно слать бинарное число.

[Aslamov Ilya]

Бинарные я имел в виду не про телескоп. Возмите для примера USB. Там даже не цифры. Манчестер вроде.

При чем здесь физический уровень? У вас в доке Rumount.pdf ясно расписан принцип формирования команд, и он 100% строковый.

Контрольных сумм я НЕ отрицаю но и НЕ декларирую. Хотите - передавайте контрольные, хотите шлите текстом.
Это кстати помечено желтым в документе - про контрольные. Ну да ладно. Я имел в виду CRC которая обязательна (?) в OpenCAN.

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

PS и еще мы говорим об протоколе между КМ и ПО. а не протоколе между КМ и исполнительным устройством.

Конечно, об нем самом.

[Максим M]

А какой смысл обсуждать физический уровень когда не известно какой он будет.
ДЛЯ того случая когда физический уровень ну воообще никакой (а это 2 шланга от компа к КМ) вот тогда смело пишите в команде КС.

А когда ваша команда долетает через USB зачем вам КС.?

[Aslamov Ilya]

2 Aslamov Ilya :: Хм. Что то я почитал 2 раза и не дошло. В первом абзаце вы говорите они все текстовые. Во втором - спрашиваете зачем слать текст когда можно слать бинарное число.

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

[Максим M]

Ага.. теперь становится понятно.

[Rusik]

давайте еще раз если проект открыт то ASCII упростит понимание, и вход новых людей.

а иначе тогда надо обсуждать не то как или что передается и как потом переводится (просто или сложно) для понимания контроллера (или человека)
А приимущества которые дает один перед другим. А то толчемся на одном месте

[Максим M]

ТОгда я Вам парирую. Не спора ради а ради выЯвления преимуществ.

1) Команды читаемы а значит понятно что происходит просто посмотреть
2) Читаем лог, это становится тривиальным
3) Стророннее ПО становится тривиальным в разработке. Не требуются алгоритмы для формирования бинарных пакетов. Воббще как таковые.
4) Становятся доступными средства автоматизации уровня ОС. Теже bash скрипты. Это ж примитивно - bash шлет на КМ echo "?SAT1#" > /dev/ttyUSB0; cat /dev/ttyUSB0 >> log_temp.txt.  И всё - это программа сбора статистики температуры.

И таких средств автоматизации я вам вагон с тачанкой напишу .. а попробуйте запустить это на бинарном протоколе

ЗЫ Любители Windows смогут написать bat файлы по конфигурации КМ. Запустил такой он заводит монтировку, распарковывает ее. Записывает в журнал наблюдений, проводит калибровки и белые поля. Красота. В бинарном для этого понадобятся месяцы и месяцы всё сделать.

[Aslamov Ilya]

А какой смысл обсуждать физический уровень когда не известно какой он будет.
ДЛЯ того случая когда физический уровень ну воообще никакой (а это 2 шланга от компа к КМ) вот тогда смело пишите в команде КС.

Так и я про тоже. Если физический уровень - КОМ порт, то в потоке байт без контрорльных сумм не обойтись.

А когда ваша команда долетает через USB зачем вам КС.?

Если USB работает тупо в режиме эмуляции COM порта - то лишним не будет. В других случаях - это избыточно, согласен.

[Aslamov Ilya]

1) Команды читаемы а значит понятно что происходит просто посмотреть

Тут еще можно поспорить, я тоже смотрю COM-сниффером и все понимаю. Команд ведь не тысяча.

3) Стророннее ПО становится тривиальным в разработке. Не требуются алгоритмы для формирования бинарных пакетов. Воббще как таковые.

Не скажите, какая разница для программы отправить букву "F" - фокусер, или допустим цифру 3? Или например число 545682345, или его бинарное представление в оперативной памяти? Помоему наличие текстовых команд только усложняет написание программы. Ведь не спроста P2P протокол бинарный?

4) Становятся доступными средства автоматизации уровня ОС. Теже bash скрипты. Это ж примитивно - bash шлет на КМ echo "?SAT1#" > /dev/ttyUSB0; cat /dev/ttyUSB0 >> log_temp.txt.  И всё - это программа сбора статистики температуры.

А вот тут я с вами не поспорю, Linux рулит! С этим аргументом согласен 100%



Альтернатив реализации конечно куча, а решать, Маским, однозначно вам! 

[Максим M]

Не далее как вчера? вы меня отговорили от харакири в смысле писать на асме. В пользу Си. С лозунгом что там экономить. Там же 8 килобайт оперативки. 

Сегодня Вы меня тянете обратно, экономить байты

ЗЫ Опыт программистом 19 лет Кричит о том, что самое ВАЖНОЕ это человек. И без разницы вообще отправлять буквы или цифры.
Это байты.. Бинарный отличается от текстового тем что в 2 раза уже.

Какая разница? .. на скорости 115200 ваш пакет занимает меньше миллисекунды. В обоих случаях.

[Aslamov Ilya]

Не далее как вчера? вы меня отговорили от харакири в смысле писать на асме. В пользу Си.
С лозунгом что там экономить. Там же 8 килобайт оперативки. 

Сегодня Вы меня тянете обратно, экономить байты

Не байты памяти программ, а переданные байты.
Да, конечно, экономия не такая уж и большая, хотя даже при 1-2 переданных за раз величин с плавающей точкой - она выше 50%.

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

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

P.S.
Хотя... универсализм конечно и на благо. Если протокол понятен не только компьютеру но и человеку - это только плюс! 

[Максим M]

  .. ну вот, всех обидел.

Итого мы выявили три разных мнения.

1) полностью текстовый
2) полностью бинарный
3) эээ.. значит два.

В силу того, что все существующие протоколы текстовые. В той или иной мере секрентности но команды из текста. В пользу автоматизации обсерваторий bash и python скриптами. В пользу логирования протокола в текстовые файлы. В пользу управления КМ человеком. В пользу управления теми устройствами которых блин ну нету в аскоме.

Протокол между КМ и всем миром выбран ТЕКСТОВЫМ. Решение изменению не подлежит.

Все люди, которые приняли участие в этой минидискуссии - Я Вас благодарю, и вписываю в благодарности в документ.

[Rusik]

на УАРТЕ чесно сказать не вижу разницы большой, единственное при бинаре пакет меньше.
Применял промышленые контроллеры ICPCON там ASCII ни каких проблем даже без CRC, скоростя от 9600 до 115200 и длине связи до 100м.

не заморачивайтесь! давайте возьмем ASCII, тем более что там проверять CRC если в авторском контролере преобразователь USB на борту.
если не УАРТ, то тогда только CAN 

[Максим M]

Обмен с внешним миром UART это вообще нерушимо. А во что завернут этот уарт - несущественно.

[Aslamov Ilya]

.. ну вот, всех обидел.

Даже и в мыслях не было))

В силу того, что все существующие протоколы текстовые. В той или иной мере секрентности но команды из текста. В пользу автоматизации обсерваторий bash и python скриптами. В пользу логирования протокола в текстовые файлы. В пользу управления КМ человеком. В пользу управления теми устройствами которых блин ну нету в аскоме.
Протокол между КМ и всем миром выбран ТЕКСТОВЫМ. Решение изменению не подлежит.

Вот это правильный ход. В кучу собраны все реальные аргументы. Хотя... по большому счету они касаются только линуксоида, кем на сколько я понял, является разработчик системы. Остальным в принципе от этого решения не горяче не холодно.

[Aslamov Ilya]

Обмен с внешним миром UART это вообще нерушимо. А во что завернут этот уарт - несущественно.

Вот именно на чистый  УАРТ я и предполагал CRC. Хотя в свете тесктового протокола нужно будет еще подумать как ее присобачить....  Хотя можно воспользоваться вариантом реализации в протоколе NMEA

[Максим M]

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

Скоро последуют дебаты поинтересней. Небесная механика. Гото. Госё. И моменты истины. Векторное управление. "А где мой драйвер?". Надеюсь всё впереди.

ЗЫ - именно, опциональный КС нас спасет. Ваш вариант?? CRC16? 8? Как присобачить вариант есть - !DAS2346226:9A#