Эстетически прекрасное руководство по LaTeX для полных новичков.

Легко читается и хорошая подборка ссылок и литературы, куда идти за конкретными темами. Самое главное, оно написано из 2020х, с учетом современных реалий.
[pdf] [github]

любимая книга Андрея @hardware_design в удобном веб-формате. есть ощущение, что зумерскому мозгу намного легче воспринимать текстовую информацию с html-страничек.

https://the-epic-file.com/text/bookz/aoe_3/aoe3_contents.htm

камбэк года

Особенности микроконтроллеров от Espressif💎

Речь пойдёт именно о серии ESP32.
- ESP32 - только у него есть классический Bluetooth, годится для многих классических применений, в частности, для Bluetooth-аудиосистем
- ESP32S2 - может удерживать подключение к WiFi даже находясь в некоторых спящих режимах, но одноядерный во всех вариациях; первый контроллер с поддержкой Flash до 128 МБ, интерфейсом под дисплей и USB
- ESP32S3 - 2 ядра и варианты с бОльшим количеством Flash и PSRAM (PSRAM до 16 МБ); даа варианта ULP-сопроцессора: FSM (который на ассемблере), и RISC-V
- ESP32C3 - первый контроллер на RISC-V-ядре; как правило, имеют встроенную Flash на 4 МБ
- ESP32C6 - первый контроллер с поддержкой WiFi 6 (но только в 2.4 ГГц)
- ESP32H2 - контроллер с беспроводным интерфейсом, но без WiFi, только BLE/ZigBee/Thread
- ESP32P4 - первый контроллер со вторым USB 2.0, есть MIPI-интерфейсы под дисплей и камеру, Ethernet, но нет своего беспроводного интерфейса (если нужен, подключается внешний контроллер с беспроводным интерфейсом и используется esp-hosted)
- ESP32C5 - первый контроллер с 5 ГГц

Сегодня попался, наверное, самый подробный гайд по основам проектирования для 3D-печати (FDM/FFF) из всех какие я видел.

Монументальный, отлично структурированный и красиво оформленный пост в блоге (с чеклистом!), который построен по принципу: золотое правило + его иллюстрированное объяснение. Таких правил там больше 40 штук.

Это не мейнстрим советы для новичков о том как избавиться от узинга и варпинга в подаренном на день рождения принтере, а набор коротких заметок о том как чертить, чтобы хорошо печаталось, выглядело, работало и не разваливалось. Особенно радует, что в гайде сделан акцент на функциональные детали, а не на low-poly фигурки покемонов и цветочные горшки.

Если честно, некоторые кусочки я бы предложил почитать даже тем инженерам по механике, которые проектируют под субтрактивные способы производства и даже литьё. А то бывает такое начертят, что потом стыдно китайцам показывать. 😀

Уверен: каждый найдёт там для себя что-то новое и полезное. Страница отлично сохраняется в pdf, если вы такое любите.

https://blog.rahix.de/design-for-3d-printing/

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

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

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

С другой стороны, никто не обещал, что будет легко. Вот в какой-нибудь Киргизии или Нигерии вообще никакой электроники нет, всё везут из Китая.

Принято считать, что язык Си очень простой. Оригинальная книжечка Кернигана и Ритчи — это всего 200 страниц. Однако, учитывая специфику применения Си (низкоуровневые приложения), здесь можно найти немало тонкостей, о которых мало где слышно.

Я решил написать несколько заметок о неочевидных приколах языка Си.

⚡️Битовые поля.
Часто одна байтовая переменная содержит несколько значащих бит, обозначающих что-то сепаратное, и эти биты обычно приходится выделять масками. Не приходится, если использовать битовые поля.
Пример.

typedef union
{
    uint8_t all;
    struct
    {
        uint8_t idle_state : 1;
        uint8_t erase_reset : 1;
        uint8_t illegal_command : 1;
        uint8_t crc_error : 1;
        uint8_t erase_sequence_error : 1;
        uint8_t address_error : 1;
        uint8_t parameter_error : 1;
        uint8_t __res : 1;
    };
} MIK32SD_R1_Response_TypeDef;

Ответ SD-карты типа R1 легко разобрать побитово, если байтовый ответ присвоить члену all, а затем в отдельных if'ах проверить каждый бит.

⚡️alignment

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

С ростом разрядности процессора появляется проблема. Процессор обязан уметь читать и записывать объём информации, равный машинному слову, за одну инструкцию, иначе профит от увеличения разрядности во многом теряется. Но при этом нужно уметь читать и записывать байтную информацию, это удобно для многих приложений, скажем, для работы с ascii-строками. Если процессор 32-разрядный, то хорошо бы ещё уметь адресовать 16-битные полуслова, так как некоторые переменные целесообразно делать именно 16-битными. Итого имеем множество способов обращения в память, и сделать устройство управления, которое допускало бы все сценарии обращений, очень тяжело.

