Сваричевский Михаил - RSS подписка http://3.14.by/ Сваричевский Михаил - RSS подписка en-us Tue, 10 Jun 2006 04:00:00 GMT Wed, 20 Nov 24 05:42:26 +0000 3@14.by 120 10 <![CDATA[Запускаем Intel 87C51 - первый крупносерийный микроконтроллер (1980)]]> http://3.14.by/ru/read/87C51-programming-first-microcontroller-MCS-51-8051-UV-EPROM   Но так было не всегда. Первым монолитным микроконтроллером был Intel 8048 (MCS-48) выпущенный в 1976 по n-МОП технологии. Не планировалось что у него будет длинный жизненный цикл и уже через 4 года в 1980 на смену ему пришел Intel 8051 (MCS-51), завоевавший мир. Он имел на борту 4КиБ однократно-программируемой памяти, 128 байт SRAM, GPIO, последовательные порт и, собственно, 8-битное процессорное ядро. Intel 87C51FC был вариантом на базе УФ-стираемой EPROM памяти (объемом 32КиБ), C-версия - на КМОП процессе, объем памяти увеличен до 256 байт. Ядро 8051 не было особенно производительным - т. к. даже самые простые операции требовали 12 тактов, так что при тактовой частоте 20МГц он едва мог сделать миллион операций в секунду. Также отсутствовали команды деления (16->8 бит, деление восьмибитного на восьмибитное было, за 48 тактов), впрочем, для того времени это было повсеместно. Конечно, современные 8051-совместимые ядра зачастую на порядки быстрее (и по тактовой частоте, и по количеству тактов на команду).

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



Всегда было интересно, что там внутри и какая толщина кварцевого окна, так что я пожертвовал AMD AM27C64. Окно оказалось толщиной примерно 1mm и приклеено на удивление хорошо:


  Мы привыкли думать, что плоские оптические окна не влияют на изображение и через них все можно рассмотреть без ограничений. Но это верно только для объектов на условной бесконечности, а вблизи, когда мы наблюдаем с большой числовой апертурой (что обычно делают для повышения разрешения в случае микроскопа) - плоское окно вносит сферическую аберрацию и для объективов с апертурой примерно более 0.3 - разрешение начинает ухудшаться, а не увеличиваться. Аналогичная проблема есть и при попытке увидеть данные на компакт-диске - со стандартным объективом с апертурой 0.3 видно лучше, чем с 0.7.
  Тут самое время достать козырь - объектив с коррекцией толщины стекла (изначально их сделали для контроля ЖК мониторов при производстве). На фотографии ниже - слева 87C51 без коррекции стекла (низкий контраст и разрешение из-за сферической аберрации), справа - с коррекцией на 1.05mm стекла:




Теперь можно сфотографировать весь кристалл через кварцевое окно:

Стирание чипа

  Чип стирается относительно высокой дозой УФ излучения, в документации написано короче 400нм. Обычно используются кварцевые лампы излучающие 254нм. Я попробовал стереть светодиодов на 245nm - но у него была настолько маленькая мощность, что даже через час ни одного бита не стерлось. Видимо для длин волн короче 350нм ртутные лампы пока безусловно разрывают полупроводниковые светодиоды.
  Некоторое время назад для другого проекта и купил странные ртутные лампы, требующие 10v/300mA. Их продают в версии "с озоном" (кварцевая колба, пропускает линию ртути 185нм) и "без озона" (излучение 254нм и далее). Для стирания данных, конечно, лучше использовать 254нм, но у меня была более злая версия. Интересно, что только верхняя часть спирали лампы покрыта оксидным слоем для увеличения эмиссии электронов.


Лампа работает очень необычным образом. Включать её нужно к блоку питания с напряжением ~14-15В и ограничением тока 300mA. При включении спираль нагревается до красна, и испаряет ртуть из пластины с амальгамой.


  Когда давление паров достаточно повышается - зажигается разряд между верхними частями спирали, и резистивный нагрев спирали автоматически резко снижается. Эта фотография сделана в защитных очках, камера с УФ фильтром. Все тело должно быть закрыто, т. к. и 185 и 254нм вызывают рак кожи и катаракту. Озон ядовит. В общем, это лучше не повторять, и стирать лампой без озона.
  Когда кварц так светится голубым - нужно бежать!


Лампа установлена в банке с огурцами (без огурцов), с алюминиевой фольгой с внутренней стороны. Обычное стекло банки не пропускает излучение короче 365нм. Точка излучения лампы была примерно в 2 сантиметрах от окна микросхемы, и содержимое стиралось примерно за 10 минут.


