Пример, нужная информация через UART.

#1

Попробую вкратце объяснить, как выуживать нужную нам информацию через UART в FLProg ver 1.10

Часть 1.
Для примера возьмем две платы arduino UNO.
Из одной сделаем имитацию работы модема, другой будем модему посылать АТ команды, и выбирать нужные ответы.
И так начнем с «клиента», УНка дающая запросы модему, и принимающая ответы.
С помощью кнопки будем подавать запрос модему.
Делаем плату1 «кнопка».

СпойлерПоказать

Схема простая, по нажатию кнопки, через UART уйдет команда «АТ» модему.
Дальше нужно слушать ответ.
Делаем плату2 « Прием через UART»

СпойлерПоказать

Здесь нужно помнить , что прием инфы идет посимвольный.
Чтобы не городить паровоз, использую в ней задержку на пакет с помощью таймера.
Таймер настраивается на самый длинный пакет символов.
Если время будет мало – пакет будет резать, если большое – будет зацикливание.
Теперь определимся:
Если модем на связи, должен прийти ответ «ОК».
Это будет сигналом для автоматической отправки следующей команды «AT+CSQ».
Если не готов, ответ «NO» никаких дальнейших действий. + эту информацию будем выводить на дисплей.
Создаем нужный алгоритм.

СпойлерПоказать

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

************************

Добавлено (18.10.2015, 01:39)
---------------------------------------------
Если команда «AT+CSQ» ушла на модем, должен прийти ответ в виде «+CSQ ХХ,ХY» где:
+CSQ ключ на выборку, после которой следует пробел.
ХХ первая нужная информация
ХY вторая нужная информация
Разделителем между инфой является запятая.
Создаем второй алгоритм на выборку.

СпойлерПоказать

Выбираем нужную инфу, и отправляем на дисплей.

СпойлерПоказать

Считаем что «клиент» готов… ) заливаем в УНку и ложем в сторонку.

#2

Часть2.
Создаем эмулятор модема на второй УНке.
Мы определились, что по нажатию кнопки с «клиента» идет команда, следовательно, модем должен ее принять.
Создаем плату «Прием через UART» аналогичную как на «клиенте».
Пришедшая команда «АТ», теперь будет являться ключом на отправку пакета готовности.
Создаем алгоритм отправки готовности.

СпойлерПоказать

UNO-TX-RX.flp: (199 КБ) 117 скачиваний

Режим работы «ОК»– через раз. Для наглядности ).
Посылка состоит из двух ОК, через запятую. Первая ОК – ключ для «клиента». Вторая ОК инфо для дисплея.
Далее нам «клиент» по сигналу ОК должен выслать команду «AT+CSQ»,
которая будет являться ключом для выполнения следующего действия модема.
Создаем алгоритм отправки информации «+CSQ ХХ,ХY».

СпойлерПоказать

UNO-Modem.flp: (163.39 КБ) 108 скачиваний

Алгоритм следующий:
+CSQ – ключ для клиента, ХХ – через раз 55 или 99, ХY – грандом двухзначное число.

Модем тоже готов. Шьем. Подключаем на крест RX – TX между платами. Подаем питание.
И…наслаждаемся работой

СпойлерПоказать

[video][/video]

***************************

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

***************************

viga5 · #3

Если еще как-то nrf24l01 получится прикрутит?

Max · #4

rw6cm писал(а):После сохранения проекта он снова включится. Это баг

Да, тоже заметил это.

Спасибо за проделанную работу! На днях поэкспериментирую в живую с модулем!

Добавлено (19.10.2015, 22:03)
---------------------------------------------
Огромное спасибо за Вашу статью!

Похоже у меня стало получаться распарсивать строки и вычленять нужное!

Надеюсь в обозримом будущем похвастаюсь комбайном GSM+Ардуино!

Max · #5

rw6cm писал(а):П/с В файлах проектов, перед записью на УНки, нужно в элементах «Поиск подстроки» отключить пункт «выход индекса».
После сохранения проекта он снова включится. Это баг.

Посмотрите проект. Протестируйте у себя.
Уже начинал его несколько раз.
Выскакивает ошибка и программа закрывается.
Не пойму в чем дело, может я туплю как то?
Принт скрин ошибки выложил в багтрекере, туда же выложу файл проекта. Сюда так же продублирую.

Добавлено (22.10.2015, 21:25)
---------------------------------------------

Max писал(а):Выскакивает ошибка и программа закрывается.

Что вы сделали, что бы исправился вылет программы?

А то уже много написал в новый проект и он опять начал вылетать при попытке компилирования.

DrMario · #6

