Блог переехал

Новое место: https://l-proger.ru

"RealPad" DualShock(1,2) gamepad plugin for PCSX2 PS2 emulator

  Написал за несколько вечеров код работы (чтение/конфигурация) с игровыми контроллерами Sega, PlayStation1, PlayStation2 под микроконтроллер STM32F7, высунул данные через USB (HID устройство), можно пользоваться как обычным компьютерным геймпадом.

  Я использовал борд с микроконтроллером серии STM32F7  с сайта одного знакомого "электронщика": https://evaluationboard.ru .  В борде нет ни чего лишнего и имеется всё необходимое. Например, в нём распаян полностью рабочий программатор ST-Link V2 и установлена микросхема FTDI (USB to COM адаптер), оба они припаяны к хабу, от которого идёт наружу "принтерный" USB разъем. Получаем  отладку SWD, UART через 1 кабель и ни каких лишних девайсов/проводов. Остальные плюшки борда можно рассмотреть на сайте, при желании.

  Но этого оказалось недостаточно...

  Когда всё заработало, я подумал: а что если реализовать мечту "детства" и написать немного кода для некогда часто мной используемого эмулятора PlayStation2 "PCSX2"?

  Сделал fork pcsx2 проекта на github, разобравшись (со скрипом, т.к. API очень не интуитивно сделан и не документирован) в API эмулятора, накидал быстро код общения с моим хардварным интерфейсом к геймпадам и назвал проект "RealPad" по аналогии с другими плагинам. "Real" - тут важная часть названия, т.к. подключается настоящий геймпад и по-настоящему читается виртуальной PS2 без дополнительных алгоритмов обработки ввода.

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

  Вот что получилось:

  Ссылка на репозиторий: https://github.com/L-proger/pcsx2/tree/develop/RealPad

  Disclaimer: код пока что сырой, написан в скоростном режиме как proof of concept.  Предстоит его почистить, реализовать правильную выгрузку, поддержку нескольких геймпадов, починить косяк, когда игры не видят контроллер после загрузки быстрого сохранения (F3).  А ещё ввод с клавиатуры не работает, когда используется мой плагин, например, не могу использовать "быстрое сохранение" (F1), придётся разобраться что ещё от меня хочет эмулятор.

  В дальнейшем выложу и прошивку под STM32, как только её в порядок приведу )

Run Stm32CubeMX & STM32CubeProgrammer applications with OpenJDK on Windows

Stm32CubeMX требует наличие установленного OracleJRE/JDK и при его отсутствии в системе ругается, что не может найти JRE версии 1.8.0_45 или выше. Кубу всё равно на то, что у меня в системе есть OpenJDK (ставил разные версии, добавлял в PATH, не помогало) и мне на пару секунд даже показалось, что придётся сдаться и поставить ещё и OracleJRE (чего я очень не хотел), но на самом деле сдаваться рано )

Сначала попробовал изменить требуюмую версию Java в инсталлере куба, но понял, что это не помогает. Потом нашёл и "поставил" именно 1.8.0_45 но OpenJRE а не OracleJRE - всё равно не помогло. Потом нашёл некий интересный путь C:\ProgramData\Oracle\Java\javapath ! В нём лежат 3 симлинка на java.exe, javaw.exe, jawaws.exe.

Тут я решил, что "вот оно", мне надо эти симлинки создать на соответствующие exe файлы из моей версии OpenJRE. И создал. И не помогло ) Куб при установке ругался всё тем же сообщением.

Теперь я решил запустить java.exe через мой симлинк и о чудо, java ругнулась, что в реестре не хватает ветки. Я поставил OracleJDK, экспортнул ветку, удалил OracleJDK, импортнул ветку и подправил пути на свои, вычистив лишние ветки/ключи.

И всё заработало !

Моя версия OpenJDK лежит по такому пути: C:\openjdk-12.0.2

А вот текст .reg файла, которым можно указанный выше путь зарегистрировать в реестре:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\12.0.2]
"JavaHome"="C:\\openjdk-12.0.2"
"RuntimeLib"="C:\\openjdk-12.0.2\\bin\\server\\jvm.dll"
"MicroVersion"="0"
"BuildNumber"="10"


Насчёт необходимости ключей "MicroVersion"="0", "BuildNumber"="10" я не разбирался. Может они не нужны (так выглядит), но OracleJRE их создаёт. Хз, решил, что лучше оставить. Кто знает что в будущем может поломаться из за их отсутствия.


ОБНОВЛЕНИЕ:

STM32CubeProgrammer не захотел работать с хаком, описаным выше. Как оказалось, CubeProgrammer использует JavaFX, которого нет в официальной сборке OpenJDK. Почему-то за преемлимое время мне не удалось установить OpenJFX поверх OpenJDK, потому я пошёл другим путём и скачал OpenJDK сразу собранный вместе с OpenJFX.

Скачать можно вот по этой ссылке:  https://bell-sw.com/pages/java-13/

Архив с этим билдом JDK я распаковал в корень диска C

