Начал реализовывать задуманное

Датчик температуры прикрутил, сделал простое меню, uart настроил. Теперь идет вопрос с реализацией сети.

Alkul, чуть выше вы писали про прием и обработку пакета в течении 1,5t приема пакета. А как быть с передачей? Т.е. мастер должен учитывать это время или как?

Передавать собираюсь бинарные данные, выше была мысль использовать начальный символ пакета, например 0x01, по приему которого будет начинаться прием пакета. Можно ли сделать такой алгоритм, вместо подсчета времени? + Добавить еще последний стоповый байт.

Я делал очень простой протокол обмена. Два или три стартовых байта типа 0xAA, затем данные фиксированной длины, потом стоповые байты 0х55. Вроде как сбоев протокола не было, но можно же еще контрольную сумму добавить.

А что будете делать, если в данных байт совпадет со стартовым или стоповым ?

PCBWay - всего $5 за 10 печатных плат, первый заказ для новых клиентов БЕСПЛАТЕН

Сборка печатных плат от $30 + БЕСПЛАТНАЯ доставка по всему миру + трафарет

Онлайн просмотровщик Gerber-файлов от PCBWay + Услуги 3D печати

Берем 3 одинаковых стартовых байта, далее посылка и контрольная сумма, 2 одинаковых стоповых байта.
По приему каждого байта инкриментируем счетчик. И проверяем первые 3 байта, если равны приняли верно, проверяем стоповые байты. Считаем контрольную сумму - если она верна - посылка принята верно. Еще проверяем длину посылки, она будет заранее известна. Мастер будет слать например 10 байтовые посылки, слейв - 7.

Алгоритм вижу таким.

А что будет если совпадет.. То сорвется обмен пакетами...

Но после 3 стартовых байт идет адрес слейва, и его можно сделать что бы он не был равен стартовому, как и стоповому, исключить эти 2 числа из нумерации адресов слейвов.

Организация питания на основе надежных литиевых аккумуляторов EVE и микросхем азиатского производства

Качественное и безопасное устройство, работающее от аккумулятора, должно учитывать его физические и химические свойства, профили заряда и разряда, их изменение во времени и под влиянием различных условий, таких как температура и ток нагрузки. Мы расскажем о литий-ионных аккумуляторных батареях EVE и нескольких решениях от различных китайских компаний, рекомендуемых для разработок приложений с использованием этих АКБ. Представленные в статье китайские аналоги помогут заменить продукцию западных брендов с оптимизацией цены без потери качества.

Подробнее>>

Разница во времени между передачей байта в массиве и передачей массива.

Новый аккумулятор EVE серии PLM для GSM-трекеров, работающих в жёстких условиях (до -40°С)

Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре. Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.

Подробнее>>

Пускай в пакете полезных данных 16 байт, в него же включены байт (ы) контрольной суммы, так же в пакете три стартовых 0xAA и три стоповых0x55.

Счетчик принятых данных инициализирован нулем.
Приходит байт данных:
- Если счетчик меньше 3, то проверяется что пришло, если 0хАА , то счетчик инкрементируется, иначе обнуляется.
- Если 3<=счетчик<=18, то данные кладутся во временный массив. TempMass[счетчик-3]=Data. Счетчик инкрементируется.
- Если 19<=счетчик<=20, то проверяется что пришло, если 0х55 , то счетчик инкрементируется, иначе обнуляется.
- Если 20<счетчик, счетчик обнуляется, проверяется что пришло, если 0х55 , то проверяется контрольная сумма. Если сумма в порядке, данные из временного массива копируются в массив принятых данных, выставляется флаг (или еще что-то) об успешном приеме пакета.

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


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


А зачем самому закладывать вероятность сбоя? Как сказал в свое время мой препод в универе - зачем самому подкладывать ёжика себе на стул?
Что Вас не устраивает или смущает в предложенном мной алгоритме?

Я могу дать Вам пример программы, но только на ассемблере.


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

"Вот иманно" © Называем топик Модбас, а дальше идет самопал, с Модбас'ом мало общего имеющий.
У Модбас'а 2 режима : Modbus RTU И Modbus ASCII . Первый передает бинарные данные, конец пакета - по тайм-ауту. Второй - бинарные данные кодируются двумя HEX-символами, и действительно есть стартовый символ : , но уже внутри пакета : не встретится. Бери и пользуйся.
А уж если так невтерпеж старт-стопы влимонить, то будьте бобры прмиенить байтстаффинг с ESC-последовательностью, чтобы приемник не сбивать с толку - а оно вам надо ?
Пример использования : https://ru.wikipedia.org/wiki/HDLC

Я так понял, что ТСу модбас и не нужен.Преимущество в том, что нет привязки ко времени. Это упрощает программу, как для передатчика, так и для приемника. А про байтстафинг, который упоминает Jack_A, я не знал, хорошая вещь.

