У меня, когда я работал через битовые поля, каждое обращение к полю компилировалось в отдельную операцию чтение-модификация-запись. Собирал тогда GCC 7
Возможно. Не настаиваю на своём подходе, тем более у уважаемого lamerok всё гораздо лучше проработано в этом отношении.
Однако, это то, чем я пользуюсь в реальных проектах, мне так удобно. Возможно кому-то ещё пригодится, если нет — тоже не беда, по итогам обсуждения, спасибо сообществу, появилось множество новых идей, значит уже писал не зря.
Нет, крутится всё на stm32f429. stm32f103 для более лёгких применений. И как пример здесь. Но никто же не мешает так и с AVR работать. Благо там тоже gcc.
Я не от хорошей жизни туда полез. Когда поддерживаешь прошивки шести железок, похожих, но не совсем, всё время что-то в них докручивая, остро встаёт вопрос повторного использования кода и его удобочитаемости, а также невнесения ошибок при модификации.
Попробовал делать на шаблонах — понравилось, стало легче. В свою веру не обращаю, кому как удобнее.
На вкус и цвет…
Вот есть в Кейле отличный отладчик с просмотром содержимого регистров по полям. И монитор реального времени. Завидую. Однако, те возможности, что есть в gcc, для меня перевешивают всё это. Плюс возможность писать под любой операционкой, для меня это важно.
Извините если вопросы наивны, я об этом языке имею самое поверхностное представление.
Получается, что Ада умеет оптимизировать работу с битовыми полями, и эти две операции будт выполнены как одно чтение-модификация-запись?
Если да, то как написать код, чтобы значения устанавливались последовательно, например, сначала необходимо включить периферию, а затем установить какое-то конфигурационное значение?
У меня эти выкрутасы работают при чтении 16 каналов 24-разрядного внешнего АЦП с вычислением амплитуд и фаз сигнала по нескольким частотам, параллельным чтением акселерометра, гироскопа и GPS, и передачей всей этой радости в реальном времени по USB HS.
Есть за что бороться, не находите?
Как ни странно, компилируется. Даже gcc 9.2.1 не выдаёт по этому поводу никаких предупреждений. Тот же Clang, который работает в QtCreator в качестве статического анализатора кода тоже молчит.
Однако, эта конструкция мне самому не нравится. На этапе отладки не всегда можно через неё получить значения регистров, gdb её плохо переваривает. Буду думать, чем заменить.
Интересная статья. Странно, что не видел её у себя в ленте.
Никогда не получалось настолько глубоко погрузиться в шаблоны, всё время приходится искать компромис между сложностью реализации (читай — временем на разработку) и качеством получаемого результата. Автору — респект!
С SVD файлами не всё так просто. Например, у того же ST в них есть некоторое количество ошибок, которые в неизменном виде кочуют в reference manual, видимо, его каркас генерируется автоматически. Нет там и признака R/W у поля регистра, и допустимых значений. Ручного труда по описанию периферии со всеми его ошибками не миновать, как ни крути.
Плохо пока понимаю, как можно красиво написать обёртку над CMSIS. Слишком разные подходы.
У меня, когда я работал через битовые поля, каждое обращение к полю компилировалось в отдельную операцию чтение-модификация-запись. Собирал тогда GCC 7
Возможно. Не настаиваю на своём подходе, тем более у уважаемого lamerok всё гораздо лучше проработано в этом отношении.
Однако, это то, чем я пользуюсь в реальных проектах, мне так удобно. Возможно кому-то ещё пригодится, если нет — тоже не беда, по итогам обсуждения, спасибо сообществу, появилось множество новых идей, значит уже писал не зря.
Нет, крутится всё на stm32f429. stm32f103 для более лёгких применений. И как пример здесь. Но никто же не мешает так и с AVR работать. Благо там тоже gcc.
Я не от хорошей жизни туда полез. Когда поддерживаешь прошивки шести железок, похожих, но не совсем, всё время что-то в них докручивая, остро встаёт вопрос повторного использования кода и его удобочитаемости, а также невнесения ошибок при модификации.
Попробовал делать на шаблонах — понравилось, стало легче. В свою веру не обращаю, кому как удобнее.
На вкус и цвет…
Вот есть в Кейле отличный отладчик с просмотром содержимого регистров по полям. И монитор реального времени. Завидую. Однако, те возможности, что есть в gcc, для меня перевешивают всё это. Плюс возможность писать под любой операционкой, для меня это важно.
Извините если вопросы наивны, я об этом языке имею самое поверхностное представление.
Получается, что Ада умеет оптимизировать работу с битовыми полями, и эти две операции будт выполнены как одно чтение-модификация-запись?
Если да, то как написать код, чтобы значения устанавливались последовательно, например, сначала необходимо включить периферию, а затем установить какое-то конфигурационное значение?
У меня эти выкрутасы работают при чтении 16 каналов 24-разрядного внешнего АЦП с вычислением амплитуд и фаз сигнала по нескольким частотам, параллельным чтением акселерометра, гироскопа и GPS, и передачей всей этой радости в реальном времени по USB HS.
Есть за что бороться, не находите?
Как ни странно, компилируется. Даже gcc 9.2.1 не выдаёт по этому поводу никаких предупреждений. Тот же Clang, который работает в QtCreator в качестве статического анализатора кода тоже молчит.
Однако, эта конструкция мне самому не нравится. На этапе отладки не всегда можно через неё получить значения регистров, gdb её плохо переваривает. Буду думать, чем заменить.
Интересная статья. Странно, что не видел её у себя в ленте.
Никогда не получалось настолько глубоко погрузиться в шаблоны, всё время приходится искать компромис между сложностью реализации (читай — временем на разработку) и качеством получаемого результата. Автору — респект!
С SVD файлами не всё так просто. Например, у того же ST в них есть некоторое количество ошибок, которые в неизменном виде кочуют в reference manual, видимо, его каркас генерируется автоматически. Нет там и признака R/W у поля регистра, и допустимых значений. Ручного труда по описанию периферии со всеми его ошибками не миновать, как ни крути.
Плохо пока понимаю, как можно красиво написать обёртку над CMSIS. Слишком разные подходы.