А вот контент .reg файла, регистрирующего установку этой версии JDK:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK]
"CurrentVersion"="13.0.0"

[HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\JDK\10.0.2]
"JavaHome"="C:\\bellsoft-jdk13-windows-amd64\\jdk-13"


Здесь можно заметить, что ветка реестра содержит версию 10.0.2, а не 13.0.0.  Это важно, т.к. по этому имени STM32CubeProgrammer проверяет версию java, которая должна быть 1.8.0 - 10.99.99.  Приходится таким путём обманывать STM32CubeProgrammer, если хочется иметь в системе свежую версию JDK.

Как собирать С++ приложения в Windows C# кодом

Понадобилось тут собрать С++ Qmake приложение под Windows используя cl компилятор из под C# приложения. При этом хотелось не запускать это C# приложение из под VisualStudio comand prompt, а разрулить всё прямо в коде.

Обычно, для сборки приложения в консоли студийным компилятором, необходимо открыть VisualStudio command prompt и делать сборку там, либо вручную вызвать vcvars64.bat или vcvarsall.bat для настройки окружения, но  тут есть 2 проблемы: 1. Как найти этот bat файл, 2. Как его запустить внутри C# приложения так, что бы он правильно настроил environment variables.

Решение:
1. Найти все VisualStudio >= 2017 можно при помощи приложения vswhere, которое ставится с VisualStudio installer
2. Находим VisualStudio при помощи vswhere, находим vcvars64.bat, выполняем bat файл, забирая себе его environment в текстовом виде, парсим и применяем в своё приложение.

//Find vswhere path
var programFilesDir = Environment.GetEnvironmentVariable("ProgramFiles(x86)");
var vsInstallationDir = Path.Combine(programFilesDir, @"Microsoft Visual Studio", "Installer");
var vsWherePath = Path.Combine(vsInstallationDir, "vswhere.exe");

//Find latest VisualStudio installation directory
var vsWhereResult = SystemProcess.Execute(vsWherePath, "-latest -property installationPath");
var vsInstallPath = vsWhereResult.outBuffer[0];

//Import VisualStudio environment
var vsEnvBatchFile = Path.Combine(vsInstallPath, @"VC\Auxiliary\Build\vcvars64.bat");
var vsEnvResult = SystemProcess.Execute("cmd", $"/C \"{vsEnvBatchFile}\" > nul 2>&1 && set");
Regex envVariableRegex = new Regex("^([^=]+)=(.*)");
foreach(var str in vsEnvResult.outBuffer) {
 var match = envVariableRegex.Match(str);
 if (match.Success) {
  System.Environment.SetEnvironmentVariable(match.Groups[1].Value, match.Groups[2].Value);
 }
}

В коде вообще нет ни каких проверок, потестил просто как proof of concept. SystemProcess - мой мини враппер над System.Diagnostics.Process, запускает процесс и возвращает массив строк stdout, stderr и exit code. По хорошему надо делать не совсем так, необходимо применить лишь diff переменных окружения, но в моей задаче это было не нужно. А дальше просто собираем своё Qmake приложение:

//run qmake
SystemProcess.Execute(@"C:\Qt\5.13.0\msvc2019_64_custom\bin\qmake.exe", proFileDir + " -spec win32-msvc \"CONFIG += release\"");
//run nmake
SystemProcess.Execute("nmake");

Попиливаю процедурную генерацию геометрии

  Для всякого моего домашнего прототипирования в Unity часто хочется быстро, "вот прям тут", не переключаясь в другую софтину,  сгенерировать визуализацию какой-нибудь занятной штуковины, например, 2D функции или же 3D объекта. Сейчас вот использую для визуализации линз оптической системы. Чаще всего это нужно "вот прям тут", т.к.  модели параметрические (те же линзы) и на каждое изменение параметров лезть в пакет 3D моделирования и править геометрию - пустая трата времени.

  Использовать готовые решения (даже не искал, знаю только о плагине Houdini для Unity) я, конечно же, не хочу. Так веселее, да и вообще это как отдых ) В большинстве случаев нода процессинга геометрии пишется просто и потому процесс не напряжен, а результат радует.

  Сегодня почти допилил L-System, стараясь косить под Houdini )

  Осталось немного доделать Context matching.

  А вот и хорошая книга по L-системам: The algorithmic beauty of plants

PSY-Q SDK (Sony PlayStation1 SDK) на Windows 10 x64

Для тех, кто уже попробовал запускать программы из PSY-Q SDK, понятно, что этот древний софт ещё не мало проблем принесёт.

На удивление, компилятор ccpsx оказался 32-битным и спокойно работает в Windows10 x64, чего не скажешь о cpe2x.exe (конвертер .cpe в .exe) и psymake.exe (аналог make), они 16 битные, написаны под DOS, а в Windows x64 NTVDM выпилен, потому приложения запустить невозможно. Видел я, конечно, порты NTVDM под x64, но там встраивание в систему идёт через заднее место и мне это не нравится, тем более они все с жирными пометками "proof of concept".