Здравствуйте!
Есть необходимость сделать устройство обмена данными между компьютером и другими устройствами. Сергей в двух видео уроках по UART рассказывал и показывал как это можно сделать.
У меня задача немного сложнее. Скорость обмена между компом и контроллером будет стандартной и постоянной, а вот со стороны контроллер-устройство скорость необходимо будет задавать нестандартную, причем самая низкая должна быть 72 бод.
Мои платы ардуино еще не приехали по этому не могу проверить, будет корректно работать два КОМ порта на разных скоростях, или необходимо делать какие то дополнительные преобразования?
У меня пока только одни вопросы, прошу сильно не пинать.
В программе скорость обмена можно выбрать из списка стандартных скоростей без возможности изменить значения. Подозреваю, что контроллер может работать на нестандартных скоростях, как например чип FTDI. Если скорость обмена может быть произвольной, каким может быть нижний предел? У FTDI нижний предел около 200 бод, ниже не получится.
При выборе платы Arduino Mega 25600 в программе есть возможность выбора SoftwareSerial и четыре Com Port. Про КОМ порт мне понятно, а вот про SoftwareSerial не совсем, в чем различие между SoftwareSerial и Com Port ?
У меня есть только предположение, что при выборе SoftwareSerial можно организовать КОМ порт по заданным пинам ?
При выборе Arduino Micro есть только SoftwareSerial и один Com Port.
На форуме в распиновке плат для платы Micro нарисованы Serial 1, Serial 2 Serial 3, это опечатка или я что то не понимаю ?
Заранее спасибо.

eugeneb · #7

ComPortы организованы в контроллере аппаратно и мало грузят
микроконтроллер. Они выведены на определённые пины.

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

И ещё. Работа с COMPortом (хоть с аппаратным, хоть с программным) предполагает только двухточечную связь.
И обе стороны ДОЛЖНЫ работать на ОДНОЙ скорости.

DrMario · #8

Здравствуйте. Спасибо за разъяснения!
Между двумя аппаратными портами на разных скоростях нормального обмена конечно же не выйдет.
Как я понимаю, SoftwareSerial это виртуальный порт, и SoftwareSerial - ComPort должны нормально работать с разными скоростями. Если напрямую не получится, то байты данных думаю можно поместить в какой нибудь буфер обмена, возможно даже передавать по одному байту. Такие девайсы существуют и без проблем работают на совершенно разных скоростях обмена.
Мои платы ардуино где то застряли, чтобы проверить свое предположение.
Мне нужно сделать такое устройство, чтобы служебными командами, подаваемыми с компьютера через ComPort управлять SoftwareSerial, причем с возможностью включения, отключения и сменой скорости обмена и пинов RX TX для SoftwareSerial. Попытался сделать из готовых блоков, но там нет возможности управлять изменением параметров SoftwareSerial, порт открывается с фиксированными параметрами. Во вложении попытка сделать, как я себе все это представляю. Подключить прием/передачу SoftwareSerial у меня так и не получилось.
Из видео уроков понял, что можно создать пользовательский блок для своих надобностей, но вот познаний совсем мало. Если не трудно, подскажите как нужно сделать пользовательский блок.

eugeneb · #9

Не знаю что это за устройства, работающие с нестандартными скоростями,
старые модемы что-ли какие

Стандартными блоками вы здесь не обойдётесь. Индустрия давно выработала
для себя известный ряд скоростей и все программные и аппаратные
реализации приёмо-передатчиков UART заточены под этот ряд.

Добиться нестандартной скорости можно с помощью BitBang подхода он вообще универсальный), но это вам самому придётся реализовать его
на С. Потом можно будет сделать пользовательский блок. А перед этим досканально изучить предмет, допустим по полному даташиту на ATMega328, раздел USART. (не завидую этой работе )

DrMario · #10

Уже догадался, что придется во всех деталях изучать тонкости на С.
Это устройства для обмена данными между программным сканером и ЭБУ автомобиля. К примеру адаптер ELM327 как самый примитивный вариант. Со стороны программного сканера (компьютера) для обмена с адаптером выбирается стандартная скорость по выбору, обычно 38400 или 115200. А уже адаптер <-> ЭБУ автомобиля скорость может быть разной. На общих протоколах 4800, 9600, 10416 - это по К линии, CAN Low и CAN High уже с преобразователем. На заводских протоколах (OEM) количество скоростей обмена еще больше.
Для меня стандартных протоколов недостаточно, требуется собственный адаптер с возможностью коммутации выводов диагностического разъема автомобиля в адаптере. Понимаю что можно сделать такой адаптер на ATMega328, но вот умения программирования у меня почти нет от слова совсем, за меня программный код пишет мой коллега но только на Delphi. Хотелось бы самому разобраться с "железом".

eugeneb · #11

Дело не в тонкостях С, он-то как раз не сложен, там всего с десяток
ключевых слов. Можно в метро выучить по дороге на работу/учёбу.

Дело в тонкостях работы USART. Синхронный-асинхронный, старт-стоп биты,
тайминги/уяйминги. По-большому, это просто сдвиговый регистр с несколькими
флажками.
Тоже ничего смертельного. Протоколу больше сорока лет, он прост
как валенок, литературы - горы.

Надо просто потратить время.

А по CAN - дк там свои скорости и свои протоколы. Это совсем другая
сказка. Никак не связаная с USART.

DrMario · #12

Не вижу проблем обмениваться с CAN шиной через КОМ порт. Вот один из примеров.
Знание архитектуры CAN это совсем другой вопрос.

eugeneb · #13

