STM32 новичку в ARM что к чему

ARV

вот только что убедился, что при питании 3.2-3.3 вольта контроллер работает, а при 3.4 - уже нет. Хотя по даташиту вроде же +0,5В от нормы может быть... или не может?

По даташиту норма - до 3.6V и, естественно, там все с запасом.

где-то явно соврали... 3,4 в не работает, 3,3в работает... Факт. День убил на выяснение.

Добавлено after 2 minutes 31 second:

tonyk писал(а):

ARV писал(а):

в итоге от источника питания за 50 рублей пришлось отказаться в пользу источника питания за 300.

Наверно, вам лучше вернуться к AVR из-за неспособности читать, изучать новое и думать:
https://www.promelec.ru/product/206989/
Зато очень быстро умеете тыкать кнопки в Кубе.

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

Реклама

smacorp

Как-то странно взрослому и опытному человеку "обвинять и жаловаться" на что-то, что такое, какое оно есть и другим быть не может. Никто ведь не будет жаловаться на ребёнка за то, что он такой нежный, хрупкий и не может жрать чипсы и водку взрослую еду. Вы или "терпите" детей, или объявляете себя чайлдфри. Не нравятся STM32, не используете их, а если вынуждены использовать по работе, тогда просто приноравливайтесь.

Лично у меня STM32 выходили из строя только при скачках питания выше 4.1V, что полностью соответствует даташиту, а до этого напряжения работали нормально.

Мало того, имею бракованный F103C8T6, потребляющий под 300 мА и греющийся больше 70 градусов, но, опять же, отлично выполняющий свои функции, если не ужасаться температуре корпуса.

Реклама

Уош

И всё же, у меня тоже такое ощущение, что прошлый период был как-то более пофигистичный к ошибочным телодвижениям. Причём, во всём. А сейчас без ESD-диодов - фу, пайка свинцом - фу, всё как-то не так, всё фу, если не поставил то, сё, не измерил еср и не вымыл руки, прежде чем вообще трогать. Ну, особых проблем действительно не создаёт, но ощущение, схожее с высказанным ARV, у меня давно есть.

Что касается питания, то, наверное, этот экземпляр отбраковка какая-нить или подделка. Их же ща полно.

ARV

Может и подделка, кто ж их различит?! И они не выходят из строя, они просто не стартуют или зависают при 3,4в питания... И выяснить невозможно, что с ними происходит... Но если привести питание к 3,3 - все стартует и работает. Этакий BOD наоборот

Добавлено after 2 minutes 35 seconds:
Может, из моей нелюбви копаться в даташитах я пропустил важное, и нынче в stm32 есть "оконный" BOR?!

Реклама

В продаже новые LED-драйверы XLC компании MEAN WELL с диммингом нового поколения

Компания MEAN WELL пополнила ассортимент своей широкой линейки светодиодных драйверов новым семейством XLC для внутреннего освещения. Главное отличие – поддержка широкого спектра проводных и беспроводных технологий диммирования. Новинки представлены в MEANWELL.market моделями с мощностями 25 Вт, 40 Вт и 60 Вт. В линейке есть модели, работающие как в режиме стабилизации тока (СС), так и в режиме стабилизации напряжения (CV) значением 12, 24 и 48 В.

Подробнее>>

jcxz

ARV писал(а):

Чем больше я погружаюсь в пучину stm32, тем сильнее я утверждаюсь в мнении, что это контроллеры для тепличных условий. Пины не перегрузи, питание не превысь, от помех защити...
...
помню AVR: налаживаешь что-нибудь, и вдруг чуешь - воняет что-то... трогаешь МК - он кипяток, аж канифоль дымится (утрирую) - батюшки! да я на него 7 вольт подал! выключил, остудил, подал 5 вольт и пошел дальше работать... как ни в чем ни бывало.

Те кто строил ещё ламповые схемы, то же самое говорили про ваши AVR: "Налаживаю что-нить; вдруг чую - палёными тараканами воняет, и припой с платы капает... батюшки! - на сетку подал 300V вместо положенных 100V!! выключил, остудил, припой затвердел, включил - работает. А ваш AVR уже давно бы растёкся тонким слоем по плате." :)))

Добавлено after 2 minutes 58 seconds:

ARV писал(а):

