Stm32 с чего начать изучение...

dosikus

Тыкаясь в спл а тем более в калокубе, вы ничего не осознаете.
А сие

Библиотеки SPL и HAL позволяют разрабатывать программы без необходимости изучения МК на уровне регистров.

Мягко говоря лукавство, а по большому счету - ложь.

Для 103ьих - по умолчанию тактирование всей периферии выключено.
За это отвечает домен RCC Reset and Clock Control[/b]

Открываем даташит , ищем диаграмму STM32F103xx performance line block diagram
Где указано на какой шине какая периферия висит.
GPIOC на APB2.
Идем читать RM .
Ищем регистры RCC, конкретно RCC_APB2ENR. (APB2 ENable Registr)

Имена регистров образуются так - домен _ имя регистра .
Так же образуются имена бит регистров домен_ имя регистра _ имя бита
Это и есть стандарт CMSIS, и по этому стандарту прописаны и регистры и биты в хэдере.

Таким образом бит отвечающий за включение GPIOC - RCC_APB2ENR_IOPCEN

Ну и включаем GPIOC :

RCC->APB2ENR |=RCC_APB2ENR_IOPCEN;

Таким образом даже не нужно знать значение RCC_APB2ENR_IOPCEN, но если приспичит - все они прописаны в хэдере.

Реклама

СЦБист

полюбасу надо смотреть описание регистров.

пока я только вникаю в принципы построения этих структур.

пока выяснил что каждая структура связанна с конкретной картой регистров.

в карте может быть куча регистров.

эти регистры карты и есть поля структуры.

структура для портов как я понял.

Код: Выделить всё

typedef struct
{
  __IO uint32_t CRL;
  __IO uint32_t CRH;
  __IO uint32_t IDR;
  __IO uint32_t ODR;
  __IO uint32_t BSRR;
  __IO uint32_t BRR;
  __IO uint32_t LCKR;
} GPIO_TypeDef;

Реклама

Мурик

dosikus, программу можно написать используя библиотеки SPL или HAL и только при необходимости напрямую обращаясь к регистрам. Так что никакой лжи в моих словах нет.

СЦБист писал(а):я пошел дальше и пришел к такой структуре

Найти эту структуру можно парой кликов мышкой.

ПКМ по RCC и в меню выбрать "Найти объявление". Откроется файл stm32f10x.h со строкой

Код: Выделить всё

#define RCC                 ((RCC_TypeDef *) RCC_BASE)

Далее проделываем тоже самое кликнув по RCC_TypeDef и смотрим структуру в файле stm32f10x.h.

Чтобы было меньше вопросов по устройству МК нужно хотя бы поверхностно ознакомится с ядром ARM Cortex-M. Из литературы на русском можно посмотреть "Мартин М. Инсайдерское руководство по STM32".

СЦБист

хорошо бы иметь набор описаний функций. c примерами

к примеру функции для работы с портами , ацп и т.д.

а не так как в заголовочных все смешано.

кто то встречал подобное на других форумах ?

_____

нужно ли знать работу библиотечных функций , а именно работу начинки ?

в обычных языках этой хе..ей не занимался.

Реклама

dosikus

"Программу" можно на тыкать и в аурдунье.
Эффективно работать с железом через спл и калокуб нельзя.
СЦБист, насколько я понимаю, хочет именно эффективно работать, а не копипастить чужие куски кода, непонятно как сляпанные.
Вся прелесть стм в периферии , периферии не настолько сложной чтобы закрываться от нее сплней и калокубом.

СЦБист, я уже писал - проштудируйте сниппетсы для F0 а так же примеры кода в RM . И лучше вААще начните сразу с F0 .

Да и какие вам примеры нужны? Для SPI , UART я здесь уже выкладывал.

Реклама

Мурик

СЦБист писал(а):хорошо бы иметь набор описаний функций. c примерами

В сети мало примеров?

Пробовали искать?
Нужно уметь самостоятельно находить нужную информацию, иначе никак!

dosikus писал(а):"Программу" можно на тыкать и в аурдунье.

Ардуина дороже и начинка в ней (ATmega) оставляет желать лучшего.

Реклама

СЦБист

Я имел ввиду примеры применений конкретной функции из библиотеки.

ну типо что-то этого

http://www.cplusplus.com/reference/cstdlib/rand/

в заголовках есть описание функций но нету примера их применения.

нету нюансов и т.д.

lazarev

СЦБист писал(а):структура для портов как я понял.
Код: Выделить всё
typedef struct
{
  __IO uint32_t CRL;
  __IO uint32_t CRH;
  __IO uint32_t IDR;
  __IO uint32_t ODR;
  __IO uint32_t BSRR;
  __IO uint32_t BRR;
  __IO uint32_t LCKR;
} GPIO_TypeDef;

Ну без reference manual обойтись сложно, все таки там детально описаны все значения флагов управления, но можно и по SPL хеадерам.
Для каждой фичи МК, есть своя собственная структура типа <фичя>_TypeDef, ну и поинтеры ADC1, ADC2, TIMx, ..., GPIOx,в большинстве случаев эта структура хорошо описана уже в хеадере, так само как и все возможные параметры к ней которые можно найти по названию регистра,
например, для включения таймена #2 нужно установить бит CEN в TIM_CR1 в поинтере TIM2 со структорой TIM_TypeDef, а параметры к нему можно найти в хеадере по префиксу TIM_CR1_<имя нужного бита>

