Вышел пре-релиз компактного столика для reflow-пайки. Ориентирован на тех, кто любит DIY-электронику. Питается от зарядника USB.

Зачем он нужен:

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

Сборка не требует особой квалификации. Из механических работ – только раззенковать отверстия крепления пластины под потайные винты. Все остальное заказывается в полтора клика на jlcpcb / jlc3dp / lcsc / aliexpress.

Чем отличается от того что есть:

• Размер рабочей зоны 80х70мм. Мелкие столики из доступных на рынке – максимум 50x50мм, всё еще маловато.
• Управление по BLE из браузера. Намного комфортнее настраивать и смотреть, что там вообще происходит.

Самый простой вариант, с нагревателем из алюминиевой платы – до 180°C. Этого более чем достаточно для нижнего подогрева и пайки LTS-пастами. Учитывая, что прожарка платы снизу насквозь – подход немного спорный, с низкотемпературными пастами это достаточно безопасно и прощает ошибки.

Есть вариант головы с MCH-нагревателями, работающей до 300°C (в документации отдельно описаны подробности сборки). Но там пока динамика не очень, проще дождаться новых зарядников PD 3.2 в следующем году, где появятся AVS-профили и станет проще выдурить нужное количество ватт. Технически, можно решить вопрос уменьшением рабочей зоны, но пропадет преимущество в комфортном размере, пока не хочется. Тема очень экспериментальная, с алюминиевой платой нагреватель намного проще и дешевле.

Стоит не забывать, что любой девайс – это баланс фич под конкретные задачи. Этот столик нацеливался в сторону «ненапряжно чилить дома». Если запросы более высокие – значит надо смотреть в сторону печек, но они заметно крупнее.

>>> Репозиторий на гитхабе

Вышел предварительный релиз pdsink. Библиотека ориентирована на разработчиков железа, которым нужна простая поддержка питания по USB PD. Основной упор сделан на режиме SNK, как наиболее востребованном.

Power Delivery (PD) — универсальная спецификация, разработанная как общий стандарт быстрой зарядки, который можно использовать с любыми гаджетами с поддержкой USB-интерфейса. PD существует с 2012 года — примерно с того же момента, когда представили порт USB-C.

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

>>> Репозиторий на гитхабе

Знаете ли вы что… на алике у низкотемпературных паст 70% совсем брак, а остальные еще смотреть надо. Т.е. греем каплю пасты, она сначала растекается, а потом вместо того чтобы собраться в шар - то несколько шаров образует, то вообще пыль во флюсе оставляет.

Когда первый раз паял, получил дикое количество мусорных шаров. И элементы вместо выравнивания уводило куда-то вбок. Полез плакаться к опытным садоводам, и меня «обрадовали». Я конечно в курсе, что с китайскими расходниками всякое бывает, но и представить не мог что с висмутовыми все так плохо. Причем запоминать какой-то конкретный магазин или этикетку - бесполезно.

Со свинцовыми такого ада не было. Есть получше, есть похуже, но так чтобы совсем мусор - не нарывался. Пока остановился на китайкой «wonder way» с амазона, и канадской chip quick с серебром.

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

Всё, я выдохнул :)

Кто имеет опыт работы со встроеннымы операционниками на stm32g4, для токовых шунтов с нижним включением?

Хочется в хоббийных поделках выпилить ina213/ina180, но сцыкотно :). С инструментальниками все понятно - аккуратно подоткнул дифференциальный вход на шунт, и всё «просто работает».

Как будет со встроенными - непонятно. И как разводить чтобы силовых наводок не налипло - тоже.

Токи обычно меньше 5А, больше 10А точно не будет.

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

Перемещено hobbit из general

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

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

Что-то мне подсказывает, что если есть ассистенты для написания кода, то и ревьюеры долны быть. Нюанс в том, что при написании кода обычно работают с отдельными модулями. А для ревью надо целиком проект всосать и большой отчет сгенерить. И я вот навскидку не знаю, чем это сподручнее проделать.

https://github.com/pdsink/pdsink

Пилю USB-PD стек для эмбедов (только Sink), чтобы раз и навсегда закрыть вопрос извлечения ваттов из зарядников. Текущие не устраивают тем, что либо не все фичи поддерживают (chunking, например), либо фик заюзаешь в качестве независимой библиотеки.

Целился специально только в Sink, т.к. Src нужен намного реже, сложность заметно увеличивает, а времени мало. Ну и мне в конце концов надо не идеальную шарообразную библиотеку сделать, а свою reflow-паялку закончить.

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

