какие-то рекомендации по тому, как в пределах проекта организовывать зависимости между файлами? Просто столкнулся с тем что нужно написать как можно более легко портируемую библиотеку (обязательные условия - api интерфейса связи микроконтроллера и чипа - cmsis-driver I2c, а так же api cmsis-os2 для всех функций ос) для одного чипа и застрял на прерываниях. Функции-обработчики прерываний от периферии микроконтроллера живут вроде бы в отдельном своем файле. В файлах моей библиотеки есть функция обработчик события. Осталось совместить, но как то я не уверен что в лоб в файле с обработчиками прерываний писать #include "Stupid_library.h" это красиво. Вообще накопать какую-то литературу с примерами по архитектуре по для микроконтроллеров оказалось не так просто.. Да и висит вся эта история на i2c который могут и другие потоки использовать. Логика шепчет что нужен мутекс, но как и где его создать и передать кому и куда непонятно
Сейчас нашел книжку Embedded Systems Architecture (Daniele Lacamera), но если у кого-то есть пример организации проекта, то это было бы очень кстати
Низкоуровневый драйвер i2c, использующий мютекс - отдельно, драйвера устройств на этом i2c - отдельно. Прерывания в отдельный файл, если хочется вынести из них бизнес логику - заводить задачу оси и передавать в нее сигнал о том что произошло прерывание, и данные от устройства, которые надо обработать. Но это скажется на скорости конечно, если это критично. А так в целом по архитектуре - как обычно строится слоями, вся железная часть для простоты портирования на разные камни это отдельный слой скрытый своими интерфейсами. Новый камень - новые драйвера периферии, а бизнес-логика остаётся полностью прежней. Как то так архитектура и строится.
получается, стоит завести на каждый физический интерфейс по потоку?
если потокобезопасное,то можно иметь слой драйверов для операционки,как это сделано в esp idf
Вроде как реализация драйвера у меня есть, cmsis-driver. Сделать для него прослойку, в которой инициализировать мютекс и интерфейс через который потоки смогут перехватывать контроль над i2c в принципе можно..
Хотелось бы да, потокобезопасное. В идеале еще и всю "бизнес-логику" вынести в непривилегированные потоки
Вызов interrupt call back тз прерывания, их по месту надо будет вставлять и вск
Ну получается что нужно создать ещё один уровень, который будет иметь доступ к библиотеке, связанной с чипом (чтобы взять оттуда функцию обратного вызова) и доступ к всякому там hal_exti для структур, связанных с прерываниями. Что-то такое и думал, спасибо:)
Обсуждают сегодня