[Arlleex 131]

39 минут назад, jcxz сказал:

Ну и в конце-концов - а кто выбирал МК? Не Вы ли сами?  Кто мешал выбрать другой МК?

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

Поэтому никаких STM8 тогда еще и не было, думаю. AVR и PIC были в самом ходу. Свежий вариант железки я сделал, разумеется, на народном STM32F103, которых за глаза в любом хлебобулочном магазине.
 

Цитата

Тот же STM8 (если речь об экономии)?

Нет, речь не об экономии: в электропоездах вообще мало на чем экономят, даже на массе. Я ссылаюсь на вот это

Цитата

Суперлупы - это тяжкое наследие абдурины. От которого давно пора избавиться. Но как переделать мышление большой массы кодеров???

потому что не во всех архитектурах такое а) предусмотрено вообще; б) если и предусмотрено, то использование на уровне кода может быть совсем разным. Я про аналоги SLEEPONEXIT.

В конечном счете, даже внутри задач RTOS код строится в while(1) {} - суперцикле.

[Forger 17]

1 hour ago, Сергей Борщ said:

у которой переключатель контекста при переключении на IdleTask этот бит взводит

ага, наверно поэтому у всех вменяемых осей обычно предусмотрен соотв колбэк на idle задачу

 

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

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

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

 

зы. сам так не делал, нет проектов с экономией электричества, поэтому просто рассуждаю ))

[Arlleex 131]

8 минут назад, Forger сказал:

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

Мой опыт говорит мне, что в микроконтроллерах (где тактовые до условных 300-500 МГц) снижение тактовой против банального сна - бесполезное занятие. Уж лучше следить за активной периферией и не включать ее такты, если она не используется. Вплоть до "Надо отправить по UART? Ок - активировал такты, быстро настроил, отправил, сбросил такты через gate-регистры". Еще, например, в разных режимах работы изделия системной частотой можно жонглировать, если сам домен синхронизации кривой (не гибкий) - например, надо обеспечить не очень стандартный бодрэйт на каком-то интерфейсе, а на максимальной системной частоте его не получить. Для экономии энергии в МК лучше загонять его в сон, а не частоту снижать.

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

А вот в SoC-ах или Application CPU - короче, когда частоты за гигагерцы, там да - управление частотой дает существенное влияние на потребление. Но в таких штуках рулят не только частотой, но и настройками питания, включая внешний PMIC.

[Forger 17]

13 minutes ago, Arlleex said:

Еще, например, в разных режимах работы изделия системной частотой можно жонглировать,

Так я про это и говорю, например, через встроенный предделитель

13 minutes ago, Arlleex said:

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

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

Такие действия производятся за считанные такты.

[Arlleex 131]

1 минуту назад, Forger сказал:

Так я про это и говорю, но ситуации разные бывают.

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

Такие действия производятся за считанные такты.

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

[Forger 17]

10 minutes ago, Arlleex said:

Ну, диапазоны делителей после генератора, зачастую, не так уж велики

Нормальные там диапазоны, 2, 4, 8, 16 ...

Для этого похоже собственно они и придуманы.

Можно ставить делители на периферийный шины, переключаться на внутренние RC генераторы, да вообще тут богатое поле для "творчества" (в разных мк по-разному).

[jcxz 184]

49 минут назад, Arlleex сказал:

Мой опыт говорит мне, что в микроконтроллерах (где тактовые до условных 300-500 МГц) снижение тактовой против банального сна - бесполезное занятие.

Ваш опыт не прав.  

В одном батарейном проекте как раз снижал тактовую ядра (в 256 раз). В том проекте нужно периодически (раз в <300 мсек) контролировать наличие входящих данных (UART) и (если они появились) - запускать рабочий процесс. Если просто положить спать ядро (без снижения его частоты), то экономия получалась незначительная. А вот если максимально снизить тактовую ядра (до нескольких десятков кГц = 6МГц/256), то потребление получалось почти как во сне с остановленным генератором (только немного выше). Но при этом - UART работал. Ядро там выполняло WFE, предварительно поставив будильник (таймер) на пробуждение через 300 мсек.

49 минут назад, Arlleex сказал:

Уж лучше следить за активной периферией и не включать ее такты, если она не используется.

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

49 минут назад, Arlleex сказал:

Для экономии энергии в МК лучше загонять его в сон, а не частоту снижать.

А вы попробуйте померять. Возможно - будете удивлены.  

Я мерял на LPC1758 вариант с CPU спящем на 6 МГц и работающее ядро (пустой цикл) на 6МГц/256. Во втором случае потребление было значительно ниже. Цифр не помню, помню что разница была заметной.

49 минут назад, Arlleex сказал:

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