Есть темплейт, инстанс которого надо юзать в разных файлах (например лог), и которому надо прокинуть строку конфига:

template<const char* filterLabels>
class log {
...
}

Понятно, что инстанс создается в одном месте, а в остальных объявляется через extern.

Но проблема в том, что передаваемую строку надо объявлять в хедере как inline, простого constexpr недостаточно - валится линкер. А inline поддерживается только от c++17.

// без inline - жопа
inline constexpr char labels[] = "foo,bar";

Есть ли какой-то хак для c++11, чтобы строки передавались, и темплейты понимали, что они про одно и то же (а не плодились, роняя линкер)?

Перемещено hobbit из general

Хочется покрыть тестами static_assert. Но без жести с ручным раскомментированием строк тестирования, анализом выхлопа компилятора и т.п.

Вот пример темплейта со статическими ассертами:

    template<typename Func>
    void addMethod(const std::string& name, Func func) {
        using traits = jrcpd::function_traits<decltype(func)>;
        using Ret = typename traits::return_type;
        using ArgsTuple = typename traits::argument_types;

        static_assert(!std::is_same<Ret, void>::value, "void functions not supported");

        static_assert(jrcpd::is_supported_type<Ret>::value, "Return type is not allowed");
        static_assert(jrcpd::check_all_types_supported<ArgsTuple>(), "Argument type is not allowed");

        functions[name] = [func](const JsonArray& args) -> std::string {
            try {
                if (args.size() != std::tuple_size<ArgsTuple>::value) {
                    throw std::runtime_error("Number of arguments mismatch");
                }

                // Check if each argument in JsonArray can hold the appropriate type from ArgsTuple
                if (!jrcpd::TypeChecker<ArgsTuple>::check(args)) {
                    throw std::runtime_error("Argument type mismatch");
                }

                auto tpl_args = jrcpd::from_json<ArgsTuple>(args);
                Ret result = jrcpd::apply(func, tpl_args);
                return jrcpd::generate_response(true, result);
            } catch (const std::exception& e) {
                return jrcpd::generate_response(false, e.what());
            }
        };
    }

Посоветуйте, как сейчас принято такое тестировать.

• https://github.com/puzrin/bt_test/blob/arg_tests/src/json_rpc_dispatcher.hpp - сорец.
• https://github.com/puzrin/bt_test/blob/arg_tests/test/test_json_rpc_dispatcher/test_json_rpc_dispatcher.cpp - тесты.

Плюсов толком не знаю, а код нужен. Поэтому делал на чатгпт :). И чего-то он перестал вывозить. Тупо подогнал имплементацию под тесты, где были функции с 0 и 2 параметрами :). А когда новых тестов добавил - начинает уже совсем бред гнать по кругу.

Помогите нормально сделать темплейты функций. Там надо проверять при «создании», что типы аргументов из списка допустимых. А в рантайме, когда приходит json с именем метода и массивом аргументов - проверить что типы соответствуют зарегистрированной функции, и вызвать ее.

На с++11, т.к. надо под esp32 - там тулчейн староват.

Нужно приконнектить esp32 к вебне по bluetooth:

1. Получать события (апдейты температуры)
2. Дергать полтора метода с простыми параметрами (нагреватель включить, на уровне отправить жысон и получить ответ жысоном)

Каких-либо требований по экономии памяти и потреблению - нет. Т.е. заюзать плюсовый парсер жысона вместо тру протобафа - вообще не вопрос.

Web Bluetooth это GATT. Задуманный в стародавние времена под стародавние задачи, которые теперь не актуальны. Руками уродоваться через GATT properties - штука совсем на любителя. Хотелось бы какую-то молодёжную обертку, которая будет заботиться о нарезке длинных данных, спрячет всё говнище за смузихлёбным rpc / event emitter и т.п. Километры совместимости с версионированием протоколов - не нужны. Чем проще, тем лучше.

Посоветуйте куда копать. Пока не нашел готового решения, которое было бы понятно и нравилось.

Навалял на vue рыбу приложеньки https://puzrin.github.io/reflow_mock/. Теперь пытаюсь понять, как туда втулить поддержку нескольких девайсов.

Допустим, у меня есть полностью виртуальный и реальный девайсы, которые отдают температуру и т.п., a также имеют методы start/stop. Хочется чтобы при переключении на другой девайс все реактивные биндинги продолжили работать, просто забирая данные из другого источника.

Как это положено правильно делать в vue?

Пока в голову пришло сделать проксирующий объект:

const currentDriver = ref(defaultDriver)

// там где переключаем драйвер
currentDriver.value = driverInstance

