[data_stack 0]

Идет процесс бурного изучения, возникает много вопросов, все вопросы мелкие, плодить темы не хочется

1. Вопрос по отладчику Keil. Есть массив указателей, который указывает на другие массивы:

unt8_t const* const strings[]
{
string1,
string2...
}

и где то объявлены сами массивы, в некоторый момент передается номер массива, который нужно прочитать. Возможно ли в этот момент посмотреть содержимое этого массива в отладчике?

2. Имеется 1 АЦП и несколько ног, с одной нужно снимать 12битные значения, со другой 8битные. Пересчитывать пропорцией?

3. Делаю библиотеку. Где по правильному хранить платформозависимые дефайны в h или в c файле

4. Дефайны пишем заглавными буквами, а на макросы это распространяется или нет? По сути это тоже дефайны?

5. Перед некоторыми функциями ставят знак нижнего подчеркивания, что это значит?

6. Почему в библиотеках не используют структуры? Например вместо

lcd_drawLine(x0, y0, x1, y1)

не написать

typedef struct
{
uint8_t x;
uint8_t y;
}point_t;
lcd_drawLine(pont_t start_point, pont_t end_point)

это же нагляднее?

[slavokhire5 0]

1. да, можете посмотреть содержимое памяти по адресу вашего массива. Одно из отладочных окошек должно называться "Memory", или как-то так. я не спец в кейле:)

2. считайте так, чтобы было понятно тем, кто будет в будущем ваш код читать

3. в большинстве случаев платформозависимые дефайны хранятся в *.h

4. на макросы распространяется тоже

5. нижнее подчеркивание обычно обозначает, что ф-ция зарезервирована какой-то стандартной либой. старайтесь в своих ф-циях не использовать нижнее подчеркивание в начале названия

6. возможно потому, что поля структуры придется заполнять перед вызовом ф-ции. итого n лишних строк кода

[LLLLLLLLLL 8]

Добавлю еще один мелкий ( но при этом большой ) вопрос.

 

Изучал функцию GPIO_Init из стандартной библиотеки STM32F0xx_StdPeriph_Driver.

 

Правильно ли я понимаю, что при помощи этой функции можно сделать только такие настройки:

 

1) По умолчанию все ноги - входы General-purpose

2) Ноги, перечисленные в строке структуры GPIO_InitStructure.GPIO_Pin становятся выходами

с одинаковыми параметрами, которые указаны в следующих строках структуры.

 

Если так, то вопрос, как сконфигурировать ноги порта, если там и входы разного типа ( General-purpose, аналоговые, с подтяжкой или без) и еще и выходы тоже разного типа?

 

Видел в англоязычных форумах более ручной способ конфигурирования, типа:

 

GPIOC-> MODER |= (GPIO_MODER_MODER8_0 | GPIO_MODER_MODER9_0) ;

 

Есть ли более подробные примеры? Среда - IAR 6.40

Изменено 29 ноября, 2015 пользователем =L.A.=

[aaarrr 69]

Если так, то вопрос, как сконфигурировать ноги порта, если там и входы разного типа ( General-purpose, аналоговые, с подтяжкой или без) и еще и выходы тоже разного типа?

Написать свой конфигуратор, например:

 typedef enum
 {
     GPM_INPUT    = 0,
     GPM_OUTPUT    = 1,
     GPM_AF        = 2,
     GPM_ANALOG    = 3,
 } GPIO_MODE;

 typedef enum
 {
     GPF_AF0        = 0,
     GPF_AF1        = 1,
     GPF_AF2        = 2,
     GPF_AF3        = 3,
     GPF_AF4        = 4,
     GPF_AF5        = 5,
     GPF_AF6        = 6,
     GPF_AF7        = 7,
     GPF_AF8        = 8,
     GPF_AF9        = 9,
     GPF_AF10    = 10,
     GPF_AF11    = 11,
     GPF_AF12    = 12,
     GPF_AF13    = 13,
     GPF_AF14    = 14,
     GPF_AF15    = 15,
 } GPIO_AF;

 typedef enum
 {
     GPT_PP        = 0,
     GPT_OD        = 1,
 } GPIO_TYPE;

 typedef enum
 {
     SPD_2M        = 0,
     SPD_25M        = 1,
     SPD_50M        = 2,
     SPD_100M    = 3,
 } GPIO_SPD;

 struct pin_mode
 {
     void        *port;
     char        pin;
     GPIO_MODE    mode;
     GPIO_AF        af;
     GPIO_TYPE    type;
     GPIO_SPD    speed;
 };

 void gpio_setup(const struct pin_mode *setup)
 {
     while(setup->port)
     {
         GPIO_TypeDef *port = (GPIO_TypeDef *)setup->port;

         port->MODER = (port->MODER & ~(3UL << setup->pin * 2)) |
             (setup->mode << setup->pin * 2);
         if(setup->mode == 2)    // Alternate function
         {
             int p = (setup->pin > 7) ? 1 : 0, n = setup->pin & 7;

             port->AFR[p] = (port->AFR[p] & ~(15UL << n * 4)) |
                 (setup->af << n * 4);
         }
         if(setup->type)
             port->OTYPER |= 1UL << setup->pin;
         else
             port->OTYPER &= ~(1UL << setup->pin);
         port->OSPEEDR = (port->OSPEEDR & ~(3UL << setup->pin * 2)) |
             (setup->speed << setup->pin * 2);
         setup++;
     }
 }