3,4 в не работает, 3,3в работает... Факт. День убил на выяснение.

Может стоит поменять свой мультиметр? Или хотя-бы отдать его на проверку?

Реклама

tonyk

ARV писал(а):

стоило бы поинтересоваться условиями, в которых было принято решение о выборе ИП

Условий озвучено не было, но после бреда про 3.4В оставалось только дать ссылку на LDO.

Реклама

Распродажа паяльного оборудования ATTEN!
Паяльные станции, паяльники и аксессуары по самой выгодной цене.

По промокоду radiokot скидка 10%

a5021

В пятничный вечер -- самое время заняться чем-нибудь сомнительным. :-)

Первый подход -- компактный макрос задержки на систике:

Код:

#define GET_TICK()    (SysTick->CTRL >> SysTick_CTRL_COUNTFLAG_Pos)
#define DELAY_MS(MS)  for (unsigned _ = (SysTick->CTRL, (MS)); _; _ -= GET_TICK()) (void)0

Код для проверки (считаем, что SysTick проинициализирован на 1 мс внутри init()):

Код:

int main(void) {

  init();

  for(;;) {
    GPIOC->BSRR = GPIO_BSRR_BR13;
    DELAY_MS(500);
    GPIOC->BSRR = GPIO_BSRR_BS13;
    DELAY_MS(500);
  }
 
} /* main() */

смотрим, во что это превращает компилятор (GCC 14.2):

Код:

 080001DE   MOV.W          R1, #0x20000000
