AlexBel

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

Деваться некуда, приходится работать с тем, что есть. В RM версии 1 этого операционника вообще нет, в версии 2 он появился. То, как он нарисован, мне тогда сразу показалось, очень мягко выражаясь, странным. Ладно бы, у него питание намертво подключено, так ещё и его выход идёт на один из пинов контроллера. Я не исключаю, что этот операционник вообще появился в RM по ошибке или, правильнее сказать, по наплевательскому отношению к разработки документации. Во всяком случае, и в версии 2 RM я уже находил ошибки. Но, пока что, контроллер ведёт себя прилично. Да, именно так. Но когда я не мог найти причину проблемы с потреблением, присутствие такого странно включённого ОУ для меня было одним из объяснений. Кстати, в хидерах этого контроллера есть биты, которые в RM указаны, как RESERVED. А в первой версии хидеров мне пришлось некоторые биты писать ручками, так как они просто отсутствовали.

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

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

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

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

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

Да, вполне возможно. Тем более, что этот контроллер, похоже, сам по себе - сплошной наихудший вариант 😞 Почитав ещё RM и DS я так и не понял, зачем вообще там эти ОУ. Конечно, их можно использовать для усиления сигнала на входе АЦП, но если это не нужно, то что делать? На схеме их выходы нарисованы так, что неминуемо будут конфликтовать с сигналами на пинах контроллера и отключить их нельзя. Кроме того, их питание подключено к VDD, а не к AVDD, как, считаю, было бы сделать правильно. Я специально отключал вывод AVDD - потребление не изменилось. Но и это ещё не всё. Я решил "пощупать" эти ОУ. Включил пины, к которым ОУ подключены, в аналоговый режим, к пину выхода ОУ подключил осциллограф, на один вход ОУ подал половину напряжения питания, на втором входе начал изменять напряжение. В моём предположении, испытуемый ОУ должен был работать, как компаратор. Но на выходе ничего не менялось. То же самое было и со вторым ОУ, т.е. - ничего. Скорее всего, завтра займусь другим контроллером, а про этот АТ забуду, как страшный сон с напоминанием о потерянном времени.

Да, примеров довольно много, это не может не радовать. И, думаю, много (если не большинство) задач можно решить чипами от Артерии. Но! Учитывая то, что я узнал о них за последнее время, уже не уверен в будущем. Не уверен, что не всплывёт что-то очередное, что не было ранее документировано и перечеркнёт всю предыдущую работу. Поэтому, думаю, буду тоже от АТ отказываться. Очень уж большой риск.

В новой версии RM нашёл упоминание об операционном усилителе: В предыдущей версии RM упоминания о нём не было, во всяком случае, я не обнаружил. Особенно заинтересовали эти две строчки: For the products with embedded OPA, its OPA is automatically enabled and cannot be switched off. Quiescent mode: 900uA (single-version OPA) at 3.3V Получается, что операционник постоянно подключен и, даже в режиме StandBy, продолжает потреблять. И, судя по схеме, подключен прямо к пинам питания. Правда, у меня в StandBy потребление порядка 240-250мкА, а не 900мкА, но, вполне возможно, это очередная ошибка в RM. Вот схема:

В новом RM названия регистров изменены. Скачал последнюю версию CMSIS, где эти названия соответствуют RM. Создал в Кейле новый проект, в котором минимум строк для настройки пинов и входа в Standby. Результат тот же, 240мкА. Пробовал входить в этот режим функцией "от производителя" - то же самое (что и понятно - у меня то же самое, что и в этой функции). Опять в тупике...

А можно ссылку, откуда скачивали? Уже не нужно, нашёл, изучаю. Да, есть ощутимые отличия, большое спасибо! Завтра проверю на железе.

Вот скрин из референса, файл RM_AT32F421_EN_V1.01, страница 48.

Чтобы не было влияния других элементов, установил контроллер на плату, на которой впаяны только необходимые для питания и программатора пины. Паял обычной, нейтральной, спиртоканифолью. Все пины переведены в режим входа с подтяжкой к GND. В соответствии с RM Execute WFI (Wait for Interrupt) or WFE (Wait for Event) while: – Set SLEEPDEEP bit in Cortex®-M4F system control register – Set PDDS bit in power control register (PWR_CR) – Clear WUF bit in power control/status register (PWR_CSR) выполняю перевод в Standby: PWR->CTRL |= PWR_CTRL_CLWUF; PWR->CTRL |= PWR_CTRL_PDDS; SCB->SCR |= SCB_SCR_SLEEPDEEP; __WFI(); То же самое - ток потребления 250мкА.

