Форматирование данных и передача даных UART

[WindoЗavr]

попробую организовать обмен данными по протоколу из примера, а затем так

Потом все равно захочется как-то программно обрабатывать полученные данные. Так что поставьте OPC сервер, напишите slave modbus функцию 3 в устройстве и не парьтесь. Неделя работы, больше п...дите тут.
План работ:
Выбрать скорость обмена
В таймере сделать прерывания не меньше 2 на 1 байт (время приёма байта - для 9600 1 мс). каждое прерывание прибавлять счётчик тишины. при достижении счётчика тишины, например, 8 (2х4байта в случае 2 прерывания на байт) выставлять счётчик тишины.
Определить состояния устройства - простой, приём данных, обработка данных, ответ, ошибка.
Если состояние "приём данных" и флаг тишины установлен, переход в обработку заброса и ответ.
В обработке запроса проверка CRC16 и допустимого диапазона данных, допустимого адреса данных, адреса устройства и функции.
Если всё нормально, подготовка байтов ответа, подсчёт CRC16 ответа. Добавление 2 байт CRC в конец сообщения. Передача сообщения.
При неправильном CRC приёма состояние ошибка - обработка ошибки и возврат в простой.

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

[WindoЗavr]

попытался из комментария выше сделать алгоритм
имхо это бред

зачем проверять на допустимый диапазон значений входы АЦП?
зачем устанавливать флаг простоя?
зачем куча флагов

с таймером, счётчиком тишины и CRC16 согласен

-------------- прерывание срабатывающее раз в  1 мс
  //время приёма байта  (9600) 
  счётчик тишины = счётчик тишины+1
-----------------------------------------------------------
если num ‹1 или ›7
        отсылка кода ошибки
        num=1

считать АЦП номер (num)

 если  счётчик тишины == 8
      расчёт  CRC16 для значения АЦП (num)
      формирование посылки //(num)_значение АЦП_CRC16
      отсылка данных
      num= num + 1
         если  num==7 
            отсылка посылки из 2 байт забитых 0 и 1
            num=1
      сбросить счётчик тишины

так будет работать?
как хоть примерно парсить это на компе?

[akegor]

WindoЗavr, свое видение вопроса я изложил. Тащить сюда модбас считаю извращением. Но это чисто мое мнение и на истину в последней инстанции не претендую.
Что за "счетчик тишины"? За каким корнеплодом он сдался?
Зачем CRC16 на три байта?
Почему не передать все замеры (каналы) одним пакетом?
Зачем усложнять там, где все просто, как два байта переслать?

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

[kosmos440o]

Modbus нужен для передачи в СКАДу без извращений с протоколом и защиты данных (защита даже нормируется ГОСТами, если серьёзно делать). А дальше - графики, таблицы, любая обработка, передача в SQL, в интернет - всё намного легче и понятней другим людям.
Состояние простоя - только в нём по приёму байта вы понимаете, что это первый байт, можно позырить адрес и начать счёт байтов сообщения.
Флаг тишины - если вы в состоянии приёма байтов, и тишина уже 4 байта, то можно считать сообщение законченным и начинать его обработку. Если есть какие-то другие методы, можете их озвучить. Некоторые просто периодически проверяют программный буфер, в который пихают по прерыванию УАРТ, но я считаю это некорректным.

[akegor]

Modbus нужен для передачи в СКАДу

Для одного-двух отсчетов АЦП ? Может, пушку подобрать по воробью?

Флаг тишины

и

если счётчик тишины == 8

не совсем стыкуются.

тишина уже 4 байта, то можно считать сообщение законченным и начинать его обработку.

Это как подойти к формированию данных. Если все собирать в пакет и передавать "единоразово", то - да, а если передается каждый замер, нет.
А вообще-то, я же сказал

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

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

[Boba_spb]

Да сделайте на простеньком DCON протоколе и не парьтесь.
http://www.bookasutp.ru/Chapter2_10.aspx

Приходилось делать прослойку для перевода MODBUS в DCON. В системе были модули на DCON и несколько девайсов на MODBUS. OPC сервера модбасовсхих девайсов регулярно отваливались. Поэтому быренько сделал прослойку, которая из модбасовских устройств сделала модули DCON.А далее DCONовский OPC молотил уже сутками без всяких проблем.

[WindoЗavr]

akegor
я пытаюсь часть вашей программы в которой идёт отправка данных, перенести в МК
пытаюсь передать 7777
почему он ошибки пишет, я же вроде всё правильно написал

#include ‹mega8.h›
#include ‹delay.h›
#include ‹stdio.h› 
             
void init(void)                 
{
  while(1){
          
  char mas[5];

  printf-›PutString("Bizzard"); 
  printf-›PutChar('?'); 
  sprintf(mas,"%04X",7777-›Value);
  for(int i=0; i‹4;i++)  printf -›PutChar(mas[i]);
  
}

 }

[akegor]

Строка "CommPort1-›PutString" означает "компонент CommPort1, метод компонента PutString". Такого, естественно, для меги нету. Вывода в УАРТ строки в готом виде тоже нету. Тут уж Вам надо творчески перерабатывать с учетом наличности.
А зачем передавать "Bizzard"? Это ведь просто иллюстрация "избирательности" приема, что принимает не все подряд, а ждет заголовок пакета, игнорируя все предыдущее.

[WindoЗavr]

а для такой передачи printf сойдёт, или что то другое использовать?

[akegor]

Можно, но я не использую - тяжелый. Да и смысла нет для передачи байтов.