Это не преимущество, а недостаток. Допустим, у Вас сеть с одним мастером и несколькими слейвами.
В процессе передачи пакета мастер прервал передачу (питание пропало, завис, не суть важно). Слейвы будут "висеть" в ожидании продолжения бесконечно, ибо время, отведенное на передачу байта в частности и пакета в целом, никак не контролируется. Когда мастер "придет в себя" и начнет передавать пакет заново, эти первые три байта 0xAA не будут распознаны как начало нового пакета, а будут приняты за продолжение байт данных предыдущего пакета. Даже если Вы в теле пакета передаете его длину, это ничего не значит - передача может остановиться сразу после передачи трех префиксных байт, при этом в качестве длины пакета может быть взят первый (или второй) префиксный байт. В итоге сеть восстановит работоспособность только тогда, когда:
1. счетчик принятых байт досчитает до нуля, при этом, скорее всего, текущий принимаемый пакет будет будет где-нибудь на середине. Ваш алгоритм остановит прием пакета по длине пакета (в качестве которой был взят "мусор", как мы помним). Ваш алгоритм должен будет отбросить этот пакет, поскольку длина исчерпана, а завершающих постфиксных байт не было, и перейти в ожидание следующего пакета
2. Но текущий-то передаваемый пакет продолжает приниматься, поэтому вместо трех префиксных байт Вы получите продолжение тела пакета. Этот пакет Вы тоже отбросите, потому что префикса не было.
3. И только после этого сеть восстановит работу. Если же Вы, надеясь только на свои префиксные и постфиксные байты не используете длину пакета вообще, то сеть никогда не восстановит работу после описанного мной сбоя. Вам придется перегружать всех - и мастера, и слейвов.

Понятно, что описанный мной случай может возникнуть нечасто, а "на лабораторном столе" так и вообще практически никогда. Но коль скоро механизм возникновения сбоя так легко просчитывается, то я бы не стал закладывать такую мину в алгоритм.

Кроме того, как быть, если помеха исказит один из постфиксных байтов 0x55? Конец пакета уже не будет распознан, и сбой начнет развиваться по описанному выше сценарию.
При передаче бинарных данных недопустимы любые пре- и постфиксы, потому что нет механизма, позволяющего отличить их от данных.

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


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

Кстати, например, в протоколе TCP/IP делается контроль времени приема в виде параметра "время жизни дейтаграмм".

Alkul, Вы неудачно процитировали меня. Оба предложения - это одна мысль. Их нельзя было разделять на цитаты. Алгоритм приема/передачи действительно очень простой. Несомненно, данный протокол очень не идеален и в ответственных системах, например, где сбой работы влечет угрозу здоровью, применять бы я его и сам не стал. Применение таймера, тоже не сложно. Но Вы, возможно, заметили в этом форуме, что многие коты теряются, когда надо применять несколько периферийных устройств для одной задачи, иногда даже не пытаются это сделать. Нет, Вы тут ошибаетесь. Теряется кривой пакет (само-собой) и нормальный последующий, после чего все восстанавливается. Если сбой - это исключение (а именно так должно быть), то в целом это не проблема. У меня есть устройство, которое передает данные уже несколько лет, выключаясь только летом. Протокол еще убогее, чем я предложил. Два старта и два стопа, нет контроля целостности данных. Данные передаются через "блюпуп". Еще не было ни одного сбоя, но если бы были, то в том устройстве не страшно.

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

Я с ним знаком только "тетеритически" , применять не приходилось. В "раньших" проектах применял ASCII mode, бинарные кодировал 2 шестн. цифрами, потому : в данных не мог встречаться. Но избыточность была гигантская, перешел на RTU mode.
Насчет таймингов есть одна засада. Если обмен меж двумя МК, мастер при передаче может сосредоточиться именно на ней, ложных тайм-аутов не будет. А если обмен с ПК - Винда вообще-то не реалтаймовая, и какой-нибудь более приоритетный процесс может тормознуть передачу. Потому я окончания передачи пакета ждал не 1,5 байта, а несколько миллисекунд. Рекордных скоростей обмена не получишь, но мне хватало, т.к. остальными участниками системы были еще более медленные компоненты - люди .

Я свой "мега протокол" придумал лет двадцать назад. И для моих нужд вполне устраивал, в некоторых вариациях. Байтстафинг явно бы его улучшил, но догадаться или наткнуться на книгу про него, как то мозгов не хватило.

Поскольку я программирую на ассемблере, то у меня выработался свой стиль, ускоряющий работу, а именно - максимальная стандартизация алгоритмов и подпрограмм с целью использования их во всех проектах. Изменения в отлаженные подпрограммы и алгоритмы вносятся только тогда, когда этого требует задача. Исходя из этого, правильней сразу освоить и в дальнейшем использовать более стабильную/лучшую версию алгоритма, чем перерабатывать его коренным образом под каждую задачу.
Что же касается котов-новичков... на моей памяти, еще ни одному "котенку" не отказали в помощи, если он действительно хочет научиться и докопаться до истины.
И тредстартеру никто (ни я, ни, надеюсь, Вы) не откажет в помощи, если он попросит показать ему, как в данном случае одновременно использовать USART и таймер.


