Сразу упомяну, что я не в России, санкционные проблемы меня не касаются.

Покупаю ноутбук, сертифицированный для RHEL. Планирую на него установить, собственно, RHEL. Вижу два варианта - либо купить лицензию ($180/год), либо использовать его бесплатно с Developer License. Хочу понять - а зачем, собственно, платить? Поддержка в эту цену не входит. Ещё и непонятная мне приписка «Is not intended for production environments.» (это у платной версии).

Там есть подписка за $300/год, с ней всё понятно, там поддержка включена и нет странной приписки про production.

Причём Developer License можно использовать на 16 физических и 16 виртуальных машинах, а платную только на 1 физической и 1 виртуальной (ну про физическую понятно, а вот про виртуальную - прям вообще не понятно).

В общем я смущён всей этой политикой. Деньги заплатить я готов, но хочется понимать - за что.

Наткнулся на такой код в спринге:

PropertyMapper map = PropertyMapper.get().alwaysApplyingWhenNonNull();
map.from(settings::readTimeout).asInt(Duration::toMillis).to(this::setReadTimeout);
map.from(settings::connectTimeout).asInt(Duration::toMillis).to(this::setConnectTimeout);

Пришлось его скопипастить, потому, что при всей его гибкости как-то не очень он гибкий оказался там, где мне надо. Долго вкуривал, что тут написано, в итоге переписал по-простому:

if (settings.readTimeout() != null) {
  setReadTimeout(settings.readTimeout());
}
if (settings.connectTimeout() != null) {
  setConnectTimeout(settings.connectTimeout());
}

Да, я понимаю, что тут два раза вызывается геттер settings.xxx и это чисто теоретически может привести к багу… Но по-моему это мелочь. А то, что код нечитаемый получился сверху, это вообще не мелочь.

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

В лиспе есть чудесное свойство: код и данные выглядят одинаково. Это позволяет очень легко и естественно писать код, генерирующий другой код. Что называется макросом.

Однако в индустрии данный подход применяется нечасто.

К примеру в С используется отдельный язык, генерирующий текст (препроцессор).

В С++ используется отдельный язык на шаблонах для метапрограммирования.

В Scheme тоже изобрели отдельный язык.

Из похожих подходов я видел только D, в котором можно написать функцию, возвращающую текст. Эту функцию можно вызывать во время компиляции и её результат компилятор тоже откомпилирует. Этот подход похож на лисп, хотя и гораздо менее удобен. Но больше нигде я такого не видел.

Если говорить про не-лисповые языки, то естественным кажется ввести официальный API для AST (по сути там ерунда) и разрешить писать функции, возвращающие этот самый AST. Это будет всё же лучше, чем текст и концептуально более похоже на лисп. Но я такого не видел. Разве что в Java есть annotation processor-ы, но и там такой подход это на уровне хаков скорей.

Можно сказать, что достаточно популярен подход, при котором генерируется исходный код перед компиляцией, к примеру из openapi спецификации. Это близко к постановке задачи, но всё же не совсем то.

Мне кажется идея генерировать код тем же языком, которым он пишется, на 100% естественной и удачной. Единственное, что я бы тут дополнил - сохранять весь этот сгенерированный код в хорошо отформатированном виде где-то в каталоге с остальными артефактами сборки и предоставлять простую навигацию, чтобы не нужно было гадать, что же там эти макросы нагенерировали. Но это уже мелочи и вопрос инструментария, а не что-то фундаментальное.

Почему же так не делают? Зачем почти в каждом языке изобретают какие-то особые пути для метапрограммирования?

Присматриваюсь к ThinkPad T15p

Вроде нравится, но там видеокарта nvidia, мне это не надо.

Там процессор i7-12700H. На сайте Intel написано, что он «Intel® Iris® Xe Graphics eligible». Не очень понятно, что это значит.

Я хочу, чтобы линукс грузился и работал со встроенной видеокартой от Intel. А nvidia я может быть или для вычислений буду использовать, если вдруг сподобится, или винду в виртуалке запускать и туда пробрасывать.

Получится ли такой план на этом ноутбуке? Пробовать возможности нет.

У многих команд параметры можно указывать в коротком виде (например -r) или в длинном виде (например --recursive) Вроде всегда читал, что короткие параметры нужно использовать для интерактивных shell-сессий, а длинные в скриптах. Но всегда ли это так?

Как вы думаете, как лучше писать в скриптах? Несколько примеров ниже

mkdir -p a/b
mkdir --parents a/b
curl -fLsS "${url}" | tar -xzv -C /opt
curl --fail --location --silent --show-error "${url}" | tar --extract --gzip --verbose --directory=/opt

