Чип видишь? А он есть!

Про серию материалов Блумберга о китайских закладках в материнках Supermicro я скажу коротко — следующим актом драмы я ожидаю исторический полёт главреда из окна санатория с криком «узкоглазые идут!».

Во-первых, предецент есть, во-вторых, ничем другим это объяснить уже нельзя.

https://t.me/sforsecurity/60

Проверка корректности адресов в памяти на Cortex-M0/M3/M4/M7

Одна из весьма полезных и при этом почему-то в готовом виде нигде не описанных возможностей на микроконтроллерах Cortex-M (всех) — это возможность проверки корректности адреса в памяти. С её помощью можно определять размеры флэша, ОЗУ и EEPROM, определять наличие на конкретном процессоре конкретной периферии и регистров, прибивать упавшие процессы при сохранении общей работоспособности ОС и т.п.

В штатном режиме при попадании в несуществующий адрес на Cortex-M3/M4/M7 вызывается исключение BusFault, а при отсутствии его обработчика эскалируется до HardFault. На Cortex-M0 «детализированных» исключений (MemFault, BusFault, UsageFault) нет, а любые сбои сразу эскалируются до HardFault.

В общем случае игнорировать HardFault нельзя — он может быть следствием аппаратного сбоя, например, и дальнейшее поведение устройства станет непредсказуемым. Но в частном случае это делать можно и нужно.

На Cortex-M3 и выше проверка валидности адреса делается достаточно просто — надо запретить все исключения (кроме, очевидно, немаскируемых) через регистр FAULTMASK, отключить конкретно обработку BusFault, а потом ткнуть в проверяемый адрес и посмотреть, не взвёлся ли флажок BFARVALID в регистре BFAR, то есть Bus Fault Address Register. Если взвёлся — у вас только что был BusFault, т.е. адрес некорректный.

Код выглядит так, все дефайны и функции из стандартного (не вендорского) CMSIS, так что должен работать на любом M3, M4 или M7:

bool cpu_check_address(volatile const char *address)
{
    /* Cortex-M3, Cortex-M4, Cortex-M4F, Cortex-M7 are supported */
    static const uint32_t BFARVALID_MASK = (0x80 << SCB_CFSR_BUSFAULTSR_Pos);
    bool is_valid = true;

    /* Clear BFARVALID flag */
    SCB->CFSR |= BFARVALID_MASK;

    /* Ignore BusFault by enabling BFHFNMIGN and disabling interrupts */
    uint32_t mask = __get_FAULTMASK();
    __disable_fault_irq();
    SCB->CCR |= SCB_CCR_BFHFNMIGN_Msk;

    /* probe address in question */
    *address;

    /* Check BFARVALID flag */
    if ((SCB->CFSR & BFARVALID_MASK) != 0)
    {
        /* Bus Fault occured reading the address */
        is_valid = false;
    }

    /* Reenable BusFault by clearing  BFHFNMIGN */
    SCB->CCR &= ~SCB_CCR_BFHFNMIGN_Msk;
    __set_FAULTMASK(mask);

    return is_valid;
}

С Cortex-M0 и Cortex-M0+ всё сложнее, как я сказал выше, у них нет BusFault и всех соответствующих регистров, а исключения сразу эскалируются до HardFault. Поэтому выход один — сделать так, чтобы обработчик HardFault смог понять, что исключение было вызвано преднамеренно, и вернуться обратно в вызвавшую его функцию, передав туда некий флажок, указывающий, что HardFault был.

Делается это сугубо на ассемблере. В примере ниже регистр R5 устанавливается в 1, а в регистры R1 и R2 записываются два «магических числа». Если после попытки загрузить значение по проверяемому адресу случится HardFault, то он должен проверить значения R1 и R2, и при обнаружении в них нужных чисел установить R5 в ноль. В сишный код значение R5 передаётся через специальную переменную, жёстко привязанную к этому регистру, в ассемблер проверяемый адрес — в неявной форме, мы просто знаем, что в arm-none-eabi первый параметр функции кладётся в R0.

bool cpu_check_address(volatile const char *address)
{
    /* Cortex-M0 doesn't have BusFault so we need to catch HardFault */
    (void)address;
    
    /* R5 will be set to 0 by HardFault handler */
    /* to indicate HardFault has occured */
    register uint32_t result __asm("r5");

    __asm__ volatile (
        "ldr  r5, =1            \n" /* set default R5 value */
        "ldr  r1, =0xDEADF00D   \n" /* set magic number     */
        "ldr  r2, =0xCAFEBABE   \n" /* 2nd magic to be sure */
        "ldrb r3, [r0]          \n" /* probe address        */
    );

    return result;
}

