[решено]Raspberry <=> Arduino через I2C

в который раз убеждаюсь - буратино код - это фуфел

 

...только поосторожнее. Посмотрите тему "что за деталь" рядом. А железки типа Atmega328p и т.п. по цене (включая сам ремонт) в разы у малины дороже. Сам по неосторожности вторую (Pi2) сгубил. И с тех пор пользуюсь только Arduino <-USB/SERIAL-> Raspberry Pi3. И только малина (первая B+) служит как программатор и т.д.

 

Кстати...может и не удачный пример - простите. Но тут (на форуме) реализовывал на C:
"Raspberry PI3" <--USB/SERAL--> "Arduino UNO R3" <-- I2C--->"ComMotion 4 motors shield" + "Muliservo(Амперка)". Реализовать реально.

 

c таким подходом надо забыть про GPIO)))

и использовать дуню как щит

 

Убрал Serial.print из обработчиков прерываний i2c у ардуины, и малина стала читать без задержеки корректно

 

Надо конечно быть осторожным. Но в данной теме речь идёт о Arduino <- I2C -> RaspberryPI. В данном случае на стороне Arduino пины в режиме "открытый сток -- open drain", поэтому на пинах не может появится напряжение выше напряжения подтяжки на стороне Raspberry -- 3.3V. Что с одной стороны является безопасным для "Малинки", а с другой стороны нормально распознаётся "Ардуинкой" ("АВРкой").
Что касается Serial, то скорее всего там имеется подтяжка на стороне Arduino, как минимум, для передающего пина (TX), поэтому на пине будет 5V (но надо смотреть доку, полной уверенности нет). В результате можно спалить как минимум USART у "Малинки" или её всю целиком (имеется ввиду процессор).

 

Да не забыть, а буферировать. И не вешать существенные нагрузки, согласовывать и т.п. Вы же на PCI на ПК не вешаете, что попало. Потому как дорого... и трудоёмко. А ATmega по цене в разы дешевле и паять легче. Хотя дело вообще Ваше... хозяин - барин

 

Да не о том я... Если Arduino с его на плате установленным USB-SERIAL малиной распознаётся как SERIAL порт. Стандартное устройство /dev/USBtty какой-то. И с ним работать и ничего согласовывать не надо. Вы же сами мне давали рекомендации. И получалось так, что малина на высоком уровне ардуино управление шилдами... ну а шилды управляют приводами.

 

я так понял Игорь говорит воткнуть через юсб порт малины.

 

Подтяжка маловероятна, а вот с пина TX идет амплитуда равная питанию.

 

К чему такой изврат?

 

Так я это и применяю... Даже Arduino IDE стоит на малине. Там и редактирую, там и компилирую, там и заливаю... там же и применяю. Не одновременно конечно... устройство ведь одно... по очереди.

 

I2c шина достаточно безопасна, если все участники следуют протоколу и напряжение самого "слабо напряжённого" участника расценивается остальными как логическая единица.

 

...
- Давид Маркович идите как хочете по Одессе. Я пойду как мне надо. ("Ливидация")

 

Да, в этом случае ничего согласовывать не надо. Мне почему-то показалось, что речь идёт о подключении USART интерфейса Arduino к USART интерфейсу Raspberry. В этом случае нужно согласование уровней.

 

Потому как ардуина дешевле и сама в каком-смысле извратом и является. Не в обиду конечно. Но камера и малина в проекте не может быть заменена ардуиной. А вот всякие шилды типа WIFI, ETHERNET, USB, SD card и т.д. на контроллер и есть ГОЛИИИИИИМЫЫЫЫЫЫЫЫЫЙ изврат. И пригоден только для начального обучения.
НООО! есть и польза в этом - ребята познают что такое контроллер... программирование... оценят свои возможности и т.п. Да и цена доступная.

 

А купленный УЗ дальномер по I2C я всё же не стал вешать на ардуину... а к малине. Да и питание от малины же по 5В.

 

Я в своем проекте планирую нагрузить малину загрузить приемом команд из сети и стримом видео, а контроллер ардуины управлением двигателями платформы и сервоприводом турели камеры. От ардуино останется только сам мк, без обвязки на юсб, так что через него не подключиться.

 

Так и я про то же... и именно так и делал. Только шилды нужны были - их и купил. И сразу по I2C на малину вторую. Пока сваял программу... (пару месяцев на изучение шилдов и программу) малина умерла при очередных тестах. Вот и решил отвязать всё от малины через ардуино. А на ардуино "изуродованный" протокол Modbus RTU... реализовал несколько команд.