Прошивка

С народным программатором MiniPro TL866 - никаких сложностей (сейчас на него есть open-source софт open source software).


Пишем демо-программу

  Что ж, завязываем с фотографиями - пора писать код! В дополнение к стандартному мигающему светодиоду я решил также рассчитать простые числа и напечатать их через последовательный порт (чтобы задача была не слишком сложная, и не слишком тривиальная вычислительно). Изначально я попробовал пойти по пути Jay Carlson и попробовал использовать современную IDE 8051-совместимых чипов от Silicon Labs (Simplicity Studio). К сожалению, там бинарная совместимость похоже только для GPIO, но не для последовательного порта (что не удивительно, последовательный порт в оригинальном 8051 очень уж простой). Так что я перешел на open source SDCC с которым все пошло как по маслу.
  Я не хотел усложнять код кольцевыми буферами и прерываниями, и отправляю данные побайтно. Единственная оптимизация, которую я тут сделал - проверка завершения отправки до отправки следующего байта, а не после (как это в большинстве примеров). Это позволяет частично распараллелить работу последовательного порта и вычислений. Для того, чтобы это работало и для первого байта - я устанавливаю флаг завершения передачи предыдущего байта TI = 1 в начале программы.
#include <8051.h>
#include <stdio.h>
#include <stdbool.h>

int putchar(int c) {
    /* We never start when transmission is not complete */
    while (TI==0);      /* Wait until stop bit transmit */
    TI = 0;
    SBUF = c;     
    return c;
}

void toggle_led(void)
{
    P1_0 = !P1_0;
}

int main (void)
{
    int i, j, loop_limit;
    bool is_prime;

    //Serial port speed. Perfect 9600 for 18.432MHz crystal
    TH1 = (unsigned char)(256-5);//No "overflow in implicit constant conversion"
    TMOD = 0x20;
    SCON = 0x50;
    TR1  = 1;
    TI = 1;//To continue work while we are transmitting - we are waiting before transmission, not after


    printf("Hello world!\r\n");
    printf("Let's calculate some primes: 2");
    while (1) 
    {
      for (i = 3; i <= 32000; i+=2) {
          loop_limit = 180;
          if(i-1<loop_limit)loop_limit = i-1;//We will not calculate square root :-)
          is_prime = true;

          for (j = 2; j <= loop_limit; ++j) {
              if (i % j == 0) {
                  is_prime = false;
                  break;
              }
          }

          if (is_prime) {
              toggle_led();
              printf(" %d", i);
          }
      }

      printf("\r\nHere we go again: 2");
    }                             
}

Т. к. в 8751 нет PLL (что не удивительно), получить требуемую скорость работы последовательного порта может оказаться сложнее, чем кажется. Скорость последовательного порта определяется частотой кварца и предельным значением счета таймера1 (TH1). Изначально я запускал 8751 от кварца с максимальной частотой 20Мгц и TH1=256-5 - но данные последовательного порта не удавалось корректно прочитать на компьютере. А вот осциллограф декодировал корректно. Оказалось, что скорость последовательного порта получилась с ошибкой в 9% (10416 бод вместо 9600, по формуле X = F/(12*32*Y) где F это частота кварца и Y - предел счета таймера). Можно было бы сконфигурировать USB-UART адаптер CP2102 на эту частоту, или подобрать другой кварц, который дал бы меньшую ошибку.
Оказалось, что с кварцем на 18.432Mhz и таймером 256-5 - частота получается идеальная, как будто этот кварц и был создан для этой задачи (Комментатор: Именно так)

Собираем прототип

P1.0 (pin 1): LED.
Reset (pin 9): Active high. Притягиваем к GND резистором, и к VCC через небольшой электролитический конденсатор. Это обеспечит сброс микроконтроллера при подаче питания.
TXD (pin 11): Выход последовательного порта.
XTAL1 и XTAL2 (pins 18 and 19): Кристалл на 18.432Mhz. Заработало без внешних конденсаторов, что вероятно дает некоторую незначительную ошибку частоты и меньшую стабильность. Паразитных емкостей макетной платы однозначно недостаточно (~2pF).
GND (pin 20) и VCC (pin 40): 5V питание и земля.
EA (pin 31): Для отключения внешней памяти (её у нас нет) - подключаем к VCC.


Запускаем

С корректными настройками последовательного порта - все работает!


Если посмотрим на TX осциллографом при передачи разных простых чисел, можно увидеть что-то неожиданное:




Когда печатаем трехзначное число - задержка между пробелом и первой цифрой ~1.25ms, 1.8ms для четырехзначного и 2.5ms для пятизначного. Почему так получается?
  После того как printf(" %d", i) печатает пробел, микроконтроллеру нужно перевести число в строку. И этот перевод без аппаратного деления 16-и битных чисел занимает достаточно большое время, так что даже на скорости 9600 бод заметно. Больше знаков - больше делений - больше задержка на конвертацию.

Резюме

  Заметную часть времени до рабочего кода съели 8 итераций стереть-записать, раньше для этого были полноценные дев-борды с быстрой отладкой во внешней памяти. Самые необходимые фичи современных микроконтроллеров уже существуют 87C51 - он очень сильно обогнал своё время. Тем не менее, современные контроллеры на этой задаче ожидаемо были бы намного проще в работе:

1) Производительность. 1(один) 8-bit MOPS против ~50-150 32-bit MOPS в современных микроконтроллерах за 1-2$. Разрыв в математике еще больше, т.к. теперь мы избалованы относительно быстрым делением и умножением. Вместо написания уникального ручного кода деления 16-битного числа на 10 сдвигами - можно просто делить и не переживать. Теперь и аппаратной арифметикой с плавающей точкой местами никого не удивить.
2) PLL. Сейчас можно поставить самый популярный/дешевый кварц на 8Mhz и сконфигурировать почти любую удобную частоту, не собирая библиотеку кварцев на все случаи жизни. Уникальные кварцы теперь нужны в основном только в ситуации где нужен низкий фазовый шум (высокоскоростные интерфейсы, ЦАП/АЦП высокого разрешения и проч.).
3) Аппаратный отладчик и программирование через JTAG - обеспечивает очень быстрые итерации.
4) Последовательные порты (и другие интерфейсы) с буферами и гораздо более высокими скоростями.
5) Внутренний сброс, brown-out detection, watchdog timer.

  Так что, несмотря на то что зачастую 8051-совместимые микроконтроллеры дешевле, разработка под них требует больше времени (=денег). Но для применений с очень большим объемом (миллионы штук), где задача относительно несложная и не требует много математики (условная микроволновка) или уже есть наработанная база готового кода - общая стоимость проекта может оказаться минимальной, потому наследники 8051 ставят в новые продукты и сегодня (и нет предпосылок к уходу 8051 на пенсию даже при наличии свободных/условно-бесплатных ядер RISC-V).]]>
Sun, 12 May 24 13:03:48 +0000
<![CDATA[Sony F828 и инфракрасная фотография]]> http://3.14.by/ru/read/Sony-F828-IR-photography-magnet-hack-RGBE-CCD
На снимке - электроплитка светит в работе инфракрасным светом, и черное стекло - прозрачно для инфракрасного излучения, и тут виден электронный фарш:


Далее сама камера. ИК-фильтр убирается неодимовым магнитом 15x15mm. Более мелкие магниты 10x5mm оказались слабоваты.
К камере - 3 ИК фильтра : 680nm+, 760nm+ и 950nm+. 760nm наиболее практичен, так как заметно по другому показывает мир, но все еще пропускает много света. На 950nm+ резкое падение чувствительности кремния увеличивает выдержку и приходится снимать только на штативе.


Далее глянем на свитер:


Краски не имеют видимых отличий в диапазоне 760nm+, к моему удивлению даже черная краска прозрачна. Только на 680nm+ разница между красками едва видна.


]]>
Fri, 19 Jan 24 21:19:26 +0000
<![CDATA[RISC-V мини-ноутбук : Lichee Console 4A - обзор и тесты]]> http://3.14.by/ru/read/RISC-V-Sipeed-Lichee-Console-4A-Alibaba-T-Head-TH1520-review маленькие ноутбуки (нетбуки?) и телефоны - но почему-то производители их не взлюбили, и соревнуются у кого больше. Маленькие и микро-ноутбуки остались зачастую только на ebay - например UMPC от Sony, которые до сих пор стоят 300$ и выше. Недавно начали появляться портативные системы основанные на Raspberry Pi/CM4 - например у clockwork, но все они не складываются книжкой. Так что когда летом 2023-го Sipeed анонсирована Lichee Console 4A, да еще и на RISC-V процессоре - я немедленно его заказал, и наконец в начале января он до меня доехал. Результаты тестирования и обнаруженные сложности/проблемы - ниже.

Спецификации и внутренности

