Dmitry Muravyev 

Подготовил для вас подробный отчёт о моих изысканиях в области JBC-совместимых паяльных станций. Конечно же, не на пустом месте, а по результатам вскрытия моей новой трансформаторной паяльной станции SUGON T60. Чтобы понять насколько всё хорошо или плохо сделано, буду сравнивать её со схемой хоть и устаревшей, но зато оригинальной паяльной станции JBC CD-2BC. Она тоже трансформаторная, долгое время была очень популярна и до сих пор продаются её китайские клоны, поэтому я считаю, что такое сравнение будет и уместным и интересным. Посмотрим, можно ли за меньшие деньги предоставить больший (и при этом полноценный) функционал, ну и надеюсь вы сможете получить общее представление о том, чего ожидать от паяльных станций под брендом SUGON. Обратите внимание, что в других странах они могут продаваться под другими брендами, например, на Amazon можно найти продукты этого производителя под брендом X-Tronic.

Для начала приведу технические характеристики, заявленные производителями обеих станций:

- Net Weight: 2.6 kg (5.7 lb)

- Size: 150x175x145 mm

- Voltage(AC): 230V

- Input Fuse: 1A

- Output Peak Power: 130W / 23.5V

Выложил минимально рабочую версию прошивки контроллера вентиляторов! Это далеко не финальный вариант, в нём ещё будут корректироваться ошибки (которых там наверняка полно, поскольку функционал достаточно богатый и я ещё не всё успел проверить). И хотя без управляющего софта бОльшая часть плюшек недоступна, но это уже по-настоящему рабочая версия, а инженерная версия управлялки у меня сейчас в работе и я очень надеюсь, что в каком-то виде я смогу её выпустить до НГ.

Думаю, для начала будет полезно привести список фич прошивки, а потом уже я остановлюсь на некоторых из них более подробно:

✔️ Плавная линейная регулировка ШИМ и питания. Резкие изменения не допускаются.

✔️ Автоматическое определение состава оборудования для каждого из 6-ти каналов:

  - ШИМ,

  - датчик оборотов,

  - MOSFET,

  - DC-DC,

  - вольтметр.

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

Собственно, этот пост как раз и призван ответить на главный вопрос жизни, вселенной и всего такого:

А потому, что тестирование на реальных вентиляторах занимает гигантское количество времени. Ниже будет понятно о чём речь, но просто для примера: поначалу, пока я ещё не определился с алгоритмами сканирования вентиляторов и не подобрал для них приемлемые параметры, на каждый вентилятор (а я тестирую сразу 6 разных) у меня уходило до 20 минут и более. Очень надеюсь, что по крайней мере с первой версией платы мне не придётся возвращаться к этой задаче. Во всяком случае, MVP я совершенно точно выложу на том, что уже сделано.

По той же причине некоторые работы мне пришлось отложить. В частности, аппроксимацией буду заниматься уже когда дело дойдёт до второй версии и её прошивки (там как раз планируется STM32G431, а в нём есть FPU)

Итак, перечислю без избыточных подробностей,

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

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

К примеру, есть корпусы ПК, оборудованные передней дверцей, открытие и закрытие которой может оказывать влияние на воздушные потоки, а следовательно и на нагрузку на двигатели. Может быть наоборот, если один вентилятор работает на захват, а другой на выброс воздуха, то они будут облегчать работу друг друга. Теоретически, можно отслеживать затруднения в работе из-за всяких загрязнений (кошачья/собачья шерсть или волосы там намотались, если башня на полу стоит 😬) и всякое такое прочее. Можно и другие бытовые применения придумать. Следить за работой водяной помпы... а можно отслеживать не обороты, а потребляемый ток и вообще любые зависимые друг от друга параметры (при условии, что их зависимость можно описать выбранной аппроксимирующей функцией). Я когда гуглил материалы по теме - встречал на форумах вопросы по аппроксимации показаний датчиков температуры.

OK, c целями разобрались, теперь посмотрим на возможные варианты реализации.

Оказывается, прямо сейчас в Сочи проходит выставка "Микроэлектроника 2024", на которой Мишустину (это нынешний Председатель Правительства, если кто не в курсе или читает из будущего) презентовали отечественный Микроконтроллер MIK32, он же АМУР, он же К1948ВК018.

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

Ну, супер! Давайте на него посмотрим.

Собственно, почему у меня были большие ожидания именно от этого проекта? Дело в том, что помимо Микрона у нас всего три производителя микроконтроллеров: Ангстрем, Миландр и НИИЭТ. Среди их номенклатуры есть интересные экземпляры, но проблема в том, что они либо отсутствуют в продаже, либо их стоимость колеблется в диапазоне 60-140 тысяч рублей (я не преувеличиваю, полюбопытствуйте сами, или вот, или вот ещё).

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

Периферия:

• SPI, I2C, UART.

• Датчик температуры.

• АЦП 12 бит, 8 каналов, частота дискретизации до 1 МГц

• ЦАП 12 бит, 2 независимых канала, частота дискретизации до 1 МГц.

• Часы реального времени с поддержкой полного календаря.

