гироскоп mpu6050 и i2c lockup- виснет i2c Опции

[Onkel]

mpu6050 (6 осевой гироскоп) на гиростабилизированной платформе - все работает как часы, пока не подключен мотор. Когда подключен мотор - виснет i2c, может сразу, может через минуту, ну через 10 минут точно. Симптоматика - clk встает в 1, sda в 0, и так зависает или через некоторое время передает шум. Дело, видимо, в 6050 - инет полон жалоб на 6050 при любых контроллерах, от ардуино до эдисонов. Сижу гадаю - или забить на mpu6050 и взять что еще, но у 6050 бортовой вычислитель, что экономит кучу ресурсов мк, а других я такой фичи не видел. Какая- то наводка, это точно, при одних моторах виснет сразу, при других - через минуту, обвешивал кондерами как дикобраза, проверял перепроверял signal ground? делал даже полную опторазвязку, причем отдельные блоки питания для моторов и для мк с imu - все точно также.
Помогите кто чем может.

Вот хороший пример плача Ярославны, показатель что не я один такой :

I've tried two devices (though both from the same manufacturer/class of devices, MPU6050 and MPU9250), I've tried all the different I²C speed settings, I've tried running the polling loop at a lower frequency (slowing it down with usleep()), I've tried to not do any setup or self-testing or calibration and just getting the values, I've tried both I²C buses, I've tried a couple of different level converters... Not sure what else I can tell you; it's my experience that it doesn't really matter what you do or what steps are taken---the I²C bus will eventually freeze on 2.1, at least with the devices I've tried and polling in a loop the way I am.
I threw weeks of testing on this with a bunch of different software approaches (from as barebones as possible to thoroughly scanning the datasheets to configure each register that seemed relevant to optimise the chances of things working) and hardware wiring/configurations (hence the different level converters and plain resistive voltage dividers, two different IMUs that do the same thing, two different Edisons on two different mini breakout boards, different breadboards in case of dodgy internals to eventually soldering things thoroughly on prototype boards) and it just didn't matter. Turns out the problem was seemingly in the Edison kernel/drivers themselves. Ugh.

[agregat]

Если делали разные изолирванные блоки питания для двигателя и MCU и все равно зависало, то это просто наводки.
Закрывайте MCU в металлическую коробку, а на все провода выходящие из нее, включая питание фильтры.