В первую очередь, Lichee Console - крошечный ноутбук размером 185 x 140 x 19 mm и весом 656g. Корпус алюминиевый и выглядит добротно. Клавиатура - по моим ощущениям похожа на Lenovo, но конечно меньше по размерам. Из-за размера не глядя на ней печатать я пока не могу, но это возможно. Самое большое неудобство доставляют уменьшенные по ширине клавиши [,][.][/] которые часто нужны при работе в консоли. Trackpoint - как обычно на Lenovo, но я бы предпочел работать с Bluetooth мышью (что пока не удалось из-за софта).

Lichee Console 4A работает на 4-х ядерной SoC T-Head (Alibaba) TH1520 RISC-V (4 ядра C910). TH1520 может работать на частотах до 2.0-2.5Ghz, но в Lichee Console частота снижена до 1.5Ghz, видимо для борьбы с тепловыделением (но сильно это не помогло). Максимальная конфигурация железа - внушительна для такого размера устройства: 16Gb DDR4 RAM (у меня такой вариант, гулять так гулять) и максимум 128Gb памяти на распаянной микросхеме eMMC . Также есть слот для 42mm SATA M.2 SSD, но он подключен через адаптер ASM1153 USB3.0->SATA. Это мы еще затронем ниже.

С точки зрения безопасности данных - конечно предпочтительнее работать на M.2 SSD, т.к. если что-то сломается - данные легко перенести. А вот с распаянного eMMC это будет дорого. M.2 42mm SATA SSD - сейчас довольно редкий зверь, и единственный вариант с MLC памятью и нормальным размером, который мне удалось найти - это Transcend MTS400 256Gb (он все еще в почте). Много разных SSD такого типа делают Китайцы, но это вероятно TLC/QLC память и не проверенная надежность.

У дисплея разрешение 1280x800, матрица похожа на IPS - нет искажения цветов под большими углами. Для экрана такого размера - разрешение достаточное. Слева (!?!) от дисплея - full HD 30p вебкамера среднего качества (требует хорошего освещения), ориентация - ландшафтная (т.е. это не просто повернутый экранный модуль от планшета). Можно подключить внешний монитор через mini-HDMI (кабель приложен). На FullHD мониторе - заработало без проблем, а вот на 4k - не заработало.

Батарея - 2S 3000mAh. Зарядка возможна через USB-C (максимум 5V 2.2A, не активирует 9/12V через PD или QC) и через DC блок питания 12V с 3.45мм круглым разъемом (лично я использовать его не планирую). 12V блок питания пришел с китайской/американской вилкой, так что у нас придется использовать через адаптер. Удобнее будет использовать 12V PD адаптер (вроде такого - но обязательно 12V).

На ноутбуке установлена Debian 12 с Xfce, собранная под 64-bit RISC-V. WiFi и Ethernet заработали сразу из коробки, Chrome-based браузер без проблем играет 720p видео из YouTube, тяжелые сайты конечно открываются не очень быстро - но жить можно. apt update обновляет пакеты с Китайского сервера.

Видео распаковки (дополнительной информации и комментариев там нет, только рассмотреть в действии и со всех сторон):


Качество сборки:
У моего образца была 1 проблема с корпусом: толи нижняя алюминиевая часть корпуса сжимает клавиатуру, толи что-то давит на клавиатуру снизу, но она выгибалась в центре примерно на 1мм, и задевала нижнюю кромку крышки с дисплеем при открывании. После пересборки надавил на клавиатуру в центре - и проблема разрешилась.

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

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


В отличии от типичных компоновок ноутбуков, в Lichee Console 2 печатные платы (+модуль с процессором, памятью и eMMC). Плата ввода-вывода с USB, аналоговым звуком и microsd - подключена через flex кабель, и это принесет свои проблемы. Вероятно это сделано т.к. у Sipeed несколько аналогичных продуктов в разных корпусах, и видимо там отличие в этой интерфейсной плате.



SoC модуль - в SODIMM слоте, можно заменить или установить в dev-борду. Выйдут ли следующие поколения - вопрос интересный. На сайте T-Head пока более мощных чипов не анонсировано. Тепло передается через силиконовую резинку на сплющенную тепловую трубку, прилепленную на нижнюю алюминиевую крышку. С перегревом/тротлингом проблем не было, хотя вентилятор включен постоянно (даже когда в холодильник поставил) - но тут возможно виновато высокое потребление в покое (об этом больше ниже).


Тесты