Если понятия "длина пакета" нет вообще, то сеть не восстановится. В предлагаемом Вами алгоритме это понятие есть, но но оно жестко определено алгоритмом, поэтому, действительно потеряется "кривой" пакет плюс следующий за ним один нормальный.


Бесспорно, реализация зависит от задачи. Но, на мой взгляд, если мы говорим об упрощении, то в бОльшей степени упрощение делается не в случае некритичной задачи, а в случае ограничений "железа".
Например, делаете Вы уличный термометр-"показомер", замену спиртового градусника. Если при ежесекундном обновлении данных (которое для термометра-"показомера" просто не нужно, достаточно раз в 10 секунд) даже каждый 10-й замер будет "битым" - ничего страшного. При этом, если у Вас есть отлаженный программный модуль обмена данными с переменной длиной пакета, контролем времени передачи и т.д., то почему бы не использовать его? Однако, если у Вас выбран МК с малым количеством программной памяти, и задача такова, что её реализация "впритык" умещается в памяти, то допустимо упростить протокол обмена, если потеря какой-то части данных не критична.


Я понял. Без проблем


Последнее слово, бесспорно, за ТС.

Спасибо за помощь коты !!!

Выбираю реализацию обмена при помощи прерывания от таймера.

Как вижу я его , исходя из прочитанного выше.

Вы, я так понимаю, сейчас про приемник.

i - глобальная переменная, я бы ей дал другое имя.


В прерывании от UART.
Первым делом, data[i] = UDR, чтобы освободить буфер. И массив, скорее всего, у меня был бы буферный (временный).


После этого.
Если i==0, сбрасываете и запускаете остановленный таймер.
i++
Если i == "усё". Остановить таймер.; i=0; Если данные целые и по адресу, скопировать из буферного массива, в постоянный массив полезные данные. Как то, просемафорить основной проге, о принятых данных.

Прерывание от Таймера (Лучший режим CTC, преывание совпадение с регистром OCR).

Остановить таймер,
i=0
просемафорить проге о сбое кадра (если это надо).


Как-то так наверное.

Не совсем так. Перезапускать таймер нужно после получения каждого байта на время, равное полуторному времени приема байта. Например, при скорости 19200, 8-ми битах данных, одном старт-бите и одном стоп-бите время приема байта будет равно 10/19200 = 0,53 мс, а задержку надо взять равной 0,8 мс. Тут я сделаю оговорку, и сошлюсь на уважаемого Jack_A, который совершенно справедливо заметил, что для случая, когда МК ведет обмен с виндой или другой не реалтаймовой ОС, это время надо увеличить. Если же обмен ведут два МК, тогда считать время задержки именно так, как я показал.

Приняли байт в data[i], и сразу же перезапускайте таймер. Для перезапуска надо его остановить, обнулив биты CSx2...CSx0 регистра TCCRxB, занести в соответствующий регистр TCNTx новое значение и снова запустить таймер, установив необходимую комбинацию битов CSx2...CSx0 регистра TCCRxB. буквой "х" в данном случае я обозначаю цифры 0...2 в зависимости от того таймера, который будет использован.


Желательно после этого еще и вычислить CRC. alex38779, если нужен алгоритм расчета CRC-16 на Си - их есть у меня


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


alex38779, Вы не ответили, нужен ли Вам пример работы с USART на ассемблере.

Да, так будет лучше. В моем предложенном варианте, таймер должен был настраиваться на время передачи всего пакета, а это замедлит пропускную способность линии. Была бы у меня фактическая практика с модбасом, сразу бы дошло. Да наверное его даже и не надо останавливать, лишь обновить значение, особенно если использовать прерывание по переполнению.

Кстати, про буферный массив. Лучше кончено будет не копировать данные из буферного в другой массив. А просто переключать их - двойная буферизация.

Алгоритм расчета CRC-16 нужен!
Насчет примера на ассемблере, думаю можно глянуть и попробовать разобраться. На ассемблере могу и что-то знаю.



А как сделать эту двойную буферизацию? С таким не сталкивался.


Посчитал таймер Т2, 8 битный, прерывание по переполнению в 0,8с:
частота 8МГц
предделитель 256

256/8000000 = 0,032мс
0,8/0,032 = 25
Начальное значение TCNT = 256-25 = 231

Правильно?

Один массив буферный, другой основной. Как только в буфер легли правильные данные, назначение массивов меняется местами. Для этого используйте указатели. Если скорости передачи и обработки принятого позволяют, то можно обойтись и без буферного массива.
Параметры UART еще надо знать, т.е. время передачи одного байта.