Код: Выделить всё

TIM2->CR1 |= TIM_CR1_CEN

, хотя такой метод з хеадерами не всигда прокатит для регистров с длинной больше одного бита:

Спойлер

lazarev

СЦБист писал(а):Я имел ввиду примеры применений конкретной функции из библиотеки.

ну типо что-то этого

http://www.cplusplus.com/reference/cstdlib/rand/

в заголовках есть описание функций но нету примера их применения.

нету нюансов и т.д.

Возможно Вам нужно что то вроде UM1061 - Description of STM32F2xx Standard Peripheral Library

Спойлер

СЦБист

lazarev писал(а):[q
Возможно Вам нужно что то вроде UM1061 - Description of STM32F2xx Standard Peripheral Library
Спойлер

да, это похоже на то что мне надо.

где скачать этот пдф не подскажите, буду признателен за помощь...

http://cxem.net/mc/mc133.php
тут нашел описание на несколько функций, но шибко жиденькое.

lazarev

СЦБист писал(а):где скачать этот пдф не подскажите, буду признателен за помощь...

UM1061 или тут

СЦБист писал(а):http://cxem.net/mc/mc133.php
тут нашел описание на несколько функций, но шибко жиденькое.

о, так это ж перевод первых страниц сUM1061

Мурик

СЦБист писал(а):да, это похоже на то что мне надо.

Описание почти аналогичное тому что в SPL.

Код: Выделить всё

/**
  * @brief  Initializes the ADCx peripheral according to the specified parameters
  *         in the ADC_InitStruct.
  * @param  ADCx: where x can be 1, 2 or 3 to select the ADC peripheral.
  * @param  ADC_InitStruct: pointer to an ADC_InitTypeDef structure that contains
  *         the configuration information for the specified ADC peripheral.
  * @retval None
  */
void ADC_Init(ADC_TypeDef* ADCx, ADC_InitTypeDef* ADC_InitStruct)

СЦБист

Нужно ли знать , как реализована начинка библиотечных функций ?

dosikus

СЦБист, работу периферии вам не объяснит ни мануал на спл ни калокуб . Не занимайтесь фигнёй как эти товарищи.
Что спл что калокуб содержат в себе примитивы аналоги софтодрочерства, в то время как периферия рассчитана на полную аппаратную работу.

Мурик

Знать желательно (чтобы понимать как устроена и работает функция), но не обязательно.

Это примерно как с WinAPI.

lazarev

СЦБист писал(а):Нужно ли знать , как реализована начинка библиотечных функций ?

Нет не обязательно, хотя вам никто не мешает

Например я никогда не использовал этот функционал, а только структуры и переменные с параметрами для регистров,
так получаеться бистреє, и меньше кода(если вам важна скорость)

dosikus

Они ниавные чукотские юноши считают, что в тех говнолибах, что они юзают реализован весь функционал, ну пусть так думают.
Теперь дело за вами, или вмести с ними гнить в ардуиновском болоте или плодотворно изучать платформу.

lazarev

Каждому свое, кому то больше по душе осознанность, лаконичность и быстродействие а кому то достаточно базового функционала с красивым конструктором с графическим интерфейсом, валидацией, менюшками, все возможными значениями, куда нужно вставить только бизнес логику:

Спойлер

Выглядит очень даже симпатиШно, но цена этому - куча шаблонного/ненужного кода, и бесполезных "проверок на дурака"

хотя наверное все рано или поздно приходят к истокам и "ручной" настройке...

Andrew Martin

Мурик писал(а):Это примерно как с WinAPI.

Да нет, не тот уровень. Это скорее как работа с драйвером устройства - нужно четко осознавать взаимодействие драйвера с железом, чтобы корректно посылать и обрабатывать запросы.
В Windows работа с железом через драйвера - это необходимость, и сделана по причине большой сложности и закрытости этого самого железа, и производитель согласен поставлять собственные драйвера лишь бы держать в тайне железо.
У STM32 же периферия простая, открытая и хорошо задокументирована, поэтому и всякие HAL - это излишество.

Немного оффтопа ))
Сейчас время такое - все компании повышают уровень абстракции. На больших ОС поначалу драйвера, потом API, теперь вовсю толкают фреймворки, чтобы как можно больше изолировать разработчика от железа. Это компаниям выгодно, поскольку позволяет со временем совсем закрывать для разработчиков низкоуровневый доступ. Скажем, если львиная доля программистов в мире полностью пересядут на дотнет, то это позволит мелкомягким изменять нижележащую Windows как им заблагорассудится. Вот перепишут начисто API и закроют MSDN, сделают её конфиденциальной и платной - тогда хорошо будет? Не думаю.
Такая же "голубая" мечта и у STM - закрыть прямой доступ к периферии. Это им выгодно. Дадут вам в зубы корявый индийский HAL - и радуйтесь.

Мурик

Andrew Martin писал(а):мечта и у STM - закрыть прямой доступ к периферии

Смысл? Многие сменят производителя МК и уровень продаж у ST уменьшится. Им это нужно?