#include <EEPROM.h>
int del;
void setup() {
Serial.begin(9600);// put your setup code here, to run once:
}
void loop() {
if (Serial.available() > 0) { //если число передали то значение больше 0
int addr = Serial.parseInt();
int impuls = Serial.parseInt();
EEPROM.update(addr, impuls);
del = EEPROM.read(addr);
Serial.print("IMPULS=");
Serial.println(del);
Serial.println(addr);
}
}
Приветствую участников. Пытаюсь получить данные с матричного дисплея климат-контроля в а/м Ниссан. Передача на дисплей в протоколе UART (вроде бы). Получилось вывести эти данные в монитор порта.
Подскажите пожалуйста, как исправить скетч, чтобы значения в мониторе выводились в более удобочитаемой форме? Сейчас они вываливаются в столбик, каждая цифра начанается с новой строки, можно выделить одну цифру, которая как бы начало, а за ней переменные. Передача циклическая, идет непрерывно, количество переменных разное, в зависимости от положения органов управления, но в установившемся режиме, данные просто повторяютс циклически.
Например эта цифра 30 (в десятичном счислении), подскажите правильный вид строки, подставляю в разных вариантах, в оператор, ничего не получается, также все валится в монитор без перерыва...
Проблема как из потока информации выделить "метку" и переводить строку по этой метке.
if (mySerial.available() > 0), строки 3,4 и 6 не нужны. И, как я понимаю, пустую строку надо печатать до, а не после числа. Так же обратите внимание на условие с числом - сравнение написано неверно (знак не тот).
В общем читать у меня получилось, но есть сомнения в правильности установленной скорости. Есть ли какая нибудь возможность узнать скорость работы uart-шины? Или по другому, как проверить правильность принимаемых пакетов?
Смущает то, что количество чисел в пакете разные для разных положений органов управления и нет какой либо однозначной зависимости. Например меняешь температуру на пол градуса, а в пакете менеются несколько чисел, хотя на экране поменялся только один символ.
Проблема как из потока информации выделить "метку" и переводить строку по этой метке.
Как справедливо было отмечено, нужно знать, что это за метка. "десятичная цифра 30" такой меткой очевидно быть не может в виду несуществования таковой в природе.
Я тоже в сомнениях. Просто надо же с чего то начинать? А цифра 30 присутствует в большинстве пакетов и по ней можно как-то их разделять. Однако я думаю, что не правильно определил скорость передачи, т.к. если поменять скорость в скече, то набор цифр получается тоже, но уже другой. Проблема как определить правильную скорость? Тупо перебирать из стандартной линейки?
Еще раз: "цифры 30" в природе не существует. В десятичной системе есть цифры от "0" до "9", в шестнадцатиричной - от "0" до "F". Предположительно "цифра 30" могла бы присутствовать в 60-ричной системе счисления, но сама эта система уже несколько тысяч лет не используется.
Чтобы решить задачу, нужно для начала правильно сформулировать условие. А пока это у Вас не получается.
Если речь идет о скорости последовательного порта, то способов достоверно определить ее не существует - ее надо знать заранее. Если устройство постоянно передает изменяющиеся данные, можно попытаться опредеить скорость перебором, т.е. найти ту, при которой принимаются осмысленные данные.
Если устройство постоянно передает изменяющиеся данные, можно попытаться опредеить скорость перебором, т.е. найти ту, при которой принимаются осмысленные данные.
Понятно. Думаю нужно сначала осциллографом попытаться установить длительность единичного импульса, потом подобрать подходящую скорость (300, 600, 1 200, 2 400, 4 800, 9 600, 19 200, 38 400, 57 600, 115 200). В итоге должны получиться 8-ми элементные двоичные посылки в мониторе.
Сейчас у меня, если смотреть в двоичном виде, каждая посылка разной длины, но пачки этих посылок повторяются циклично (вроде связно изложил).
Скорость работы uart-шины между блоком климата и дисплеем климата в Ниссан 9600. Это точно.
Появились осмысленные данные, которые напрямую зависят от того, что выводится на дисплей. Единственно не удобно выявлять их в бесконечно бегущей колонке. Может есть какой-то вариант использование не стандартного "монитора порта", а какого-то стороннего монитора с фильтрами. Например для кан-шины очень удобен КанХакер, а для уарт есть что либо подобное?
У CAN стандартизованные фреймы с известной структурой, там ничего выискивать не надо и Кан-хакер просто выводит определенные поля.
UART не имеет жесткой структуры фреймов протокольного уровня и каждый производитель пляшет как хочет. Скорее всего в вашем UART тоже летит что-то структурированное, но формат вам неизвестен. Поэтому, на данный момент, для всех нас это просто непонятный поток байт. Его надо исследовать, искать взаимосвясзь между физическими действиями и пролетающими данными. Реверс-инжинирингом такая деятельность зовется.
Вы употребили термин "длительность единичного импулься". Именно для этого термина я и просил дать пояснения.
Следующий вопрос, естественно, будет: "как ее определить при помощи осциллографа". Так что будет хорошо, если Вы сразу ответите и на него (чтобы время зря не терять).
"как ее определить при помощи осциллографа". Так что будет хорошо, если Вы сразу ответите и на него (чтобы время зря не терять).
На переключателе строчной развертки осциллографа "время/деления" есть цифры, цена одного деления сетки на экране, и в зависимости от положения второго переключателя "мкс/мс" можно увидеть длительность импульса. 1 импульс это 1 бит. Это в общем-то общеизвестно.
Но т.к. у меня получилось подобрать скорость тупо перебором, то я с оциллографом не заморачивался.
Хорошо. Реальный пример из жизни: по каналу связи примерно 3 раза в секунду передается отрицательный импульс длиной 64 мкс. Известно, что это соединение именно по последовательному порту. Какова скорость передачи?
Хорошо. Реальный пример из жизни: по каналу связи примерно 3 раза в секунду передается отрицательный импульс длиной 64 мкс. Известно, что это соединение именно по последовательному порту. Какова скорость передачи?
Этот пример показывает, что в общем случае по ширине импульсов определить частоту передачи невозможно. Тем более, что приведен был не некоторый искусственный, а вполне конкретный пример: MIDI источник сигнала, например, клавиатура или секвенсер регулярно передают команду Active Sense (0xfe), чтобы сообщить приемнику, что музыкант на клавиши не нажимает и ручки не крутит, но связь между устройствами есть.
Этот пример показывает, что в общем случае по ширине импульсов определить частоту передачи невозможно.
Вы не корректно сформулировали задачу. Судя по реальной скорости, 64 мкс не один, а два импульса, т.е. два бита информации, а длительность предачи одного бита равна 32 мкс. Если смотреть осциллографом весь пакет, то тогда будет отлично видно единичный импульс, в Вашем примере его длительность будет равна 32 мкс, а не 64 мкс. Как-то так.
Как раз таки в реальной жизни только так и можно определить реальную частоту сигнала и соответственно скорость передачи.
Вы бы лучше помгли чем-то дельным, а не экзамены по теории устраивали.
А теперь реальная жизнь, есть поток, в котором 12 чисел, которые повторяются циклично.
Выглядит приблизительно так
0 1 A0 28 28 14 4E 5A A1 19 3 C
Каждое число всегда находится на своём месте в пакете и может изменяться в некотором диапазоне начиная с 0. Как выделить конкретное число и привязать к нему какое-то действие? Числа могут быть одинаковые, поэтому просто оператором "if" не получается.
Вы не корректно сформулировали задачу. Судя по реальной скорости, 64 мкс не один, а два импульса, т.е. два бита информации, а длительность предачи одного бита равна 32 мкс.
Задача сформулирована вполне корректно: на экране виден единственный импульс длиной 64 мкс. Да - это два бита: стартовый и первый "0". Остальные в байте 0xfe равны единице, равно как и стоповый бит. Т.е. на осциллографе выглядят точно так же, как5 и отсутствие передачи.
Цитата:
Если смотреть осциллографом весь пакет, то тогда будет отлично видно единичный импульс, в Вашем примере его длительность будет равна 32 мкс, а не 64 мкс. Как-то так.
Что Вы мне сказки-то рассказываете!
На экране именно один импульс длительностью 64 мкс, что принимающий порт должен воспринимать как два бита. Но чтобы понимать, что это именно два бита, а не 1, не 3 не 4 и не 5, он должен заранее знать скорость передачи.
Цитата:
Как раз таки в реальной жизни только так и можно определить реальную частоту сигнала и соответственно скорость передачи.
Теоретик, блин!
Вы бы взяли осциллограф и посмотрели, как на экране выглядит 0xfe.
Каждое число всегда находится на своём месте в пакете и может изменяться в некотором диапазоне начиная с 0. Как выделить конкретное число и привязать к нему какое-то действие? Числа могут быть одинаковые, поэтому просто оператором "if" не получается.
очень просто. Находим начало пакета. отсчитываем нужную позицию - а уже к ней применяем IF
очень просто. Находим начало пакета. отсчитываем нужную позицию - а уже к ней применяем IF
А если еще проще... Вот такое получается сообщение
0 1 A0 28 28 14 4E 5A A1 19 3 C Как в нем отсчитать нужную позицию?
Повторяется циклично, каждая цифра соответствует своему значению на экране, идут непрерывно, начинаются всегда с "0", поэтому признаку я "перевожу строку". Например, в этом на 4 и 5 месте числа 28, что значит 22 градуса слева и справа, 10 и 11 (19 3) это скорость вентилятора, причем значений скорости 7, а цифры меняются еще и в зависимости от других органов управления, всего получилось три набора значений скорости, хотя реально семь скоростей всего.
Я думаю с помощью библиотеки TV-out выводить на сторонний экран эту информацию. Вначале я думал просто с помощью "if' это делать, но в наборе появляются одинаковые числа, т.е. имеется ещё и зависимость от положения числа в наборе.
Сейчас читаю, там нужно использовать стринг?
Вы не могли бы написать пример кода или тыкнуть ссылку, не могу найди.
Ещё раз спс.
Рафаэль, какой стринг! Вам память девать некуда? Разбирать все прямо на ходу.
Пока такой написал . через запятую работает.
сейчас уже поздно , завтра буквами займусь.
Спасибо, Вам , за помощь.
Приветствую участников. Пытаюсь получить данные с матричного дисплея климат-контроля в а/м Ниссан. Передача на дисплей в протоколе UART (вроде бы). Получилось вывести эти данные в монитор порта.
Скетч такой
Подскажите пожалуйста, как исправить скетч, чтобы значения в мониторе выводились в более удобочитаемой форме? Сейчас они вываливаются в столбик, каждая цифра начанается с новой строки, можно выделить одну цифру, которая как бы начало, а за ней переменные. Передача циклическая, идет непрерывно, количество переменных разное, в зависимости от положения органов управления, но в установившемся режиме, данные просто повторяютс циклически.
Сейчас они вываливаются в столбик, каждая цифра начанается с новой строки...
Замените println() на print().
Тогда будет идти в бесконечную строчку
Перед цифрой, которая есть начало - println().
Перед цифрой, которая есть начало - println().
Например эта цифра 30 (в десятичном счислении), подскажите правильный вид строки, подставляю в разных вариантах, в оператор, ничего не получается, также все валится в монитор без перерыва...
Проблема как из потока информации выделить "метку" и переводить строку по этой метке.
В какой оператор и в каких вариантах подставляете?
В println(). Я понимаю, что наверное не правильно подставляю, в лучшем случае это число еще раз выводится в монитор.
Проблема как из потока информации выделить "метку" и переводить строку по этой метке.
чтобы выделить метку, надо сначала договориться с самим собой, что будет меткой
Проблема как из потока информации выделить "метку" и переводить строку по этой метке.
http://arduino.ru/Reference/If
Т.е. вот так должно быть правильно
Спасибо! Вечером проверю.
чтобы выделить метку, надо сначала договориться с самим собой, что будет меткой
Пока договорился, что это будет десятичное число 30, оно есть в большинстве пакетов
Т.е. вот так должно быть правильно
if (mySerial.available() > 0), строки 3,4 и 6 не нужны. И, как я понимаю, пустую строку надо печатать до, а не после числа. Так же обратите внимание на условие с числом - сравнение написано неверно (знак не тот).
Спасибо, поправил ошибки.
пустую строку надо печатать до, а не после числа.
Так?
В какой строке вы число печатаете? Вот перед ней и ставьте условие с печатью пустой строки.
В какой строке вы число печатаете? Вот перед ней и ставьте условие с печатью пустой строки.
Понял! Спасибо
Надо как-то показывать, что 30 десятичное число?
Надо как-то показывать, что 30 десятичное число?
Мне - нет, а так - от задачи зависит, конечно. Serial по-умолчанию числа десятичными рисует.
Спасибо, поправил ошибки.
перловик? :)
упс
В общем читать у меня получилось, но есть сомнения в правильности установленной скорости. Есть ли какая нибудь возможность узнать скорость работы uart-шины? Или по другому, как проверить правильность принимаемых пакетов?
Смущает то, что количество чисел в пакете разные для разных положений органов управления и нет какой либо однозначной зависимости. Например меняешь температуру на пол градуса, а в пакете менеются несколько чисел, хотя на экране поменялся только один символ.
Например эта цифра 30 (в десятичном счислении)...
Нет такой цифры!
Проблема как из потока информации выделить "метку" и переводить строку по этой метке.
Как справедливо было отмечено, нужно знать, что это за метка. "десятичная цифра 30" такой меткой очевидно быть не может в виду несуществования таковой в природе.
Я тоже в сомнениях. Просто надо же с чего то начинать? А цифра 30 присутствует в большинстве пакетов и по ней можно как-то их разделять. Однако я думаю, что не правильно определил скорость передачи, т.к. если поменять скорость в скече, то набор цифр получается тоже, но уже другой. Проблема как определить правильную скорость? Тупо перебирать из стандартной линейки?
Еще раз: "цифры 30" в природе не существует. В десятичной системе есть цифры от "0" до "9", в шестнадцатиричной - от "0" до "F". Предположительно "цифра 30" могла бы присутствовать в 60-ричной системе счисления, но сама эта система уже несколько тысяч лет не используется.
Чтобы решить задачу, нужно для начала правильно сформулировать условие. А пока это у Вас не получается.
Если речь идет о скорости последовательного порта, то способов достоверно определить ее не существует - ее надо знать заранее. Если устройство постоянно передает изменяющиеся данные, можно попытаться опредеить скорость перебором, т.е. найти ту, при которой принимаются осмысленные данные.
Понятно. Думаю нужно сначала осциллографом попытаться установить длительность единичного импульса, потом подобрать подходящую скорость (300, 600, 1 200, 2 400, 4 800, 9 600, 19 200, 38 400, 57 600, 115 200). В итоге должны получиться 8-ми элементные двоичные посылки в мониторе.
Сейчас у меня, если смотреть в двоичном виде, каждая посылка разной длины, но пачки этих посылок повторяются циклично (вроде связно изложил).
Думаю нужно сначала осциллографом попытаться установить длительность единичного импульса
А что такое "длительность единичного импульса"?
Часто используются следующие стандартные скорости передачи интерфейса UART.
бод
мкс
http://mypractic.ru/urok-12-posledovatelnyj-port-uart-v-arduino-bibliote...
Ну или просто перебирать стандартные значения скорости, пока не получится что-то осмысленное.
Скорость работы uart-шины между блоком климата и дисплеем климата в Ниссан 9600. Это точно.
Появились осмысленные данные, которые напрямую зависят от того, что выводится на дисплей. Единственно не удобно выявлять их в бесконечно бегущей колонке. Может есть какой-то вариант использование не стандартного "монитора порта", а какого-то стороннего монитора с фильтрами. Например для кан-шины очень удобен КанХакер, а для уарт есть что либо подобное?
У CAN стандартизованные фреймы с известной структурой, там ничего выискивать не надо и Кан-хакер просто выводит определенные поля.
UART не имеет жесткой структуры фреймов протокольного уровня и каждый производитель пляшет как хочет. Скорее всего в вашем UART тоже летит что-то структурированное, но формат вам неизвестен. Поэтому, на данный момент, для всех нас это просто непонятный поток байт. Его надо исследовать, искать взаимосвясзь между физическими действиями и пролетающими данными. Реверс-инжинирингом такая деятельность зовется.
В потоке передаваемых данных есть паузы (их видно осциллографом), можно их как-то отслеживать? Это были бы метки начала посылки.
Часто используются следующие стандартные скорости передачи интерфейса UART.
бод
мкс
http://mypractic.ru/urok-12-posledovatelnyj-port-uart-v-arduino-bibliote...
Я Вас не об этом спрашивал.
Вы употребили термин "длительность единичного импулься". Именно для этого термина я и просил дать пояснения.
Следующий вопрос, естественно, будет: "как ее определить при помощи осциллографа". Так что будет хорошо, если Вы сразу ответите и на него (чтобы время зря не терять).
В потоке передаваемых данных есть паузы (их видно осциллографом), можно их как-то отслеживать? Это были бы метки начала посылки.
А рядом с паузами может всегда одинаковые байты?
"как ее определить при помощи осциллографа". Так что будет хорошо, если Вы сразу ответите и на него (чтобы время зря не терять).
На переключателе строчной развертки осциллографа "время/деления" есть цифры, цена одного деления сетки на экране, и в зависимости от положения второго переключателя "мкс/мс" можно увидеть длительность импульса. 1 импульс это 1 бит. Это в общем-то общеизвестно.
Но т.к. у меня получилось подобрать скорость тупо перебором, то я с оциллографом не заморачивался.
Нет, разные.
Вопрос в том, как выделить именно паузу.
1 импульс это 1 бит. Это в общем-то общеизвестно.
Да?
Хорошо. Реальный пример из жизни: по каналу связи примерно 3 раза в секунду передается отрицательный импульс длиной 64 мкс. Известно, что это соединение именно по последовательному порту. Какова скорость передачи?
Хорошо. Реальный пример из жизни: по каналу связи примерно 3 раза в секунду передается отрицательный импульс длиной 64 мкс. Известно, что это соединение именно по последовательному порту. Какова скорость передачи?
Скорость передачи вы можете и сами рассчитать https://bravikov.wordpress.com/2012/08/24/скорость-передачи-данных-через-uart/
Мне не нужно ничего рассчитывать. Раз Вы утверждаете, что рассчитать возможно, рассчитайте для конкретного случая: 64 мкс импульсы с периодом 300 мс.
PS. Да, по приведенной Вами ссылке мне не удалось найти способа определения скорости порта при помощи осциллографа.
~ 15000 бит/сек
~ 15000 бит/сек
Неверно.
Правильный ответ 31250.
Этот пример показывает, что в общем случае по ширине импульсов определить частоту передачи невозможно. Тем более, что приведен был не некоторый искусственный, а вполне конкретный пример: MIDI источник сигнала, например, клавиатура или секвенсер регулярно передают команду Active Sense (0xfe), чтобы сообщить приемнику, что музыкант на клавиши не нажимает и ручки не крутит, но связь между устройствами есть.
Т.е. такие сигналы встречаются в реальной жизни.
Неверно.
Правильный ответ 31250.
Этот пример показывает, что в общем случае по ширине импульсов определить частоту передачи невозможно.
Вы не корректно сформулировали задачу. Судя по реальной скорости, 64 мкс не один, а два импульса, т.е. два бита информации, а длительность предачи одного бита равна 32 мкс. Если смотреть осциллографом весь пакет, то тогда будет отлично видно единичный импульс, в Вашем примере его длительность будет равна 32 мкс, а не 64 мкс. Как-то так.
Как раз таки в реальной жизни только так и можно определить реальную частоту сигнала и соответственно скорость передачи.
Вы бы лучше помгли чем-то дельным, а не экзамены по теории устраивали.
А теперь реальная жизнь, есть поток, в котором 12 чисел, которые повторяются циклично.
Выглядит приблизительно так
0 1 A0 28 28 14 4E 5A A1 19 3 C
Каждое число всегда находится на своём месте в пакете и может изменяться в некотором диапазоне начиная с 0. Как выделить конкретное число и привязать к нему какое-то действие? Числа могут быть одинаковые, поэтому просто оператором "if" не получается.
А из реальной жизни несколько пакетов как выглядят? Какой-то хидер у них есть общий?
Вы не корректно сформулировали задачу. Судя по реальной скорости, 64 мкс не один, а два импульса, т.е. два бита информации, а длительность предачи одного бита равна 32 мкс.
Задача сформулирована вполне корректно: на экране виден единственный импульс длиной 64 мкс. Да - это два бита: стартовый и первый "0". Остальные в байте 0xfe равны единице, равно как и стоповый бит. Т.е. на осциллографе выглядят точно так же, как5 и отсутствие передачи.
Если смотреть осциллографом весь пакет, то тогда будет отлично видно единичный импульс, в Вашем примере его длительность будет равна 32 мкс, а не 64 мкс. Как-то так.
Что Вы мне сказки-то рассказываете!
На экране именно один импульс длительностью 64 мкс, что принимающий порт должен воспринимать как два бита. Но чтобы понимать, что это именно два бита, а не 1, не 3 не 4 и не 5, он должен заранее знать скорость передачи.
Как раз таки в реальной жизни только так и можно определить реальную частоту сигнала и соответственно скорость передачи.
Теоретик, блин!
Вы бы взяли осциллограф и посмотрели, как на экране выглядит 0xfe.
Каждое число всегда находится на своём месте в пакете и может изменяться в некотором диапазоне начиная с 0. Как выделить конкретное число и привязать к нему какое-то действие? Числа могут быть одинаковые, поэтому просто оператором "if" не получается.
очень просто. Находим начало пакета. отсчитываем нужную позицию - а уже к ней применяем IF
очень просто. Находим начало пакета. отсчитываем нужную позицию - а уже к ней применяем IF
А если еще проще... Вот такое получается сообщение
0 1 A0 28 28 14 4E 5A A1 19 3 C Как в нем отсчитать нужную позицию?
Повторяется циклично, каждая цифра соответствует своему значению на экране, идут непрерывно, начинаются всегда с "0", поэтому признаку я "перевожу строку". Например, в этом на 4 и 5 месте числа 28, что значит 22 градуса слева и справа, 10 и 11 (19 3) это скорость вентилятора, причем значений скорости 7, а цифры меняются еще и в зависимости от других органов управления, всего получилось три набора значений скорости, хотя реально семь скоростей всего.
Я думаю с помощью библиотеки TV-out выводить на сторонний экран эту информацию. Вначале я думал просто с помощью "if' это делать, но в наборе появляются одинаковые числа, т.е. имеется ещё и зависимость от положения числа в наборе.
Надоел уже.
Я думаю с помощью библиотеки TV-out выводить на сторонний экран эту информацию.
Вы ничего не перепутали? Собираетесь одновременно использовать SoftwareSerial и TVout?