На вкус и цвет,…
Как по мне, в данном подходе есть необходимость помнить какие биты надо ставить и как они переопределены программистом.
Пользовался подобным описание для регистров внешних чипов, тот же акселерометр например. Не очень удобно оказалось. Особенно когда коллега перепутал порядок бит при описании регистров…
Вот пример модуля с интерфейсом SDIO JODY-W2 series (там еще есть и JODY-W3 серия):
Smallest, most flexible automotive modules supporting Wi-Fi 802.11ac at 105 °C
Dual band Wi‑Fi 2.4 GHz and 5 GHz 802.11a/b/g/n/ac
Dual‑mode Bluetooth 5 (Bluetooth BR/EDR and Low Energy)
Supports operation at 105 ° C
Simultaneous access point (AP), station (STA), or Wi‑Fi Direct (P2P)
Optimized for parallel operation of Wi‑Fi and Bluetooth
судя по последним нескольким статьям предлагаю лозунг «даешь С++ на микроконтроллеры»
активно читаю данные статьи, не все понятно, но я пытаюсь. И вроде все хорошо, но хотелось бы чуть больше менее абстрактных примеров. Ну запись в регистры, ну много разных методов. Разнообразие это хорошо, но меня пока и мой подход устаивает.
А будет расмотрено что более сложное, чем запись в регистры? Например описание реализации класса по работе, скажем с I2C акселерометром. На чистом Си я знаю как это будет выглядеть, на С++ примерно. Там и наследование, и желание избежать лишенго кода, ибо на шине может быть и кто-то другой, да и разделенный доступ к ресурсу будет. Вот какие преимущества от использования С++ будут там?
Сам опыта в С++ имею крайне мало, да и то, из-за наличия желания повозится с GUI на QT
Если будет использован BMP280, то в файле main/bme280.c нужно закоментировать все строки помеченные // Comment for BMP.
почему тогда не воcпользоваться #ifndef… #endif для того чтобы исключать не нужные строки? зачем пользователя то заставлять лазить в код, искать и комметировать строки? Вроде ж очевидное решение и прямо таки просится…
в своё время старший брат научил играть в эту игру, называл её «матрица». наверно, из схожести с падающими символами фильма)
к короткому решению я шел долго… но когда его увидел, даже растроился. как-то оно очевидно при должном внимании
в принципе наверно можно и так сказать.
но опять же, смотрите. Вот выставили мы например значение 00 в регистр. Это же не означает, что МК не сможет и не позволит вывести через данный пин сигнал в 40МГц. Меандр будет на выходе, но очень уж близкий к синусу. Если Вам нужно работать с цифровым интерфейсом, то это проблема. Вот и получается, что это не сколько частота работы (максимальная\разрешенная), сколько признак того насколько меандр выведенный с данного пина будет меандром.
я надеюсь Вы понимаете что я не пытаюсь придираться)
и снова ошибка. не скорость переключения, а именно время нарастания фронта (то есть его крутизну). За примером в даташит, а именно поискать таблицу "I/O AC characteristics" и посмотреть там строки «Output rise and fall time».
Из-за своего названия этот регистр много путаницы вносит в понимание работы такого просто модуля, как GPIO.
как правило заголовочники можно вытащить из IDE, которая пользуется отдельными паками для вендоров (Keil/Segger Embedded Studio например), ну или выкачивая монструозные библиотеки HAL\LL на все семейство.
моё почтенье после прочтения, было интересно и познавательно. но позволю себе пару вставить пару комментариев:
Без комментариев тут не обойтись. Хотя код всего-то устанавливает скорость работы порта GPIOA.0 в значение 40 Мгц
тут не совсем так, скорее даже совсем не так. Порт как работал со «скоростью» шины AHB так и будет работать. Регистр OSPEEDR определяет скорость нарастания фронта на выводе настроенном как выход. Кстати, в более новых поделиях этой фирмы, они заменили конкретные цифры на абстракции вида VeryLow\Low\Medium\High или их вариации.
Но, как я уже говорил выше, не все производители заботятся о своих потребителях, поэтому не у всех в файле SVD описаны перечисления, из-за этого для ST микроконтроллеров все перечисления, после генерации выглядят примерно так
я наверно Вас удивлю сейчас, но для некоторых МК st не то что не описали перечисления, они некоторые периферийные модули забыли описать. Так что полностью автоматизировать вряд ли получится. Для примера реальная история с stm32l4r4zi и попыткой найти DMAMUX в svd файле:
с момента публикации прошло полгода, исправления так и не было… за
это время были найдены ещё несколько ошибок в этом файле.
Как по мне, в данном подходе есть необходимость помнить какие биты надо ставить и как они переопределены программистом.
Пользовался подобным описание для регистров внешних чипов, тот же акселерометр например. Не очень удобно оказалось. Особенно когда коллега перепутал порядок бит при описании регистров…
первый раз такое встречаю за свою практику, поэтому хочу больше подробностей знать)
они ж итак стартапе описаны с этим атрибутом.
и да, маленькая очепятка у Вас:
EXTI->EMR &= ~EXTI_IMR_MR7;
EXTI->IMR &= ~EXTI_IMR_MR7;
явно должно быть:
EXTI->EMR &= ~EXTI_EMR_MR7;
не смертельно, так как маски в данном случае одинаковы, но внимательности это не отменяет.
Smallest, most flexible automotive modules supporting Wi-Fi 802.11ac at 105 °C
Dual band Wi‑Fi 2.4 GHz and 5 GHz 802.11a/b/g/n/ac
Dual‑mode Bluetooth 5 (Bluetooth BR/EDR and Low Energy)
Supports operation at 105 ° C
Simultaneous access point (AP), station (STA), or Wi‑Fi Direct (P2P)
Optimized for parallel operation of Wi‑Fi and Bluetooth
www.u-blox.com/en/product/jody-w2-series#tab-product-selection
активно читаю данные статьи, не все понятно, но я пытаюсь. И вроде все хорошо, но хотелось бы чуть больше менее абстрактных примеров. Ну запись в регистры, ну много разных методов. Разнообразие это хорошо, но меня пока и мой подход устаивает.
А будет расмотрено что более сложное, чем запись в регистры? Например описание реализации класса по работе, скажем с I2C акселерометром. На чистом Си я знаю как это будет выглядеть, на С++ примерно. Там и наследование, и желание избежать лишенго кода, ибо на шине может быть и кто-то другой, да и разделенный доступ к ресурсу будет. Вот какие преимущества от использования С++ будут там?
Сам опыта в С++ имею крайне мало, да и то, из-за наличия желания повозится с GUI на QT
почему тогда не воcпользоваться #ifndef… #endif для того чтобы исключать не нужные строки? зачем пользователя то заставлять лазить в код, искать и комметировать строки? Вроде ж очевидное решение и прямо таки просится…
к короткому решению я шел долго… но когда его увидел, даже растроился. как-то оно очевидно при должном внимании
но опять же, смотрите. Вот выставили мы например значение 00 в регистр. Это же не означает, что МК не сможет и не позволит вывести через данный пин сигнал в 40МГц. Меандр будет на выходе, но очень уж близкий к синусу. Если Вам нужно работать с цифровым интерфейсом, то это проблема. Вот и получается, что это не сколько частота работы (максимальная\разрешенная), сколько признак того насколько меандр выведенный с данного пина будет меандром.
я надеюсь Вы понимаете что я не пытаюсь придираться)
Из-за своего названия этот регистр много путаницы вносит в понимание работы такого просто модуля, как GPIO.
как правило заголовочники можно вытащить из IDE, которая пользуется отдельными паками для вендоров (Keil/Segger Embedded Studio например), ну или выкачивая монструозные библиотеки HAL\LL на все семейство.
тут не совсем так, скорее даже совсем не так. Порт как работал со «скоростью» шины AHB так и будет работать. Регистр OSPEEDR определяет скорость нарастания фронта на выводе настроенном как выход. Кстати, в более новых поделиях этой фирмы, они заменили конкретные цифры на абстракции вида VeryLow\Low\Medium\High или их вариации.
я наверно Вас удивлю сейчас, но для некоторых МК st не то что не описали перечисления, они некоторые периферийные модули забыли описать. Так что полностью автоматизировать вряд ли получится. Для примера реальная история с stm32l4r4zi и попыткой найти DMAMUX в svd файле:
с момента публикации прошло полгода, исправления так и не было… за
это время были найдены ещё несколько ошибок в этом файле.