Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Вспомнил, как взламывали какую-то игровую консоль, от Sony вроде или Nintendo, через контроллер аккумулятора. Стандартно, через определённые промежутки времени, контроллер записывал в основную память приставки несколько байт состояния (температура напряжение...). Адрес записи был прописан в коде контроллера. Код не был закрыт, но это цветочки. Ягодки - контроллер мог производить запись по любому адресу, полный доступ к памяти.
У вас такого нет?
Конкретно по библиотеке, в ней нет привязки к реализации драйвера контроллера питания, а только реализует конечный автомат, и выполнение действий по состояниям может быть реализовано как угодно.
Единственное, что забыл на момент публикации: прямой запрос на включение устройства, если оно запитывается от розетки, аккумулятор как резервный источник, и с розетки подают питание, но добавил позже.
Касательно драйвера в Sony/Nintendo, который допустил, что конкретное поле может быть больше, чем в спецификации SMBus, в моем демо-проекте драйвер к MP2722, который я писал, при запросе значений регистров забирает не более, чем требуется по спецификации (если взлом строился на выходе за пределы массива). ЕМНИП в каждом регистре MP2722 1 байт значения, и оно либо состоит из флагов, либо наборное значение (например, 80+160+1000 мА).
взламывали какую-то игровую консоль, от Sony вроде или Nintendo
Это страшная уязвимость для Sony вроде или Nintendo?
Как вы наказали Sony вроде или Nintendo таким взломом? Скупили все их игровые консоли?
Взлом консоли, мой скоропалительный коллега - это КАТАСТРОФИЧЕСКАЯ уязвимость для производителя, поскольку ПРОДАЖА ИГР составляет от 50% до 100% (в зависимости от политики компании) в планируемой прибыли проекта. А взлом направлен на предоставление возможности пользователям запихивать в консольку не игру с полки магазина за столькосколькохочетиздательилиSonyNintendo, а болванку с образом игры за столькосколькостоиткупитьвларькеболванку.
И это сильно "наказывает" и Sony, и Nintendo, и всех производителей.
Из Вашего профиля следует, что Вы считаете себя "software developer", сильно Вас накажет, если Вы за два года разработаете софтину, в кредит выпустите партию в миллион дисков, ещё на такую же сумму проплатите рекламу, а через неделю после старта продаж кто-то обнаружит, что если ваше детище два раза запустить-закрыть, на третий раз запустить, свернуть и запустить снова - то программа будет считать себя получивший лицензионный ключ и дальше будет работать без ограничений?
поскольку ПРОДАЖА ИГР составляет от 50% до 100% (в зависимости от политики компании) в планируемой прибыли проекта.
а я могу вам не поверить? Откуда у вас такие данные?
Но даже если это правда:
если вы купили диск с игрой он же подходит на любую приставку соответствующего типа? И в общем-то никогда нет проблем его скопировать если очень хочется, даже если это не законно, то есть кроме той проблемы что это не законно.
Потом какой процент игрунов захотят вникать в процесс:
ваше детище два раза запустить-закрыть, на третий раз запустить, свернуть и запустить снова - то программа будет считать себя получивший лицензионный ключ и дальше будет работать без ограничений
...
В общем мне кажется что слово КАТАСТРОФИЧЕСКАЯ на этом фоне выглядит серьезным преувеличением, просто потому что ничего такого КАТАСТРОФИЧЕСКого до сих пор не случилось, несмотря на известные случаи СТРАШНОГО ВЗЛОМА о которых вы написали.
Да Вы можете не верить хоть в закон всемирного тяготения. Не стану рекомендовать Вам его проверить при помощи ближайшего окна. Данные у меня, представьте себе, в том числе и из первоисточников. Компании такого уровня - это, знаете ли, немного более открытые для публичного интереса заведения, чем ларёк с шаурмой. Будь у Вас немного больше самоуважения, Вы дали бы себе небольшую нагрузку (примерно эквивалентную набору своего вопроса) и уточнили цифры самостоятельно в финансовых отчётах, раз Вам так важно мне не поверить.
И в общем-то никогда нет проблем его скопировать если очень хочется, даже если это не законно, то есть кроме той проблемы что это не законно.
Потом какой процент игрунов захотят вникать в процесс
Достаточно высокий. И чем выше соотношение "цена одной игры/уровень доходов", тем больше игроков попытается вникнуть. Это как с софтом. Если по голове не прилетит, и цена полезного ПО в разы превышает стоимость времени, потраченного на проделывание уже широко известных манипуляций по кряку - софт будут ломать.
В общем мне кажется что слово КАТАСТРОФИЧЕСКАЯ на этом фоне выглядит серьезным преувеличением, просто потому что ничего такого КАТАСТРОФИЧЕСКого до сих пор не случилось, несмотря на известные случаи СТРАШНОГО ВЗЛОМА о которых вы написали.
Ну да, ну да, пошли мы нахер, Фурукава-сан. Человек, который, судя по всему, игровые консоли видел только на картинках, сказал, что ничего катастрофического не случилось. Так что можете переставать банить пользовательские свитчи за использование картриджа MIGSwitch и распускать боевые команды юристов.
Вы тут мне много разных вопросов задали, из которых у меня, в свою очередь тоже вытекает вопрос. Вот то, что Вы - "software developer" - это Вам мама в детстве сказала? Или Вам на визитке написали для участия в выставках? Потому что вопросы Ваши пока больше тянут именно на "радиоинженера"*
*Не в обиду коллегам, занимающимся разработкой аппаратного обеспечения. В данном случае термин "радиоинженер" обрисовывает специалиста, занимающегося непосредственно спущенными отдельными задачами, не имея представления ни о том, куда результат его трудов будет установлен, ни для чего вообще предназначено конечное изделие.
Не понял, в чем проблема по наступлению любого пробуждения, просто проверить состояние кнопки/зарядки/чего-то ещё и согласно приоритету на каждое действие решить что делать?
Если нужна последовательность действий типа показать, что заряд на 0 и упасть в сон - для этого есть очереди (на томже ESP), если их нет, то примитивно они реализуются на массиве и 2х функциях - потребителе, и поставщике.
Можно и так, если логика позволяет.
Но я сталкивался с тем, что, например, модем уже инициирован, а устройство надо просто перевести в спящий режим. И при просыпании модем не нужно повторно инициировать. Если бы условий был чуть больше, то это привело бы к спагетти-коду и ненадежной логике обработки состояний питания.
Плюс: если есть контроллер питания, надо опрашивать его состояние, и если надо учитывать пользовательский опыт, то зарядка/кнопка в различных условиях должны обрабатываться по-разному. Например, по-разному отрабатывается подключение/отключение зарядки, когда устройство выключено, в спящем режиме или когда оно работает в активном режиме. Примерно также и с кнопкой. И всё это всё равно приведет к созданию конечного автомата, и я решил собрать этот опыт в библиотеке.
Для этого для каждого самостоятельного модуля заводится статус в массиве статусов, так кроме этого ещё какая-то телеметрия может для конкретного модуля храниться - например чем модуль в данный момент инициализирован.
Модем - типичный модуль, мало того - основной цпу - такойже модуль и там тоже хранится его текущее состояние - например сон, или глубокий сон или вообще обесточка.
При таком подходе понять, что делать элементарно.
Момент №1: модуль хранит статус в массиве статусов только относительно себя и своей логики, если это ведомый модуль
Момент №2: цпу, или ESP32, может потерять состояния, если их хранить в SRAM, а не RTC RAM. Но это ещё полбеды. При просыпании из DeepSleep ESP32 стартует сначала, а не оттуда, где произошло засыпание. Такое умеет LightSleep, но, как оказалось, там тоже свои нюансы по WiFi, и добавлю поддержку и LightSleep. Библиотеку строил с учетом только DeepSleep.
Поэтому, при просыпании из DeepSleep нужно понимать, что стоит таки инициировать заново, а что - нет.
Ещё момент: запрос на перезагрузку, выключение, уход в сон может быть вызван как из самого конечного автомата, так и из приложения пользователя. При этом, PowerManagement берет на себя и рассылку событий, что устройство скоро уснет/выключится/перезагрузится (и сделает через определенное время), а разработчику остается лишь определить, как этот сигнал будет обработан
Запрос должен быть представлен одной функцией, и абсолютно все равно, откуда она будет вызвана.
Если реально устройство очень тяжёлое по количеству модулей и сами модули самостоятельные, то может и есть смысл делать очередь PM, но тогда надо учитывать то, что модули могут иметь разное время обработки этих событий, и надо дожидаться их статуса, вплоть до того, что модуль сможет отменить уход в сон или что-то ещё (из-за ошибки или из-за того что-то обрабатывает).
Но в 99% эмбедеда этого нет, и решается централизованной фй, а все модули ведомые. Никчему переусложнять это дело.
Касательно очередей и event_loop: в PowerManagement используется и то, и другое.
Очереди - для запросов самому PowerManagement, например, на задание времени безделья, что делать, если время безделья истекло, выключить/перезагрузить, уйти в сон, обнулить счетчик времени безделья, и другое.
Event-loop используется для рассылки событий как из самого конечного автомата, так и из логики пользователя.
Ещё может быть такое, что на старте батарея с хорошим напряжением, но под нагрузкой напряжение сильно просело, и надо обработать.
Тут согласен, если напряжение сильно просела, то аккум дохлый. И вообще, наиболее точный замер заряда батареи делается не только по напряжению (по модели напряжений батареи на холостом ходу), но и кулонометру. В MP2722 нет встроенного кулонометра, но есть вывод, показывающий ток батареи как на заряд, так и на разряд. Думаю, удастся соорудить программный кулонометр.
P.S. изучив event-loop esp-idf, обнаружил, что там тоже очередь, обработчик которой поочередно запускает делегаты
Ещё может быть такое, что на старте батарея с хорошим напряжением, но под нагрузкой напряжение сильно просело, и надо обработать.
И при этом я еще не встречал ни одного телефона, планшета или видеорегистратора, которые бы этот обычный сценарий обнаруживали и говорили: "у вас аккумулятор дохлый, обратитесь в сервис". Нет, устройства бодро включаются и рапортуют 100% заряда, а через пять секунд - 10% заряда, и ничего их в этой ситуации не смущает.
Один ноутбук мне сообщал, что батарейка сдохла (Dell Inspiron 1300), точнее, сообщал, что остаточного ресурса в батарее 39,4%, и просил заменить, но это под управлением Ubuntu.
Но это делается по SoH (State of Health), думаю, айфоны и некоторые андроиды тоже так умеют.
По остальным приборам, из-за стремления к удешевлению конечного продукта упрощают схемотехнику и ПО, из-за чего такого поведения не отслеживают
Плюс, в дешевой электронике аккум подыхает чаще всего после окончания срока гарантии, и ты не понесешь в сервис - ты купишь новый девайс.
Если ты рукастый (и если время/желание ремонтировать), то сможешь сам заменить аккумулятор, а если нет, то выставишь на продажу или выкинешь
Сталкивался с разным поведением касательно состояния аккумулятора даже в фототехнике. Есть две камеры класса "продвинутая мыльница". При съёмке на морозе аккумулятор естественно теряет ёмкость, напряжение на нем падает быстрее обычного и замёрзшая камера говорит "всё, аккумулятор кончился". Засовываешь камеру себе за пазуху отогревать и потом опа, сюрприз. Камера Sony: "ура, аккумулятор снова жив, продолжаем работу". Камера от Panasonic: "да ты даже не заряжал аккумулятор, он же уже разрядился, выключаюсь".
Отдельную сложность добавляет Deep Sleep. В ESP32 он обеспечивает минимальное энергопотребление, но при этом полностью обесточивает SRAM. После пробуждения система фактически стартует заново, и без явной архитектуры становится неочевидно, чем «пробуждение» отличается от сброса и как восстановить корректное состояние устройства.
В DeepSleep моде у ESP32 функционирует RTC ядро имеющее 8К медленой и 8K быстрой РАМ в которых можно хранить достаточно переменных, чтобы восстанавливать состояние при пробуждении.
Согласен, это есть, и в демо-проекте как раз там храню флаг пробуждения. Однако пробуждение из DeepSleep без явной архитектуры выглядить для МК также, как и включение, и будет пытаться, например, переинициировать модем, а этого не нужно.
Хорошо, можем использовать этот флаг. Но тут добавляются сложности с тем, чтобы правильно устройство выключить. В демо-проекте использую DeepSleep также и для выключения: MP2722 всегда выдает питание при подключенном ЗУ, даже если дана команда на выключение, в документации явно указано, что рубит питание от батареи. Если устройство было запитано от батареи, то до этого DeepSleep выполнение не дойдет, а если была подключена зарядка, то DeepSleep выполнится, с пробуждением по таймеру. И после пробуждения также произойдет инит интерфейсов для контроллера питания кнопки, PowerManagement увидит, что кнопка не нажата, а зарядка подключена, и перейдет в PM_OFF_CHARGER.
Если хранить как набор флагов, то логика управления будет разрозненной, и могут вылезти неочевидные баги, если нет четкого понимания, какие состояния у устройства с точки зрения питания, и как происходят переходы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управляем питанием по-взрослому: конечный автомат для устройств с батарейным питанием