В батарейных проектах PLL может и не использоваться. А некоторые МК вообще позволяют довольно высокие внешние частоты тактирования (40МГц - запросто). Да и внутренние RC-генераторы бывают и на 24МГц и на 36МГц.

35 минут назад, Arlleex сказал:

Ну, диапазоны делителей после генератора, зачастую, не так уж велики

У некоторых LPC17xx - 8 разрядов. Куда ещё больше?  

[Arlleex 131]

56 минут назад, Forger сказал:

Нормальные там диапазоны, 2, 4, 8, 16 ...

Для этого похоже собственно они и придуманы.

Можно ставить делители на периферийный шины, переключаться на внутренние RC генераторы, да вообще тут богатое поле для "творчества" (в разных мк по-разному).

А должны быть 1, 2, .... хотя бы до ~500.

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

1 час назад, Forger сказал:

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

В такой системе systick почти не нужен  Просто ищу наименьший timeout из активных и завожу на него будильник. А при пробуждении ОС вычитываю из будильника, сколько же прошло времени на самом деле (разбудить ведь мог не будильник, а какое-то другое прерывание) и подправляю системное время и оставшиеся timeout-ы. SysTick включаю только на время исполнения задач ОС, перед спячкой выключаю.

[Forger 17]

6 minutes ago, Arlleex said:

А должны быть 1, 2, .... хотя бы до ~500.

1 там конечно всегда есть (без делителя), а остальное - зависит от МК, их проектируют не идиоты и такие делители закладывают как раз для подобных задач и вряд ли берут значения с потолка

[Arlleex 131]

1 минуту назад, Forger сказал:

их проектируют не идиоты

В 90% случаев именно так - маркетологи их и проектируют.
 

Цитата

вряд ли берут значения с потолка

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

[Forger 17]

1 minute ago, Сергей Борщ said:

Просто ищу наименьший timeout из активных и завожу на него будильник.

Для этого нужно залезать в недра ос, рыться в ее данных, в соотв. списках. По сути это некий костыль.

Just now, Arlleex said:

маркетологи их и проектируют.

Речь про внутренние дебри МК, которые даже в даташите не каждый заметит и уж тем более мало кто будет эти пользоваться.

Даже вы не в курсе на что способны делители внутри )) Маркетологи видно хорошо поработали ))

3 minutes ago, Arlleex said:

В 90% случаев

Откуда взята эта цифра?

[Arlleex 131]

53 минуты назад, jcxz сказал:

В том проекте нужно периодически (раз в <300 мсек) контролировать наличие входящих данных (UART) и (если они появились) - запускать рабочий процесс.

А МК не имел LPUART?
 

Цитата

У некоторых LPC17xx - 8 разрядов. Куда ещё больше?

Кол-во разрядов, это, конечно, хорошо, но гораздо лучше, когда 8 разрядным делителем можно делить на коэф-ты 1...256 с шагом 1, а не на степени двойки 1, 2, 4, ..., 256.

[Forger 17]

15 minutes ago, Arlleex said:

нежели придумывать делители, не кратные степени двойки.

А с какой целью нужна такая точность? 

Давайте сразу уж добавим возможность дробного деления. Чего у ж мелочиться )

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

8 minutes ago, Arlleex said:

когда 8 разрядным делителем можно делить на коэф-ты 1...256 с шагом 1

Опишите хотя бы один пример, где это вот прям необходимо. Реальный, не гипотетический

[Arlleex 131]

22 минуты назад, Forger сказал:

Откуда взята эта цифра?

Когда берешь STM, думаешь, щас я как да подниму на нем все что мне надо - и начинается: список CAN baudrare не бьется с UART-ами, USB тоже ноет в сторонке, требуя 48 МГц на своей шине, и сидишь как дурак со стекляшкой перебираешь циферки из 5 предделителей-степеней двойки, еще и дыркой посередине, и что? Много такими кривыми предделителями можно нарегулировать? Поэтому невольно лезешь в настройки делителей PLL и уже гораздо точнее выставляешь частоту, на которой вся нужная периферия будет довольна. В итоге то, что все частоты подходят - становится "ошибкой выжившего", т.е. повезло, если проект реализуем, когда на конкретные особенности МК внимания не обращал при закладывании в проект. А потом еще начинается - шина работает на какой-то кривой частоте, которая не дает спроектированными такими же кривыми маркетологами выдавать какие-то точные интервалы и т.д. CPU в таких случаях тоже, зачастую, будет работать не на максимальной частоте (как хотелось бы), а на "какой получилось".

В разных МК - по-разному, и где-то сделаны нормальные деревья тактов, позволяющие вообще любую периферию тактировать в том числе и дробным делителем вне зависимости от других шин/периферий.