CPU & потребляемая мощность
TH1520 @1.5GhzRaspberry Pi 4Raspberry Pi 5
idle power7.68 / 6W (with/without screen)1.93W2.42W
CoreMark 1 core6900793817725
Power 1 core8.376W (with screen)2.70W4.47W
CoreMark 4 cores256893153269860
Power 4 cores9.408W (with screen)4.85W7.35W
В coremark из коробки скорость чуть меньше Raspberry Pi 4 из-за сниженной частоты (с 2.0 to 1.5Ghz). Sipeed говорит что можно еще поднять скорость оптимизацией компилятора - но так можно и с тестом на Raspberry Pi. Так что во всех случаях настройки "из коробки", без профайлеров и проч. Лично меня такая производительность уже вполне устраивает для работы с удаленными серверами. В сравнение я также добавил Raspberry Pi 5 - т.к. уже 2024 год, и скоро мы сможем ожидать конкурирующие продукты на модулях CM5.

Вот что мне не понравилось - это высокое статическое энергопотребление Lichee Console. В простое система снижает тактовую частоту до 300Mhz, и даже при отключенных вручную 3 из 4 ядер - система все равно потребляет ~6W (без экрана). Такой уровень потребления в таком маленьком корпусе - делает Lichee Console заметно теплой даже в бездействии. Также, это означает что батареи хватит только на ~2.5 часа работы без тяжелой нагрузки. Т.к. зарядка USB ограничена 5V/2.2A - этого едва хватает для покрытия энергопотребления включенной Lichee Console и она будет очень медленно заряжаться (~3 часа до полной зарядки в выключенном состоянии и ~10 часов во включенном). Конечно, используя 12V блок питания зарядка будет существенно быстрее.

В даташите указано динамическое потребление ядер C910 - 200µW/MHz/ядро, что дает примерно 300mW динамического потребления на ядро на частоте 1.5ГГц, и 1.2Вт для всех 4 ядер. Практические измерения подтверждают эти цифры, так что основной проблемой является высокое статическое потребление.

Для того чтобы понять что-же выжирает столько энергии взглянем на консоль Lichee Console в простое через тепловизор:


Тут мы видим, что примерно половина энергии рассеивается чипом Via VL817 - USB 3.0 хаб, расположенным под модулем SoC. Меньше, но все еще заметно потребляет чип ASM1153 (USB->SATA адаптер), несмотря на то что SATA устройство не подключено. Если программное решение для отключения не задействованных интерфейсов не будет найдено - вероятно я просто выпаяю их или перережу дорожки питания. 5-6 часов работы от батареи для меня важнее чем SATA.

WiFi & Ethernet:
WiFi модуль подключен через интерфейс SDIO. Практическая скорость через iperf3 - 122/115 Mbit/sec, достаточно для работы на удаленных серверах. Проводной Ethernet пропускает 925/925 Mbit/sec без jumbo пакетов, тут жаловаться не на что. Примечательно, что у TH1520 2 Ethernet порта, но только один выведен на корпус.

Производительность диска
eMMC
Random 4k: Writes 8102 IOPS, 31.6MiB/s. Reads 2502 IOPS, 9.77MiB/s
Random 1Mb: Writes 202mb/s, Reads 130mb/s

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

MicroSD:
При тестировании быстрых MicroSD карт (Samsung Pro Ultimate, Sandisk Extreme Pro) - сразу вскрылась проблема стабильности: операции чтения часто падали с ошибками ввода-вывода. Вероятно это связано с длинным путем сигнала: от SoC модуля, далее по первой плате, далее сложенный несколько раз flex-кабель, дальше по второй плате... Старые и медленные MicroSD карты работают стабильно. Надеюсь скорость интерфейса удастся снизить программно, чтобы добиться стабильной работы всех карт памяти без ущерба скорости eMMC.

Не работает на текущий момент (из типичных функций ноутбуков):
1) Bluetooth - падает при попытке спарить устройства из GUI.
2) Нет сна. Каждый раз нужно выключать / загружать систему с нуля.
3) Не знаю, есть ли датчик закрытия экрана. Сейчас при закрытии экрана - система продолжает работать со включенным экраном.
4) Настройка яркости экрана не работает (яркость или максимальная, или экран выключен). Update: "apt install pkexec" исправляет регулировку через gui. С клавиатуры пока еще не работает.
5) Как отмечал выше - управление питанием оставляет желать лучшего, очень высокое энергопотребление в покое. Удастся ли программно выключить неактивные VL817/ASM1153? Работает ли динамическое управление напряжением питания SoC в зависимости от частоты?

По мере решения проблем - я обновлю статью.

Резюме