Давно задаюсь вопросом: а может ли сейчас, в наше время, достаточно одарённый человек, один или в компании ещё 2-х, 3-х или 5-ти не менее талантливых и болеющих за идею соратников, повторить успех таких титанов прошлого, как Билл Гейтс, Марк Цукерберг или, например, Стив Возняк со Стивом Джобсом? Чтобы вот так вот засесть за свой комп на несколько месяцев (да хоть бы и на пару-тройку лет) или запереться в родительском гараже и выдать продукт, который найдёт и своего потребителя и инвестора, желающего вложиться в развитие, а со временем этот продукт перерастёт в крупный, а то и крупнейший технологический бизнес (на всякий случай уточню, что под талантливыми людьми я не имею в виду себя, я для этого слишком стар, туп и ленив).

Ведь до сих пор подобные истории волнуют и вдохновляют многих людей, готовых тратить время и силы, рассчитывая в итоге, если не на что-то подобное, то хотя бы просто на успех и признание в мире технологий. Потому что помимо гигантов, наверняка очень многие из нас знают и восхищаются успехами Питера Нортона (которому, кстати, в прошлом году исполнилось 80 лет) с его знаменитыми утилитами, конечно же нельзя не упомянуть Линуса Торвальдса (его имя говорит само за себя), легендарного Джона Кармака, прославившегося игровыми движками для Dangerous Dave, Wolfenstein 3D, а потом и серии DOOM. Да что там говорить, сам Илон Маск в ранние годы начинал вдвоём со своим братом с маленького проекта бизнес-карт Zip2.

Но все эти герои именно что герои прошлого. Попробуйте-ка назвать какое-то громкое имя за последние 5 лет. Или за 10. Мне в голову приходит только Сатоси Накамото, под именем которого, вероятно, скрывается хоть и серьёзная, но всё-таки небольшая группа мотивированных учёных и разработчиков программного обеспечения. Но и это было в далёком 2008 году. Аркадий Волож, Илья Сегалович, братья Дуровы, Виталий Бутерин тоже начинали свой путь одно-два-три десятилетия назад. Из свежего, разве что бум Искусственного Интеллекта и OpenAI, а это уже крупные коллективы исследователей и разработчиков с хорошими инвестиционными бюджетами.

Выпустил рабочую версию на гитхаб: https://github.com/DmitryMuravyev/Delta-Compression

Релиз всё ещё может содержать (и конечно же содержит) какие-то баги, но, тем не менее я его изрядно со всех сторон протестировал пока делал примеры применения, которых тут целых 8 штук под разные задачи и платформы. Помимо тестового железа, примеры отличаются ещё и тем, что в них работают разные модификации кода декомпрессии:

• Полный код, максимально функциональный, но медленный. Под него есть пример на ATMega2560 + TFT дисплей ILI9486 480x320.

• Версия с меньшей разрядностью переменных и большей производительностью с примером на тех же ATMega2560 + ILI9486.

• Вариант с поддержкой пиксельного буфера и раскрашивания пикселей прямо во время распаковки. Примеры:

    ▪ Arduino Nano + IPS дисплей ST7789 240x240,

    ▪ ESP32 DEVKIT board + ST7789 240x240,

    ▪ STM32F070CB chip + ST7789,

    ▪ STM32F407ZGT6 DevEBox board + большой и мощный дисплей на NT35510 800x480.

Коллеги, добрый день!

Я доделал тестовую версию приложения-компрессора на основе материалов первых трёх спринтов и теперь могу подвести некоторые промежуточные итоги:

1) Использование дельта-кодирования для сжатия данных применимо и очень неплохо себя показывает в микроконтроллерных системах низкого и среднего уровня. Декомпрессор легко можно запустить даже на семействе ATtiny (см. пример для ATtiny85). Но и для более продвинутых микроконтроллеров, в тех случаях когда нет возможности (или желания) применять более распространённые технологии сжатия, вполне можно воспользоваться простым и нетребовательным дельта-кодированием.

2) Степень сжатия, конечно же, сильно зависит от исходных данных, но в целом вполне приемлема. К тому же, в моём приложении можно устанавливать произвольную глубину цвета для каждого из цветовых каналов (если речь идёт об изображениях), а это оказалось очень удобно для создания элементов интерфейса. В приведённых примерах я на платформе AVR (Arduino Nano) использовал формат Grayscale 2bit, который позволил обеспечить и хорошую степень сжатия и высокую скорость декомпрессии и некоторое сглаживание краёв изображения по сравнению с форматом B/W 1bit. А при помощи небольшой модификации алгоритма декомпрессии я смог раскрашивать иконки "на лету", прямо во время распаковки и вывода на экран. В результате данные 25-ти иконок 48x48 и код распаковки заняли около 5.5 килобайт флеш-памяти.

3) Для более производительных систем, алгоритмы дельта-кодирования тоже не лишены смысла, поскольку выигрыш от применения более мощных алгоритмов сжатия может быть перекрыт бОльшим объёмом кода декомпрессора. Тут, само-собой, надо исходить из конкретной задачи и дополнительный инструмент в арсенале разработчика вряд ли будет лишним.