Выход: сделать систему чтения памяти, которая всегда читала бы 32-разрядное слово, чей адрес описывается битами A31-A2. При команде lw (чтение 32 бит) слово сразу бы передавалось в регистр. При команде lb (чтение 8 бит) конкретный байт выбирался бы битами A1 и A0 и передавался бы в младший значащий байт регистра. При команде lh (чтение 16 бит) нужное полуслово выбиралось бы битом A1 и следовало бы в младшее значащее полуслово регистра.

Собственно, так и сделано в RISC-V.

Из минусов: команда lw применима только к двоичным адресам, которые оканчиваются на 2 нуля. То есть, обратиться в ячейку 0x1234 можно, а 0x1235 — нет, процессор выкинет исключение "load address misaligned", "адрес загрузки не выровнен". Аналогичная ситуация с командой lh, она неприменима к нечетным адресам.

Компилятор, зная данную особенность процессора, размещает переменные в памяти как надо, чтобы не вызывать конфликтов выравнивания при обращении и использовать статическую память оптимально.

Однако есть 2 вещи, где порядок переменных пользователь определяет сам: структуры и аргументы функций. Аргументы функций сейчас трогать не будем, а вот структуры рассмотрим подробнее.

Я создал тип данных-структуру:

typedef struct
{
    uint32_t dummy1; //4
    uint8_t dummy2;  //1
    uint32_t dummy3; //4
    uint8_t dummy4;  //1
    uint8_t dummy5;  //1
} my_struct_t;

И вроде бы она должна занимать в памяти 4+1+4+1+1=11 байт, но если посмотреть размер через sizeof, получим:

Size of struct: 16
Object address: 02003FE0

На поле dummy1 компилятор выделяет 4 байта. Адрес начала объекта-структуры делится на 4 нацело. Если бы на dummy2 был выделен 1 байт, то абсолютный адрес dummy3 уже не был бы кратен 4, и процессор не смог бы быстро читать поле dummy3. Поэтому на dummy2 выделяется аж 4 байта, где 3 байта никак не используются, это пустышки. Чтобы адреса переменных за структурой были так же выровнены, после полей dummy4 и dummy5 идут еще 2 байта-пустышки. Итого получаем 16.

5 байт драгоценной ОЗУ улетели в трубу. Ужас!
Иногда экономия памяти важнее производительности, и на этот случай в компиляторах GCC существует атрибут packed:

typedef struct __attribute__((packed))
{
    uint32_t dummy1; //4
    uint8_t dummy2;  //1
    uint32_t dummy3; //4
    uint8_t dummy4;  //1
    uint8_t dummy5;  //1
} my_struct_t;

В этом случае структура будет плотно "сжата", и пустышек не будет:

Size of struct: 11
Object address: 02003FE4

Но в то же время обращение к полю dummy3 очень сильно усложнится. Для простого чтения поля процессору придется дважды читать 32-разрядные ячейки, дважды применять инструкцию сдвига и еще применить инструкцию логического ИЛИ. Атрибут packed — это очень радикальная вещь, и лучше его не использовать. Вместо этого предлагается оптимальнее расставлять переменные в структуре.

typedef struct
{
    uint32_t dummy1; //4
    uint32_t dummy3; //4
    uint8_t dummy2;  //1
    uint8_t dummy4;  //1
    uint8_t dummy5;  //1
} my_struct_t;

Здесь компилятору приходится вводить лишь одну пустышку, и память удается сэкономить.

Size of struct: 12
Object address: 02003FE4

⚡️alignment-2

Собственно, слово "alignment" означает "выравнивание". В 16-разрядных машинах адреса переменных выравниваются по 2 байта, в 32-разрядных — по 4 байта. Но иногда нам нужно выровнять переменные так, чтобы их адреса были кратны какой-то большей степени двойки. Для этого в GCC существует атрибут aligned.

Рассмотрим на примере.

typedef struct __attribute__((aligned(8)))
{
    uint32_t dummy1; //4
    uint32_t dummy3; //4
    uint8_t dummy2;  //1
    uint8_t dummy4;  //1
    uint8_t dummy5;  //1
} my_struct_t;

Size of struct: 16
Object address: 02003FE0

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

typedef struct __attribute__((aligned(128)))
{
    uint32_t dummy1; //4
    uint32_t dummy3; //4
    uint8_t dummy2;  //1
    uint8_t dummy4;  //1
    uint8_t dummy5;  //1
} my_struct_t;

Size of struct: 128
Object address: 02003F00

Адрес действительно выравнивается, теперь он стал кратен 128.
Кстати, интересно, что абсолютное значение адреса уменьшилось. Это потому что я создаю объект в теле функции main, не помечая его ключевыми словами volatile или static, и этот объект лоцируется в область стека, которая растет сверху вниз. То, что адрес стал меньше, значит, что под объект было выделено больше памяти в стеке.

P.S. Кстати, атрибут aligned сильнее, чем атрибут packed. Если написать так:

typedef struct __attribute__((aligned(128), packed))
{
    uint32_t dummy1; //4
    uint32_t dummy3; //4
    uint8_t dummy2;  //1
    uint8_t dummy4;  //1
    uint8_t dummy5;  //1
} my_struct_t;

Результат будет тот же, что и раньше.

Size of struct: 128
Object address: 02003F00