Да, в показаниях прибора уверен. Им уже неоднократно производились измерения таких значений тока у других устройств, результаты замеров подтверждены. У меня два варианта этого контроллера в разных корпусах с разным количеством ног. Настраиваю все линии портов, те, что подключены и те, что не подключены. Т.е. 16 линий каждого порта. Выходные закончились, продолжу войну с потреблением...

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

Питание - напрямую на контроллер

Измеряю потребление всей платы. Но на плате нет ничего, кроме кварца и светодиода, это маленькая девборда-макетка. Кварц в статичном режиме - конденсатор, он никак не может давать утечку, тем более, что на пинах, к которым он подключен, одинаковый уровень. Светодиод на одной плате подключен анодом к пину, но на этот пин я, предварительно, подаю ноль. На второй плате (их две, один и тот же контроллер, но в разных корпусах) светодиод вообще можно отключать джампером. Остальные элементы - конденсаторы по питанию, на сбросе и резистор на BOOT, подключение которого на питание/минус мало что меняет.

Проверил DBGMCU. Когда включаю, потребляемый ток увеличивается. Написал в Artery, может, ответят. В режиме отладки прошагал каждую строчку до входа в standby...

Попробовал сейчас контроллер того же типа, но в корпусе на 48 ног - AT32F421C8T7. Порты настроены на вход и подтянуты с GND. После перехода в Standby результат почти тот же, что и ранее - потребляемый ток порядка 290мкА. В библиотеке Artery для Keil нашёл функцию перевода в StandBy: Использовал её вместо своей, ничего не изменилось. Что, впрочем, понятно - у меня такая же. Опробовал функцию перевода в Stop из той же библиотеки - ничего не изменилось. Оба контроллера на отладочных платах, минимум компонентов, которые не влияют на GPIO. Уже начинаю думать - может, делаю всё правильно, а проблема в контроллерах...

Используется Keil с библиотекой для Artery. Я ничего не корректировал, использовал названия регистров такими, какие они есть в этой библиотеке. Эти названия немного отличаются, но весьма схожи с STM32, как, впрочем, и RM и DS.

Всем привет. Перевожу контроллер AT32F421F8P7 в режим Standby, при этом потребление составляет порядка 250мкА. Измерения производил мультиметром Keithley DMM6500. Вывод из сна производится сбросом по IWDG, т.е. работает низкочастотный внутренний генератор на 40кГц. Для чистоты эксперимента выводы портов никуда не подключены. Пробовал, чтобы не было "висячек", перед переводом в Standby, включать их на вход с подтяжкой вверх и вниз, включал на выход с выводом нуля и единицы, переводил в аналоговый режим - на потребляемый ток это не повлияло. По даташиту ток в режиме Standby должен быть менее 8мкА. Кому-нибудь приходилось переводить AT32F421F8P7 в режим Standby с током потребления, соответствующим даташиту, т.е. менее 8мкА? Видимо, где-то у меня ошибка, но не могу понять, где. Помогите, пожалуйста, найти. Вот моя функция, котороая переводит контроллер в Standby. В первой части - настройка IWDG, во второй - перевод в Standby. Закомментированные строчки - варианты настройки GPIO, которые я использовал в ходе эксперимента.

За это время ток успевает вырасти настолько, что выходят из строя датчики тока и симисторы. Да, я понимаю, что может за собой повлечь очень высокое быстродействие, но нужно будет найти "золотую середину". Сейчас эксперименты с защитой пришлось временно прекратить, в скором времени продолжу и обязательно отпишусь с результатами и вопросами. Извиняюсь за задержку с ответами, но не приходят уведомления о новых сообщениях, хоть я и подписан на тему :(

К сожалению, как показала практика, быстродействия электромеханического автомата недостаточно - выходят из строя не только маломощные измерители тока, но и довольно мощные симисторы BTA-12. При проверке использовал как раз S2C-A1, причём, для максимального быстродействия, питал его от напряжения около 60Вольт. Быстродействие схемы детектирования тока - порядка 10-15 микросекунд. В плане моторных приводов, значит, я не ошибся - это просто связка "автомат+расцепитель", т.е. то, что при испытаниях использовал я.

Очень важно быстродействие. Да, спираль - только для опытов. Нагрузкой будет электродвигатель. Автоматическое включение после устранения КЗ не нужно и, более того, в данном случае, запрещено. Что касается моторных приводов, я не смог найти их электрическую схему, но, судя по внешнему виду, там применяются обычные автоматические выключатели. Если я не прав, то какие там используются методы отключения и где можно посмотреть электрическую схему?