Но кто сказал, что это конец? psymake как бы можно вообще выкинуть, заменить его обычным make, например из MinGW!  Я решил ради любви к прекрасному оставить таки имя этой утилиты таким, какое оно есть, потому переименовал PSYMAKE.EXE в _PSYMAKE.EXE, вдруг пригодится, а так же вместо него запилил BAT файл PSYMAKE.BAT

@echo off
"C:\Program Files\mingw-w64\x86_64-7.2.0-posix-seh-rt_v5-rev1\mingw64\bin\mingw32-make.exe" %*

Теперь при вызове psymake на самом деле перевызывается mingw32-make.exe и всё параметры ему передаются через %*
А вот с cpe2x всё немного сложнее. Я видел его порт под x64, не из оригинальных исходников, а с нуля написанный. И снова у него были какие-то проблемы. Не тру это всё. Есть же рабочее решение, его просто нужно запустить...

DosBOX - вот кто придёт на помощь. Заменяем CPE2X.EXE на CPE2X.BAT вот примерно с таким контентом

@echo off
SET PSYQ_PATH=D:\L\PSOne\psyq
SET DOSBOX_EXE="C:\Program Files (x86)\DOSBox-0.74\DOSBox.exe"
SET SDL_VIDEODRIVER=dummy
REM cleanup CPE2X.EXE stdout file
copy /Y nul: CPE2XOUT.TXT > nul
REM execute CPE2X.EXE inside DOSBOX
%DOSBOX_EXE% -noconsole -c "MOUNT D 'D:\'" -c "D:" -c "cd %cd%" -c "%PSYQ_PATH%\bin\_CPE2X.EXE %* > CPE2XOUT.TXT" -c exit
REM print CPE2X.EXE stdout to console
type CPE2XOUT.TXT

Я тут свои реальные пути в системе оставил, ну да ладно.
Что там происходит:

1.

SET SDL_VIDEODRIVER=dummy

- т.к. DOSBOX написан с использованием SDL, то есть такой вот легальный путь запустить dosbox в headless режиме!

2.

copy /Y nul: CPE2XOUT.TXT > nul

- тут генерится/очищается файл, который будет содержать в себе выхлоп реального cpe2x.exe, нам же надо всё красиво сделать!

3. Вызываем DOSBOX!  Я монтирую реальный диск D в диск D внутри DOSBOX, так проще работать с путями. Потом переход в папку проекта: -c "cd %cd%"  тут важное уточнение: cd указывает на папку проекта, ибо я из неё запускаю данную команду, о том как это делается - напишу ниже. Дальше идёт запуск реального приложения

"%PSYQ_PATH%\bin\_CPE2X.EXE %* > CPE2XOUT.TXT"

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

4. Ну и принтим  в консоль вывод

type CPE2XOUT.TXT

С SDK вроде всё.

Далее внутри проекта прям рядом с сорцами и мейкфайлом я создаю ещё 1 bat файл build_console.bat

start "PSX Build Console" call "D:\L\PSOne\psyq\PSPATHS.BAT"

Он мне настраивает пути psy-q и оставляет окно консоли в котором я могу билдить проект! Это удобно!
Внутри окна консоли я просто вбиваю psymake и происходит магия! Всё отлично собирается и даже не видно, что я запускал dosbox!
Вот мой тестовый Makefile

.PHONY: all

all:main.c
  ccpsx -O3 -Xo$80010000 main.c -omain.cpe,main.sym,mem.map
  cpe2x main.cpe

После запуска psymake в этой консоли получаем вот такой красивый вывод:

D:\L\PSOne\projects\PS1Dev>psymake
ccpsx -O3 -Xo0010000 main.c -omain.cpe,main.sym,mem.map
cpe2x main.cpe
CPE2X Ver1.5
Copyright (C) 1994,1995 by Sony Computer Entertainment Inc.
convert from main.cpe to main.EXE for Japan area
pc0:0000881c  t_addr:00002710  t_size:00008800

Ретро задротство: запилил диски для PlayStation 1

Еле нашёл нормальные Jewel box-ы для дисков в Воронеже (не удивительно, время дисков уже прошло)! Китайцы же вообще обалдели, продают по цене от 140р за ОДНУ коробку!!! Ну да ладно, это как с биткоинами - главное вовремя закупиться ) Ах да, купил я эти коробки в классном магазинчике "Темп" на Плехановской, вот: https://goo.gl/maps/MUTooGEchcH2

Потом разобрался с размерами печати, запилил разметку в фотошопе и нагенерил кучу обложек, распечатал, вырезал, вставил в  диски и вот...

И вот

И вот

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

Ретро задротство: пишем простое приложение для PlayStation 1

Наконец дошли руки и я таки выполнил одно из древних желаний - написал хоть какой-то рабочий код для PlayStation1 !!

Буду иногда тут исследовать PS1 SDK (Psy-Q) https://github.com/L-proger/PS1Dev

Понял как выводится дефолтный текст (шрифт грузится из BIOS-а), очищается экран (можно просто очистить через GsClearDispArea или закинуть вместе с другими задачами через GsSortClear).

