Ограничивается это не уровнями и частотой шины, а работой драйверов в Linux.
Частотой работы шины, безусловно, тоже ограничивается т.к. чтобы узнать какое именно произошло изменение, нужно прочитать его из одного из слейвов. При частоте шины 400 КГц на 1 мс придётся всего 44 байта на i2c. Это в идеале.
Если линия прерываний 1 на все модули, а не индивидуальная, то нужно будет ещё успеть опросить все модули с входами.
Я не пытаюсь придраться, просто доношу, что 1мс в модульных системах с последовательной шиной и кучей накладных расходов — вовсе не так уж и много. Уверен, что все технические проблемы решены и заявленные характеристики проверены. Поэтому ждём статью
Добрый день, очень понравился конструктив! Спасибо за статью!
Модули подключаются к процессору по шине I2C, а их сигналы обрабатываются драйвером в ядре Linux по прерыванию. Благодаря этому, задержка между, например, срабатыванием входа на модуле расширения и детектированием сигнала в ПО не превышает 1мс, что на два-три порядка быстрее чем при работе по Modbus.
Расскажите, каким образом достигается время детектирования входа на модуле в 1 мс. Какая частота работы i2c, какие лог. уровни выбраны для межмодульной шины? Какие особенности межмодульного протокола (в контексте обеспечения времени реакции)? Какой контроль целостности передаваемых по шине данных? Всегда ли соблюдается время детектирования в 1мс (разное кол-во доп. модулей на шине)?
В качестве альтернативы i2c можно было также использовать rs485 на скоростях в несколько Мбит. Наверное, решение было бы более помехоустойчивым.
Применять встроенный генератор можно всегда, когда вас устраивает его НЕ стабильность в условиях работы вашего устройства (в документации есть графики зависимости его частоты от температуры и напряжения питания). А ещё есть разбег от экземпляра к экземпляру и есть процедура калибровки этого генератора.
Но есть и плюсы. Например, от встроенного генератора микроконтроллер стартует быстрее, чем от внешнего кварца (его ещё надо раскачать)
Существуют похожие серийные решения в наружной рекламе. Без микроконтроллера и USB правда, только система управления на логике и массив светодиодов. Интерфейс последовательный.
Градации серого, правда, получают там очень частым обновлением индикатора (своеобразный ШИМ поверх последовательного интерфейса).
Модули для управления такими модулями тоже есть с разными интерфейсами (на базе микроконтроллеров или ПЛИС)
Синхронизация времени — довольно скользкий момент в вашей системе.
Расскажите, учитываете ли вы повторы передачи канальным уровнем nRF24L01 в случае пропуска пакета синхронизации или ACK-пакета?
Какой длины пакеты синхронизации?
Скорость передачи 2 mbps?
А пол не скрипит?
И не повылетает ли вся затирка между досками при эксплуатации? Дерево же прогибается всё-таки
Статья очень понравилась, жду продолжения
Чтобы корпус диммера влезал в стандартные подрозетники без необходимости углубления, надо сделать корпус раза в 2 ниже.
Какие размеры, кстати, у корпуса?
ну есть несколько нюансов в моей реализации, о которых мне известно:
— можно слушать только операции записи от мастера к слейву, операции чтения из слейва перехватить не получится (в моей задаче и не нужно)
— шпион выдаёт аппаратно ACK на каждый байт, который мастер пишет в слейв. Если TDA отвалится от шины (выйдет из строя) процессор магнитолы будет считать что TDA отвечает на шине, но шлёт 0xFF. Как на это среагирует мастер — знает только разработчик магнитолы))
— слейв (в данном случае TDA) имеет право задерживать выдачу ACK если сильно занят. В итоге возможна ситуация, когда мастер продолжит обмен по ACKу шпиона, хотя реальный слейв не готов принимать следующий байт. Уверен, что TDA не использует эту возможность.
Только не совсем понял, в случае RGB-матрицы, через какой пин будут лететь данные синего цвета?
Частотой работы шины, безусловно, тоже ограничивается т.к. чтобы узнать какое именно произошло изменение, нужно прочитать его из одного из слейвов. При частоте шины 400 КГц на 1 мс придётся всего 44 байта на i2c. Это в идеале.
Если линия прерываний 1 на все модули, а не индивидуальная, то нужно будет ещё успеть опросить все модули с входами.
Я не пытаюсь придраться, просто доношу, что 1мс в модульных системах с последовательной шиной и кучей накладных расходов — вовсе не так уж и много. Уверен, что все технические проблемы решены и заявленные характеристики проверены. Поэтому ждём статью
Расскажите, каким образом достигается время детектирования входа на модуле в 1 мс. Какая частота работы i2c, какие лог. уровни выбраны для межмодульной шины? Какие особенности межмодульного протокола (в контексте обеспечения времени реакции)? Какой контроль целостности передаваемых по шине данных? Всегда ли соблюдается время детектирования в 1мс (разное кол-во доп. модулей на шине)?
В качестве альтернативы i2c можно было также использовать rs485 на скоростях в несколько Мбит. Наверное, решение было бы более помехоустойчивым.
Но есть и плюсы. Например, от встроенного генератора микроконтроллер стартует быстрее, чем от внешнего кварца (его ещё надо раскачать)
Дисплеи и раньше использовали с DMA через FSMC (ныне FMC).
FMC для того и создан, чтобы работать с внешними микросхемами через параллельную шину. Аппаратная выдача строба в нём должна быть обязательно.
Градации серого, правда, получают там очень частым обновлением индикатора (своеобразный ШИМ поверх последовательного интерфейса).
Модули для управления такими модулями тоже есть с разными интерфейсами (на базе микроконтроллеров или ПЛИС)
Расскажите, учитываете ли вы повторы передачи канальным уровнем nRF24L01 в случае пропуска пакета синхронизации или ACK-пакета?
Какой длины пакеты синхронизации?
Скорость передачи 2 mbps?
И не повылетает ли вся затирка между досками при эксплуатации? Дерево же прогибается всё-таки
Статья очень понравилась, жду продолжения
Штатные системы как раз лучше защищают. Особенно от угона
Какие размеры, кстати, у корпуса?
— можно слушать только операции записи от мастера к слейву, операции чтения из слейва перехватить не получится (в моей задаче и не нужно)
— шпион выдаёт аппаратно ACK на каждый байт, который мастер пишет в слейв. Если TDA отвалится от шины (выйдет из строя) процессор магнитолы будет считать что TDA отвечает на шине, но шлёт 0xFF. Как на это среагирует мастер — знает только разработчик магнитолы))
— слейв (в данном случае TDA) имеет право задерживать выдачу ACK если сильно занят. В итоге возможна ситуация, когда мастер продолжит обмен по ACKу шпиона, хотя реальный слейв не готов принимать следующий байт. Уверен, что TDA не использует эту возможность.
Для моей задачи все эти пункты не критичны.
Чтобы внешние усилители держать включенными только вместе с магнитолой. Для тех, кого не устраивает управление усилителями от ACC/зажигания.
Чтобы просыпаться только тогда, когда идёт обращение к усилителю, а не на каждый чих на шине.