Форум РадиоКот

YS писал(а): Да не, фузы мы не трогали. Я говорю про само понимание процесса.

Я так понял, вы и сами не знаете, что такое CMSIS. Ну так я вам расскажу.

А пока не надо грузить его вещами, не относящимися к сути.

От которых у начинающего рябит в глазах.

Процесса чего... одурманивания?

YS писал(а):С опытом разработки это проходит.

А я продолжу свободно использовать любое из знакомых мне семейств по мере необходимости и осваивать новые. Вот продукцию NXP я еще не пробовал, и Stellaris от TI тоже...

Не проходит, а ПРИХОДИТ!

Ничего страшного в этих STM32 нет... все эти страшилки надуманные...

Даже с точки освоения NXP или Stellaris от TI... С чего легче будет переходить... с STM32 или Мега16??? То-то!!!

Вот продукцию NXP я еще не пробовал, и Stellaris от TI тоже

если так много времени пробовать, порекомендую попробовать еще микроконтроллеры Nuvoton Cortex™-M0

YS писал(а): Именно проходит. Когда-то я тоже считал, что AVR круче всего, как вы сейчас считаете, что STM32 круче всего - это было оттого, что я просто не знал ничего другого. Познакомился еще с пятком семейств - и стал относиться ко всему гораздо спокойнее...

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

А я говорил, что они страшные? Я только утверждаю, что они не слишком подходят для старта. Начинать можно и с них, просто если сразу взяться серьезно, начиная с нуля, мозг раскалится гораздо сильнее, чем если начать с MSP430/PIC или подобного.

На самом деле, если навык уже выработан, разницы нету.

Pavel_1978 писал(а):посмотрите цены на Дискавери STM32 или эта http://www.terraelectronica.ru/catalog_ ... DE=1318065 причем все имеют на борту отладчик программатор.

как выставить фусы что бы МК не навернулся ?

YS писал(а):

как выставить фусы что бы МК не навернулся ?

Лучше вообще их не трогайте, если не уверены, что это вам надо.

И вот тут почитайте, специально для таких случаев писал.

Сам код

Не поглядите в чем дело ?

#include <avr/io.h>
#include <util/delay.h>
#include <stdint.h>

#define LED1					(1<<PB1)
#define LED2					(1<<PB2)
#define LED3					(1<<PB3)
#define BUTTON_PIN				(1<<PD0)

#define ANIMATION_DELAY_MSEC	4000

#define ANIMATION_STOP			0
#define ANIMATION_FORWARD		1
#define ANIMATION_BACKWARD		2

static volatile uint8_t animation_type=ANIMATION_STOP;
static volatile uint8_t last_pind_state=0;

void main(void)
{
  DDRB=LED1 | LED2 | LED3;
  PORTB=LED1;
  DDRD=0;

  last_pind_state=PIND;

  while (1)
  {
	if (PIND!=last_pind_state)
	{
		if (PIND & BUTTON_PIN)
		{
			animation_type=ANIMATION_BACKWARD;
		}
		else
		{
			animation_type=ANIMATION_FORWARD;
		}

		last_pind_state=PIND;
	}

    if (animation_type == ANIMATION_FORWARD)
	{
		PORTB|=LED1;
		_delay_ms(ANIMATION_DELAY_MSEC);
		PORTB&=~LED1;
		PORTB|=LED2;
		_delay_ms(ANIMATION_DELAY_MSEC);
		PORTB&=~LED2;
		PORTB|=LED3;

		animation_type=ANIMATION_STOP;
	}
	
	if (animation_type == ANIMATION_BACKWARD)
	{
		PORTB|=LED3;
		_delay_ms(ANIMATION_DELAY_MSEC);
		PORTB&=~LED3;
		PORTB|=LED2;
		_delay_ms(ANIMATION_DELAY_MSEC);
		PORTB&=~LED2;
		PORTB|=LED1;

		animation_type=ANIMATION_STOP;
	}
  }
}

YS писал(а):Первое - использовать компиляторо-специфичные костыли вроде PORTB.x крайне не рекомендуется. Это плохой стиль. Следует использовать битовые операции и сдвиги.

unsigned char mask = LED1;
while(1){
   PORTC = mask;
   delay_ms(ANIMATION_DELAY_MSEC);
   if(PIND & BUTTON_PIN){
      mask <<= 1;
      if(mask > LED3) mask = LED1; 
   } else {
      mask >>= 1;
      if(mask==0) mask = LED3;
   }
}

а что же в вашем примере нет этих самых сдвигов?

если я верно понял, то нужен "бегущий огонь", меняющий направление в зависимости от состояния кнопки?

конечный автомат немножко притянут за уши...

Набросал вот такую схему...

Как наиболее надежно и наименее геморройно дать понять микроконтроллеру о наличии/отсутствии 12В. Проще говоря, необходимо врезаться в 12В проводку автомобиля и стырить оттуда наличие/отсутствие напруги в проводе.

Проблема, что у считающего МК не хватает ног для этого.