Ви не увійшли.
Всем доброго времени суток!
Для передачи между Arduino Uno и Arduino Mega использую библиотеку Wire. Передать мне нужно 2 значения типа Integer.
На Arduino Mega объявляю Wire вот так
Wire.begin();
На Arduino Uno так:
Wire.begin(8);
Wire.onRequest(requestEvent);
void requestEvent() {
byte myArray[4];
MyArray[0] = (intToSend1 >> 8) & 0xFF;
MyArray[1] = intToSend1 & 0xFF;
MyArray[2] = (intToSend2 >> 8) & 0xFF;
MyArray[3] = intToSend2 & 0xFF;
}
Для запроса данных на Arduino Mega вызываю requestFrom и сразу же читаю данные, которые пришли:
Wire.requestFrom(8,4);
byte a, b;
a = Wire.read();
b = Wire.read();
receiveInt1 = a;
receiveInt1 = ( receiveInt1 << 8 ) | b;
a = Wire.read();
b = Wire.read();
receiveInt2 = a;
receiveInt2 = ( receiveInt2 << 8 ) | b;
Данные приходят нормально, правда иногда путаются местами переменные, вместе receiveInt1 я получаю receiveInt2 и наоборот, т.е. какой-то рассинхрон.
Хочу уточнить у знатоков, правильный ли это способ передачи двух чисел между Arudino ? И что вы можете посоветовать поадекватней ?
Остання редакція froziq (2017-07-10 22:59:34)
Неактивний
Эту проблему решает протокол ,с маркерами начала и конца потока, а так же с управлением его скоростью (поставщик данных не должен передавать данные быстрее чем потребитель может их воспринимать).
Спасибо за ответ!
Судя по тому, что Вы не указали конкретный, протокол писать надо самому ?
Неактивний
I2C - фигня )
медленный. нужно ловить АСКи.
давайте ему предложим CAN )
у автора проблема. он путает числа что логично. у него ведь нет header/footer
самый простой вариант добавить дополнительную линию, если не жалко провода и ногу. если 0 то число 1ое,
если 1 то 2 ое ) ловить между байтами. а то зачем нам задержки? )
но автор то не обьяснил что за числа. как часто нужно отправялять, т.д.
нужен ли ответ ? критичность доставки.
я бы использовал UART: TX на общую линию через резистор.
и вместо 4 байт отправлял бы 6+ даныне >= 0x20 + \r старт \n стоп
даные меньше 0x20 кодировал бы 7D + DATA|0x20 )
пусть не так логично как пачка 4b в i2c
но можно по человечески отправлять ответ юартом )
встречная передача доступна это раз. можно в сеть обьединить
привычно .
если что не получается не нужен осфилограф )
а можно и парсить json, пусть привыкает
а с другой стороны все можно на i2c cделать красиво )
Неактивний
I2C - фигня )
медленный. нужно ловить АСКи.давайте ему предложим CAN )
у автора проблема. он путает числа что логично. у него ведь нет header/footer
самый простой вариант добавить дополнительную линию, если не жалко провода и ногу. если 0 то число 1ое,
если 1 то 2 ое ) ловить между байтами. а то зачем нам задержки? )но автор то не обьяснил что за числа. как часто нужно отправялять, т.д.
нужен ли ответ ? критичность доставки.
я бы использовал UART: TX на общую линию через резистор.
и вместо 4 байт отправлял бы 6+ даныне >= 0x20 + \r старт \n стопданые меньше 0x20 кодировал бы 7D + DATA|0x20 )
пусть не так логично как пачка 4b в i2c
но можно по человечески отправлять ответ юартом )встречная передача доступна это раз. можно в сеть обьединить
привычно .
если что не получается не нужен осфилограф )а можно и парсить json, пусть привыкает
а с другой стороны все можно на i2c cделать красиво )
Добрый день. Вы так всё конкретно описываете) спасибо за ответ!
В общем задача у меня такая: есть две ардуинки, 1.Uno считывает значения с датчика, 2.Mega выводит значения на экран.
Работает это так - Mega, как я описал выше, обращается по Wire к Uno и сразу читает значения. На Uno код вообще простой, она тупо считывает значения с датчика и на запрос Meg'и отправляет значения по Wire ( всё как описано в 1 сообщении ). То, что Mega с отрисовкой экрана работает медленнее и следовательно запрашивает отправку значений у Uno реже, чем Uno успевает считывать значения для меня не совсем критично, но в дальнейшем буду пробовать разгонять Meg'у.
Числа у меня целые, я их перед отправкой привожу к Integer ( примерно на отправку будет такой массив [ 430, 132 ], следующий например [ 411, 78 ] и т.д. ).
В ответ на вопрос "Как часто нужно отправлять ?", получается, что частота задаётся периодом выполнения одного цикла у Meg'и.
arduino Uno у меня считывает значение с датчика и отсылает на Meg'у, которая в свою очередь.
Пока я только разбираюсь с передачей двух чисел. В перспективе задача следующая: На каждый запрос Meg'и нужно отправлять ей два значения Integer ( это получается первая часть задачи, она такая же, как описано выше ). Вторая часть - на Uno будет таймер, который отсчитывает некоторое время ( например, 10 секунд ), про прошествии 10с Uno должна считать значения уже с других датчиков и сама отправить Mege значения, там будет массив из 4 значений тоже Integer ( например [ 123, 45, 72, 201 ] ). Вот я и думаю, как лучше сделать, отправлять Mege два разных массива или по прошествии 10с просто к тому массиву добавлять еще 4 значения и уже на Mege это всё парсить.
Буду очень благодарен, если Вы поможете мне дальше разобраться с передачей!
Неактивний
привет. данных недостаточно.
какой дисплей используете? какая длина? мега - удаленный индикатор или логгер со своей системой записи данных датчика?
давате так - вы расскажете что делаете.
если ноухау - пишите в вличку, NDA обязуюсь соблюдать. )
возможно вам было бо полезно приобщится к modbus. особенно если планируете еще датчки добавлять.
опишите задачу ...
Неактивний
привет. данных недостаточно ...
Сзади на дисплее написано 3.2' TFTLCD Shield for Arduino Mega2560 HVGA 480x320, он еще крепится к Meg'e на 2 ряда входов ( занимает с 22 по 53 ногу, в общем все входа на двух параллельных дорожках ). На Meg'e предполагается читать данные, выводить их на экран и, возможно она же будет иногда записывать данные на flash-накопитель.
Я Вам рассказал, что делаю, только не в тех понятиях и определениях, которые используются у меня в проекте.
Мне только нужно решить проблему с передачей данных между платами.
Неактивний
Вы хотите, чтобы вас научили или, чтобы вам сделали?
Добрый вечер.
Я хотел, чтобы мне подсказали. Делать за меня ничего не надо, у меня и так работает, только через одно место..
Вот и спрашиваю совета у форумчан)
Неактивний
привет. я не работаю с "закрытыми" проэктми на этом форуме
в принципе кого что сказали достаточно что б рекомендовать только raw.
если по простому то используйте любой из варинтов что ранее предлагал
а если по красивому хочестя - то вариант что предложил Вячеслав Азаров ).
но мне лично не нравится I2С как минимум перераход энегрии на резисторах при передаче.
посмотрел стандартную либу из ардуино. ничего не понял. низкой уровень передачи дето заныкан )
проще написать свое решение.
ознакомьтесь
http://www.nxp.com/docs/en/application-note/AN10216.pdf
успеха.
Неактивний
Я уже писал есть у меня два устройства, Pro mini+Atmega2560+ESP8266. На Pro mini измерительная часть, на Atmega аналогичный гр. дисплей и энкодер для управления меню а также все управление исп. устройствами (реле) а на ESP вэб сервер. И Pro mini и ESP общаются с ATmega по Serial используя JSON.
Вячеслав, хорошо пусть будет не протокол а формат, наверное Вы правы , но почему Вы решили что надо использовать JS для парсинга? Ардуиновская библиотека о которой я упоминал прекрасно все парсит и делает форматирование для отправки. JS использую для парсинга json в вэб сервере. Мне так кажется что использование Serial для коммуникации более оправдано нежели Wire. Простота использования ( serialEvent() ) USART упрощает эту задачу.
P.S. Забыл, у меня Pro mini оправляет даные через 5 сек (нет необходимости проводить измерения чаще). Хотя возможен и вариант (если так надо) запрос от Atmega.
P.P.S. Еще забыл, в библиотеке Serial в ардуино есть прикол, даже для Ат2560, имеет буфер в 64 байта (я нарвался два дня убил ) это нужно учитывать, или лезть в библиотеку и править размер буфера для атмеги.
Остання редакція Nefreemen (2017-07-16 11:23:20)
Неактивний
Nefreemen пише:Вячеслав, хорошо пусть будет не протокол а формат, наверное Вы правы , но почему Вы решили что надо использовать JS для парсинга? Ардуиновская библиотека о которой я упоминал прекрасно все парсит и делает форматирование для отправки. JS использую для парсинга json в вэб сервере. Мне так кажется что использование Serial для коммуникации более оправдано нежели Wire. Простота использования ( serialEvent() ) USART упрощает эту задачу.
JavaScript Object Notation (JSON) и все. А на счет того, что лучше - так это зависит от поставленной задачи.
Да нет не все. Действительно это формат, и формат текстовый. Когда то действительно родился в JS но на данный момент он не зависит от языка реализации. И когда используют JSON то это может быть никак не связанно с JS а в данном контексте точно .
Неактивний
JSON удобный формат для машинной и ручной обработки. в принципе удобен {a:1,b:1555 } или {a:[1,1555]}
и парсер не ошибется где какое число, но для автора топика такой механизм избыточен.
Неактивний