[Lmx2315 3]

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

 

всмысле миф - генерируемое не работает?

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

[_Pasha 0]

всмысле миф - генерируемое не работает?

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

Code generation is currently not iplemented

[MrYuran 21]

А дергать пинами - у меня лично такого уровня просто нет. У меня в board.h есть например "включить реле", а set-reset какой-то сферический пин - нету. :laughing:

++

В основном тексте не должно быть ни пинов, ни портов.

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

[Lmx2315 3]

Code generation is currently not iplemented

 

 

ничего не пойму, скачал эту прогу : "STM32 генератор кода" - выбираю фичи , снизу генерится код.

Код не рабочий?

 

 

[_Pasha 0]

ничего не пойму, скачал эту прогу : "STM32 генератор кода" - выбираю фичи , снизу генерится код.

Код не рабочий?

:cranky: Хде?

Version 2.2

Нету!

[Tahoe 0]

А вот с таймерами - уже засада. Или с АЦП.

Ну а в чем именно засада? Если хорошо продумать имена функций API, плюс самодисциплина, то работать будет для любого проца, с минимальными изменениями, хоть для AVR, хоть для STM32.

////////////////////////////////////////////////////////////////////////////////
// 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	);
}

Изменено 8 февраля, 2013 пользователем IgorKossak
[codebox] для длинного кода, [code] - для короткого!!!

[Golikov 0]

разницы между

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;

 

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

[_Pasha 0]

Ну а в чем именно засада?

Все правильно, только пространство методов надо сокращать до предела.

Я так понимаю, "хоть на AVR" - это означает, что там, где фича не отлита в железе, она либо тупо не поддерживается либо включается программная эмуляция, там где не внапряг по ресурсам.

И вот с таймерами - муки выбора - либо как у Вас, либо конкретно по областям применения - энкодер, хренсним, на авр зацепим прерывание, на пиках моторных - железный, на STM -железный. ШИМ для силовухи - то же самое. Каскадирование - там понятно, что эмуляция рулит.

Непонятна методология, может, карты какие-то ассоциативные составлять? Уж очень много вариантов.

С периферией очевидные вещи- {open, close, ioctl} - это легко, за счет инлайнов можно более не лезть в ДШ чтобы вспомнить, на какой шине оно сидит да что куда ремапится.

Еще делал типа get_pending_clock(void *sfr) - для периферии вернуть тактовую частоту той шины, где она сидит. Тоже инлайн.

Еще типа блочного устройства, но без хендлов dma_stream(void *dst, void *src, size_t size, size_t element_size) - чтобы само рулило кто у нас источник, кто приемник, накладные расходы есть.

 

Цель мсм такая:

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

 

Может, попробуем какие-то общие свойства выделить?

Изменено 8 февраля, 2013 пользователем _Pasha

[Tahoe 0]

Я так понимаю, "хоть на AVR" - это означает, что там, где фича не отлита в железе, она либо тупо не поддерживается либо включается программная эмуляция, там где не внапряг по ресурсам.

Примерно так. Только никакой эмуляции, как правило, нет. Если фичи нет, значит ее нет, "и никакие лекции не изменят этого соотношения сил, если каждый индивидуум в отдельности не будет постоянно тренироваться в шашк... то есть я хотел сказать в шахматы" (с). :)

 

И вот с таймерами - муки выбора - либо как у Вас, либо конкретно по областям применения - энкодер, хренсним, на авр зацепим прерывание, на пиках моторных - железный, на STM -железный. ШИМ для силовухи - то же самое. Каскадирование - там понятно, что эмуляция рулит.

Никаких мук. Даже странно, что этот вопрос поднимает тот, кто пишет на плюсах ( если не ошибаюсь :) ). Есть объект, у него есть свойства. Если объект "таймер", то причем тут энкодер? Энкодер, это отдельная сущность, совершенно отдельный объект. Как частный случай, подключеный с помощью "таймер". Ничем не отлиается, например, от работы с внешней ЕЕПРОМ. Абсолютно не важно, как эта ЕЕПРОМ подключена, через объект "SPI" или объект "I2C", адресация адресация и размерность данных самой ЕЕПРОМ от этого не меняются.

 

Может, попробуем какие-то общие свойства выделить?

Так см. мой пример, там именно по этому принципу сделано. Например, у таймера может быть, а может не быть канала Compare. Таймеру может требоваться, а может не требоваться инициализация ( в основном, как и другим объектам, включить/выключить системный клок, в AVR или MSP430 это не требуется ). Потому все и разбито на блоки.

Кроме того, не следует пытаться запихнуть в AVR-таймер все фичи, доступные STM32-таймеру. Описания свойств таймеров у меня не отличаются, просто среди аргументов McuTmrConfig() какие-то есть, каких-то нет, это не трагедия.

 

Еще предостерегу от попытки написать супер-пупер универсальный код, что бы прям можно было переносить копи-пастом из проекта AVR в проект LPC17xx. Этого не требуется и лишь усложнит дело. Достаточно просто иметь единообразные названия функций, с максимально типизированными аргументами.

[Golikov 0]

сдается мне что писать код который учитывает особенности реализации типа есть клок на шине и нет - тоже не особо нужно.

Очень много времени тратиться на такие функции, они становятся большими, с кучами дефайнов и ифдефов, а в итоге что?

 

включаешь ее и думаешь, а правильно ли она сработает, точно все проинититься как надо? все флажки расставил?

[Tahoe 0]

включаешь ее и думаешь, а правильно ли она сработает, точно все проинититься как надо? все флажки расставил?

+1 :)

[SyncLair 0]

разницы между

set_port("D","7")

и

PORTD->OUT |= (1<<7)

нету, что вы одно слово заменили на другое, а понятную всем кто занимается программированием операцию заменили словом, это все пустое, это шелуха которая не нужна.

 

Определитесь зачем вы это делаете?

 

Я пытаюсь сделать чуть по-другому

 

в bsp_board_def.h определяю ножку в виде дефайна, а затем

ставлю SET_PIN(LED_PIN) и CLEAR_PIN(LED_PIN) соотвественно получается некоторая "ПЛАТОПЕРЕНОСИМОСТЬ"

 

 

[Rash 0]

Сам юзаю 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);
}

 

[HHIMERA 0]

ставлю SET_PIN(LED_PIN) и CLEAR_PIN(LED_PIN) соотвественно получается некоторая "ПЛАТОПЕРЕНОСИМОСТЬ"

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

В случае малейшей ошибки, после двух-трёх бессоных ночей, у вас глаза откажут от всех этих повсеместных SET_PIN, CLEAR_PIN, SET_BIT и CLEAR_BIT... а вместе с ними и мозг...

[_Pasha 0]

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

Совершенно ага!

Если в параметрах будет const (разрулить возможные обращения по записи) - то на выходе получим минимум миниморум. Посмотрите на lib_at91samxxxxxxx.h

 

 

Никаких мук. Даже странно, что этот вопрос поднимает тот, кто пишет на плюсах ( если не ошибаюсь :) ).

Не-не, я на плюсах ни-ни :)

Как только умрет последний PIC18, - тогда да.