Честно говоря я в затруднении. Лично для меня mkdir -p читается и понимается проще, а что такое --parents я и не сразу соображу.

У меня есть телефон с разлоченным бутлоадером. Хочу залочить. Гружусь в fastboot, выполняю fastboot flashing lock, после этого телефон при загрузке выдаёт «Your device software can’t be checked for corruption. Please lock the bootloader.». Если разлочить, то грузится нормально. Что ему надо? Телефон Xiaomi Mi A2.

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

Mail -> Webmail

Idea -> VS code (в браузер пока не переехал, но хочу)

Gimp -> Photopea

Ventrillo -> Discord

Вот вчера задолбал Strongbox и я переехал в KeeWeb. Причём даже ставить не стал, в браузере прекрасно работает, синхронизирируясь с дропбоксом.

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

А у вас как?

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 9: подключаем libc

libc это стандартная библиотека языка С. До сих пор мы избегали использования любых функций из стандартной библиотеки, если бы мы попробовали это сделать, то линкер выдал бы ошибку.

( читать дальше... )

Пишу прошивку для девайса. Он в том числе взаимодействует с ПК по USB.

Имеется внешний кристалл на 25 МГц. Имеется внутренний резонатор на 8 МГц. Также имеется два внутренних умножителя и набор делителей.

Для USB-периферии я из 25 МГц получаю 48 (25 / 5 * 8 / 10 * 12).

SYS тактирование я могу выбрать либо от этих 48, либо от кристалла (25) напрямую, либо от внутреннего резонатора (8). Сейчас я беру 48.

Далее я через множитель могу это значение поделить и настроить частоту AHB шины. Сейчас я делю на 8, получаю 6 МГц. На этой частоте работает процессор.

Далее мне нужно получить частоты для шин APB1 и APB2. Сейчас я APB1 делю на 16, получаю 375 kHz и APB2 делю на 4, получаю 1.5 MHz.

Собственно это всё я настроил исходя из принципа - чем меньше, тем лучше. На 3 МГц у меня USB не завёлся, соответственно поставил 6.

На шине APB2 у меня крутится таймер, через который я делаю микросекундные задержки для USB, поэтому её тактирую повыше (таймер использует двойную частоту, 3 МГц).