Вызов:

 const struct pin_mode ui_pins[] =
{
     {LED1, GPM_OUTPUT, GPF_AF0, GPT_PP},
     {LED2, GPM_OUTPUT, GPF_AF0, GPT_PP},

     {KEY, GPM_INPUT},

     NULL
};

gpio_setup(ui_pins);

Подтяжки добавить по аналогии с остальным.

[LLLLLLLLLL 8]

Есть ли более подробные примеры? Среда - IAR 6.40

 

Сам нашел пример: Удобная настройка GPIO портов

 

http://we.easyelectronics.ru/STM32/udobnay...pio-portov.html

 

Не указан только тип микроконтроллера.

 

Написать свой конфигуратор, например:

 typedef enum
 {
     GPM_INPUT    = 0,
     GPM_OUTPUT    = 1,
     GPM_AF        = 2,
     GPM_ANALOG    = 3,
 } GPIO_MODE;

 typedef enum
 {
     GPF_AF0        = 0,
     GPF_AF1        = 1,
     GPF_AF2        = 2,
     GPF_AF3        = 3,
     GPF_AF4        = 4,
     GPF_AF5        = 5,
     GPF_AF6        = 6,
     GPF_AF7        = 7,
     GPF_AF8        = 8,
     GPF_AF9        = 9,
     GPF_AF10    = 10,
     GPF_AF11    = 11,
     GPF_AF12    = 12,
     GPF_AF13    = 13,
     GPF_AF14    = 14,
     GPF_AF15    = 15,
 } GPIO_AF;

 typedef enum
 {
     GPT_PP        = 0,
     GPT_OD        = 1,
 } GPIO_TYPE;

 typedef enum
 {
     SPD_2M        = 0,
     SPD_25M        = 1,
     SPD_50M        = 2,
     SPD_100M    = 3,
 } GPIO_SPD;

 struct pin_mode
 {
     void        *port;
     char        pin;
     GPIO_MODE    mode;
     GPIO_AF        af;
     GPIO_TYPE    type;
     GPIO_SPD    speed;
 };

 void gpio_setup(const struct pin_mode *setup)
 {
     while(setup->port)
     {
         GPIO_TypeDef *port = (GPIO_TypeDef *)setup->port;

         port->MODER = (port->MODER & ~(3UL << setup->pin * 2)) |
             (setup->mode << setup->pin * 2);
         if(setup->mode == 2)    // Alternate function
         {
             int p = (setup->pin > 7) ? 1 : 0, n = setup->pin & 7;

             port->AFR[p] = (port->AFR[p] & ~(15UL << n * 4)) |
                 (setup->af << n * 4);
         }
         if(setup->type)
             port->OTYPER |= 1UL << setup->pin;
         else
             port->OTYPER &= ~(1UL << setup->pin);
         port->OSPEEDR = (port->OSPEEDR & ~(3UL << setup->pin * 2)) |
             (setup->speed << setup->pin * 2);
         setup++;
     }
 }

Вызов:

 const struct pin_mode ui_pins[] =
{
     {LED1, GPM_OUTPUT, GPF_AF0, GPT_PP},
     {LED2, GPM_OUTPUT, GPF_AF0, GPT_PP},

     {KEY, GPM_INPUT},

     NULL
};

gpio_setup(ui_pins);

