Comments 10
Э как у них I2C покукожило то...
Самое обидное, что в I2C у тебя хотя бы есть механизм ACK/NACK. У RFFE устройств такого нет. И сиди гадай, ты не прав, или все же микросхема. А она просто молчать будет до победного.
ну вот не хочешь ты платить филипсу (кстати, где он(с)) отчисления, возьми, как все остальные, просто придумай другое название и будет у тебя вместо i2c свой очередной twi/sccb/pmbus/... при этом совместимый, но нет же - "@#$нутым нет покоя"
С таким интерфейсом я ещё не сталкивался, почитать было интересно.
Ногодрыг прям сложный получился. Если не удаётся эмулировать такой спец.интерфейс аппаратно, типа через SPI или что-нибудь подобное, я пользуюсь запросом DMA от таймера. Сама DMA-передача идёт либо в регистры таймера, либо прямо в порт GPIO. Это сильно быстрее и точнее, чем прерывания.
Передний фронт SCLK Задний фронт SCLK
Что-то вы здесь намерили не то. По описанию мк фронт должен быть короче 4 нс. Либо на осциллографе включено ограничение полосы, либо забыли щуп в 1:10 переключить.
STM32F103 не на самой большой скорости
И микросхеме QPC1220Q вроде нужны логические уровни КМОП 1,8 В, а не 3,3 В.
Спасибо за комментарий. Рад, что было интересно)
Про DMA идея отличная, на момент реализации, почему-то, для себя выбрал реализацию с таймером. Собственно, на лучшую реализацию не претендую. Главное, что стабильно работает.
Что касается измерений на линии SCLK, как будет момент, постараюсь перепроверить для STM32F411CEU6. Активная работа над реализацией была давненько, что-то мог упустить) Однако точно помню, что на AT32F413KCU7-4 тайминги точно укладывались в спецификацию интерфейса.
Очень интересно! Спасибо за такой подарок всей тусовке! В моей волосатой голове начали бродить мысли где ещё это можно применить? Давайте накидаем вариантов?
Этот кадр представляет собой стандартный вид ответа на некорректную команду. Честно говоря, не совсем понятно, что подразумевали разработчики интерфейса, включая его в спецификацию, поскольку, на практике, его применение ну совсем уж ограничено.
Это нужно для того, чтобы шина не подвисала до окончания таймаута, ожидая ответа от слэйва, когда к нему по каким-то причинам пришла некорректная команда и он её проигнорировал.
Добиться скоростей выше одного МГц при эмуляции на микроконтроллере, с учётом того, что он должен решать и другие задачи, будет очень сложно.
А зачем вам мегагерц? На вашем же скрине написано, что тактовая может быть от 32 кГц.
Добрый день, спасибо за комментарий
Это нужно для того, чтобы шина не подвисала до окончания таймаута, ожидая ответа от слэйва, когда к нему по каким-то причинам пришла некорректная команда и он её проигнорировал.
Не могли бы раскрыть подробнее? Насколько я понимаю, поводов для подвисания там вроде присутствовать не должно, т.к. шина всегда притянута вверх или вниз мастером или слейвом.
А зачем вам мегагерц? На вашем же скрине написано, что тактовая может быть от 32 кГц.
В статье я и не утверждаю, что целюсь в такие скорости. Однако, поскольку информации в интернете по данному интерфейсу особо нет, на момент реализации, я старался с запасом попасть в требуемые RFFE параметры. Чтобы исключить лишние неопределённости. Потому старался добиться максимальных скоростей тактирования на шину.
Добиться ровного и стабильного тактирования на скорости в 1МГц и более не вышло.
MIPI RFFE на GPIO ARM контроллера. Эмуляция проприетарного интерфейса на GPIO ARM-микроконтроллера