[Obam 30]

Quote

на чипах EFM32™ Gecko 32-bit Microcontroller.

С "белой" то комплектацией любой - д'Артаньян... попробуй "чайную" охмурить ;-)

[AlexBel 4]

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

[haker_fox 60]

8 minutes ago, AlexBel said:

Взял STM8

Ух ты! Вот это скачок! С Cortex-M4F на восьмибитку! А если серьёзно, то как-то необычно. Изначально, выходит, не нужна была такая мощность?

[AlexBel 4]

2 minutes ago, haker_fox said:

Ух ты! Вот это скачок! С Cortex-M4F на восьмибитку! А если серьёзно, то как-то необычно. Изначально, выходит, не нужна была такая мощность?

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

[jcxz 181]

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

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

Спорное утверждение. Априори - на CM4F не добиться того же минимума потребления как на STM8L в аналогичных режимах работы ядра. А значит не факт, что при режиме работы: N секунд спал, затем M секунд считал в плавающей точке, CM4F окажется эффективнее чем STM8L. Если нужно долго спать, а затем сделать несколько простых вычислений в плавучке и опять долго спать, я бы поставил на STM8L.

 

PS: Тем более что и не факт, что плавучка реально нужна в вашей задаче.....  

[iamnot 0]

Почему CM4F? По даташиту CM4, плавающая точка только программно делается, насколько я понял.
Так что по сравнению с STM8 отличие только в частотах.

[haker_fox 60]

16 minutes ago, iamnot said:

ак что по сравнению с STM8 отличие только в частотах.

Даже если нет математического сопроцессора, всё равно на этом различия не заканчиваются. А они есть:

1. В разрядности АЛУ: 32 против 8 бит.

2. В наборе инструкций. В Cortex-M4 (без F) даже по сравнению с Cortex-M3 набор инструкций значительно увеличивается, добавляя команды ЦСП.

А в M3 по сравнению с M0 добавляется много команд. Хотя M0 позиционировалась как некая мощная альтернатива 8-битным ядрам.

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

[jcxz 181]

57 минут назад, haker_fox сказал:

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

У ТС вроде стоит задача "уделывания" не по быстродействию, а по потреблению.

"Уделывать" имеет смысл на потоковых вычислениях. Только тогда эти отличия в командах и могут сказаться. А если речь об "опросе датчиков" и обработке данных из них (редком опросе), то речь идёт скорее всего о режиме работы в стиле: "N сотен миллисекунд спим (или даже N секунд), затем читаем датчик и делаем несколько мат.операций с полученными данными". Тогда ни будет никакой практической разницы - 10 тактов занимают вычисления (на ARM) или 1000 тактов (на STM8). На ARM получится отношение времени бодрствования МК ко времени сна например ==1%, а на STM8 ==1.1%. Ведь кроме вычислений во время бодрствования входит ещё и время транзакций (по интерфейсам связи) между МК и датчиками. А оно как правило - больше чем время вычислений и уснуть МК на это время вряд-ли возможно.

А за счёт того, что потребление STM8L во сне окажется меньше, чем у CM4. Пускай даже не на много. Но если этот режим составляет львиную долю времени работы МК, то выигрыш в потреблении будет на стороне STM8L. И скорее именно STM8L "уделает" Cortex-а.

 

PS: У меня на кухне уже больше 2-х лет лежит и работает девайс на STM8L, в который ещё в начале работы были вставлены 2 батарейки AA полудохлые (в сумме последовательно = 2.55V в момент старта работы). Лежит всё время включенным, но большую часть времени - во сне. Работает до сих пор. Сомневаюсь, что он до сих пор бы работал, будучи сделанным на CM4. Уже больше 2-х лет он "уделывает" по потреблению CM4.  

[Obam 30]

Сравнивать CM4 в "неэкономном" исполнении с "экономным" STM8 - так себе занятие ;-)
Как только смотрим на STM32L451 (к примеру) и на STM8L151 (ну вот нашёлся в компе):
- производительность (32бит) 84 мкА/МГц против (8бит) 200 мкА/МГц;
- cпячка (shutdown) 22 нА против (halt) 400 нА;
- standby+RTC 0.38 мкА против active-halt_RTC 1.4 мкА,
то видим - 32L и "переэкономичит" и "переобсчитает" 8L.

[AlexBel 4]

Продолжил эксперименты с контроллерами. Сделал ещё два проекта с STM32F030 и STM32F103. Оба замечательно уходят в Standby, первый потребляет порядка 3,5мкА, второй - порядка 2мкА. И подумал снова вернуться к артериевским чипам, сравнить их код с кодом, что я писал для STM32. И обнаружил, что у артерии я не включил тактирование модуля управления питанием! Как только я это сделал, чип сразу заснул богатырским сном AT32F421F8P - 3,2мкА! Так что в своей проблеме я оказался виноват сам.

[haker_fox 60]

3 hours ago, AlexBel said:

И обнаружил, что у артерии я не включил тактирование модуля управления питанием

А в UM на Artery об этом как-то написано? Т.е. если бы не было сличения с STM32, можно было бы как-то понять, что нужно включать модуль питания?

[AlexBel 4]

6 minutes ago, haker_fox said:

А в UM на Artery об этом как-то написано? Т.е. если бы не было сличения с STM32, можно было бы как-то понять, что нужно включать модуль питания?

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

[haker_fox 60]

@AlexBel, спасибо за ответ! Я уж подумал, не с горяча ли отверг Artery взамен GD32. Посмотрел ещё раз документацию, и подумал: нет, не зря. Всё же она скудная. Хотя коллега, сейчас трассирующий схему и печатку для GD32, отмечает, что у AT32 гораздо более продуманный мультиплексор для линий ввода-вывода. С его слов, на GD32F450 практически невозможно одновременно использовать диплей в режиме 565, SDRAM 16 бит и NOR QSPI...

[quark 48]

В 26.01.2023 в 14:11, AlexBel сказал:

И обнаружил, что у артерии я не включил тактирование модуля управления питанием! Как только я это сделал, чип сразу заснул богатырским сном AT32F421F8P - 3,2мкА! Так что в своей проблеме я оказался виноват сам.

Осталось непонятным (по крайней мере, мне), как, после включения тактирования, для операционника, который напрямую подключен к шине питания (по вашим словам), потребление вдруг снизилось почти до нуля?

[AlexBel 4]

32 minutes ago, quark said:

Осталось непонятным (по крайней мере, мне), как, после включения тактирования, для операционника, который напрямую подключен к шине питания (по вашим словам), потребление вдруг снизилось почти до нуля?

Это не по моим словам, это по словам из RM. Что там внутри на самом деле - неизвестно, во всяком случае - мне. Может быть, никакого операционника и нет. Я лишь сообщаю то, что прочитал и что смог выяснить, просто факты.

Изменено 13 февраля, 2023 пользователем AlexBel