for(;;) {
GPIOC->BSRR = GPIO_BSRR_BR13;
 080001E2   STR            R1, [R5, #16]
DELAY_MS(500);
 080001E4   LDR            R3, [R4, #16]
 080001E6   MOV.W          R3, #0x01F4
 080001EA   LDR            R2, [R4, #16]
 080001EC   SUBS.W         R3, R3, R2, LSR #16
 080001F0   BNE            0x080001EA                    ; <main>+0x52
GPIOC->BSRR = GPIO_BSRR_BS13;
 080001F2   STR            R6, [R5, #16]
DELAY_MS(500);
 080001F4   LDR            R3, [R4, #16]
 080001F6   MOV.W          R3, #0x01F4
 080001FA   LDR            R2, [R4, #16]
 080001FC   SUBS.W         R3, R3, R2, LSR #16
 08000200   BEQ            0x080001E2                    ; <main>+0x4A
 08000202   B              0x080001FA                    ; <main>+0x62

На мой взгляд и придраться не к чему. А на ваш?

VladislavS

a5021 писал(а):

А на ваш?

Будьте проще.

Код:

static void Delay(uint32_t ms)
{
  SysTick->CTRL;
  while(ms) ms -= SysTick->CTRL >> SysTick_CTRL_COUNTFLAG_Pos;
}

Только без инициализации счётчика таймера точность этого плюс-минус трамвайная остановка.

a5021

VladislavS писал(а):

Будьте проще.

интриги нет.

VladislavS писал(а):

Только без инициализации счётчика таймера точность этого плюс-минус трамвайная остановка.

органолептически отличить одну миллисекунду от двух проблематично. стало быть, точность приемлема :-)

Реклама

VladislavS

А одну от нуля?

Вот так хоть корректно будет. А разница одна ассемблерная команда.

Код:

static void Delay(uint32_t ms)
{
  if(ms>0)
  {  
    SysTick->VAL = SysTick->LOAD;
    while(ms -= SysTick->CTRL >> SysTick_CTRL_COUNTFLAG_Pos);
  }
}

a5021

надо еще SysTick на NULL проверять. а то мало ли..

VladislavS

Проверку ms на ноль компилятор уберёт в случае задания задержки константной. А вот если задержка в рантайме меняется, то эта проверка уже абсолютно необходима. А если ещё и прерывания поверху работают...

a5021

если 0 прилетел в дилей, то это само по себе проблема похлеще, чем отсутствие проверки.

VladislavS

Почему вы исключаете нулевую задержку?

a5021

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

VladislavS

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

ARV

Всё-таки двойные стандарты... HAL ругают за избыточность, а ведь там всего лишь все "функции", не задумываясь, проверяют все-все-все на допустимость...

HardWareMan

ARV писал(а):

Всё-таки двойные стандарты... HAL ругают за избыточность, а ведь там всего лишь все "функции", не задумываясь, проверяют все-все-все на допустимость...

Ну ассерты там не просто так сделаны. В некоторых местах плохие входные данные действительно могут порушить всё. Учитывая, что HAL рассчитан на всех, даже на начинающих глупцов - лучше перестраховаться.

VladislavS

ARV писал(а):

Всё-таки двойные стандарты... HAL ругают за избыточность, а ведь там всего лишь все "функции", не задумываясь, проверяют все-все-все на допустимость...

Причём тут проверка на допустимость? Функция должна правильно работать при всех значениях, которые можно подать ей на вход. Правильная работа функции это главное. Оптимизация это последний шаг. Вон a5021 дооптимизировался - наплевал на инициализацию счётчика и получил, что задержка может скакать до 1 мс в минус.

Что вы собрались оптимизировать в функции, которая в блокирующем режиме ничего не делает? Одну ассемблерную команду зажали пожертвовав функционалом? Это проблема!

Можно, например, ограничить этой функции параметр на этапе компиляции, но так его нельзя будет менять в рантайме.

Код:

template <uint32_t ms>
void Delay()
{
  static_assert(ms>0, "Wrong ms");
  SysTick->VAL = SysTick->LOAD;
  auto ms_ = ms;
  while(ms_ -= SysTick->CTRL >> SysTick_CTRL_COUNTFLAG_Pos);
}

Мы сильно ограничили функционал и не приобрели ничего взамен, так как в константном применении компилятор сам бы выкинул проверку.

"Преждевременная оптимизация — корень всех зол " - Д.Кнут.

Добавлено after 37 minutes 1 second:
Кстати, в первоначальном варианте от a5021 эта проверка тоже есть, просто она не бросается в глаза. А когда я написал так чтобы она стала очевидна и при нуле работала быстрее это вызвало протест. Почему?

Код:

// Можно её скрыть так
static void Delay(uint32_t ms)
{
  SysTick->VAL = SysTick->LOAD;
  while(ms)
    ms -= SysTick->CTRL >> SysTick_CTRL_COUNTFLAG_Pos;
}

// Или так
static void Delay(uint32_t ms)
{
  SysTick->VAL = SysTick->LOAD;
  for(uint32_t i=ms; i; i -= SysTick->CTRL >> SysTick_CTRL_COUNTFLAG_Pos);
}

Для оптимизирующего компилятора это всё будет одно и то же.

Добавлено after 42 minutes 26 seconds:

a5021 писал(а):

Код:

DELAY_MS(500);
 080001E4   LDR            R3, [R4, #16]
 080001E6   MOV.W          R3, #0x01F4
 080001EA   LDR            R2, [R4, #16]
 080001EC   SUBS.W         R3, R3, R2, LSR #16
 080001F0   BNE            0x080001EA

На мой взгляд и придраться не к чему. А на ваш?

А на мой есть. Сложная 32-битная команда вычитания. Можно от неё избавиться.

Код:

static void Delay(uint32_t ms)
{
  if(ms>0)
  {  
    SysTick->VAL = SysTick->LOAD;
    while(ms -= *((volatile uint16_t *)&SysTick->CTRL+1) );
  }
}

Вложение:

изображение_2025-04-13_101757796.png [13.53 KiB]
Скачиваний: 294

a5021

VladislavS писал(а):

Вон a5021 дооптимизировался - наплевал на инициализацию счётчика и получил, что задержка может скакать до 1 мс в минус.

отставить буйные фантазии. определяется дизайном:

Разрешение: 1 мс
Средняя погрешность: ±0.5 мс
Максимальная погрешность: до +1 мс
Точность: достаточная для большинства прикладных задач, кроме чувствительных к микросекундам.

VladislavS писал(а):

Кстати, в первоначальном варианте от a5021 эта проверка тоже есть, просто она не бросается в глаза.

вы поэтому добавили бессмысленного коду, чтобы гарантированно бросалась?

VladislavS писал(а):

Сложная 32-битная команда вычитания. Можно от неё избавиться.

не выравненный доступ и загромождает.

VladislavS писал(а):

SysTick->VAL = SysTick->LOAD;

систик может использоваться шире и отдавать его только под задержки как-то не очень.

STM32 новичку в ARM что к чему

Кто сейчас на форуме