| |
|
  |
 давайте делится удобными дефайнами для stm32f10x |
|
|
|
|
 Feb 8 2013, 11:44
|
Местный
Группа: Свой
Сообщений: 459
Регистрация: 30-03-06
Из: Москва
Пользователь №: 15 600
|
Цитата(_Pasha @ Feb 7 2013, 18:11)  А вот с таймерами - уже засада. Или с АЦП. Ну а в чем именно засада? Если хорошо продумать имена функций API, плюс самодисциплина, то работать будет для любого проца, с минимальными изменениями, хоть для AVR, хоть для STM32. CODE ////////////////////////////////////////////////////////////////////////////////
// USER INTERFACE //////////////////////////////////////////////////////////////
////////////////////////////////////////////////////////////////////////////////
void BspUifInit( void )
{
////////////////////////////////////////////////////////////////////////////
McuTmrInit( BSP_TMR_UIF );
McuTmrConfig( BSP_TMR_UIF,
MCU_TMR_TCKINT_DIV_1,
MCU_TMR_PRELOAD_ENABLE,
//MCU_TMR_MODE_UP_NONSTOP,
MCU_TMR_MODE_UP_ONESHOT,
MCU_TMR_UPDT_RQST_SRC_CNT_ONLY );
McuTmrPrescalerSet( BSP_TMR_UIF,
BSP_MCLK_HZ / BSP_TMR_UIF_CLK_HZ );
McuTmrPeriodSet( BSP_TMR_UIF,
BSP_TMR_UIF_PERIOD_LONG_TCKS );
////////////////////////////////////////////////////////////////////////////
McuTmrCompareConfig( BSP_TMR_UIF,
BSP_TMR_CHNL_LEDR,
MCU_TMR_CMPR_CLEAR_BY_ETRF_DISABLE,
MCU_TMR_CMPR_MODE_PWM_POSITIVE,
MCU_TMR_CMPR_PRELOAD_DISABLE,
MCU_TMR_CMPR_FAST_OUTPUT_DISABLE );
McuTmrCompareConfig( BSP_TMR_UIF,
BSP_TMR_CHNL_LEDB,
MCU_TMR_CMPR_CLEAR_BY_ETRF_DISABLE,
MCU_TMR_CMPR_MODE_PWM_POSITIVE,
MCU_TMR_CMPR_PRELOAD_DISABLE,
MCU_TMR_CMPR_FAST_OUTPUT_DISABLE );
McuTmrOutputConfig( BSP_TMR_UIF,
BSP_TMR_CHNL_LEDR,
MCU_TMR_OUT_P_NON_INVERTED,
MCU_TMR_OUT_N_DISABLE );
McuTmrOutputConfig( BSP_TMR_UIF,
BSP_TMR_CHNL_LEDB,
MCU_TMR_OUT_P_NON_INVERTED,
MCU_TMR_OUT_N_DISABLE );
McuTmrOutputsEnable( BSP_TMR_UIF );
McuTmrEnable( BSP_TMR_UIF );
////////////////////////////////////////////////////////////////////////////
McuPinConfig( BSP_PIN_LED_RED, MCU_PIN_MODE_OUT_PP_AF_2MHz );
McuPinConfig( BSP_PIN_LED_BLU, MCU_PIN_MODE_OUT_PP_AF_2MHz );
McuPinConfig( BSP_PIN_BEEP, MCU_PIN_MODE_OUT_PP_AF_2MHz );
}
Сообщение отредактировал IgorKossak - Feb 8 2013, 12:42
Причина редактирования: [codebox] для длинного кода, [code] - для короткого!!!
|
|
|
|
|
|
|
|
Feb 8 2013, 12:05
|
Гуру
Группа: Свой
Сообщений: 4 256
Регистрация: 17-02-06
Пользователь №: 14 454
|
разницы между
set_port("D","7")
и
PORTD->OUT |= (1<<7)
нету, что вы одно слово заменили на другое, а понятную всем кто занимается программированием операцию заменили словом, это все пустое, это шелуха которая не нужна.
Определитесь зачем вы это делаете? Если чтобы самому было удобно читать, то потратите времени больше чем на привыкание к определенному семейству процов. Увеличить читаемость кода? не увеличите. Добавить гибкости и переносимости коду? - сто пудово нет. В новой плате поменяют ножку на которой висел диод - и до свидания, или же правда через год откроете свой код и будите искать кто зажег диод.
если вы в своей программе сделаете
TEST_LED_ON (PORTD->OUT |= (1<<7))
TEST_LED_OFF (PORTD->OUT &= (~(1<<7)))
вот это уже имеет смысл.
1. понятно что происходит.
2. при смене проца или переразводке платы, меняете макрос и все едет дальше как и было. Логика програмы сохраняется функционал остается.
Я лично всегда делю проект на то что зависит от проца и конкретной схемы и что не зависит.
В вашем примере с диодом, я бы сделал макрос на мигание как показано выше в отдельном файле тестовые диоды или что-то типа того.
объявил бы константу #define TEST_LED_PIN (1<<7)
а порт бы инициализировал в общей для всего проца функции
PORTD->DIR |= TEST_LED_PIN;
потому что изменений при смене проца или разводки в данном случае столько же сколько при добавленных макросах инициализации и так далее, но макросы писать не надо, то есть выигрыш имеется.
|
|
|
|
|
|
|
|
Feb 8 2013, 12:07
|
;
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509
|
Цитата(Tahoe @ Feb 8 2013, 15:44) Ну а в чем именно засада? Все правильно, только пространство методов надо сокращать до предела. Я так понимаю, "хоть на AVR" - это означает, что там, где фича не отлита в железе, она либо тупо не поддерживается либо включается программная эмуляция, там где не внапряг по ресурсам. И вот с таймерами - муки выбора - либо как у Вас, либо конкретно по областям применения - энкодер, хренсним, на авр зацепим прерывание, на пиках моторных - железный, на STM -железный. ШИМ для силовухи - то же самое. Каскадирование - там понятно, что эмуляция рулит. Непонятна методология, может, карты какие-то ассоциативные составлять? Уж очень много вариантов. С периферией очевидные вещи- {open, close, ioctl} - это легко, за счет инлайнов можно более не лезть в ДШ чтобы вспомнить, на какой шине оно сидит да что куда ремапится. Еще делал типа get_pending_clock(void *sfr) - для периферии вернуть тактовую частоту той шины, где она сидит. Тоже инлайн. Еще типа блочного устройства, но без хендлов dma_stream(void *dst, void *src, size_t size, size_t element_size) - чтобы само рулило кто у нас источник, кто приемник, накладные расходы есть. Цель мсм такая: чтобы можно было быстро что-то опробовать, без лишней писанины, но и без сильной специализации. и не лазать в книжку каждую секунду. Может, попробуем какие-то общие свойства выделить?
Сообщение отредактировал _Pasha - Feb 8 2013, 12:10
|
|
|
|
|
|
|
|
Feb 8 2013, 12:29
|
Местный
Группа: Свой
Сообщений: 459
Регистрация: 30-03-06
Из: Москва
Пользователь №: 15 600
|
Цитата(_Pasha @ Feb 8 2013, 16:07) Я так понимаю, "хоть на AVR" - это означает, что там, где фича не отлита в железе, она либо тупо не поддерживается либо включается программная эмуляция, там где не внапряг по ресурсам. Примерно так. Только никакой эмуляции, как правило, нет. Если фичи нет, значит ее нет, "и никакие лекции не изменят этого соотношения сил, если каждый индивидуум в отдельности не будет постоянно тренироваться в шашк... то есть я хотел сказать в шахматы" (с).  Цитата(_Pasha @ Feb 8 2013, 16:07) И вот с таймерами - муки выбора - либо как у Вас, либо конкретно по областям применения - энкодер, хренсним, на авр зацепим прерывание, на пиках моторных - железный, на STM -железный. ШИМ для силовухи - то же самое. Каскадирование - там понятно, что эмуляция рулит. Никаких мук. Даже странно, что этот вопрос поднимает тот, кто пишет на плюсах ( если не ошибаюсь ). Есть объект, у него есть свойства. Если объект "таймер", то причем тут энкодер? Энкодер, это отдельная сущность, совершенно отдельный объект. Как частный случай, подключеный с помощью "таймер". Ничем не отлиается, например, от работы с внешней ЕЕПРОМ. Абсолютно не важно, как эта ЕЕПРОМ подключена, через объект "SPI" или объект "I2C", адресация адресация и размерность данных самой ЕЕПРОМ от этого не меняются. Цитата(_Pasha @ Feb 8 2013, 16:07) Может, попробуем какие-то общие свойства выделить? Так см. мой пример, там именно по этому принципу сделано. Например, у таймера может быть, а может не быть канала Compare. Таймеру может требоваться, а может не требоваться инициализация ( в основном, как и другим объектам, включить/выключить системный клок, в AVR или MSP430 это не требуется ). Потому все и разбито на блоки. Кроме того, не следует пытаться запихнуть в AVR-таймер все фичи, доступные STM32-таймеру. Описания свойств таймеров у меня не отличаются, просто среди аргументов McuTmrConfig() какие-то есть, каких-то нет, это не трагедия. Еще предостерегу от попытки написать супер-пупер универсальный код, что бы прям можно было переносить копи-пастом из проекта AVR в проект LPC17xx. Этого не требуется и лишь усложнит дело. Достаточно просто иметь единообразные названия функций, с максимально типизированными аргументами.
|
|
|
|
|
|
|
|
Feb 8 2013, 13:32
|
Местный
Группа: Свой
Сообщений: 209
Регистрация: 6-01-12
Пользователь №: 69 197
|
Цитата(Golikov A. @ Feb 8 2013, 16:05) разницы между
set_port("D","7")
и
PORTD->OUT |= (1<<7)
нету, что вы одно слово заменили на другое, а понятную всем кто занимается программированием операцию заменили словом, это все пустое, это шелуха которая не нужна.
Определитесь зачем вы это делаете? Я пытаюсь сделать чуть по-другому в bsp_board_def.h определяю ножку в виде дефайна, а затем ставлю SET_PIN(LED_PIN) и CLEAR_PIN(LED_PIN) соотвественно получается некоторая "ПЛАТОПЕРЕНОСИМОСТЬ"
--------------------
|
|
|
|
|
|
|
|
Feb 8 2013, 13:50
|
Знающий
Группа: Свой
Сообщений: 639
Регистрация: 5-09-05
Пользователь №: 8 231
|
Сам юзаю StdLib от STM, для инициализации вполне нормальная вещь (инициализация делается один раз скорости хватит даже на 1МГц работы), а для обработки использую уже регистры найденные в той же StdLib. Но пришла мысля, если эти же ф-ции для чтения записи периферии, перемести в H файл и заинлайнить, то компилятор должен их встроить, там где их вызывают, т.е. получим макс. быстродействие равное записи напрямую в регистр. например ф-ции из С файла Код uint16_t USART_ReceiveData(USART_TypeDef* USARTx)
{
/* Check the parameters */
assert_param(IS_USART_ALL_PERIPH(USARTx));
/* Receive Data */
return (uint16_t)(USARTx->DR & (uint16_t)0x01FF);
} делаем в h файле только Код inline uint16_t USART_ReceiveData(USART_TypeDef* USARTx)
{
/* Check the parameters */
assert_param(IS_USART_ALL_PERIPH(USARTx));
/* Receive Data */
return (uint16_t)(USARTx->DR & (uint16_t)0x01FF);
}
|
|
|
|
|
|
|
|
Feb 8 2013, 13:52
|
Местный
Группа: Участник
Сообщений: 226
Регистрация: 10-07-09
Пользователь №: 51 126
|
Цитата(SyncLair @ Feb 8 2013, 17:32) ставлю SET_PIN(LED_PIN) и CLEAR_PIN(LED_PIN) соотвественно получается некоторая "ПЛАТОПЕРЕНОСИМОСТЬ" Тут уже объясняли... что подобное не несёт никакой смысловой нагрузки... В случае малейшей ошибки, после двух-трёх бессоных ночей, у вас глаза откажут от всех этих повсеместных SET_PIN, CLEAR_PIN, SET_BIT и CLEAR_BIT... а вместе с ними и мозг...
|
|
|
|
|
|
|
|
Feb 8 2013, 14:17
|
;
Группа: Участник
Сообщений: 5 646
Регистрация: 1-08-07
Пользователь №: 29 509
|
Цитата(Rash @ Feb 8 2013, 16:50) перемести в H файл и заинлайнить, то компилятор должен их встроить, там где их вызывают, т.е. получим макс. быстродействие равное записи напрямую в регистр. Совершенно ага! Если в параметрах будет const (разрулить возможные обращения по записи) - то на выходе получим минимум миниморум. Посмотрите на lib_at91samxxxxxxx.hЦитата(Tahoe @ Feb 8 2013, 15:29) Никаких мук. Даже странно, что этот вопрос поднимает тот, кто пишет на плюсах ( если не ошибаюсь ). Не-не, я на плюсах ни-ни Как только умрет последний PIC18, - тогда да.
|
|
|
|
|
|
|
|
5 чел. читают эту тему (гостей: 5, скрытых пользователей: 0)
Пользователей: 0
|
|
|
Хде? 