Каких-то требований на данный момент у меня нет (точней они такие небольшие, что подойдёт что угодно, к примеру у меня ещё будет SPI, для которого нужна скорость не ниже 110 КГц и передавать данные по USB я буду со скоростью примерно 15 КБ/с.

Есть ли какие-то соображения, по которым стоит запитать AHB шину не от делителя USB? Если запитывать от 25 МГц кристалла, то делить на ровные числа не получается, а частота в 25 МГц мне кажется избыточной, хотя изначально так и делал. Запитывать от 8 МГц резонатора кажется странным при наличии внешнего кристалла.

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

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 8: используем CMSIS

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

( читать дальше... )

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 7. Hello world через UART

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

( читать дальше... )

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 6. Мигаем с таймером

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

( читать дальше... )

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 5: Мигаем на C

Эта часть будет комбинацией частей 3 и 4. Мы перепишем код из части 3 на C, используя «инфраструктуру» для сборки из части 4 и познакомимся с некоторыми не всегда очевидными моментами, которые надо помнить при работе с микроконтроллером из кода на C.

( читать дальше... )

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 4: Начинаем работать с C

Знание ассемблера важно, но многие программы разумней писать на C. В этой части мы напишем простую программу на C, скомпилируем её, исследуем получившийся объектный файл, правильно скомпонуем и запустим. После этого ещё немного изучим gdb.

( читать дальше... )

Вроде ничего особенного в нём нет, но маркдаун ломает. Использую '''c (для подсветки). Если не указывать C, то всё работает. Судя по разметке там какой-то детект XML срабатывает или что…

Не ломает:

static void enable_usart(void)
{
    uint32_t rcc_base_address = 0x40021000;
    uint32_t rcc_apb2enr_address = rcc_base_address + 0x18;
    uint32_t rcc_apb2enr_iopben = 1 << 3;
    uint32_t rcc_apb1enr_address = rcc_base_address + 0x1c;
    uint32_t rcc_apb1enr_usart3en = 1 << 18;
    uint32_t gpiob_base_address = 0x40010c00;
    uint32_t gpiob_crh_address = gpiob_base_address + 0x04;
    uint32_t gpiox_crh_mode10_0 = 1 << 8;

Ломает:

static void enable_usart(void)
{
    uint32_t rcc_base_address = 0x40021000;
    uint32_t rcc_apb2enr_address = rcc_base_address + 0x18;
    uint32_t rcc_apb2enr_iopben = 1 << 3;
    uint32_t rcc_apb1enr_address = rcc_base_address + 0x1c;
    uint32_t rcc_apb1enr_usart3en = 1 << 18;
    uint32_t gpiob_base_address = 0x40010c00;
    uint32_t gpiob_crh_address = gpiob_base_address + 0x04;
    uint32_t gpiox_crh_mode10_0 = 1 << 8;

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 3: мигаем светодиодом

Мигание светодиодом это традиционный hello world для микроконтроллеров. Это один из самых простых способов взаимодействия с окружающей средой без помощи отладчика. В этой части именно этим мы и займёмся.

Сразу оговоримся, что эта часть и далее уже очень сильно зависят от конкретного процессора и даже платы. Все адреса приведены со ссылками на reference manual, что должно помочь в переводе кода на другие процессоры.

( читать дальше... )

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

Хочется запускать этот сервис на другом компьютере и перенаправлять входящие и исходящие подключения соответствующим образом. Также хочется минимизировать настройки iptables и подобного и обойтись userspace-софтом.

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

Разумно ли использовать такую конфигурацию в продакшне? Настроить поднятие ssh-соединения через systemd-юнит в принципе несложно, но я никогда не видел, чтобы так делали. Насколько это разумно?

В качестве альтернативы видится поднятие специализированного прокси-сервера на удалённом компьютере, а также http reverse proxy (вроде nginx) на удалённом компьютере. Этот вариант кажется более «продакшн», но несёт с собой уйму дополнительных усилий по управлению всем этим добром, включая безопасность, которая в ssh обеспечивается автоматически.

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

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Часть 2: пишем простейшую прошивку

Вообще говоря, прошивка уже была описана в первой части. Нам нужно создать такой файл, в котором будет записано некое число из четырёх байтов, которое процессор присвоит регистру sp, далее там будет записан, к примеру, адрес 0x08000131 в следующих четырёх байтах, далее будут располагаться 296 нулевых байтов (0x130 - 4 - 4 = 304 - 4 - 4 = 296), а за ними 2 инструкции по 4 байта, которые и будут что-то делать. Итого файл прошивки должен занимать 4 + 4 + 296 + 4 + 4 = 312 байтов. Содержимое этого файла мы запишем в микроконтроллер по адресу 0x08000000, где и располагается флеш-память.

( читать дальше... )

Часть 1 Часть 2 Часть 3 Часть 4 Часть 5 Часть 6 Часть 7 Часть 8 Часть 9

Все файлы можно взять тут (github.com).

В данной серии статей мы попробуем поработать с процессором STM32 с помощью GNU утилит, немного познакомимся с ассемблером и отладкой.

Примеры написаны для популярной платы blue pill, построенной на микроконтроллере STM32F103C8T6.

( читать дальше... )

Я тут в очередной раз пытаюсь освоить программирование микроконтролеров. Захотелось написать такой полу-ЖЖ, полу-туториал (как говорится - хочешь разобраться в чём-то, объясни это другим). Может кто почерпнёт или подскажет чего полезного.

Если интерес будет, буду продолжать.

Итак осваиваем STM32 не как нормальные люди.

Примерный план:

1. Подключить его к компьютеру и убедиться, что там что-то происходит. Использовать будем st-util и gdb.

2. Написать простейшую программу на ассемблере, которая в цикле прибавляет регистр, скомпилировать из неё прошивку, залить на плату и пронаблюдать её работу. Использовать будем binutils и st-flash.

3. Поморгать диодом (на ассемблере же).

4. Переписать осмысленный код на С (дальше всё на С).

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

6. Сказать внешнему миру «Hello world» через UART.

7. Переписать «Hello world» с помощью CMSIS, уже с пониманием того, что там происходит.

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

Сразу скажу, что в процессе будет использовано достаточно много инструментов вроде make, ld, gdb, as, gcc и тд, по каждому из них можно книги писать (и пишут). Поэтому, конечно, углубляться в них я не буду, а напротив буду использовать в максимально примитивном виде.

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

• STM32F103xx Reference Manual. Тут вся справочная информация по всем битам и байтам конкретного микроконтроллера.
• STM32F10xxx Programming manual. Тут справочная информация по ARM: все инструкции, описание работы процессора.
• GNU debugger GDB. Это отладчик.
• GNU make
• GNU linker ld
• GNU assembler as