Курить ещё много чего надо, документация в SDK очень корявая и конечно же ни каких примеров в ней, благо есть демки в интернете, в них можно подсмотреть код )

Нашёл ещё крутейший эмулятор, no$psx:  http://problemkaputt.de/psx.htm  Он единственный (из всех что я видел) имеет дебаггер с breakpoint-ами и главное (для меня) умеет выводить в окно результат printf!!!  Дада, в ps1 был дебаг порт куда можно было принтить.

А вот и скрин (собрал диск .iso, запустил в эмуляторе, прожигать на болванку пока лень).

Если не извращаться и юзать всё как есть в SDK, то необходимо поставить Windows x86 (обязательно, в x64 не запускаются тулзы из SDK), не новее Windows 7.  Собственно, я и поставил Windows7 x86 в виртуалку, в ней и делаю сборку. Однако, программирую в своей хостовой OS Windows 10 в VisualStudio.  Открываю проект-папку, в json прописаны пути инклудов и вуаля,  годная IDE, комплит и OS в виртуалке только ради сборки.

STM32 HAL_SPI_TransmitReceive_DMA restart bug

  Захотелось мне перезапустить трансфер SPI прямо в колбэке HAL_SPI_TxRxCpltCallback. Казалось бы, из названия колбэка ясно, что вызывается он, когда и Tx и Rx полностью завершены и нет причин, почему в этом же колбэке нельзя запустить новый трансфер.

  А вот и есть: рукожопость.  Если внутри HAL_SPI_TxRxCpltCallback снова вызвать HAL_SPI_TransmitReceive_DMA, то трансфер никогда не завершится.

  А вот почему? Изначально не понятно, я же хорошо написал код, захендлил все Error code-ы библиотеки и если что-то не так, то я бы увидел в терминале ошибку и код автоматом бы мне вызвал breakpoint. Но всё вроде как ок, ошибок нет!

  Проверил под дебаггером - да,  HAL_SPI_TransmitReceive_DMA во второй раз возвращает HAL_OK! Статусы/регистры все сконфигурены корректно в SPI, стейт BUSY но прерываний нет... о_О

  Но не стоит недооценивать разработчиков HAL библиотеки, они те ещё рукожопы. Вспомнил я как несколько лет назад писал им в саппорт и уведомлял о баге, но конечно же его не починили )

Часть кода функции HAL_SPI_TransmitReceive_DMA:

/* Set the DMA AbortCpltCallback */

hspi->hdmarx->XferAbortCallback = NULL;


/* Enable the Rx DMA Stream/Channel  */

HAL_DMA_Start_IT(hspi->hdmarx, (uint32_t)&hspi->Instance->DR, (uint32_t)hspi->pRxBuffPtr, hspi->RxXferCount);


/* Enable Rx DMA Request */

SET_BIT(hspi->Instance->CR2, SPI_CR2_RXDMAEN);

  HAL_DMA_Start_IT возвращает код ошибки, который благополучно игнорируется! И кажется, что всё ОК )) А на самом деле HAL_SPI_TxRxCpltCallback  вызывается из прерывания RX DMA канала, а обработчик TX канала ещё не вызывался к этому моменту (он вызовется после RX канала).  И получается, что в колбэке RX DMA канала я перезапускаю передачу, которая не смогла запустить TX DMA канал  (он ещё не разлочен своим обработчиком прерывания) и потому всё висит.

  Это восхитительно.  Мало того, что TX прерывания ещё не было, но уже вызвался HAL_SPI_TxRxCpltCallback , так ещё и коды ошибок нагло игнорируются, вводя в глубочайшее заблуждение. Вот как так?  Железо у ST отличное, а код - говно...

Программирование и отладка NRF52 под ST-LinkV2

  NRF52 - ARM v7 микроконтроллеры от Nordic Semiconductor со встроенным радио (bluetooth, кастомные протоколы, 2.4 GHz).

  Официально программирование/отладка поддерживается хорошо лишь с J-Link, но он стоит в районе 500$, а прям ощутимого профита от его использования я особо не заметил ) Так зачем платить больше? По крайней мере для домашних проектов...

  На текущий момент в OpenOCD 0.10 нет драйвера флеш-памяти для NRF52, потому "из коробки" будет доступна только отладка, а стирание/прошивание чипа - нет.

  К счастью имеется уже готовый патч для OpenOCD, а так же инструкция как что собирать, которую я нашёл вот в этом обсуждении.

На всякий пожарный повторю здесь инструкции + дополню своими:

  Для начала при сборке в Windows придётся поставить кросс компилер, например, из msys или cygwin. Я предпочитаю mingw-w64 для x64 системы из msys, скачать можно тут.

  Запускаем mingw64.exe, ставим зависимости и инструменты, необходимые для сборки. Точный список уже не помню, но как минимум это я ставил:

pacman -S git
pacman -S curl
pacman -S make
pacman -S automake
pacman -S autoconf
pacman -S libtool
pacman -S pkg-config
pacman -S texinfo
pacman -S mingw-w64-x86_64-toolchain
pacman -S mingw64/mingw-w64-x86_64-dlfcn
pacman -S mingw64/mingw-w64-x86_64-libusb
pacman -S mingw64/mingw-w64-x86_64-libusb-usbdk
pacman -S mingw64/mingw-w64-x86_64-hidapi
pacman -S mingw64/mingw-w64-x86_64-libftdi

  Клонируем репозиторий:

git clone git://git.code.sf.net/p/openocd/code openocd-code
cd openocd-code

  Теперь необходимо применить патч, добавляющий поддержку NRF52. Однако я бы порекомендовал файл src/flash/nor/Makefile.am предварительно забэкапить )

git pull http://openocd.zylin.com/openocd refs/changes/15/3215/2

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

gedit src/flash/nor/drivers.c
gedit src/flash/nor/Makefile.am

  Во втором файле ещё и формат путей инклудов поменялся, потому там вообще ад, и как раз для этого я выше рекомендовал src/flash/nor/Makefile.am забэкапить, после чего его восстановить и вручную прописать инклуд NRF52. То есть к NOR_DRIVERS добавить файл %D%/nrf52.c \ и это всё, что там надо поменять.

Следующий шаг:

./bootstrap

После чего настраиваем сборку:

./configure \
    --prefix=/Your-path/openocd-git_install \  //Заменить на свой путь утановки
    --enable-aice \
    --enable-amtjtagaccel \
    --enable-armjtagew \
    --enable-cmsis-dap \
    --enable-dummy \
    --enable-ftdi \
    --enable-gw16012 \
    --enable-jlink \
    --enable-jtag_vpi \
    --enable-opendous \
    --enable-openjtag_ftdi \
    --enable-osbdm \
    --enable-legacy-ft2232_libftdi \
    --enable-parport \
    --disable-parport-ppdev \
    --enable-parport-giveio \
    --enable-presto_libftdi \
    --enable-remote-bitbang \
    --enable-rlink \
    --enable-stlink \
    --enable-ti-icdi \
    --enable-ulink \
    --enable-usb-blaster-2 \
    --enable-usb_blaster_libftdi \
    --enable-usbprog \
    --enable-vsllink

И собираем проект:

make
make install 

 Готово, OpenOCD собран. Теперь, для запуска его без предварительного добавления mingw директорий в PATH, необходимо рядом с OpenOCD.exe положить dll, от которых он зависит:

libftdi1.dll
libhidapi-0.dll
libusb-0-1-4.dll
libusb-1.0.dll

  Найти их все можно в папке msys64\mingw64\bin

  И казалось бы всё, готово, можно пользоваться. Да, но почти ) OpenOCD запускается и прекрасно себя чувствует, однако при попытке отладки любого st-link устройства каждый раз получаю ошибку:

stlink_usb_open(): stlink_usb_open
stlink_usb_open(): transport: 1 vid: 0x0483 pid: 0x374b serial: 
stlink_usb_open(): open failed

  Долго я думал что не так! И сорцы OpenOCD пытался править и очередные баги в исходниках libusb искать, но решил в итоге проблему намного проще )) Качаем бинарники libusb  https://sourceforge.net/projects/libusb/files/libusb-1.0/

  Заменяем корявую libusb-1.0.dll, взятую из mingw64, на нормальную из архива MinGW64\dll\libusb-1.0.dll и всё, программатор открывается.

  Пример *.cfg файла для OpenOCD

source [find interface/stlink-v2.cfg] 
transport select "hla_swd"
source [find target/nrf52.cfg]

Новая железка

  Прикупил вот в Китае для всяческих экспериментов поворотную платформу с 2 степенями свободы. https://ru.aliexpress.com/item/Official-smarian-2-DOF-All-Metal-Rotation-Base-Platform-for-Robot-Arm-with-2pcs-High-Torque/32793398433.html Интересная и относительно недорогая штука.

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

  Занятно, что ни у одного продавца на aliexpress, а также на сайте производителя http://makerobotix.com  я так и не нашёл мануала по сборке и в итоге потратил час на скручивание всех деталей вместе.

  Болтов и гаек продавец не пожалел, видимо в курсе канона, что после сборки просто обязаны остаться "лишние детали" )

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

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

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

  Ну и "лишние детали" после сборки:

Как убить материнскую плату за полчаса (перепаивание AMD GPU)

Дано:
1. Материнская плата ноутбука HP Pavilion DV6 6179er со сгоревшим GPU чипом.

2. Свежекупленный GPU чип на aliexpress

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

Задача: перепаять GPU чип.

Приступим:

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