// это выставляем приложеньке
export driver {
  temperature: computed(() => currentDriver.temperature.value),
  power: computed(() => currentDriver.power.value),
  start: () => currentDriver.start(),
  stop: () => currentDriver.stop()
}

Так годно или есть более кошерные варианты?

https://github.com/joseph2/vue-slide-unlock - что-то типа такого, только более «headless». Не нравится мне как там стили приколочены.

Нужен просто переключатель старт/стоп с защитой от случайного нажатия. Ну и без унылого «modal dialog confirmation». Если есть что-то готовое помимо слайдера - тоже интересно.

Решил написать мелкую веб-приложеньку на vue. Надо делать чем-то разметку и всякие мелочи вроде dropdown menu. Но у меня сложилось впечатление, что привинчивание к vue бутстрапа отдает попыткой привинтить в проект jquery.

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

Пока из полезного нашел:

• vueuse - всякие низкоуровневые ништяки
• TailwindCSS - для общей разметки
• HeadlessUI - мелочи вроде дропдаунов и диалогов, но тут не уверен, стоит ли оно того, или врукопашную навалять.

Посоветуйте, куда стоит копать.

Хочется придумать метрики для двух ситуаций:

1. Гладкость движения цены на отрезке (между датами). Идеальная ситуация - свечи короткие и не сильно отклоняются от прямой. Плохой вариант - свечи большие или отклоняются сильно.

2. «Акцентированность» вершины в зигзаге. Идеальная ситуация - свечи сначала идут к вершине, а затем от нее. Плохая - когда вершина «замазана», т.е. много свечей у экстремума.

Какие есть варианты оценки? Навскидку пока приходит такое:

1. Считать среднеквадратичные отклонения. Возможно, досыпав весовых коэффициентов (чтобы на середине отрезка вес погрешности учитывался слабее)

2. Сделать преобразование фурье, и проверить что энергия не сильно размазана по спектру.

Что еще можно попробовать? Каких-то готовых «индикаторов», с которых можно сколоть алгоритмы, пока не нашел.

Перемещено hobbit из general

https://github.blog/2022-06-24-thank-you-to-our-maintainers/

Майкрософт решил запихать в разработчиков немного денег. Критерий не понятен, но на организации действительно валится по 550 однократными донатами.

Мне тут пришло письмо от гугла, что почтовые аккаунты для доменов будут принудительно апгрейдить на платные, НО(!) если не использовать в коммерческих целях - то можно остаться на халявном, и вроде даже ничего не отвалится.

Типа, как в анекдоте, если не прийти то вычеркивают? Раньше пугали, что останется все кроме почты. Теперь какая-то совсем травоядная страшилка.

Мне тут надо помоделить коробочки, и возникла навязчивая идея купить SLA-принтер навроде Anycubic Photon Mono X 6K.

Правильно ли я понимаю, что надо будет:

• Купить сам принтер
• Купить вторую коробку для засветки-промывки
• Купить канистру изопропилового спирта
• Купить для черновиков любой говносмолы за 15 баксов и на чистовики ABS-like за 50.

Этого будет достаточно для комфортной работы? Или в последний момент обнаружатся какие-то откровения вроде обязательного противогаза, разворачивающие картину мира на 180 градусов?

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

Детальки тестовые, для опенсорсов, в расчете что потом будут заказывать на jlcpcb печать из LEDE 6060. Поэтому тестить хочется на чем-то близком, FDM принтер не хочу, цена SLA-расходников устраивает.

Что еще надо учесть?

Пришло письмо от bankoff, что им терминировали все карты, и заморозили счета с баблом. За большое количество транзакций из России.

Это видимо еще очень жирный намёк любителям карт Казахстана и Киргизии :).

Собираюсь сделать трактор. Как быть с мобильником, на который банки и т.п. пореганы? Типа, если телефон с симкой сопрут, то через доверенности восстанавливать пипец как долго и гиморно.

• кто кроме мтс умеет слать симки за бугор? мтс всё еще умеет?
• может есть дармовое приземление без симки? Мне нужны только входящие SMS, но с местным номером.
• есть ли смысл к засвеченному номеру завести еще один, и перегнать на него все что актуально?
• если надо на что-то еще обратить внимание - напишите.

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

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

То есть, речь о «стабильной» крипте.

• Какой кошелек/биржу посоветуете для «ежедневного использования». С учетом потенциальных банов. И какие варианты бакапов если угнали телефон и т.п.
• Какая крипта лучше для ежедневного использования и длительного хранения.
• Что в европах по законодательству насчет приземления крипты? Купить-то не проблема, но не хотелось бы на выводе претензий про легальность.