У йоты нет 3G (и как следствие, часто связи вообще). У йоты проблемы с раздачей интернета с мобильного телефона. Следуя их логике, для каждого ноутбука я должен купить по йотовскому модему и платить, платить, платить...
Ростелеком затрахал звонками по два раза в неделю. Причём им совершенно безразлично в каком городе я нахожусь, и работают ли они там вообще. Если я к ним подключусь -- то наверное звонить будут уже по три раза и предлагать подключиться? Но как-то совершенно не хочется. Общее мнение об этом операторе ниже плинтуса. Мегафон стремится туда же.
Давно выдвигал такую мысль, что персональные данные и прочая информацию может утекать не у оператора (ибо закон о тайне связи), а где-то в приложении (на которое закон не распространяется).
Зачем нужен понятно:
вместо огромной массы постоянно меняющихся USSD запросов (это которые *100# и т.п.) и управления соответствующими сервисами;
для показа рекламы абонентам;
для оплаты картами (вместо вебсайта);
для услуги "Мультифон" (где видно кто кому звонил);
если там есть SMS (у них было раньше где-то) -- для того чтобы читать чужие SMS (где в частности видно, на что абонент тратит деньги и сколько у него осталось на счету);
для определения периода активности абонента (диапазона времени) и его географических координат (место жительства, работы, посещаемые заведения и торговые точки);
для выявления прочих сфер интересов абонента средствами приложения (например, копирование клипбоарда, состав файлов в файловой системе телефона, геометки из файлов фотографий...)
По пунктам 4-7, думаю, делается какая-то "обезличенная аналитика" которая сливается в "облака". Где есть две базы данных, и простой INNER JOIN быстренько обезличенную аналитику превращает в имя, фамилию, год рождения и номер телефона.
Я только не понял, в чём обман. Вот открываю даташит: OPA376 фирмы HuanGan Semiconductor. Там же не написано Texas Insturments. А то, что буквы в наименовании совпали: у кого не бывает... И все циферки в даташите справедливые, никак на продукцию Texas Instruments мало похоже, да и вообще явно написано, мол chopper. В чём претензия? Ведь наименование микросхем фирмы Texas Instrments не защищено как торговая марка и кто угодно может навыпускать микросхем с похожими буквами и цифрами.
Вообще бы заставить всех работать по ЕСКД и чтоб все изделия обозначались своим номером ТУ, где в частности всё начинается с кода организации. Проблемы бы не было.
PS: могу допустить, что "они старались" исключительно под одного потребителя которому и так сойдёт, но по документам нужно провести именно это наименование (предприятия российского ВПК), а оно случайно выплескнулось на рынок.
Есть так называемая технология автоматного программирования или проектирования. В частности способ програмирования конечных автоматов в языке C -- "Switch-технология" А. А. Шалыто.
Там поднятые автором статьи вопросы в значительной степени давно разобраны. Обработка конечным автоматом входных событий в своём одном состоянии -- и есть "однопроходная функция".
Немного отступая, стоит ещё вспомнить язык "Дракон". Где отдельные "шампуры" -- работа программы в одном состоянии. И проход блок-схемы "шампура" та же "однопроходная функция".
Нужно отметить, что автоматное программирование -- это в первую очередь автоматное проектирование. Когда вначале проектируется конечный автомат, или система взаимодействующих автоматов, а потом происходит кодирование на каком-либо языке программирования. И логическое проектирование отделено от программирования. При кодировании сразу, "из головы", возникает много дополнительных сущностей (нужных только для практической реализации программы, но никак не связанных непосредствено с логикой управляющей системы), за которыми программист уже попросту не может уследить в голове и в связи с чем склонен совершать логические ошибки: логика управляющей системы оказывается не полноценной, может содержать тупиковые состояния, например, программа может "зависнуть", или может работать некорректно в некоторых сценариях (не во всех возможных состояниях обрабатываются все возможные входные сигналы).
Важным является ещё не только то, как запрограммировать отдельный автомат, но как построить управляющую систему в целом, состоящую из множества конечных автоматов. В общем случае можно строить иерархические системы по технологии Шалыто, или работать с автоматами выполняемыми условно параллельно (на самом деле последовательно, поочерёдно обрабатывая поступающие события) под управлением некоторого "планировщика". Взаимодействие может осуществляться путём наблюдения за состоянием другого автомата (Шалыто) или через обмен сообщениями (событиями).
Простейшим способом планирования выполнения автоматов может быть очередь сообщений: сообщение из головы очереди отправляется последовательно на обработку всем автоматам, которым оно предназначено (или которые его обрабатывают). Такой способ применён в системе Quantum Leaps (теперь state-machines.com). Данный способ имеет очевидный недостаток: подразумевается, что автомат в процессе обработки события может сам породить множество событий предназначенных другим автоматам. И такое поведение может привести к "лавине событий", переполняющей очередь сообщений.
Можно принять, что события являются атомарными: событие или произошло в прошлом и ещё не обработано, и не важно сколько раз, или событие не возникало. Событие не несёт никакой информации. Информация ассоциированная с событием, если есть, должна передаваться отдельно (через выделенные FIFO-очереди и т.п.) И очередь сообщений скорей должна превратиться в очередь с приоритетом, где очередное событие размещается в очереди только в случае если оно уже там не размещено. Тогда переполнение очереди невозможно, но происходит некоторое усложнение логики, т.к. события говорят только о факте своего возникновения, но ни не несут ассоциированную информацию, ни даже не говорят сколько раз они произошли. В принципе, всё это становится похожим на libasync или boost.asio...
Рекомендую к чтению "Механизм обмена сообщениями для параллельно работающих автоматов (на примере системы управления турникетом): https://is.ifmo.ru/download/turn.pdf
В принципе, автоматное программирование является в какой-то мере альтернативой традиционномым способам программирования многозадачных систем. Как правило автоматная программа -- это большое множество параллельных процессов, где "переключение контекстов" осуществляется после обработки очередного события очередным автоматом (а сама обработка события -- не вытесняема). Таким образбом отпадает нужда в механизмах синхронизации (и масса связанных с этим ошибок), отпадает нужда в выделении памяти под стек каждого отдельного потока, нет нужды в долгом переключении контекстов. Но есть и обратная сторона медали: реактивность автоматной системы может оказаться ниже, т.к. определяется временем обработки события самого медленного автомата. А ещё может и длиной очереди сообщений, впрочем и в традиционной многозадачной системе планировщик может иметь очередь готовых к исполнению процессов не нулевой длины.
Ещё нужно отметить, что распространённая в embedded-среде методика программирования с использованием т.н. Big Loop -- по сути тот же планировщик запускающий отдельные автоматы. Но крайне не эффективный: ни только нет приоритетов, так ещё и автоматы запускаются независимо от того, есть ли для них входные события или нет. Когда автоматов (задач) становится очень много, цикл начинает проворачиваться неприемлемо медленно.
Практические сложные программные системы как правило -- комбинация всех методов программирования. Сложная система скорей будет многозадачной, где один или несколько потоков будут выделены для отложенной обработки событий. Остальные потоки будут выполнять времякритичные задачи, требующие быстрой реакции, или задачи где событийный подход не удобен по каким-то причинам, или задачи где важно сохранение контекста в стеке или выполняются блокирующие функции...
Наверное всё перечисленное -- минимум для радиолюбителя. На алиэкспрессе сейчас продаются приборчики типа NanoVNA: антенный анализатор из них, есть подозрение, что очень так себе. Но там есть и генератор качающейся частоты, и измеритель амплитуды, и АЧХ фильтра он вполне построит.
Хотя с другой стороны, в данном случае, фильтр делается "на глаз". Изготавливаем фильтр согласно расчётам, настраиваемся на станцию с более-менее известной частотой и крутим КПЕ или скорей сжимаем/растягивае катушку добиваясь максимума сигнала. Речь же об LC-фильтре с невысокой добротностью и единственной резонансной частотой, которая должна примерно соответствовать промежуточной частоте. Или это входной фильтр. В принципе, всё примерно то же самое.
фильтры используют для автоматизации частоты среза...
С переводом помогал ChatGPT что ли? Такой термин ни в какой литературе не встречался никогда. Нашёл у музыкантов, мол "на каждую дорожку эквалайзера добавить функцию автоматизации". Подразумевается управление эквалайзером по определённому алгоритму. Но это совершенно не технические термины. Можно просто сказать, что фильтры используются для построения эквалайзеров для обработки аудиосигнала.
Статья очень вскользь упоминает от фазочастотной характеристике фильтра. А она очень важна в отдельных приложениях. Да даже для эквалайзера.
Не упомянуты гребенчатые фильтры, так же очень важные в отдельных применениях: когда нужно выделить или наоборот подавить единственную частоту и её гармоники (например 50-гц гудёж в аудиозаписях или 217Гц шумы от GSM-телефона)
Можно было сказать, что фильтры имеют важное значение не только в радиосвязи, но и в аналоговых системах цветного телевидения (PAL, SECAM, NTSC) и аналоговых системах видеозаписи (VHS). В системах цифровой связи: модемы, факсы. В современных мобильных телефонах тоже, но там оно не очевидно уже.
Наконец нужно было упомянуть о возможности построения цифровых фильтров с помощью преобразования Фурье.
Реальный мультитул для "пентестеров" это какой-нибудь toughbook. Который можно швырнуть с размаху на пол, облить пивом и вынести поработать на улице зимой (он не выключается как многие потому, что у датчика температуры процессора отрицательные значения не превращаются в пекло в 255 градусов). И батареи хватает день. И всегда есть компорт.
А тюкаться с вводом буковок через джойстик -- мало кому понравится.
я и сам понимаю, что в нормальных условиях работа в консоли с такого крохотного девайса — это боль и извращение.
Почему заведомо известную? Цену покупатель до взгляда на дисплей не знает. Как и время до взгляда на часы.
Разряд батареи от количества отображаемых элементов не очень зависит, скорей от их совокупной площади (и электрической ёмкости).
И буквы на LCD-дисплее (наименование товара) запросто можно сделать. Ну немного прямоугольные и не очень много... Поэтому E-ink и лучше, что там наименование товара можно полноценно отобразить.
Если информация не обновляется, что как и E-ink, так и LCD-дисплей -- одинаковые примерно свойства. Цифровой LCD-дисплей может хранить картинку без питания многие часы (в часах и калькуляторах цифры гаснут, т.к. разряжаются через электронную схему, можно от батарейки зажечь циферку на дисплее, убрать батарейку -- а циферка останется гореть и потускнеет только завтра). И там и там для обновления картинки нужно контроллеру лишь иногда проснуться и перезаписать содержимое (в LCD неплохо бы ещё с другой полярностью, чтоб дисплей не деградировал).
Статья какая-то оборванная, не законченная. Ожидал увидеть хотя бы описание типовых приёмов работы с отладчиком. Особенно команд сохранения и восстановления состояния и скриптов. Ведь в процессе отладки часто и автоматизировать что-то нужно (иначе много ручной работы, просто не выполнимо), и исследование проблемы может пойти не в ту сторону и проще быстро откатиться к предыдущему состоянию, чем заново воспроизводить весь сценарий приводящий к тому же состоянию (а сценарий может быть очень и очень непростой).
Изначально под отладкой понималось пошаговое исполнение кода, также называемое трассировкой. Сегодня же программы распухли настолько, что трассировать их бессмысленно — мы моментально утонем в омуте вложенных процедур, так и не поняв, что они, собственно, делают.
Kем подразумевалось? Есть разные методы отладки. И пошаговая отладка и трассировка -- лишь два метода из прочих. Причём разные. Первое подразумевает наблюдение за исполнением программы программистом. Второе -- запись хода исполнения и последующий анализ. Вовсе не обязательно ручной анализ.
Пошаговая отладка для современных програм, действительно, из-за объёмов теряет смысл, если приходится искать иголку в стоге сена.
Я думаю тут многое притянуто за уши и не факт вообще, что взлом был успешно осуществлён. Можно подумать, будто в Texas Instruments не догадываются, что таким способом контроллер могут вскрыть и не предполагают никаких защитных мер (чего требуют потребители, так как им не нужно, чтоб их продукция клонировалась китайцами).
В большинстве контроллеров есть специальный модуль следящий за напряжением и формирующий сигнал сброса при кратковременных провалах (brownout detector). Это первое. Скорей он не видит действительно коротких "глитчей", длительностью в десятки наносекунд.
Во-вторых такие сбои приведут в первую очередь не к отключению защиты, а к исполнению чего попало из памяти, к глюкам и зацикливаниям программы. И добиться осмысленного результата -- очень маловероятная удача. Это только в кино если шарахнуть шокером в электронный замок он открывается. На деле обычно намертво зависает в закрытом виде. О чём в статье и пишется...
Если в больших и сложных ARM-контроллерах есть начальный загрузчик, который считывает из флеша состояние бита защиты и конфигурирует SFR регистры соответственным образом, то в простых МК часто ничего кроме пользовательской программы и не запускается, нет там никаких других скрытых программ (у пиков только одна лишняя инструкция исполнялась, считывающая калибровку, насколько помню). И блокировка от считывания программы программатором выполняется аппаратно. Причём нетривиальными способами: Fuse-биты (ячейки flash-памяти) могут быть продублированы, причём в инверсном виде (в итоге массовое обнуление или объединичивание не приводит к успеху) и прикрыты слоем металла (чтоб сверху рентгеном не светили). Где-то блокировка -- вообще пережигаемые перемычки. Пережигаемые один раз в жизни чипа.
В данном случае смысл понятен, задача вызвать сбой при каждом обращении к биту защиты, чтоб он прочитался неправильно. Это нужны чудовищные усилия. Нужно очень точно подобрать время и длительность импульса (чтоб засбоило только то что нужно, а не всё подряд, чтоб не случился сброс, чтоб не исказились считанные данные). Усилия сопоставимые с разработкой печатной платы и программы этого прибора с нуля.
От обычных ЖК-экранов e-ink отличается тем, что энергия расходуется только при изменении содержимого. Это позволяет оснастить ценники батареей небольшой ёмкости и работать без замены батареи несколько лет...
"Карусель", которая X5 retail group, более 15 лет тому назад имела в магазинах электронные ценники на батарейках. Без всякого E-ink. Там была литиевая батарейка CR2302 или подобная. На сколько точно хватало не знаю, но надолго. Ценники ещё через инфракрасный порт загружали новые цены.
Дисплей там был -- самый обычный LCD, а не E-ink. Без излишеств, только цифры (излишества и динамическая индикация быстро бы съели батарейку).
От электронных ценников потом отказались в пользу бумажных. О причинах не догадываюсь, наверняка совокупные себестоимость и стоимость обслуживания.
И ещё можно вспомнить любые электронные часы. Не современные "смарт часы" которые каждый день заряжать нужно, а уже теперь "антикварные", 30-летней давности, где будет серебряно-цинковая батареечка со смешной ёмкостью порядка 30ма*Ч. И которой хватит на год. И да, там LCD-дисплей.
Поэтому утверждения, что дескать только E-ink позволяет что-то там сделать работающее по году на одной батарейке -- они совершенно не справедливы. Приборы с LCD-дисплеями тоже запросто работают по году на одной батарейке.
Но речь разумеется про простые дисплеи, а не матричные, где нужна динамическая индикация (что и съедает энергию, а не сам дисплей). Где набор отображаемых символов очень ограничен и где вывод призвольной графики невозможен. В основном, типично цифры, редко буквы, и ограниченное множество отдельно зажигаемых пиктограмм.
Во-первых, сенсорный блок в передней части модуля, который измеряет площадь физически и отправляет аналоговый сигнал на второй блок, усилитель.
Чего он измеряет? Какой-то некачественный перевод. Хоть бы стоило осмыслить написанное прежде чем публиковать.
Потребляемый ток: 10 мА
Это -- нижнее днище нижнего ада. Потому, что на электретных микрофонах делают диктофоны потребляющие где-то столько же. И датчики разбития стекла и т.п. потребление котороых падает ниже сотни микроампер. Смысл в том, что в постоянной работе микрофона смысла особого нет и ток через транзистор подаётся короткими импульсами, несколько тысяч раз в секунду. Потом фильтруется и интегрируется малопотребляющим усилителем и т.п. Микрофон в такой системе часто самое потребляющее устройство, потому так.
В данном же случае "хлопок" -- это короткий по времени сигнал с широким спектром (от сотен Гц до десятка кГц). Можно фильтром высоких частот на ОУ отрезать низкочастотные шумы (ниже килогерца), пропустить через амплитудный детектор, а потом выделить всплески длительностью в сотню миллисекунд. Проще наверное опять же выделить аналоговым фильтром на ОУ (сигналы с частотой порядка 10Гц). Или простейшей логической схемой с парой одновибраторов.
Микроконтроллер здесь вообще не нужен, или нужен простейший, самый дешёвый, PIC10. Скорей не нужен, т.к. любой микроконтроллер -- затраты на программирование при разработке и программирование на производстве. А полностью программная обработка съест слишком много электричества. С другой стороны, если датчик должен работать на цифровой шине, то МК всё равно будет и ему можно поручить вторую фазу (после амплитудного детектора, выделение импульсов определённой длины). Речь всяко не о "цифровой обработке сигнала" в классическом понимании, с разложением в ряд Фурье и т.п.
Картинки у меня не загрузились, поэтому дальше я ничего не понял.
Датчики KY – 038 и GY –MAX9814 являются конденсаторными.
Весьма условно. Разумеется там самые дешёвые китайские электретные микрофоны. где метализированная майларовая мембрана (пленка) несущая заряд колеблется над выводом затвора JFET-транзистора, через которого пропускается небольшой ток. Соответственно колебания плёнки пропорциональны изменению потенциала на затворе (потому, что при изменении расстояния между условными обкладками конденсатора -- плёнкой и выводом транзистора, при постоянстве заряда изменяется потенциал -- напряжение). И колебания пропорциональны току через транзистор. Так работает электретный микрофон. В настоящем конденсатором микрофоне к мембране подводится напряжение (порядка десятков вольт), а тут ограничивается тем что мембрана изготовлена из специального материала в котором молекулы ориентированы так, что разные стороны плёнки имеют разный заряд (называется "электрет", по аналогии с "магнитом", диэлектрик, который только удерживает не постоянное магнитное поле, а постоянный заряд). И усилитель в настоящем конденсаторном микрофоне может быть отдельный, а не встроенный и достаточно шумный JFET транзистор.
Электретные микрофоны конечно в определённом смысле конденсаторные, но это не совсем то, что обычно называется конденсаторным микрофоном: обычно это очень качественный измерительный или студийный микрофон, требующий специального усилителя и источника питания. А электретный микрофон -- как правило это удел ширпотребной аппаратуры. Причём в современных телефонах, например, такие микрофоны вытеснены MEMS-микрофонами (которые внутри обычно пьезоэлектрические). Потому, что электретный микрофон плохо переносит плевки в него (как и конденсаторный), в отличии от динамических или пьезо.
В GCC/Clang есть __attribute__((cleanup(function))) var. Но оно не решает проблему полностью, т.к. дальше захочется подсчёта ссылок. А с этим сразу сложно, т.к. в GCC вложенные функции с (неработающими -- т.к. исполняемый стек) трамплинами, в Clang есть blocks (недолямбды...), и всё это нестандарт. Потом захочется отличать перемещение и копирование. И так будет заново изобретаться C++...
У йоты нет 3G (и как следствие, часто связи вообще). У йоты проблемы с раздачей интернета с мобильного телефона. Следуя их логике, для каждого ноутбука я должен купить по йотовскому модему и платить, платить, платить...
Ростелеком затрахал звонками по два раза в неделю. Причём им совершенно безразлично в каком городе я нахожусь, и работают ли они там вообще. Если я к ним подключусь -- то наверное звонить будут уже по три раза и предлагать подключиться? Но как-то совершенно не хочется. Общее мнение об этом операторе ниже плинтуса. Мегафон стремится туда же.
Давно выдвигал такую мысль, что персональные данные и прочая информацию может утекать не у оператора (ибо закон о тайне связи), а где-то в приложении (на которое закон не распространяется).
Зачем нужен понятно:
вместо огромной массы постоянно меняющихся USSD запросов (это которые *100# и т.п.) и управления соответствующими сервисами;
для показа рекламы абонентам;
для оплаты картами (вместо вебсайта);
для услуги "Мультифон" (где видно кто кому звонил);
если там есть SMS (у них было раньше где-то) -- для того чтобы читать чужие SMS (где в частности видно, на что абонент тратит деньги и сколько у него осталось на счету);
для определения периода активности абонента (диапазона времени) и его географических координат (место жительства, работы, посещаемые заведения и торговые точки);
для выявления прочих сфер интересов абонента средствами приложения (например, копирование клипбоарда, состав файлов в файловой системе телефона, геометки из файлов фотографий...)
По пунктам 4-7, думаю, делается какая-то "обезличенная аналитика" которая сливается в "облака". Где есть две базы данных, и простой INNER JOIN быстренько обезличенную аналитику превращает в имя, фамилию, год рождения и номер телефона.
Диапозон --> диапАзон.
Я только не понял, в чём обман. Вот открываю даташит: OPA376 фирмы HuanGan Semiconductor. Там же не написано Texas Insturments. А то, что буквы в наименовании совпали: у кого не бывает... И все циферки в даташите справедливые, никак на продукцию Texas Instruments мало похоже, да и вообще явно написано, мол chopper. В чём претензия? Ведь наименование микросхем фирмы Texas Instrments не защищено как торговая марка и кто угодно может навыпускать микросхем с похожими буквами и цифрами.
Вообще бы заставить всех работать по ЕСКД и чтоб все изделия обозначались своим номером ТУ, где в частности всё начинается с кода организации. Проблемы бы не было.
PS: могу допустить, что "они старались" исключительно под одного потребителя которому и так сойдёт, но по документам нужно провести именно это наименование (предприятия российского ВПК), а оно случайно выплескнулось на рынок.
Есть так называемая технология автоматного программирования или проектирования. В частности способ програмирования конечных автоматов в языке C -- "Switch-технология" А. А. Шалыто.
Рекомендую к ознакомлению: http://softcraft.ru/auto/ и https://is.ifmo.ru/automata/
Там поднятые автором статьи вопросы в значительной степени давно разобраны. Обработка конечным автоматом входных событий в своём одном состоянии -- и есть "однопроходная функция".
Немного отступая, стоит ещё вспомнить язык "Дракон". Где отдельные "шампуры" -- работа программы в одном состоянии. И проход блок-схемы "шампура" та же "однопроходная функция".
Нужно отметить, что автоматное программирование -- это в первую очередь автоматное проектирование. Когда вначале проектируется конечный автомат, или система взаимодействующих автоматов, а потом происходит кодирование на каком-либо языке программирования. И логическое проектирование отделено от программирования. При кодировании сразу, "из головы", возникает много дополнительных сущностей (нужных только для практической реализации программы, но никак не связанных непосредствено с логикой управляющей системы), за которыми программист уже попросту не может уследить в голове и в связи с чем склонен совершать логические ошибки: логика управляющей системы оказывается не полноценной, может содержать тупиковые состояния, например, программа может "зависнуть", или может работать некорректно в некоторых сценариях (не во всех возможных состояниях обрабатываются все возможные входные сигналы).
Важным является ещё не только то, как запрограммировать отдельный автомат, но как построить управляющую систему в целом, состоящую из множества конечных автоматов. В общем случае можно строить иерархические системы по технологии Шалыто, или работать с автоматами выполняемыми условно параллельно (на самом деле последовательно, поочерёдно обрабатывая поступающие события) под управлением некоторого "планировщика". Взаимодействие может осуществляться путём наблюдения за состоянием другого автомата (Шалыто) или через обмен сообщениями (событиями).
Простейшим способом планирования выполнения автоматов может быть очередь сообщений: сообщение из головы очереди отправляется последовательно на обработку всем автоматам, которым оно предназначено (или которые его обрабатывают). Такой способ применён в системе Quantum Leaps (теперь state-machines.com). Данный способ имеет очевидный недостаток: подразумевается, что автомат в процессе обработки события может сам породить множество событий предназначенных другим автоматам. И такое поведение может привести к "лавине событий", переполняющей очередь сообщений.
Можно принять, что события являются атомарными: событие или произошло в прошлом и ещё не обработано, и не важно сколько раз, или событие не возникало. Событие не несёт никакой информации. Информация ассоциированная с событием, если есть, должна передаваться отдельно (через выделенные FIFO-очереди и т.п.) И очередь сообщений скорей должна превратиться в очередь с приоритетом, где очередное событие размещается в очереди только в случае если оно уже там не размещено. Тогда переполнение очереди невозможно, но происходит некоторое усложнение логики, т.к. события говорят только о факте своего возникновения, но ни не несут ассоциированную информацию, ни даже не говорят сколько раз они произошли. В принципе, всё это становится похожим на libasync или boost.asio...
Рекомендую к чтению "Механизм обмена сообщениями для параллельно
работающих автоматов (на примере системы управления турникетом): https://is.ifmo.ru/download/turn.pdf
В принципе, автоматное программирование является в какой-то мере альтернативой традиционномым способам программирования многозадачных систем. Как правило автоматная программа -- это большое множество параллельных процессов, где "переключение контекстов" осуществляется после обработки очередного события очередным автоматом (а сама обработка события -- не вытесняема). Таким образбом отпадает нужда в механизмах синхронизации (и масса связанных с этим ошибок), отпадает нужда в выделении памяти под стек каждого отдельного потока, нет нужды в долгом переключении контекстов. Но есть и обратная сторона медали: реактивность автоматной системы может оказаться ниже, т.к. определяется временем обработки события самого медленного автомата. А ещё может и длиной очереди сообщений, впрочем и в традиционной многозадачной системе планировщик может иметь очередь готовых к исполнению процессов не нулевой длины.
Ещё нужно отметить, что распространённая в embedded-среде методика программирования с использованием т.н. Big Loop -- по сути тот же планировщик запускающий отдельные автоматы. Но крайне не эффективный: ни только нет приоритетов, так ещё и автоматы запускаются независимо от того, есть ли для них входные события или нет. Когда автоматов (задач) становится очень много, цикл начинает проворачиваться неприемлемо медленно.
Практические сложные программные системы как правило -- комбинация всех методов программирования. Сложная система скорей будет многозадачной, где один или несколько потоков будут выделены для отложенной обработки событий. Остальные потоки будут выполнять времякритичные задачи, требующие быстрой реакции, или задачи где событийный подход не удобен по каким-то причинам, или задачи где важно сохранение контекста в стеке или выполняются блокирующие функции...
Можно, но нужна бесконечно широкая полоса. Или просто достаточно широкая, чтоб на глаз квадрат оставался квадратом.
Наверное всё перечисленное -- минимум для радиолюбителя. На алиэкспрессе сейчас продаются приборчики типа NanoVNA: антенный анализатор из них, есть подозрение, что очень так себе. Но там есть и генератор качающейся частоты, и измеритель амплитуды, и АЧХ фильтра он вполне построит.
Хотя с другой стороны, в данном случае, фильтр делается "на глаз". Изготавливаем фильтр согласно расчётам, настраиваемся на станцию с более-менее известной частотой и крутим КПЕ или скорей сжимаем/растягивае катушку добиваясь максимума сигнала. Речь же об LC-фильтре с невысокой добротностью и единственной резонансной частотой, которая должна примерно соответствовать промежуточной частоте. Или это входной фильтр. В принципе, всё примерно то же самое.
С переводом помогал ChatGPT что ли? Такой термин ни в какой литературе не встречался никогда. Нашёл у музыкантов, мол "на каждую дорожку эквалайзера добавить функцию автоматизации". Подразумевается управление эквалайзером по определённому алгоритму. Но это совершенно не технические термины. Можно просто сказать, что фильтры используются для построения эквалайзеров для обработки аудиосигнала.
Статья очень вскользь упоминает от фазочастотной характеристике фильтра. А она очень важна в отдельных приложениях. Да даже для эквалайзера.
Не упомянуты гребенчатые фильтры, так же очень важные в отдельных применениях: когда нужно выделить или наоборот подавить единственную частоту и её гармоники (например 50-гц гудёж в аудиозаписях или 217Гц шумы от GSM-телефона)
Можно было сказать, что фильтры имеют важное значение не только в радиосвязи, но и в аналоговых системах цветного телевидения (PAL, SECAM, NTSC) и аналоговых системах видеозаписи (VHS). В системах цифровой связи: модемы, факсы. В современных мобильных телефонах тоже, но там оно не очевидно уже.
Наконец нужно было упомянуть о возможности построения цифровых фильтров с помощью преобразования Фурье.
Реальный мультитул для "пентестеров" это какой-нибудь toughbook. Который можно швырнуть с размаху на пол, облить пивом и вынести поработать на улице зимой (он не выключается как многие потому, что у датчика температуры процессора отрицательные значения не превращаются в пекло в 255 градусов). И батареи хватает день. И всегда есть компорт.
А тюкаться с вводом буковок через джойстик -- мало кому понравится.
Точно.
Почему заведомо известную? Цену покупатель до взгляда на дисплей не знает. Как и время до взгляда на часы.
Разряд батареи от количества отображаемых элементов не очень зависит, скорей от их совокупной площади (и электрической ёмкости).
И буквы на LCD-дисплее (наименование товара) запросто можно сделать. Ну немного прямоугольные и не очень много... Поэтому E-ink и лучше, что там наименование товара можно полноценно отобразить.
Если информация не обновляется, что как и E-ink, так и LCD-дисплей -- одинаковые примерно свойства. Цифровой LCD-дисплей может хранить картинку без питания многие часы (в часах и калькуляторах цифры гаснут, т.к. разряжаются через электронную схему, можно от батарейки зажечь циферку на дисплее, убрать батарейку -- а циферка останется гореть и потускнеет только завтра). И там и там для обновления картинки нужно контроллеру лишь иногда проснуться и перезаписать содержимое (в LCD неплохо бы ещё с другой полярностью, чтоб дисплей не деградировал).
Статья какая-то оборванная, не законченная. Ожидал увидеть хотя бы описание типовых приёмов работы с отладчиком. Особенно команд сохранения и восстановления состояния и скриптов. Ведь в процессе отладки часто и автоматизировать что-то нужно (иначе много ручной работы, просто не выполнимо), и исследование проблемы может пойти не в ту сторону и проще быстро откатиться к предыдущему состоянию, чем заново воспроизводить весь сценарий приводящий к тому же состоянию (а сценарий может быть очень и очень непростой).
Kем подразумевалось? Есть разные методы отладки. И пошаговая отладка и трассировка -- лишь два метода из прочих. Причём разные. Первое подразумевает наблюдение за исполнением программы программистом. Второе -- запись хода исполнения и последующий анализ. Вовсе не обязательно ручной анализ.
Пошаговая отладка для современных програм, действительно, из-за объёмов теряет смысл, если приходится искать иголку в стоге сена.
А может проще было бы запустить WireShark и он сам показал бы, что нашёл такие-то пакеты таких-то протоколов?
Я думаю тут многое притянуто за уши и не факт вообще, что взлом был успешно осуществлён. Можно подумать, будто в Texas Instruments не догадываются, что таким способом контроллер могут вскрыть и не предполагают никаких защитных мер (чего требуют потребители, так как им не нужно, чтоб их продукция клонировалась китайцами).
В большинстве контроллеров есть специальный модуль следящий за напряжением и формирующий сигнал сброса при кратковременных провалах (brownout detector). Это первое. Скорей он не видит действительно коротких "глитчей", длительностью в десятки наносекунд.
Во-вторых такие сбои приведут в первую очередь не к отключению защиты, а к исполнению чего попало из памяти, к глюкам и зацикливаниям программы. И добиться осмысленного результата -- очень маловероятная удача. Это только в кино если шарахнуть шокером в электронный замок он открывается. На деле обычно намертво зависает в закрытом виде. О чём в статье и пишется...
Если в больших и сложных ARM-контроллерах есть начальный загрузчик, который считывает из флеша состояние бита защиты и конфигурирует SFR регистры соответственным образом, то в простых МК часто ничего кроме пользовательской программы и не запускается, нет там никаких других скрытых программ (у пиков только одна лишняя инструкция исполнялась, считывающая калибровку, насколько помню). И блокировка от считывания программы программатором выполняется аппаратно. Причём нетривиальными способами: Fuse-биты (ячейки flash-памяти) могут быть продублированы, причём в инверсном виде (в итоге массовое обнуление или объединичивание не приводит к успеху) и прикрыты слоем металла (чтоб сверху рентгеном не светили). Где-то блокировка -- вообще пережигаемые перемычки. Пережигаемые один раз в жизни чипа.
В данном случае смысл понятен, задача вызвать сбой при каждом обращении к биту защиты, чтоб он прочитался неправильно. Это нужны чудовищные усилия. Нужно очень точно подобрать время и длительность импульса (чтоб засбоило только то что нужно, а не всё подряд, чтоб не случился сброс, чтоб не исказились считанные данные). Усилия сопоставимые с разработкой печатной платы и программы этого прибора с нуля.
Непонятен смысл затраченных усилий по реверс-инженерингу. Такой прибор проще с нуля разработать, ничего требующего особенного изучения там нет.
"Карусель", которая X5 retail group, более 15 лет тому назад имела в магазинах электронные ценники на батарейках. Без всякого E-ink. Там была литиевая батарейка CR2302 или подобная. На сколько точно хватало не знаю, но надолго. Ценники ещё через инфракрасный порт загружали новые цены.
Дисплей там был -- самый обычный LCD, а не E-ink. Без излишеств, только цифры (излишества и динамическая индикация быстро бы съели батарейку).
От электронных ценников потом отказались в пользу бумажных. О причинах не догадываюсь, наверняка совокупные себестоимость и стоимость обслуживания.
И ещё можно вспомнить любые электронные часы. Не современные "смарт часы" которые каждый день заряжать нужно, а уже теперь "антикварные", 30-летней давности, где будет серебряно-цинковая батареечка со смешной ёмкостью порядка 30ма*Ч. И которой хватит на год. И да, там LCD-дисплей.
Поэтому утверждения, что дескать только E-ink позволяет что-то там сделать работающее по году на одной батарейке -- они совершенно не справедливы. Приборы с LCD-дисплеями тоже запросто работают по году на одной батарейке.
Но речь разумеется про простые дисплеи, а не матричные, где нужна динамическая индикация (что и съедает энергию, а не сам дисплей). Где набор отображаемых символов очень ограничен и где вывод призвольной графики невозможен. В основном, типично цифры, редко буквы, и ограниченное множество отдельно зажигаемых пиктограмм.
Чего он измеряет? Какой-то некачественный перевод. Хоть бы стоило осмыслить написанное прежде чем публиковать.
Это -- нижнее днище нижнего ада. Потому, что на электретных микрофонах делают диктофоны потребляющие где-то столько же. И датчики разбития стекла и т.п. потребление котороых падает ниже сотни микроампер. Смысл в том, что в постоянной работе микрофона смысла особого нет и ток через транзистор подаётся короткими импульсами, несколько тысяч раз в секунду. Потом фильтруется и интегрируется малопотребляющим усилителем и т.п. Микрофон в такой системе часто самое потребляющее устройство, потому так.
В данном же случае "хлопок" -- это короткий по времени сигнал с широким спектром (от сотен Гц до десятка кГц). Можно фильтром высоких частот на ОУ отрезать низкочастотные шумы (ниже килогерца), пропустить через амплитудный детектор, а потом выделить всплески длительностью в сотню миллисекунд. Проще наверное опять же выделить аналоговым фильтром на ОУ (сигналы с частотой порядка 10Гц). Или простейшей логической схемой с парой одновибраторов.
Микроконтроллер здесь вообще не нужен, или нужен простейший, самый дешёвый, PIC10. Скорей не нужен, т.к. любой микроконтроллер -- затраты на программирование при разработке и программирование на производстве. А полностью программная обработка съест слишком много электричества. С другой стороны, если датчик должен работать на цифровой шине, то МК всё равно будет и ему можно поручить вторую фазу (после амплитудного детектора, выделение импульсов определённой длины). Речь всяко не о "цифровой обработке сигнала" в классическом понимании, с разложением в ряд Фурье и т.п.
Картинки у меня не загрузились, поэтому дальше я ничего не понял.
Весьма условно. Разумеется там самые дешёвые китайские электретные микрофоны. где метализированная майларовая мембрана (пленка) несущая заряд колеблется над выводом затвора JFET-транзистора, через которого пропускается небольшой ток. Соответственно колебания плёнки пропорциональны изменению потенциала на затворе (потому, что при изменении расстояния между условными обкладками конденсатора -- плёнкой и выводом транзистора, при постоянстве заряда изменяется потенциал -- напряжение). И колебания пропорциональны току через транзистор. Так работает электретный микрофон. В настоящем конденсатором микрофоне к мембране подводится напряжение (порядка десятков вольт), а тут ограничивается тем что мембрана изготовлена из специального материала в котором молекулы ориентированы так, что разные стороны плёнки имеют разный заряд (называется "электрет", по аналогии с "магнитом", диэлектрик, который только удерживает не постоянное магнитное поле, а постоянный заряд). И усилитель в настоящем конденсаторном микрофоне может быть отдельный, а не встроенный и достаточно шумный JFET транзистор.
Электретные микрофоны конечно в определённом смысле конденсаторные, но это не совсем то, что обычно называется конденсаторным микрофоном: обычно это очень качественный измерительный или студийный микрофон, требующий специального усилителя и источника питания. А электретный микрофон -- как правило это удел ширпотребной аппаратуры. Причём в современных телефонах, например, такие микрофоны вытеснены MEMS-микрофонами (которые внутри обычно пьезоэлектрические). Потому, что электретный микрофон плохо переносит плевки в него (как и конденсаторный), в отличии от динамических или пьезо.
В GCC/Clang есть __attribute__((cleanup(function))) var. Но оно не решает проблему полностью, т.к. дальше захочется подсчёта ссылок. А с этим сразу сложно, т.к. в GCC вложенные функции с (неработающими -- т.к. исполняемый стек) трамплинами, в Clang есть blocks (недолямбды...), и всё это нестандарт. Потом захочется отличать перемещение и копирование. И так будет заново изобретаться C++...