2. Потихоньку прогреваем паяльным феном видео чип до 330 градусов.
3. Что-то не так, 330 градусов "как обычно", но чип недвижим.
4. Греем до 400 градусов - ноль реакции
5. Греем с ужасом до 430 градусов - начинает плавиться термоскотч и жутко вонять, чип недвижим о_О
6. Греем до 450 градусов - чип начинает двигаться. Здесь очень важно не прекращать ни в коем случае нагрев и не прикладывать ощутимых усилий в попытках сдвинуть чип. Лучше всего его поднимать вакуумным пинцетом, что я понял гораздо позже (. Если в процессе снятия чипа немного снизится температура, то он тут же обратно припаивается, да ещё и очень криво. Обратное припаивание в процессе снятия чипа может привести к тому, что можно сорвать площадки, к которым чип припаян. Они ОЧЕНЬ легко отрываются, тем более когда так жутко перегрета плата.
7. Снимаем чип (аккуратно, без усилий!!!). Тут ещё один важный момент есть: вокруг чипа напаяна куча SMD компонентов и снимая его пинцетом можно случайно толкнув сдвинуть эти самые SMD компоненты, потому куда приятнее поднимать его вакуумным пинцетом сразу вертикально.

8. На падах осталось много олова (или стали, WTF, почему у этого сплава температура плавления 450 градусов???), необходимо удалить всё аккуратно (о, да :(( ) и качественно, иначе чип плохо припаяется. Берём специальную оплётку, паяльник (и как я тупим дико и убираем подогрев феном, надеясь на паяльник), обильно смазываем флюсом и чистим пады.

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

Если приглядеться, можно заметить на фото оторванные площадки по краям (те, что поменьше)

Проблемы с File URI SVN в Linux после Windows

Ситуация такова: в локальной сети имеется компьютер с именем, например, server. На нём расшарена папка с именем svn в которой я храню свои SVN репозитории. На том компе нет реального "SVN сервера", просто расшареная виндовая (samba) сетевая папка, в которой вручную создаются репозитории  (каждый в своей подпапке).

Как чекаютятся репозитоии в windows в таком случае: используется file схема пути, т.е. например  file://server/svn/MyProject и всё работает отлично.

И вот настал тот час, когда мне стало необходимо зачекаутить этот репозиторий и из под Linux-а. Тут ждёт первая проблема: file схема на линуксе работает только с локальными путями! Все остальные требуют сервера на удалённом компьютере (что у меня сейчас не возможно). Первое решение очевидное - просто монтируем сетевую папку например в /mnt/svn и оттуда чекаутим file:///mnt/svn/MyProject  и это действительно отлично работает! Кроме одного косяка... Работая под Windows-ом в репозиторий MyProject я добавил внешний (external) репозиторий MyProject2! И конечно же до него путь сохранился такой: file://server/svn/MyProject2  и при чекауте MyProject SVN не может слить его зависимость по пути file://server/svn/MyProject2.

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

Первое действие - создал в корне файловой системы папку /svn и примонтировал в неё сетевую папку server/svn. Всё ок, я могу чекаутить мой проект по пути file:///svn/MyProject  Теперь на хватает в пути всего-то слова server. К счастью в svn есть один альтернативный вариант написания пути: file://localhost/svn/MyProject.  Однако проблема  в том, что на линуксе SVN просто удаляет слово localhost из пути! И если оно написано не верно, то выводит ошибку и ни чего не делает. Плохо, что нет резолва IP и чекаута по сети и слово localhost - просто затычка, однако в моём простом случае это и было решением )

Так как localhost просто заглушка и ни чего не значит, то его можно заменить и на другое слово, например...  на слово "server" )  Беда только в том, что внешних конфигов нет, это слово зашито в коде SVN. Но разве ж это настоящая проблема?

Решение:

1. Чекаут исходников subversion svn co http://svn.apache.org/repos/asf/subversion/trunk subversion

2. Идём в папку subversion/subversion/libsvn_subr, открываем файл dirent_uri.c
3. Находим функцию svn_uri_get_dirent_from_file_url
4. Ищем код

if (strcmp(hostname, "localhost") == 0)
    hostname = NULL;

5. меняем на такой код

if (strcmp(hostname, "localhost") == 0 || strcmp(hostname, "server") == 0)
    hostname = NULL;

6. Билдим SVN

 
   sudo apt-get install autoconf
   sudo apt-get install libtool-bin
   sudo apt-get install apache2-dev libapr1-dev libaprutil1-dev
   sudo apt-get install zlib1g-dev

   ./get-deps.sh
   cd apr/
   ./buildconf
   cd ../apr-util/
   ./buildconf
   cd ../apr-util/xml/expat/
   ./buildconf.sh
   cd ../../..
   ./autogen.sh
   ./configure
   make //в папке subversion

7. Устанавливаем в систему В папке subversion/subversion/svn лежит бинарник с именем svn Я его просто копировал в /usr/bin Но может ещё понадобиться сделать

    sudo make install

Иначе некоторые зависимости не находит! Почему make install не ставит сам бинарник (у меня) - не ясно, курить скрипты лень )

D3D12

Решил поломать код движка, да перевести на DX12. На удивление туго пошло осознание нового АПИ, пришлось потратить 4 вечера на минимальный порт. А вот и свежие восхитительные пиксели, отрендеренные на D3D12:

Отличная серия уроков по D3D12:  http://www.braynzarsoft.net/viewtutorial/q16390-setting-up-directx-12-for-visual-studio-2015

Работа с EEPROM 24C16 на STM32 контроллере

Понадобилось по-быстрому запилить простой "программатор" EEPROM микросхемы, да чтоб читать/писать память её можно было через юзерское приложение в Windows. И что-то я подзатупил изначально с адресацией памяти.

Для работы с EEPROM (и не только) в STM32CubeF4 библиотеке есть функции HAL_I2C_Mem_Read и HAL_I2C_Mem_Write, инициализацию I2C генерит приложение STM32CubeMX, в общем-то халява, осталось использовать функции, передать данные из/в компьютер и девайс готов. Однако меня сбил с толка параметр функций uint16_t MemAddSize, который может быть равен I2C_MEMADD_SIZE_8BIT или I2C_MEMADD_SIZE_16BIT.  В моей микросхеме 2048 байт памяти и логично предположить, что мне нужен вариант I2C_MEMADD_SIZE_16BIT,  т.е. 16 бит на адрес,ибо 8 бит хватит только на адресацию 256 байт.


А вот и нет. Память "побита" на блоки по 256 байт, выбор ID блока происходит через запись соответствующего ID в биты 1,2,3 байта адреса устройства:









Их можно трактовать как ID 256-байтного блока или просто как старшие дополнительные 3 бита адреса памяти (как в таблице и указано). То есть адресация здесь 11 битная.

Собственно, адрес _устройства_ получаем таким образом:  0xA0 | ((memory_address >> 7) & 0xE).  Нулевой бит по идее контроллируется библиотекой и делать операцию битового чтения & 0xF по идее не нужно. Но опыт подсказывает, что доверять библиотеке Cube от ST не стоит )