Э-хе-хе...
Любезный, вы передёргиватете.
В схеме, которую вы привели, контроллер общается
с адаптером CAN - микросхема TJF1051.
Общается он с ним по протоколу UART со стандартными
для UART скоростями (по другому он просто не умеет).
А уже адаптер CAN переводит это всё в скорости,
о которых он договорился со своими корреспондентами
на шине CAN (или какую ему задали).

На то он и адаптер

Добавлено (16.11.2016, 09:57)
---------------------------------------------
PS.
Должен добавить, что когда мы говорим о том,
кто с кем общается, нужно держать в голове
слоёную многоуровневую структуру любых систем связи:
https://ru.wikipedia.org/wiki....%8C_OSI

То есть, в нашем случае, контроллер общается с адаптером
на физическом уровне по протоколу UART, допустим на транспортном
уровне с нодой CAN, а на прикладном уровне с мозгом ЭБУ.
Всё это одновременно, с наложением друг на друга.

Не тривиальные вещи.

DrMario · #14

Видимо разговариваем о разных вещах.
Трансивер TJF1051 служит для физического согласования уровней и только. В КАН шине применили двухуровневый сигнал для защиты от помех. Никаких изменений в самой структуре передачи байт там нет. Подключите такой трансивер напрямую к чипу FTDI, установите на мониторе скорость обмена 500000 (в основном на этой скорости обмен) и подключив к автомобилю Вы увидите обычные байты, которыми между собой обмениваются блоки. Только этих байтов залетит в монитор огромное количество, потому как блоков управления может стоять много и все они общаются между собой на высокой скорости. Байты сложены в пакеты определенным образом. Всю работу по выделению сообщений с нужными адресами (заголовками) и отправку запросов в нужное время как раз берет на себя микроконтроллер STA, а так же соблюдением стандартов автомобильных протоколов.
Для общения с блоками авто мне не нужны знания всех тонкостей CAN, мне достаточно чтобы приходили примерно вот такие данные. Это запрос ВИН кода командой 09 02 по адресу 7DF.
В ответ получаем два одинаковых ВИН кода JMBLYV98W8J500494 с адресом 7E8 мотор, и 7E9 трансмиссия. Две системы в одном корпусе но с разными адресами.

08 07 DF 02 09 02 FF FF FF FF FF
08 07 E8 14 49 02 88 4A 4D 42 4C
08 07 E8 21 59 56 39 38 57 38 4A
08 07 E8 22 35 30 30 34 39 34 00
08 07 E9 14 49 02 88 4A 4D 42 4C
08 07 E9 21 59 56 39 38 57 38 4A
08 07 E9 22 35 30 30 34 39 34 00

eugeneb · #15

А, извиняюсь, не досмотрел. Там специальные выходы у контроллера
- CAN_TX, CAN_RX.
Видимо это не UART.

Тем хуже - таки придётся слегка погрузиться ещё и в CAN.

И, ещё, чтобы обрабатывать поток со скоростью 0,5 Мбит/с, думаю
АТМега328 будет слабовата. Или надо активно использовать
механизм прерываний. А это не самая сильная сторона
промышленных контроллеров, под идеологию которых создан FLProg.

Добавлено (16.11.2016, 14:17)
---------------------------------------------
А, или вы хотите общаться с CAN шиной через этот готовый контроллер?
Тогда не понимаю в чём вообще проблема. Общаетесь
чарез UART со стандартными скоростями, а там ELM-ка разберётся.
Или что?

DrMario · #16

Все верно, проблем общения только по КАН через этот контроллер никаких нет. В таком виде даже и не стану его делать, тем более что есть доступные адаптеры для нескольких общих автомобильных протоколов K-line и CAN. Это все только для двигателя и только в ограниченном виде.
Дело в том, что мне нужен более сложный адаптер и не только для общих протоколов. Некоторые системы автомобиля в диагностическом разъеме выведены к другим контактам. Например системы SRS, ABS, EPS, ESP и многие другие. Это так называемый OEM стандарт от производителей. Некоторые ОЕМ протоколы различаются даже по полярности сигнала в линии обмена. Сделать на адуино коммутацию диагностической линии даже для меня не составит труда при помощи FLProg. Кроме коммутации нужна еще возможность при помощи служебных команд менять все настройки SoftwareSerial и только потом его открывать/закрывать. В видео уроках Сергей не рассказывал как это можно сделать. Производительности АТМега328 вполне хватит. Обмен между сканером и автомобилем происходит по принципу запрос - ответ. Самые длинные строки в ответе около 120 байт. Команды запросов обычно очень короткие, 5-10 байт. Между ответом и запросом интервал может составлять до 3 сек.
Поскольку SoftwareSerial это программный порт, то у меня есть большая доля уверенности что моя затея с разным скоростями на COM и SoftwareSerial должна получится. Проверить смогу когда приедут мои платы.

lukaa13 · #17

ДОБРОГО ВРЕМЕНИ СУТОК
ПРОШУ ПОМОЩИ
при передаче с телефона на ардуино приходит какая то белеберда
а на телефон передается нормально