Пользователь
В жизни каждого программиста С++ рано или поздно возникает задача, которую кто-либо уже решил. Однако найти это решение бывает очень непросто в силу разных причин: оно недостаточно разрекламировано, либо имеет нечеткую документацию, или возникает проблема языкового барьера, ну, или поисковики просто плохо ищут).
Столкнувшись много раз подряд с тем, что найти что-то толковое довольно непросто, я решил попробовать распутать это узел и предложить для русскоязычных читателей свой справочник классных библиотек на С++. Я исходил из этого источника. Это очень многогранный и объемный список библиотек языка С++, но, скажем так, у меня были к нему вопросы. Потому я сделал перевод, затем значительно улучшил его в плане содержания (далее объясню, как, почему и зачем). На выходе получилось около 1000 библиотек. Как в сказке). Они, конечно, не покрывают все возможные задачи и предметные области, но поверьте, они затрагивают действительно многое.
Допустим, у нас есть массив чисел с плавающей запятой, и мы хотим их суммировать. Можно наивно подумать, что их достаточно просто сложить, например, на Rust.
Однако это запросто может привести к произвольно большой накопленной погрешности. Давайте проверим:
naive_sum(&vec![1.0; 1_000_000]) = 1000000.0
naive_sum(&vec![1.0; 10_000_000]) = 10000000.0
naive_sum(&vec![1.0; 100_000_000]) = 16777216.0
naive_sum(&vec![1.0; 1_000_000_000]) = 16777216.0
Ой-ёй… Что произошло? Проблема в том .что следующее 32-битное число с плавающей запятой после 16777216 — это 16777218. Так что при вычислении 16777216 + 1, значение округляется до ближайшего числа с плавающей запятой, имеющей чётную мантиссу, то есть снова до 16777216. Мы зашли в тупик.
К счастью, есть более совершенные способы суммирования массива.
В последнее время появилось много микроконтроллеров на ядрах ARM Cortex-M*, которые поддерживают аппаратную реализацию математики плавающей запятой (FPU). В основном FPU работают с одиночной точностью (float) и её вполне достаточно для работы с сигналами, полученными с АЦП. FPU позволяет забыть о проблемах дискретизации и проблемах переполнения целочисленных вычислений. FPU быстр - все математические операции с одиночными float, кроме деления и взятия корня, занимают на Cortex-M4F один такт. Поэтому после перехода на Cortex-M4F мы вздохнули свободно и стали писать математику на float. Как же мы удивились, найдя в скомпилированном коде математические операции над double с программной, очень медленной эмуляцией.
В статье рассказывается, как обнаружить и исправить присутствие double в прошивках, где ядро аппаратно поддерживает тип float, но не поддерживает double.
Работа ведётся в среде IAR Embedded Workbench на примере реального кода на языке Си.
Мне понравилась идея Flipper Zero в хранении и эмуляции электронных ключей. Это довольно удобно, можно избавится от половины моей связки со всеми ключами, плюс те ключи, которые я обычно даже не ношу, будут под рукой, в том числе универсальные. Но не понравились его габариты. К тому же, весь остальной функционал хоть мне и интересен, для этой задачи излишен, а за него тоже надо платить. В этот момент появилась идея и, что самое главное, желание самостоятельно реализовать такую штуку.
Конечная идея была в эмуляции ключей стандартов TouchMemory, Em-Marine и Mifare classic в одном устройстве. Хочется, чтобы это устройство было максимально компактным, в идеале вообще помещалось на связку ключей.
Полгода назад я писал, как решал проблему с ушедшими JLCPCB. И вот с марта возникла новая проблема ахахах (истерический смех) — китайские банки начали блокировать оплату от российских компаний за компоненты для сборки электроники. Оплаты не проходят даже у тех компаний, которые заключили долгосрочные контракты с китайскими производственными площадками.
Из-за этого увеличились сроки, а также ряд компаний начал работать через посредников, что сильно увеличило цену на поставку электронных компонентов.
Я порезал свой первый обзор + добавил несколько новых компаний, которые сейчас напрямую поставляют компоненты и печатные платы из Китая. В конце - сводная таблица с итогами.
Задача выяснить, как влияет “быстрая” зарядка на скорость деградации Li-ion аккумуляторов в устройствах с высоким током потребления.
В рамках исследования провел ряд экспериментов. Эксперимент заключается в зарядке аккумулятора током в 4-5 раз выше номинального. Номинальный ток заряда для исследуемых аккумуляторов от 2 до 5А, я буду использовать ток 20А.
В результате эксперимента будет видно, как “быстрая” зарядка увеличивает скорость деградации аккумуляторов.
В качестве испытуемых выбраны Li-ion аккумуляторы Sanyo NSX и LG 18650HG2 в формфакторе 18650.Выбор формфактора обусловлен тем, что именно данный они чаще всего применяется в устройствах с высоким током потребления. А именно: аккумуляторный электроинструмент, электронные сигареты, мощные фонари и некоторые виды электротранспорта.
Поскольку блокировки интернета в РФ в последние недели и месяцы многократно активизировались, а маразм все крепчает и крепчает, стоит еще раз поднять тему обхода этих самых блокировок (и делаем ставки, через сколько дней на эту статью доброжелатели напишут донос в РКН чтобы ограничить к ней доступ на территории страны).
Вы, наверняка, помните отличный цикл статей на Хабре в прошлом году от пользователя MiraclePtr, который рассказывал о разных методах блокировок, о разных методах обхода блокировок, о разных клиентах и серверах для обходов блокировок, и о разных способах их настройки (раз, два, три, четыре, пять, шесть, семь, восемь, десять, десять, и вроде были еще другие), и можете спросить, а зачем еще одна? Есть две основные причины для этого.
Журнал событий, это компонент systemd, который захватывает сообщения Syslog, логи ядра, все события при инициализации системы (RAM, диск, boot, STDOUT/STDERR для всех сервисов), индексирует их и затем предоставляет удобной пользовательский интерфейс для поиска и фильтрации логов. Журнал (systemd journal) можно использовать вместе или вместо syslog или syslog-ng.
Утилита командной строки journalctl, если сравнивать ее с традиционным инструментами для работы с логами в UNIX (tail, grep, sed, awk) более широкие возможности.
Давайте рассмотрим основные возможности которые предоставляет журнал systemd и способы их применения.
Когда речь заходит о взломе Энигмы, то всегда вспоминают об успехе британцев в Блетчли-парк. Но менее известно, что этот успех был построен на фундаменте, который заложили польские криптографы. История о том, как польские математики первыми смогли взломать легендарную Энигму.
В предыдущей статье мы рассказали, как с помощью модуля GSM/GPRS/GNSS Bluetooth HAT, созданного на базе SIM868, библиотек SIM800L, RoverConnect и Telemetry можно обмениваться данными между микрокомпьютером Repka Pi с JSON-сервисом, доступным в интернете.
Мы привели исходные коды программ на Python, которые можно использовать для такого обмена. Однако за пределами изложения остался рассказ о том, как происходит работа с модулем на уровне AT-команд.
Такая информация нужна для более глубокого понимания принципов работы SIM800 и SIM868 при передаче данных через GPRS (General Packet Radio Service). Она может пригодиться при отладке программ передачи данных, составленных с использованием других библиотек и языков программирования. Также же сведения об AT-командах GPRS потребуются, если вы собираетесь создать свою собственную библиотеку передачи данных в сетях мобильных операторов.
Собираем стенд для работы
Установка и запуск терминала minicom
Документация по AT-командам модуля
Получаем информацию с помощью AT-команд
Инициализация модуля SIM868
Обмен данными через GPRS
Полезные ссылки
Итоги
В предыдущих статьях нашей серии про сервоприводы мы рассказывали, как они устроены, как можно управлять сервоприводами с помощью широтно-импульсной модуляции ШИМ (Pulse Width Modulation, PWM) с помощью контроллеров Robointellect Controller 001, а также напрямую через GPIO через генератор ШИМ на плате микрокомпьютера Repka Pi.
В четвертой статье серии статей про сервоприводы мы расскажем, как управлять сервоприводами с помощью контроллеров Robointellect Controller 001 или PCA9685, подключенных к Repka Pi через шину I2C.
Недавно в своих ежедневных чтениях я наткнулся на явление, о котором думал уже много лет: феномен утечки информации людей, использующих SSH. Этот тип утечки информации не является новым явлением. Я давно предупреждал об этой опасности своих друзей, использующих SSH, но мой голос услышали лишь несколько человек. Поэтому я решил дать пояснения по этому поводу, потому что я считаю, что необходимо понимать этот риск в ИТ-сообществе, особенно в нынешней ситуации. Я буду исходить из предположения, что у вас, дорогой читатель, есть опыт работы с SSH.
if (a == b) {<br> printf("hello");<br>}<br><br>
Несколько лет назад я полностью перешел на Linux, и все меня устраивало за исключением отсутствия некоторых просто необходимых программ.
По мере того как приложение собирает все больше данных, правильное ведение журналов становится решающим фактором для быстрого и эффективного понимания общей функциональности. Это позволяет устранять проблемы до того, как они повлияют на конечных пользователей.
В этой статье мы рассмотрим лучшие практики логирования в Python. Следуя им, вы сможете обеспечить информативность, практичность и масштабируемость генерируемых логов. Давайте начнём!
В отличие от таких операционных систем как HPUX (dbc_min_pct, dbc_max_pct) или AIX (minperm%, maxperm%), в Linux нет возможности настраивать размер кэша страниц, читаемых с диска (страничный кэш, page cache). Под страничный кэш Linux использует всю доступную память. Размер страничного кэша можно увидеть в /proc/meminfo в параметре "Cached". В /proc/meminfo есть также значение "Buffers", которое часто путают с размером страничного кэша. "Buffers" — это память, содержащая сырые дисковые данные (raw disk data) и выступающая в роли промежуточного буфера между процессами, ядром и диском.
В этой статье рассмотрим, как Linux работает с памятью, и, в частности, со страничным кэшем, а также исследуем, как доступный объем памяти влияет на производительность буферизованного ввода-вывода (buffered IO).