Вдруг кому сэкономит время )

HDMI на FPGA Cyclone II

Запилил на своём борде с Cyclone II генерацию HDMI сигнала. Всё сделано так же как и в проекте HDMI для платы Марсоход3, только у меня разрешение картинки 800x600x60Hz

Для генерации разрешения 800x600 необходимо во-первых заменить параметры таймингов в файле HDMI_1280.v на эти

always @(posedge pixclk) DrawArea <= (CounterX<800) && (CounterY<600); 
always @(posedge pixclk) CounterX <= (CounterX==1055) ? 0 : CounterX+1; 
always @(posedge pixclk) if(CounterX==1055) CounterY <= (CounterY==627) ? 0 : CounterY+1;
always @(posedge pixclk) hSync <= (CounterX>=840) && (CounterX<968);
always @(posedge pixclk) vSync <= (CounterY>=601) && (CounterY<605);

А так же сгенерить свою PLL с 2 выходами клоков на 40MHz и на 200MHz. 40MHz - частота тактования пикселей, с ней всё ясно, а вот 200 MHz это частота тактования TMDS энкодеров (в HDMI применяется TMDS 10 битное кодирование), они тактоваться должны на частоте в 10 раз быстрее пиксельклоков, однако т.к. используются DDR выходы ПЛИС-а, частота тактования TMDS делится на 2, итого (40*10)/2 = 200MHz

Симулятор квадрокоптера: симуляция щёточных DC моторов

Решил немного поразвлечься и запилить симуляцию щёточных моторов постоянного тока в Unity для виртуального квадрокоптера и не только.

Не думал о подобном ранее, но чуток покопавшись понял, что всё достаточно просто )
(Я далеко не физик/электронщик и могу что-то сам не так понимать или описывать, но тем не менее)

Щёточный DC схематически можно представить так:

R - сопротивление обмотки ротора.
L - индуктивность обмотки ротора
e - обратная ЭДС обмоток ротора.
J - момент инерции ротора

Из за вращения ротора в статичном магнитном поле в его обмотках появляется обратная ЭДС, создающая обратное напряжение в обмотках, которое ограничивает максимальные обороты движка (но не только оно ограничивает). Зависит линейно от угловой скорости ротора.

Так же есть ЭДС самоиндукции, появляющаяся при изменении тока, проходящего по обмоткам.
E = - L* (dI/dt)
- как видно тут участвует производная тока и самоиндукция будет влиять на работу мотора только когда ток меняется, КЭП.

e - величина линейная, зависит от угловой скорости ротора, равна k_e * w. k_e - константа обратной ЭДС.

Пользуясь вторым правилом Кирхгофа можно записать уравнение напряжения в моторе:

Vs = R*I + L*(dI/dt) + e;

тут Vs - напряжение питания мотора.

Не сложно переписать уравнение так, что бы выразить производную тока:

dI/dt = (Vs - (R*I) - e) / L;

Уже хорошо, но кроме тока нам интересны ещё и обороты движка, и крутящий момент же.
Для начала можно описать, так сказать, уравнение равновесия крутящих моментов:

Me = Mm + Mf + Ml

Me = электрический крутящий момент, т.е. момент, сгенеренный обмотками ротора.

Mm - механический момент ротора,  J* (dw/dt) где J - момент инерции ротора, кг*м^2

Mf - момент трения ротора, линейно зависит от угловой скорости, k_f * w,
Ml - момент внешней нагрузки на ротор.

