Виделось достаточно дёшевое решение, но не тут то было.
Просто перетащить картинку в окно ответа
И на SCL при этом 1.5МГц такт? Удивительно…
Вот кстати ещё одно наблюдение:
Интервалы между пачками опроса гироскопа просто огромные около 100 миллисекунд. Расчёты даже включая фильтрацию шумов не могут занимать много времени.
Управлением выходных каскадов мотора скорее всего занимается модуль PWM в том же контроллере.
На кой чёрт при всём при этом использовать ультравысокоскоростной протокол I2C?
За глаза хватило бы 100 кГц.
Да решение то на поверхности. Вопрос какой взять контроллер ( желательно уже на плате с кварцем и стабилизатором, ну и с usb) чтобы он спаравился с простой задачей - оцифровать аналог и отправить данные по шине i2c со скоростью 1,5МГц в линии SCL, если так можно выразиться.
Да, взять готовый контроллер мотора, и не парить мозг. В первую очередь себе.
SPI интерфейс есть в MPU6000, а в MPU6050 его нет. Конструктивно микросхемы одинаковы, на «родном» название стёрто. Но вместо него был подключён однозначно MPU6050 и он 100% работал. Как на запредельной частоте - непонятно, да ещё и в серийной БЫТОВОЙ вещи. Но китайцы они такие кудесники, ничего не боятся. Вот только зачем гонять интерфейс на частоте близкой к ультра, если остальное время контроллер курит бамбук? Сосед лётчик испытатель говорит: ну мы же летаем на запредельных углах атаки. А я ему отвечаю: именно поэтому все улицы в городе названы Вашими именами.
Вот сюда тыкай и выбирай файл.
Я бы вместо справок всяких скриншот с логанализатора посмотрел и схему (всё таки не на словах).
ЗЫ: И вообще полезно текст в окне ввода читать ))
1 лайк
На первом фото хорошо видно 667 нс период следования SCL, а также то что после обращению к внешнему контроллеру адрес которого 0х68 нет бита подтверждения со стороны SLAVE, в качестве которого в данное время выступает ардуино нано. Видимо если условие СТАРТ принято ардуинкой то после этого события слишком высокая частота тактирования на даёт возможности контроллеру правильно записать адрес, поскольку в реальной ситуации при подключённом к шине гироскопе после записи адреса Setap Write to [0x68]+ ACK, то есть следует подтверждение приёма и дальнейшее выполнение обмена едет как по накатанной.
667 наносекунд - это 150 кГц…
И как же тогда заставить работать интерфейс быстрее, ведь дело только в скорости, и куда девалось хвалёное ожидание ответа ведомого которое есть во всех описаниях протокола i2c?
Нет, налажал в запятых )) 1500 кГц
Ёпта, почитай что есть й2с, там параметров, насколько мне известно около 4 , по восходящему клоку или наоборот , просто дальше не помню, может твои ардуинкт и СТМ по умолчанию совпали, а от датчика нет?
Как вариант, взять ATmega328PB, он “тянет” до 32МГц такт. проца. Затем найти на старом форуме “ногодрыг” , если не изменяет память , от Komandir-а до 1МГц I2C на 16МГц ардуино.
По идее 1.5МГц I2C + АЦП должен потянуть, но сам не пробовал))
P.S. АЦП скорее “обрезать” до 8-бит придётся, ради скорости
Даже если я ну или Вы посчитаем на счётах то никак не получим 150кГц. А получим 1,499 МГц. Если та считать зарплату то пора занимать место на паперти. На всякий случай ещё одна фотка: слева в прямоугольничке Freq:1,6 Mgz
1 лайк
Потому что:
Получается по идее можно обойтись и ардуино нано, но вот в реалии что-то не срастается. Попробую Wire.setClock(1000000). Но по опыту связи двух контроллеров нано и rp2040-zero скорость не увеличивалась. Не хочу ругать компилятор, так может былть библиотека Wire.h кривая?
Я говорил о софтовом I2C
А больше 8-ми бит ацп и не нужно: врядли кому-то потребуется 1023 скорости вращения гончарного круга, да и за электротачкой (типа садовой) бегать смысла нет. Это я о возможных применениях.