В целом, не смотря на ряд проблем - моё общее впечатление о Lichee Console позитивное, и мне она нравится. Не стоит её рассматривать как готовый продукт который можно брать и немедленно работать - требуются программные доработки (но так часто бывает с Linux на новых платформах). Железо имеет заметные проблемы, но в целом не фатальные, ключевые функции работают из коробки (главные проблемы - стабильность быстрых microsd и высокое энергопотребление в покое). У меня остаются опасения насчет безопасности крепления литиевой батареи металлическими лапками.

Само сердце - SoC TH1520 имеет конкурентоспособное динамическое энергопотребление и достаточную для меня производительность, но страдает от дефицита интерфейсов ввода-вывода (для ноутбука), что и заставило Sipeed лепить дополнительные адаптеры на USB которые неприлично жрут энергию.

Надеюсь, что быстрый прогресс RISC-V продолжиться и в ближайшие годы мы увидим больше процессоров, на этот раз хотя-бы с несколькими линиями PCI-E, что сильно облегчит всем жизнь.]]>
Tue, 16 Jan 24 06:34:52 +0000
<![CDATA[Рональд Рейган и Raspberry Pi]]> http://3.14.by/ru/read/Ronald-Reagan-raspberry-pi-supply-chain Советские шутки:

В СССР, чтобы купить автомобиль, — говорит Рейган, — надо десять лет про­стоять в очереди, заплатив за машину авансом. И вот один покупатель прихо­дит, вносит аванс, и служащий ему говорит:

   — Всё, приходите за вашей машиной через десять лет.
   — Утром или днем?
   — Это же через десять лет, какая разница?
   — Да просто утром ко мне сантехник придет.

28-го сентября открыли предзаказы на Raspberry Pi. Я не заказал сразу, и сделал это только в 6 утра следующего дня. Как оказалось впоследствии - каждые 6 часов задержки откладывали доставку на месяц. Так что первые получили свои малины в начале Ноября (если конечно ты не знаменитость), а ко мне они пришли только в начале Января. В любом случае, это лучше чем ситуация с 4-ыми малинами во времена пика кремниевого кризиса, когда и 6-ю месяцами до поставки никого было не удивить. Конечно, те кто хотел получить раньше - всегда могли заплатить спекулянтам 200% цены (не вполне понятно, почему производители стесняются так делать). Надеюсь со временем очереди за электроникой станут короче (впрочем, ситуация вокруг Тайваня может иметь неожиданные для всех последствия).

Теперь, с двумя малинками на руках - можно ненадолго почувствовать себя среди победителей лотереи. Краткий тест coremark подтверждает ускорение в 2.2x раза при росте энергопотребления в 1.5x раза, ну и PCI-E действительно есть. Остается еще достаточно много пространства для роста энергопотребления в будущих версиях, пока пиковое энергопотребление не достигнет 100Вт :-)

]]>
Fri, 12 Jan 24 11:59:08 +0000
<![CDATA[Делаем 10-минутную задачу за 2 часа с помощью ChatGPT]]> http://3.14.by/ru/read/chatgpt-gpt-openai-10-minute-task-in-2-hours-llm Все мы видели много статей, где с помощью AI-инструментов за минуты выполняется работа, на которую раньше мог легко уйти день. Особенно впечатляют примеры, где работа (успешно) идет вне зоны компетенции человека (т.е. когда AI позволяет делать то, что человек в принципе один сделать не мог бы). Но сегодня у меня получился несколько другой случай:

Задача стояла относительно тривиальная: нужно было сгенерировать look-up table (LUT) для по-канального увеличения контраста (S-кривая), и применить эту кривую на фотографии с камеры. Берем ChatGPT (даже 3.5 должен прокатить, тут всего-то одна формула), за 10 секунд получаем Python-код типичной S-кривой (также ChatGPT для моего удобства сразу добавил отрисовку графика через matplotlib), настраиваем параметр "кривизны" кривой по вкусу - и можно вставлять в финальное приложение. Среди множества S-кривых/сигмоид ChatGPT использовал "логистическую функцию" - она одна из наиболее простых. Но у неё есть и недостаток - параметром "кривизны" нельзя сменить увеличение контраста на снижение (и наоборот) - впрочем, мне это особо и не нужно было, снижать контраст в целевом применении не нужно никогда (крайний случай - оставить все как есть, а это логистическая функция может).

Но праздновать завершение работы оказалось рано: сгенерированный код упрямо рисовал график, снижающий контраст вместо его увеличения. Когда я предъявил эту претензию ChatGPT - он извинился, и с каждым разом выдавал все более и более поломанный код. Просто изменить параметр кривой оказалось невозможно т.к. формула недостаточно универсальная. Что-ж, похоже тут с ChatGPT ничего не получится - но это и не конец света. В конечном итоге, границы применимости LLM известны, и чем более узкая сфера - тем проще за них выйти. Но история тут не заканчивается.