Код обработчика HardFault в простейшем виде выглядит так:

__attribute__((naked)) void hard_fault_default(void)
{
    /* Get stack pointer where exception stack frame lies */
    __asm__ volatile
    (
        /* decide if we need MSP or PSP stack */
        "movs r0, #4                        \n" /* r0 = 0x4                   */
        "mov r2, lr                         \n" /* r2 = lr                    */
        "tst r2, r0                         \n" /* if(lr & 0x4)               */
        "bne use_psp                        \n" /* {                          */
        "mrs r0, msp                        \n" /*   r0 = msp                 */
        "b out                              \n" /* }                          */
        " use_psp:                          \n" /* else {                     */
        "mrs r0, psp                        \n" /*   r0 = psp                 */
        " out:                              \n" /* }                          */

        /* catch intended HardFaults on Cortex-M0 to probe memory addresses */
        "ldr     r1, [r0, #0x04]            \n" /* read R1 from the stack        */
        "ldr     r2, =0xDEADF00D            \n" /* magic number to be found      */
        "cmp     r1, r2                     \n" /* compare with the magic number */
        "bne     regular_handler            \n" /* no magic -> handle as usual   */
        "ldr     r1, [r0, #0x08]            \n" /* read R2 from the stack        */
        "ldr     r2, =0xCAFEBABE            \n" /* 2nd magic number to be found  */
        "cmp     r1, r2                     \n" /* compare with 2nd magic number */
        "bne     regular_handler            \n" /* no magic -> handle as usual   */
        "ldr     r1, [r0, #0x18]            \n" /* read PC from the stack        */
        "add     r1, r1, #2                 \n" /* move to the next instruction  */
        "str     r1, [r0, #0x18]            \n" /* modify PC in the stack        */
        "ldr     r5, =0                     \n" /* set R5 to indicate HardFault  */
        "bx      lr                         \n" /* exit the exception handler    */
        " regular_handler:                  \n"

        /* here comes the rest of the fucking owl */
    )

В момент ухода в обработчик исключения Cortex скидывает регистры, которые гарантированно будут испорчены обработчиком (R0-R3, R12, LR, PC…), в стек. Первый фрагмент — он уже есть в большинстве готовых обработчиков HardFault, кроме написанных под чистый bare metal — определяет, в какой именно стек: при работе в ОС это может быть либо MSP, либо PSP, и у них разные адреса. В bare metal проектах обычно априори устанавливается стек MSP (Main Stack Pointer), без проверки — ибо PSP (Process Stack Pointer) там быть не может в силу отсутствия процессов.

Определив нужный стек и положив его адрес в R0, мы читаем из него значения R1 (смещение 0x04) и R2 (смещение 0x08), сравниваем с магическими словами, если оба совпадают — читаем из стека значение PC (смещение 0x18), добавляем к нему 2 (2 байта — размер инструкции на Cortex-M) и сохраняем обратно в стек. Если этого не сделать, при возвращении из обработчика мы окажемся на той же инструкции, которая собственно и вызвала исключение, и будем вечно бегать по кругу. Добавление 2 перемещает нас на следующую инструкцию в момент возвращения.

Далее пишем 0 в R5, что служит индикатором попадания в HardFault. Регистры после R3 до специальных регистров в стек не сохраняются и при выходе из обработчика никак не восстанавливаются, поэтому портить или не портить их — на нашей совести. В данном случае R5 с 1 на 0 мы меняем целенаправленно.

Возвращение из обработчика прерывания делается строго одним способом. При входе в обработчик в регистр LR пишется специальное значение под названием EXC_RETURN, которое для выхода из обработчика надо записать в PC — и не просто записать, а сделать это командной POP или BX (то есть «mov pc, lr», например, не работает, хотя по первому разу вам может показаться, что работает). BX LR выглядит как попытка перехода по бессмысленному адресу (в LR будет лежать что-то вида 0xFFFFFFF1, не имеющее никакого отношения к реальном адресу процедуры, в которую нам надо вернуться), но в реальности процессор, увидев это значение в PC (куда оно ляжет автоматически), сам восстановит регистры из стека и продолжит выполнять нашу процедуру — со следующей после вызвавшей HardFault процедуры благодаря тому, что PC в этом стеке мы руками увеличили на 2.

Прочитать про все смещения и команды можно понятно где, разумеется.

Ну или если магических чисел не видно, то всё перейдёт к regular_handler, после которого идёт обычная процедура обработки HardFault — как правило, это сишная функция, печатающая в консоль значения регистров, решающая, что дальше делать с процессором и т.п.

Использование всего этого просто и понятно. Хотим написать прошивку, которая работает на нескольких микроконтроллерах с разным объёмом ОЗУ, при этом каждый раз используя ОЗУ по полной программе?

Да легко:

static uint32_t cpu_find_memory_size(char *base, uint32_t block, uint32_t maxsize) {
    char *address = base;
    do {
        address += block;
        if (!cpu_check_address(address)) {
            break;
        }
    } while ((uint32_t)(address - base) < maxsize);

    return (uint32_t)(address - base);
}

uint32_t get_cpu_ram_size(void) {
    return cpu_find_memory_size((char *)SRAM_BASE, 4096, 80*1024);
}

maxsize здесь нужен затем, что на максимально возможном объёме ОЗУ между ним и следующим блоком адресов может не быть зазора, на котором сломается cpu_check_address. В данном примере это 80 КБ. Все адреса прощупывать также нет смысла - достаточно по даташиту посмотреть, каков минимально возможный шаг между двумя моделями контроллера, и поставить его в качестве block.

Не благодарите.

Китайские напряжометры

У любого мультиметра с функцией измерения напряжения есть, по большому счёту, две задачи:

  • Показать вам величину, более-менее соответствующую напряжению в цепи, в которую вы воткнули его щупы
  • Не уебать вас током насмерть

В последнее время на почве появления контроллера DTM0660, который обладает программной калибровкой и позволяет любому китайцу сделать мультиметр, удовлетворяющий первому требованию, интернеты наполнились радостными отзывами о всевозможных Аненгах, Холдпиках и прочих продуктах с алиэкспресса, поражающих соотношением цены к качеству.

Хотелось бы, однако, в связи с этим прояснить второе требование.

Начнём с теории. Требования к мультиметру по способности не уебать вас током обычно представлены у него на корпусе надписью в духе «600V CAT III» (если этой надписи нет, то всё плохо), которую обычно понимают в духе «можно измерять до 600 В».

Это не совсем так. Первая часть надписи — «600V» — означает не только способность не сдохнуть при подаче 600 В, но, главное, способность встроенных цепей защиты эффективно сработать в случае, если мультиметр, будучи под напряжением 600 В, сдохнет по причине, напрямую с этим напряжением не связанной (например, вы сунете щупы в трёхфазную сеть в режиме амперметра).

Например, если в мультиметре стоит стеклянный полый предохранитель, рассчитанный на 250 В, то при таком эксперименте он вместо размыкания цепи способен устроить зажигание дуги внутри себя, с дальнейшим взрывом его корпуса и иными неприятными последствиями.

Вторая часть — CAT III — описывает, в каких цепях можно проводить такие эксперименты без риска для своей жизни:

  • CAT I — использование в безопасных цепях питания, гальванически развязанных от электросети
  • CAT II — использование в бытовых внутриквартирных электросетях
  • CAT III — использование в сетях электропитания здания и внутренних электрощитках
  • CAT IV — использование в сетях на вводе в здание

Причина такого деления проста: сети отличаются не только напряжением, но и наличием собственной защиты. Внутриквартиная сеть при коротком замыкании в общем случае может отоваривать вас 16 амперами, прежде чем сработает её пакетник; элетрощит на лестничной площадке — сотнями ампер, а элетрощит на вводе в здание — тысячами. Это само по себе повышает вероятность зажигания дуги вместо обрыва в неподходящем предохранителе, ну а что сделает такой ток с кусочком пластика у вас в руках — можете сами представить.

Кроме того, чтобы не доводить до греха, каждой категории и её номинальному напряжению соответствует также величина импульсов, которые устройство обязано выдерживать без пробоя. Например, 600V CAT II должен выдерживать до 4 кВ, CAT III — 6 кВ, CAT IV — 8 кВ. Максимальная категория — 1000V CAT IV — выдерживает 12 кВ и почти не встречается в природе.

А теперь берём отвёртку и смотрим внутрь нескольких мультиметров (фоточки не мои).

Читать далее

А вот и к кормушке IoT товарищи спешат

Потратил полчаса своего бесценного времени и немного почитал первую редакцию национального стандарта протокола для Интернета Вещей, который нам предлагает ФРИИ и аффилированные с ним «экспертные сообщества», включая, собственно, компанию «Вавиот».

Это, конечно, полный пиздец. Ни один вменяемый эксперт в разработке «стандарта» участия с очевидностью не принимал (и это, конечно, говорит об уровне экспертизы ФРИИ и товарищей примерно всё, ну а также заодно и о Вавиоте — «а король-то голый»), весь текст представляет собой поверхностное описание крайне наивного и простенького протокола, который Вавиот применяет в своих устройствах, при этом не раскрываются детали, необходимые для его реализации на уровне, обеспечивающем совместимость с той же продукцией Вавиота.

Оставляя в стороне тезис о том, что всё это служит исключительно целям рекламы компании Вавиот, а потому подписавшиеся под этим эксперты не заслуживают ничего, кроме «вон из профессии», посмотрим на техническую сторону.

1. Описание физического уровня сводится к тезису «мы используем модуляцию DBPSK и BPSK». Больше ничего содержательного не сказано, только налиты несколько страниц воды, большая часть которых имеет отношение не к физическому уровню протокола, а к характеристикам конкретных устройств и базовых станций (очевидно, просто перепечатаны ТТХ Вавиотовской базовки).

2. MAC-уровень представляет собой простой и наивный протокол, написанный под конкретную задачу. Для обеспечения помехоустойчивости используется кодирование по протоколу zigzag, разработанному в 2001 году.

MAC-уровень обеспечивает примерно нулевую расширяемость за рамки собственных потребностей компании Вавиот. ID устройства — всего 3 байта, некоторые из полей системных пакетов не допускают указания значений, отличных от используемых в текущих устройствах Вавиота (например, невозможно указать напряжение питания ниже 2,0 В, хотя под это поле выделен целый байт), в большинстве случаев над оптимизацией пакета по размеру авторы протокола даже не задумывались.

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

Для пейлоада указано опциональное шифрование XTEA, выбор стандарта шифрования ничем не обуславливается, хотя, вероятно, является следствием использования Вавиотом дешёвых 8-битных микроконтроллеров вкупе с желанием упростить самим себе разработку (для примера: полный цикл шифрования 16-байтного пакета на Cortex-M3 32 МГц по протоколу AES-128 занимает около 100 мкс, поэтому уже на ядрах такого класса рассматриваться как ресурсоёмкая процедура не может).

Добавление при шифровании соли никак не регламентируется, соответственно, в общем случае возможно определение состояния атакуемого устройства по анализу содержимого пакета без его расшифровки.

3. Возможность независимого существования оператора сети передачи данных и производителя устройств стандартом исключается — во-первых, из-за отсутствия у устройств гарантированно уникальных ID, во-вторых, из-за механизма выдачи ключей шифрования (индивидуальный ключ прописывается в прошивку устройства при его производстве). Кроме того, никак не описана архитектура системы в целом, всё, что лежит дальше антенны базовой станции, в стандарт не входит.

4. Соответственно, сама базовая станция также не описана практически никак, если не считать перечисления паспортных характеристик собственной базовой станции Вавиот.

5. В качестве примеров применения описывается исключительно коммерческая деятельность компании «Вавиот», при этом граничные условия применимости стандарта, практические показатели, методики измерения, возможные проблемы и пути их решения не описываются никак — вместо этого предлагаются рекламные тезисы в духе «осуществляется 100% сбор данных со всех устройств, включая данные с устройств, установленных в металлические щиты и полуподвальные помещения» (в то же время имеющиеся у меня в распоряжении сторонние отчёты, например, о деятельности компании «Стриж», использующей то же оборудование и тот же протокол, позволяют усомниться в подобных заявлениях).

Весь так называемый «стандарт» является поверхностной писулькой, представляющей собой недетализированное описание наивного и подверженного простейшим атакам протокола, используемого компанией Вавиот в своих устройствах. Стандарт не позволяет ни организовать выпуск совместимых друг с другом устройств разными производителями, ни обеспечить минимально приемлемый уровень надёжности и защищённости.

Ни один профильный эксперт в разработке «стандарта» с очевидностью участия не принимал.

Более того, в связи с продемонстрированным крайне низким уровнем экспертизы разработчиков «стандарта» и общей очевидной нацеленностью всей работы на продвижение коммерческой продукции компании Вавиот, на данном этапе участие каких-либо сторонних экспертов в дальнейшей разработке, формирование официальных предложений и замечаний по содержанию представляется неблагоразумным.

Такое участие при отсутствии каких-либо гарантий учёта мнений сторонних экспертов приведёт лишь к формальной легитимизации этой работы, что служит исключительно корыстным интересам ФРИИ, компании Вавиот и других инициаторов разработки, уже допустивших выход «стандарта» в его текущем виде в свет.

Единственным разумным выходом из ситуации является полный отказ от поддержки данного «стандарта» в его текущем виде, а также от любого сотрудничества с организациями, его поддерживающими:

  • Комитет по стандартизации «Кибер-физические системы» АО «РВК»
  • Фонд развития интернет-инициатив (ФРИИ)
  • Ассоциация участников рынка интернета вещей
  • ООО «Телематические Решения» (торговая марка «Вавиот»)
  • Некоммерческое партнерство «Русское биометрическое общество»

СР! УВЛ!

Перенесу-ка я это сюда из фейсбука, а то там сгинет, а здесь ещё пригодится — всяких футурологов упромысливать.

Благодаря автоматическому бурению, для выполнения этой когда-то опасной и очень трудоемкой операции теперь требуется меньше людей. Автоматизация буровых вышек означает увеличение производительности при уменьшении количества обслуживающего персонала. Если раньше для обслуживания одной буровой вышки требовалось 20 человек, то скоро достаточно будет 5 человек. Применение новых технологий при бурении нефтяных скважин означает, что из 440 000 рабочих мест, сокращенных во время мирового экономического кризиса, около 220 000 рабочих мест будет потеряно навсегда.

Теперь снова взгляните на график и обратите внимание на скорость падения. Оно заняло всего ДВА ГОДА. Почему так быстро? Нефтяной промышленности действительно не нужны рабочие, поэтому она избавилась от них в первую очередь. В нефтянке можно было заработать очень большие деньги, и когда они текут в карман нескончаемым потоком, не нужно сосредотачиваться на эффективности производства. Быть бережливым и скромным — это не про них. Тем не менее, всё меняется, когда наступают сложные времена. А нынешние времена стали большим испытанием даже для нефтяной промышленности. Одним из факторов резкого падения цен на нефть стало соперничество с еще одним видом технологического прогресса — технологией гидравлического разрыва пласта.

Вы наверняка встречали этот график и примерно такой сопроводительный текст, более того — вы наверняка ещё неоднократно встретите его в выступлениях и презентациях всевозможных футурологов и инноваторов, чаще всего — из числа приглашённых лекторов или сотрудников тех или иных фондов, часто окологосударственных.

Строго говоря, этот график — правда.

А вот прицепленный к нему комментарий — ложь.

Дело в том, что авторы графика специально выбрали временной период, а также сдвинули оси так, чтобы график подтверждал их высказывание. На самом же деле, если посмотреть на статистику обоих показателей с 2000-го года, то выглядит она вот так («0» у обоих графиков совпадает, временные диапазоны совпадают, график занятости — официальная статистика US Dept of Labor, вертикальную ось для него рисовать не стал, абсолютные числа здесь не особо важны):

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

И вот так, лёгким движением руки, тезис «нефтянке больше не нужны люди» превращается в «число людей в нефтянке в расчёте на одну вышку больше, чем когда-либо».

Если же вам когда-нибудь под показ первого графика начнут рассказывать, что нам нужна новая концепция образования, которая научит детей самостоятельно получать знания и учиться всю жизнь, чтобы не погибнуть от железной руки рынка робота, то помните — такое образование существует дольше, чем роботы и нефтедобыча, вместе взятые, и называется «естественнонаучным».

К сожалению, оно явно прошло мимо многих футурологов и визионеров. Ну или они прошли мимо него, тут что совой по пню, что пнём по сове — результат одинаковый.

Охуенные эксперты

В любой публичной технической дискусии рано или поздно появляется человек из левой части диаграммы Даннинга-Крюгера, он же — охуенный эксперт.

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

Обнаруживается охуенный эксперт буквально с первого же выступления по очень характерному признаку — претезнии его многочисленны, критичны, неотразимы и столь неконкретны, что понять, в чём именно они заключаются, невозможно.

Например, в дискуссии об аккумуляторах автомобилей Tesla любого эксперта обычного интересуют чисто практические вопросы — как в батарее такого размера делается балансировка? С каким разбросом подбираются элементы? Есть ли автоматическое выкидывание из цепи вышедших из строя элементов или целых блоков? Интересуют они при этом довольно немногих — в первую очередь тех, кто сам работает с литиевым аккумуляторами, понимает, где именно там в них кладбище домаших животных, а ответы хочет узнать в основном для расширения собственного кругозора. Шарлатан Маск или не шарлатан, ему в общем и целом наплевать.

Охуенные эксперты же делятся на два подвида. Первые — это эксперты начинающие, впервые в жизни столкнувшиеся с обсуждаемой темой накануне вечером; как правило, они выбирают один из понятных им внешних признаков, столь же очевидно наличествующих у обсуждаемого предмета, сколь очевидно не влияющих на его работоспособность никаким образом, и с гневом указывают на него:

— Посмотрите!!! У него же в машине аккумулятор собран из 18650, как у меня фонарик!!!

Эксперты обычные не понимают сопутствующего этому уровня экзальтации — ну, да, 18650, фонарик, ты иди сам фонарик на 80 кВт*ч хоть на батарейках из Ашана собери, чтобы он работал, а потом поговорим, в форм-факторе ли у тебя была проблема. Эксперта охуенного эта реакция, разумеется, не останавливает — он просто считает, что окружающие не замечают вещей, очевидных любому эксперту. Такому, как он, например.

Второй подвид — опытные охуенные эксперты, в головы которых за предыдущие годы удалось вколотить идею о том, что тезиса «вода — мокрая, а солнце — жёлтое» недостаточно для обсуждения мореходных качеств судов на солнечных батареях. К сожалению, понимание этого заняло всё доступное межушное пространство, поэтому больше в голове ничего нет. Впрочем, так как голова в результате в любом случае заполнена от края до края, пусть и всего лишь одной мыслью, пустоты в ней охуенный эксперт не чувствует — а значит, выступать ему это не только не мешает, но даже помогает.

На фоне неопытного охуенного эксперта опытный звучит значительно увереннее, хотя, если вслушаться в его речь, конкретики в ней не то что ещё меньше — её там нет вообще. Обычно это выглядит так:

— Но так же ведь просто нельзя проектировать автомобили, здесь сразу кучу грубейших ошибок, ну почитайте, если вам такие вещи непонятны, хоть какие-нибудь учебники, там же всё это описано уже двадцать лет назад!

Хотя вступление звучит многообещающе, быстро выясняется, что охуенный эксперт не может сформулировать, что конкретно нельзя, какие конкретно ошибки допущены, а также в каких конкретно учебниках что конкретно написано. Начиная ощущать тревогу, охуенный эксперт второго подвида быстро встаёт в защитную стойку и начинает уничтожать собеседников меткими вопросами:

— Нет, вы сначала ответьте, у него вообще аккумуляторные шины из бескислородной меди сделаны, или нет?

Оппонент, профессионально проектирующий системы автономного питания всего лишь десятилетие, в этот момент понимает, что до сих пор он ни разу не задумывался о том, какой процент кислорода содержит медь в токонесущих шинах — а также, собственно, какое это имеет значение и какой ответ — правильный.

В этот момент важно понять, что в беседе с охуенным экспертом оба ответа — неправильные для вас.

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

В связи с чем никакого смысла вести с охуенным экспертом дискуссию нет.

Напротив, надо сразу переходить к оскорблениям.

Работы пост

Хочу инженера-схемотехника. Можно студента.

Что делать: разрабатывать электронику сравнительно невысокого уровня сложности. Нарисовать принципиальную схему, подобрать элементную базу, нарисовать плату, подготовить файлы для производства.

Уровень сложности: невысокий. Полностью самостоятельное ведение проекта не требуется, по всем вопросам есть с кем консультироваться. Платы средней сложности: не будет параллельных шин, напряжений выше 600 В, частот выше 3 ГГц, слоёв больше четвёртого, норм меньше 0,15 мм, корпусов в BGA и т.п. Умеющие это люди есть, нужен человек на достаточно банальные текущие проекты. Обязательно будут микроконтроллеры, несложные радиотракты, гальванические развязки, иногда дифференциальные линии, вопросы минимизации энергопотребления, вопросы безопасности и искрозащиты.

Если что-то из этого непонятно — научим, но хотеть учиться надо в первую очередь самому, за ручку водить никто не будет.

Среда разработки: DipTrace. Потому что Altium — это дорого, а остальное — говно, слова «KiCad» и «Eagle» при мне даже не произносите, я не знаю, как и зачем вы этим пользуетесь. DipTrace несложный, имея опыт любого другого CAD, за выходные можно базовые вещи освоить — так что мозги между ушей важнее, чем опыт работы именно с DT.

Условия: можно в офисе постоянно, можно иногда появляться. Неполный рабочий день ok, см. в начале про студента.

Есть кто?

Мощный удар по британским учёным

Прекрасный пример «удовлетворения личного любопытства за государственный счёт», а также к термину «британские учёные» можно добавлять «диснеевские учёные».

Люди сделали серьёзное лабораторное исследование по конструированию IoT-датчиков с пассивным —
то есть практически не потребляющим энергию — радиопередатчиком, при том, что результат этого исследования был очевиден заранее.

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

Соответственно, управляя нагрузкой, можно регулировать вторичное излучение антенны, передавая таким образом какие-то данные.

Так работают RFID-метки — не те, у которых дальность несколько сантиметров, у них индуктивная связь, а дальнобойные, на 5-10 метров; наведённого в их антенне им хватает даже на питание их крошечных мозгов, так что батарейки они не имеют вовсе.

Проблема в том, что такие системы фантастически неэффективны. В том же Wi-Fi передатчик выдаёт в эфир до 100 мВт (+20 дБм), типовая сила сигнала на приёмнике при этом — в районе -40 дБм на расстоянии всего лишь в несколько метров. -40 дБм — это 0,1 мкВт. Ещё раз, капслоком: ОДНА ДЕСЯТАЯ МИКРОВАТТА. Для сравнения — даже у маломощных активных устройств в тех же системах «умного дома» излучаемая мощность обычно не меньше нескольких милливатт, при этом пробивная способность таких устройств не превышает 2-3 железобетонных стен; более дальнобойные имеют мощность до 25 мВт.

На практике такие системы «обратного рассеяния» в результате и используются только в вышеупомянутых дальнобойных RFID-метках, и там передатчик вкачивает в эфир до 1 Вт мощности. В остальных случаях они попросту бессмысленны: так, есть много работ по Wi-Fi backscattering, в которых используется излучение Wi-Fi-роутера (и это логично, т.к. роутер можно считать присутствующим всегда), но при получаемой дальности порядка 5 м практическая ценность этого очень невелика.

Собственно, вся научная новизна «диснеевских учёных» заключается в том, что они предложили использовать многоантенную широкодиапазонную систему, которая будет выгребать энергию со всего спектра. Правда, в конце почему-то постеснялись сказать, что уверенная дальность выше 10 м прямой видимости у них получалась исключительно при работе на частоте УКВ-радиостанции, фигачащей в эфир 1,75 кВт в 270 метрах (sic!) от их офиса, а больше 15 метров — только при расположении рядом с «безбатарейным» устройством непрерывно работающего на передачу смартфона.

Прочитав последнее, сходу решил предложить дальнейшее развитие проекта — ведь и мобильник этот можно питать от термоэлемента, повешенного на печку! Чем топить печку? Ну, можно литиевыми аккумуляторами, они отлично горят.

Эффективность и осмысленность получится такая же.

STM32L1 power consumption on NUCLEO-L152RE above 200 uA in all sleep modes

Пациент: отладочная плата ST NUCLEO-L152RE (и другие аналогичные)

Симптомы: даже в режиме Stop потребление микроконтроллера превышает 200 мкА (измеренное через джампер IDD)

Лечение: ток утекает через интерфейс JTAG. На платах NUCLEO JTAG не отключается от микроконтоллера, но проблему можно решить, подключив питание следующим образом:

  1. JTAG — через кабель miniUSB к порту компьютера
  2. Основную плату — к внешнему источнику +5 В через контакты «5V» и «GND»
  3. Переключатель PWR — в положении «E5V»

При таком подключении JTAG-адаптер работает в штатном режиме, однако, если после заливки прошивки выключить и снова включить внешнее питание +5 В, JTAG отключится от контроллера, и потребление последнего в глубоком сне упадёт до положенных 1-2 мкА. Если вам потребуется залить новую прошивку — просто запустите ST-Link/OpenOCD/etc., а после заливки снова передёрните внешнее питание.

Читать далее