w - угловая скорость ротора [рад/с]

т.е. Me = J*(dw/dt) + k_f*w + Ml;

Тут есть важная штука: "электрический" момент линейно зависит от тока на обмотках якоря и его коэффициент является одной из важнейших характеристик моторов. То есть "электрический" момент (Me) = k_t * I;

k_t * I = J*(dw/dt) + k_f*w + Ml;

Выразим производную угловой скорости ротора:

dw/dt = (k_t*I - k_f*w - Ml) / J

Теперь у нас есть 2 дифференциальных уравнения, которые можно проинтегрировать и получить графики работы движка.

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

Изначально ничего не сошлось, т.к. я не корректно вбил коэффициенты. Плюс к тому не ясно для какого точно напряжения построен график и какое точно сопротивление было у движка, для которого он строился.  Коэффициенты то есть в даташите, но они немного отличаются от того, что на графике!

Что бы график сошёлся идеально, необходимо было крутить несколько коэффициентов. Это достаточно геморно и потому я использовал алгоритм оптимизации Левенберга-Марквардта для автоматической подстройки параметров ))) Критериями ошибок стали максимумы и производные графиков тока и оборотов мотора, а так же разница между идеальными и реальными экстремумами графиков мощности и эффективности, вот что получилось:

Тут gizmo используется для отрисовки графиков, под ними подложка с текстурой реальных графиков. Всё вполне совпадает )

А вот график по времени. Сначала включается питание мотора и потом по достижению максимальных оборотов питание отключается. Видны 2 всплеска на графиках - большой пусковой ток и выброс в отрицательную сторону при выключении.  Синий график - обороты, красный - ток.

Коптер

   Начал совсем недавно пилить свой квадрокоптер. За основу пока взят мой борд STM32VLDISCOVERY. У него на борту не очень крутой контроллер STM32F100RBT6: 24MHz, 128Kb FLASH, 8Kb RAM, однако пока что его даже много )

   Что успел запилить:
Напаял железки на борд! 2 RFM70 радио модуля пока на 1 общий SPI, акселерометр BMA280 на отдельный SPI, собрал узел контроля оборотов коллекторного мотора, схемка вышла не сложная ) Через полевой транзистор IRLML2803  ШИМ-ом включаю/отключаю питание у мотора, скважностью пульса регулируются обороты, так же добавлен диод Шоттки в качестве шунта мотора, резистор на 100К что бы не происходило произвольного открывания затвора транзистора если WPM пин в подвешенном состоянии.

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

   Так же завёл акселерометр, что, в общем то, не сложно, используя стандартную библиотеку от BOSCH https://github.com/BoschSensortec/BMA2x2_driver.  Хотя конечно некоторые вещи в нём не очевидны! Например, у него в bma2x2.c файле в глобальной переменной u8 V_BMA2x2RESOLUTION_U8 = BMA2x2_14_RESOLUTION; захардкодена битность показаний осей акселерометра, всегда 14 бит. И это странно тем, что мне нужно менять чужой драйвер что бы получить другую битность.

   А ещё одна корявость состоит в том, что у них же в файле-примере bma2x2_support.c есть семплы имплементации функций чтения/записи SPI и чтение осей акселерометра. Акселерометр позволяет последовательно читать несколько регистров за раз! И для этого в семпле используются буферы и их размер задефайнен как #define SPI_BUFFER_LEN 5 чего не хватает для работы с функцией bma2x2_read_accel_xyz которая в этом же семпле и используется. Я изначально внимание не обратил и долго думал, почему у лежащего горизонтально акселерометра ускорение 0 )  Оказалось ось Z просто не вмещалась в буфер!

   Радио пока через RFM70. Для реального применения в квадрокоптере этот радио модуль не подходит из за малого радиуса действия (метров 10), но хоть что-то. Будет использоваться для передачи команд с пульта на коптер.

Мелкий апдейт движка

Добавил систему ввода, поддерживаются множество клавиатур, мышей, джойстиков, всё крайне просто и достаточно удобно.

auto keyboards = Input::instance()->keyboards();

if(keyboards[0]->get_key_state(0x57)){
gameObject->transform->set_local_position(gameObject->transform->get_local_position() + gameObject->transform->forward() * (deltaTime * move_speed));
}

Так же начал прикручивать AMP рендереры, пока что для параметрических поверхностей, чуть позже сделаю биндинги к полигональным моделям. Таким образом можно будет делать гибридный рендер стандартный (растеризацией полигонов) и Path Tracing-ом.

Сложнейший рендер: сферка отрендеренная трассировщиком пути, в цвете выведены нормали.

Unity Killer :D

Пописываю параллельно с остальными проектами "убийцу Unity" :D

Что уже есть:
Компонентная система сущностей, иерархии трансформов, шейдеры, система материалов удобная, класс для рисования Gizmo, меши с сабмешами, рендеринг из нескольких камер в кадре и так ещё всякие мелочи)   Скоро добавлю загрузку текстур и мешей.