Для справки, вот исходный (наилучший) вариант от ChatGPT (можно потренироваться и найти тут ошибки):

import numpy as np
import matplotlib.pyplot as plt

def create_s_curve_lut():
    # Define parameters for the sigmoid curve
    a = 10.0  # Adjust this parameter to control the curve's shape
    b = 127.5  # Midpoint of the curve (127.5 for 8-bit grayscale)

    # Create the S-curve LUT using the sigmoid function
    lut = np.arange(256)
    lut = 255 / (1 + np.exp(-a * (lut - b) / 255))

    # Normalize the LUT to the 0-255 range
    lut = (lut - np.min(lut)) / (np.max(lut) - np.min(lut)) * 255

    return lut.astype(np.uint8)

# Create the S-curve LUT
s_curve_lut = create_s_curve_lut()

# Plot the S-curve for visualization
plt.plot(s_curve_lut, range(256))
plt.xlabel("Input Values (0-255)")
plt.ylabel("Output Values (0-255)")
plt.title("S-curve Contrast Enhancement LUT")
plt.show()

# You can access the S-curve LUT with s_curve_lut

В этот момент я поставил крест на LUT от ChatGPT и переделал (если так можно говорить про пару строчек кода из google) используя регуляризованную неполную бета-функцию. Покрутил параметры a=b пока не получил на графике кривую по вкусу (аналогично тому, что выставляю обычно руками в графическом редакторе) и наконец применил LUT на тестовое изображение используя в OpenCV. К моему полному удивлению, функция уменьшила контраст, а не увеличила его. Как так?

Медитирование не позволило быстро найти ошибку. Я написал тестовый кусочно-линейный LUT для увеличения контраста - и на изображении он дал ожидаемый результат. Лишь добавив кусочно-линейный LUT на график - корень проблемы стал виден: когда я выкинул функцию генерации S-curve LUT от ChatGPT, я оставил код рисования графика. Там ChatGPT старательно напечатал заголовок графика и названия осей.. но сделал конкретную подставу используя данные оси X - в Y, и наоборот. Т.к. параметры plt.plot используются без имени - не используя регулярно / не помня порядок параметров человеку очень легко тут не заметить ошибку.

Таким образом, когда я настраивал фактор формы кривой - я настраивал его на перевернутом графике, и сделал его уменьшающим контраст. Когда я обвинял ChatGPT в том, что он неправильную формулу мне сделал - и он соглашаясь со мной судорожно пытался что-то исправить - у него не было шансов. Т.к. формула была правильная, а ошибка была в графике. Конечно, если ChatGPT указать на ошибку в выводе графика - он радостно соглашается и исправляет её (но так я и сам могу). Это подстава уровня #define true false на университетских компьютерах.

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

▶ Глянуть в код

Но и это оказался не конец: Взглянув на график - бросается в глаза легкая асимметричность кривой GPT-TRAP в районе 255. Это банальная ошибка округления : вычисленное вещественное число результата просто приводят к uint8 (=отбрасывают дробную часть), а значит результат (и яркость изображения) будет в среднем на 0.5 единицы / 0.25% меньше, пиксели с полной яркостью (255) будут намного более редкими. Интересной эту ошибку делает то, что она есть в коде, сгенерированной и ChatGPT, и Bing Copilot и Google Bard. Т.е. видимо такой код очень распространен в тренировочных данных и все модели решили что "умножить на 255 и привести к uint8" - это успех. Технически конечно в диапазон мы попали, но результат не безупречен.

▶ Глянуть в код