Подтяжки добавить по аналогии с остальным.

 

 

Я так понимаю, это всё для отдельного вход/выхода? Выходит громоздко. К тому же в хидерах стандартной библиотеки многое уже объявлено и определено, зачем придумывать целиком свой код?

[aaarrr 69]

Я так понимаю, это всё для отдельного вход/выхода? Выходит громоздко. К тому же в хидерах стандартной библиотеки многое уже объявлено и определено, зачем придумывать целиком свой код?

Да, для каждого отдельного пина, затем они собираются в группы.

Громоздко? Не вижу смысла в современных реалиях экономить флеш, это не ATtiny.

Стандартную библиотеку не использую и никому не рекомендую.

[Herz 5]

Идет процесс бурного изучения, возникает много вопросов, все вопросы мелкие, плодить темы не хочется

Однако потрудитесь назвать тему более информативно, иначе она будет удалена.

Но если вопросов слишком много, то не лучше ли обратиться к литературе?

[slavokhire5 0]

Я за стандартные либы. Да, местами криво. Да, жрут. Но представьте, что вам достался чужой глючный проект с десятками тысяч строк кода, и все либы - велосипед...

[aaarrr 69]

Но представьте, что вам достался чужой глючный проект с десятками тысяч строк кода, и все либы - велосипед...

Если уж прямо десятки тысяч строк, то и доля "либ" в них будет невелика. И Вы не допускаете мысли, что "велосипед" может быть построен аккуратно и грамотно, в отличие от?

[slavokhire5 0]

Если написать свои библиотеки на всю переферию какого-то жирного стм32, то кода там будет ого-го. Велосипед может быть весьма хорош. А может и не быть. Допускаю переписывание части библиотек, только если не будет хватать производительности.

[aaarrr 69]

Вся ли периферия "жирного" STM32 используется в каждом изделии? Да и вообще она большей частью примитивна, за исключением USB, EMAC и, возможно, чего-нибудь еще. Зато посмотрите, сколько на этом форуме тем типа "стандартная USB CDC либа не отправляет пакеты с размером, кратным 64 байтам"! Куда уж тут говорить о производительности.

[jcxz 197]

Я за стандартные либы. Да, местами криво. Да, жрут. Но представьте, что вам достался чужой глючный проект с десятками тысяч строк кода, и все либы - велосипед...

Какие либы на десятки тысяч строк? Для периферии??? Чушь несёте.

Что там можно писать десятками тысяч строк? Вы мануал на периферию хоть раз открывали или только "либами" пользуетесь?

Работа практически с любой широкораспространённой периферией типа UART-ов, SPI, I2C, таймеров ... - десятки строк аппаратно-зависимого кода.

USB, Ethernet и некоторая другая - чуть побольше (к примеру в моём текущем проекте на LPC43xx в драйвере USB-device уровень работы с железом чуть больше 500строк).

 

PS: Ну если только "кодом" называть все дефайны определяющие регистры периферии и битовые поля в них, только тогда можно раздуть на десятки тысяч строк. Только это не код.

[data_stack 0]

Однако потрудитесь назвать тему более информативно, иначе она будет удалена.

Но если вопросов слишком много, то не лучше ли обратиться к литературе?

 

offtop mode = true

На вашем форуме не хватает такой темы, где можно сгрузить мелкие вопросы по STM32, работе с отладчиком, вопросам по оформлению кода. Этого нет в книгах. Я задал несколько не связанных вопросов, получил на них ответы, не понимаю что здесь необычного. Поверьте нигде больше я бы не нашел на них ответ. А вот нытье по поводу выбора инструментария и прочий флуд не нужен, дайте мне полномочия только на эту тему, я буду следить и чистить только ее, все будут довольны. Если я не прав, можно удалять тему, буду на каждый вопрос создавать отдельную тему.

offtop mode = false

 

 

 

[LLLLLLLLLL 8]

Еще небольшой вопросец. Есть такая штука "SysTick_Handler". Я проштудировал доки и не нашел ответа, какой таймер использует эта функция ? Это один из периферийных ( TIM1 ... TIM17 ) или дополнительный таймер из ядра?

[Сергей Борщ 123]

SysTick timer и использует. Из ядра. И его описание, соответственно, в описании ядра. Кстати, и вектор SysTick_Handler находится среди векторов ядра (всяких xxxAbort_Handler и т.п.).