Я пишу прошивку для esp32 на C++, и мне показалось замечательным передать ссылку на объект в качестве параметра при регистрации ISR, потому что я могу просто делегировать работу из ISR конкретному объекту (ресурсу в данном случае), управление свойствами и функциональностью ресурса непосредственно из класса. Однако я не совсем уверен, на что обращать внимание при использовании этой техники.
Есть ли что-то неправильное в передаче «это» в качестве аргумента для регистрации ISR?
No.
Есть ли в этом что-то изначально неправильное?
No.
Если нет, то о чем нужно помнить, делая это?
Срок службы объекта. Оптимизация компилятора. Совместное использование ресурсов. Блокировка. Атомарный доступ. Специфическая аппаратная семантика. Кроме того, esp32 — это двухъядерная платформа. Список можно продолжить, и есть много книг о программировании на esp32, о программировании в параллельных средах и о совместном использовании ресурсов между основной частью кода и подпрограммами обработки прерываний. Следует знать обо всех таких темах, связанных с программированием, а также о хороших соглашениях о коде, именовании и языке C++.
volatile он буквально отключает оптимизацию компилятора. Но есть также переупорядочивание инструкций, std::atomic и std::memory_order, а также барьеры на случай, если вы хотите использовать оптимизацию компилятора вместо использования volatile.
- person KamilCuk; 22.01.2021
Я могу просто делегировать работу из ISR конкретному объекту (в данном случае ресурсу), управляя свойствами и функциями ресурса непосредственно из класса.
Это уже неправильно. Если вы пишете драйвер в виде класса для определенного аппаратного периферийного устройства, то ISR должен быть внутри этого класса как статическая функция-член. Или, по крайней мере, находиться в той же единице перевода, что и функция static, но это противоречит цели использования класса с самого начала.
Если вы разрабатываете программу таким образом, то, конечно, вы можете передать ссылку на этот класс.
Есть ли в этом что-то изначально неправильное?
Помимо вышесказанного, тогда да, это должен быть одноэлементный объект со статической продолжительностью хранения. А использование объектов статической длительности хранения классов C++ по своей сути неправильно во встраиваемых системах, потому что они будут вызываться CRT во время запуска микроконтроллера. Что, в свою очередь, заставляет все такие программы C++ запускаться медленнее, чем эквивалент C.
Но и в этом конкретном случае, если прерывание необходимо запустить своевременно с момента сброса при включении питания, тогда инициализация объекта C++ не обеспечит необходимой производительности в реальном времени. Это делает классы C++ непригодными для таких прерываний, как сторожевые таймеры, предупреждения о низком напряжении, монитор часов, исключения ЦП и другие важные аппаратные прерывания.
Если нет, то о чем нужно помнить, делая это?
Обычные проблемы с повторным входом, возникающие при обмене данными между ISR и вызывающей программой. Этот механизм повторного входа может быть инкапсулирован в классе.
И, как обычно, переменные, участвующие в этом, могут нуждаться в квалификации volatile, чтобы предотвратить неправильную оптимизацию компилятора, в зависимости от того, насколько тупой ваш компилятор. Это не имеет ничего общего с повторным входом. См. раздел Использование volatile при разработке встроенного C.
what should one be aware of when doing it?Слишком широкий вопрос. Ты должен быть в курсе всего... - person KamilCuk schedule 22.01.2021