Выводы:
  • Языковые модели - как junor разработчики: они могут и будут делать неожиданные ошибки, им нужны четкие инструкции и руководство. Впрочем, разница в том, что джуны вырастут, а у моделей остается ждать следующих поколений. Как и с джунами - с моделями нужно иметь реалистичные ожидания.
  • Весь код от языковых моделей нужно проверять, никому верить нельзя. И чем менее истоптанная поляна, тем тщательнее нужно проверять. Языковые модели генерируют код очень похожий на правду, а значит ошибки могут быть очень дороги в исправлении.
  • Если получаем неожиданный результат - зачастую проще спросить несколько разных моделей и сравнить результаты : сейчас в дополнение к ChatGPT (3.5/4) есть Copilot, Bard, Replit и другие. Никто из них не выдал идеальный код с первой попытки, но по этому пути мне не пришлось бы залипать с графиком.
  • Некоторые ошибки - систематические для языковых моделей, видимо унаследованные из частично пересекающегося набора данных для обучения, где эти ошибки были широко представлены (т.к. языковые модели на текущий момент доверяют примерам для обучения безусловно, в отличие от людей). Т.е. модели пока не могут превзойти по качеству данные для обучения, и могут лишь к ним приблизится. Непонятно, сколько работы еще предстоит чтобы "превзойти учителя", может так оказаться, что это тот случай когда 10% работы занимают 90% времени. Но прогресс в последние 3 года движется стремительно, возможны и сюрпризы.
]]>
Sun, 22 Oct 23 23:18:49 +0000
<![CDATA[Сириус и цветное мерцание]]> http://3.14.by/ru/read/Sirius-color-twinkling-astronomy-astrophotography-turbulence-atmosphere
Почему так получается? Звезды мерцают из-за того, что атмосферная турбулентность фактически работает как случайная "призма" с градиентным показателем преломления (и соответственно случайно сдвигает / расщепляет изображение на цвета - да, воздух также обладает дисперсией!) - и таким образом больше/меньше света случайных частей спектра попадает в апертуру камеры / глаза. Для звезд - призма состоит из цилиндра воздуха диаметром в данном случае 62мм и длиной ~50км, что делает эффект очень заметным. А вот для Юпитера например - турбулентность будет усреднятся в конусе, который на 50км раскрывается до 7.2м (из-за углового размера планеты). Такой большой объем "усредняемого" воздуха сильно снижает контраст мерцания и случайные цвета уже не наблюдаются. Также, можно ожидать что мерцание яркости/цвета в большие телескопы (с апертурами под 300мм) также будет радикально меньше из-за бОльшего усредняемого объема воздуха.





]]>
Mon, 25 Sep 23 03:05:34 +0000
<![CDATA[EVE Online - становится тесно в космосе в 2023-м году]]> http://3.14.by/ru/read/eve-2023-1-million-sp-space-mmorpg положены 1'000'000 SP на первом логине.

]]>
Sun, 24 Sep 23 23:24:51 +0000
<![CDATA[Voron V0.1 - Ferrari среди 3D-принтеров (V0.1430)]]> http://3.14.by/ru/read/Voron-V0.1-coreXY-printer-ferrari
Завершил сборку и настройку моего Voron V0.1. БОльшая часть деталей несущих нагрузку - из алюминия, остальное печатал из ASA-X. Маленький размер позволяет развивать очень серьёзные скорости и ускорения: быстрый профиль 175/306 mm/s (периметры / infill) с ускорениями 25'000 mm/s². Профиль на максимальное качество - 80/150 mm/s, 15'000 mm/s². Быстрые ускорения и direct extruder - сильно облегчают настройку из-за стабильной скорости экструзии на видимых частях деталей. Pressure advance + input shaper также позволили поднять ускорения с 5'000 до 25'000 mm/s² без дефектов на углах.

Работает все на Fluidd+Klipper, на SKR-PRO v1.2 + Raspberry Pi 4. При печати 306mm/s на 265°C - 40W не хватает, так что я слегка разогнал принтер до 28V (+36% мощности нагревателей). 28V - предел для TMC2209.

Изначально думал поучаствовать с соревнованиях SpeedBenchy - но там все ушло сильно далеко в "слишком быстро / слишком плохо". Печать на таких скоростях ограничена охлаждением пластика - потому достижимые скорости печати без потери качества на ASA/ABS в разы больше PLA. Т.е. скоростная печать после 200mm/s - это уже соревнование вентиляторов и воздуховодов.

Update: Мой официальный серийник V0.1430 :-)]]>
Tue, 08 Feb 22 09:00:51 +0000
<![CDATA[На прогулке с Альпаками]]> http://3.14.by/ru/read/alpaka-walk ]]> Mon, 07 Feb 22 19:09:56 +0000 <![CDATA[Млечный путь @ Gurnigel, Switzerland (1593m)]]> http://3.14.by/ru/read/Milky-Way-Gurnigel-Switzerland-astrophotography
30 секунд, A7III с Samyang 8mm F2.8 @ F4. APS-C объектив на полнокадровой камере чтобы пиксели были по-крупнее для снижения шума (увеличение разрешения тут ни к чему).

Засветка в левой части кадра от ближайшего города - Тун, в 13км. ]]>
Sun, 15 Aug 21 14:07:26 +0000