Our Services

We provide the best services

Pixel Perfect Design

Lorem Ipsum is simply text of the printing and typesetting industry. Lorem ipsum has been dummy.

WooCommerce Ready

Lorem Ipsum is simply text of the printing and typesetting industry. Lorem ipsum has been dummy.

Satisfied Clients

Lorem Ipsum is simply text of the printing and typesetting industry. Lorem ipsum has been dummy.

Our Portfolio

Recent Projects

Business Resource
Business Resource

Business Solutions

Business Consulting
Business Consulting

Consultant

App Development
App Development

Online Store

Marketing Strategy
Marketing Strategy

Digital Marketing

Testimonials

What clients are say

Olivia Kevinson

"You guys are legendary! You guys are great and having amazing support & service. I couldn’t ask for any better. Thank you!"

Olivia Kevinson Founder
Mitchell Harris

"You guys are legendary! You guys are great and having amazing support & service. I couldn’t ask for any better. Thank you!"

Mitchell Harris Financer
Julia Cloe

"You guys are legendary! You guys are great and having amazing support & service. I couldn’t ask for any better. Thank you!"

Julia Cloe Sales Manager

Recent Updates

Our Latest News

Настройка ограничения тока на TMC2209 через V_ref

В интернете очень много разных “формул” для расчёта напряжения на подстроечном резисторе, задающем ограничение тока RMS, и все они разные. Лучше почитать даташит…

Важно уточнить, что на данный момент я не использую UART протокол в драйверах и все значения регистров внутри драйверов после включения остаются по умолчанию. И вот по умолчанию там сконфигурировано использование Vref для масштабирования ограничения по току и использование внешних Rsense регистров для задания максимально “доступного” тока. Эти резисторы ставятся на BRA(23), BRB(27) пины и их легко найти на плате:

Это фото моего драйвера и на нём жёлтыми рамками выделены Rsa, Rsb резисторы (те самые Rsense). На них написано R110 что равно 110мΩ (0.11Ω). Без этого значения просто не возможно ни чего посчитать. И эти резисторы могут быть какими угодно у разных производителей плат драйверов и каким образом кто-то что-то в интернете может рекомендовать не призывая узнать номинал резисторов – мне не понятно.

Итак, миссия 1 выполнена и значение Rsense узнали. Теперь нужно найти формулу расчёта ограничения RMS тока в даташите:

Осталось только разобраться немного с Vvref. В даташите сказано, что значение (Vvref / 2.5) используется как множитель к ограничению тока, заданному Rsense резисторами. То есть если, например, Vvref == 2.5, то множитель будет == 1.0, а если, например Vvref == 1.0, то множитель будет равен 1.0/2.5 == 0.4. Значение напряжения Vvref выше 2.5 трактуется как 2.5, то есть множитель всегда будет равен 1.0 при Vvref >= 2.5.

Как ранее стало известно, у меня стоят Rsense резисторы на 110мОм, подставим это значение в формулу и упростим её:

I_rms = (325 / (110 + 20)) * (1 / sqrt(2)) * (V_vref / 2.5)
I_rms = 2.5 * 0.7071 * (V_vref / 2.5)

Тут номиналы резисторов Rsense так удобно подобраны, что умножение и деление на 2.5 можно сократить и получим:

I_rms = 0.7071 * V_vref
V_vref = I_rms / 0.7071

И да, на некоторых сайтах такой множитель рекомендуют, но без знания номинала Rsense нельзя быть уверенным, что всё посчитано правильно. И ещё на некоторых сайтах написано, что “Значение (Vref) не должно превышать 1.2 В или драйвер может выйти из строя“. Вот откуда это взялось??? В даташите не только сказано, что диапазон настройки Vvref до 2.5V (а вообще до 5V, но оно “обрежется” до 2.5V при расчёте множителя), так ещё и дополнительно сказано следующее:

то есть ниже 0.5V вообще не надо опускаться, да и лучше больше 1.0V ставить значение, в диапазоне 2-2.4V (но для этого надо правильно подобрать Rsense конечно). И сжечь мой драйвер, выставив Vvref в 2.5V, ни как не получится, ведь если посчитать по формуле максимальный ток: I_rms = 0.707 * 2.5 получим ток 1.767A, что ниже заявленного продолжительного RMS тока:

И ещё один момент: не стоит использовать результат расчёта по формуле “как есть”. Это “идеальное” значение, но номиналы Rsense резисторов могут оказаться не очень точными да и мотор может не держать заявленный ток и потому лучше выставить значение на 10-20% меньше, чем посчитанное по формуле, для безопасности.

1
0
FluidNC (и Candle) на Wemos D1 R32 + CNC SHIELD V3 + TMC2209 + SD Card + OLED Display на 4 оси

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

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

Глава 1: Питание

CNC SHIELD сделан под Arduino, у которой 5V логика. Wemos же сделан на основе ESP32 и тут логика 3.3V, потому решил запитать CNC SHIELD от 3.3V. Для этого надо:

  1. Удалить ножку 5V на шилде, чтоб на шилд с платы Wemos не поступали 5V в принципе. Я просто откусил кусачками ножку в PLS гребёнке.
  2. В верхнем правом углу на шилде есть 2 пина, стоящие рядом: 3.3V и 5V – их надо соединить между собой перемычкой. Так с шины 3.3V будет подано питание на шину 5V что и нужно.

Глава 2: Распиновка

Если понадобится использовать SD карту (да, понадобится), то не получится сохранить соответствие функций пинов на шилде с их шелгографией. SD карта ну ни как не захотела заводиться на других пинах, кроме IO5, IO18, IO19, IO23 на ванильной прошивке FluidNC и потому необходимо некоторые функции переместить на другие пины.

А ещё на самой плате Wemos не правильные подписи некоторых пинов, как и на изображениях самой платы в интернете. Это жесть. Я всё прозвонил, исправил обозначения на картинке из интернета и подписал функции всех задействованных в проекте пинов:

Глава 3: ESP32 не загружается

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

ESP32 не будет загружаться со вставленной платой CNC SHIELD. Виновником оказался IO12 пин. На CNC SHIELD плате это EN пин. Он идёт к драйверам моторов на плате на соответствующие EN ножки. IO12 не обычный пин, это т.н. bootstrap pin и его функция при старте ESP32 это выбор напряжения питания внешней микросхемы FLASH памяти с которой грузится микроконтроллер. По умолчанию при старте ESP32 этот пин подтянут к GND и будет выбрано питание 3.3V, однако на плате CNC SHIELD этот пин подтянут резистором к VDD (+питания) из за чего при старте контроллера выбирается не правильное (1.8V) питание FLASH.

Я удалил этот резистор (указано на картинке выше), тем более он всё равно бесполезен, т.к. на каждом драйвере этот пин всё равно подтянут к питанию 4.7К резисторами. И после его удаления ESP32 стартует успешно, но это только если в shield не вставлены драйверы моторов.

Устанавливаем драйверы моторов в соответсвующие разъёмы и.. снова ESP32 не загружается. Но тут всё легко, т.к. проблема всё та же – IO12 пин. На каждом драйвере установлен свой резистор для подтяжки к питанию пина EN, потому после установки драйверов EN (IO12) снова подтянут к питанию и снова та же проблема с загрузкой. Я решил эту проблему простым костылём, сделав “джампер” с резистором на 2К между EN и GND пинами на CNC SHIELD (указано на картинке 2).

Глава 4: Конфигурация

После установки последней прошивки FluidNC я залил в неё файл конфига через WEB интерфейс и применил его. Моторы крутятся, OLED дисплей работает:

name: "ESP32"
board: "Wemos_CNCShield"
meta: "4axis"

stepping:
  engine: RMT
  idle_ms: 250
  dir_delay_us: 1
  pulse_us: 2
  disable_delay_us: 0

axes:
  shared_stepper_disable_pin: NO_PIN

  x:
    steps_per_mm: 200
    max_rate_mm_per_min: 400
    acceleration_mm_per_sec2: 2
    max_travel_mm: 100
    homing:
      cycle: 2
      mpos_mm: -3.000
      feed_mm_per_min: 400
      positive_direction: false
    
    motor0:
      limit_all_pin: gpio.36:low
      hard_limits: false
      pulloff_mm: 3.000
      stepstick:
        direction_pin: gpio.16
        step_pin: gpio.26

  y:
    steps_per_mm: 200
    max_rate_mm_per_min: 400
    acceleration_mm_per_sec2: 2
    max_travel_mm: 100
    homing:
      cycle: 2
      mpos_mm: -3
      feed_mm_per_min: 400
      positive_direction: false
    
    motor0:
      limit_all_pin: gpio.34:low
      hard_limits: false
      pulloff_mm: 3
      stepstick:
        direction_pin: gpio.27
        step_pin: gpio.25

  z:
    steps_per_mm: 200
    max_rate_mm_per_min: 400
    acceleration_mm_per_sec2: 2
    max_travel_mm: 10
    homing:
      cycle: 1
      mpos_mm: 3
      feed_mm_per_min: 400
      positive_direction: true
    
    motor0:
      limit_all_pin: gpio.35:low
      hard_limits: false
      pulloff_mm: 3
      stepstick:
        direction_pin: gpio.14
        step_pin: gpio.17

  a:
    steps_per_mm: 200
    max_rate_mm_per_min: 400
    acceleration_mm_per_sec2: 2
    max_travel_mm: 360
    
    motor0:
      limit_all_pin: gpio.39:low
      hard_limits: false
      pulloff_mm: 3
      stepstick:
        direction_pin: gpio.32
        step_pin: gpio.33

spi:
  miso_pin: gpio.19
  mosi_pin: gpio.23
  sck_pin: gpio.18

sdcard:
  cs_pin: gpio.5
  card_detect_pin: NO_PIN

coolant:
  flood_pin: gpio.15

probe:
  pin: gpio.13:low:pu

user_outputs:
  digital0_pin: gpio.12

PWM:
  pwm_hz: 5000
  output_pin: gpio.2
  enable_pin: gpio.4
  disable_with_s0: false
  s0_with_disable: true
  speed_map: 0=0% 10000=100%
  
i2c0:
   sda_pin: gpio.21
   scl_pin: gpio.22

oled:
   i2c_num: 0
   i2c_address: 60
   width: 128
   height: 64
   radio_delay_ms: 1000

Глава 5: Candle

Мне лично удобно некоторые задачи выполнять через Candle и потому решил разобраться с тем, как его подключить к FluidNC. На данный момент подключаюсь к нему через виртуальный COM порт, работающий поверх IP сети. Использую программу Tibbo. Настройка там тривиальная – достаточно создать в Tibbo VSP Manager новый COM порт и указать IP адрес FluidNC платы и порт 23, после чего можно использовать этот порт в Candle.

0
0
Проектирую новые оси X и Z для своего CNC станка

Есть у меня китайский недостанок с рабочей областью 16×10 см. Изначально он не мог, конечно, ничего, но тем веселее его превращать в адекватный.

В прошлом я уже делал ему апгрейды:

  • Заменил шпиндель с 60W на 250W
  • Поставил нормальный драйвер для шпинделя
  • Прикрутил к станку блок питания на 300W и запитал с него всё, чтобы одним проводом в розетку подключать
  • Пересобрал ось Y на рельсы
  • Заменил ER11 гайку на хорошую и купил точные цанги

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

Начать переделку решил с изучения CAD софта. Не сильно это просто когда болеешь, но спустя день вот что удалось сделать с нуля:

Пока решил оставить стандартные стойки оси Y и посадить рельсы на штатные профили. В идеале было бы хорошо и эти стойки переделать, но для этого нужен ЧПУ по-больше (и алюминия по-больше) и пока не хочется с этим возиться.

Ось Z делал максимально компактной, так как её расширение съедает ширину рабочей области. И теперь станок у меня будет не 16×10 а 15×11.5 чего в принципе достаточно для моих развлекух.

Осталось это всё сделать…

А так выглядит тестовая фрезеровка дорожек платы концевой фрезой 0.2мм:

0
0
Моя первая печатная плата

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

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

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

Засел я за изучение САПР системы, схемотехники, электроных компонентов, основ трассировки плат, поспрашивал вводные у коллеги (за что ему большое спасибо) и спустя 4 вечера обучения, создания схемы и трассировки плата была заказана на заводе Резонит. Да, она тривиальная, все могут такое создать и я уже знаю как её надо переделать в следующей версии, но всё же, пройти все этапы и в итоге держать настоящую плату спроектированную своими рукаим – это отличное ощущение )

Осталось дождаться посылок с электронными компонентами )

0
0
mipsel-none-elf GCC toolchain for Sony PlayStation1

Иногда хочется просто так пописать код под что-то экзотичное, ограниченное в ресурсах для расширения сознания. А в случае с PlayStation1 можно программировать и 3D графику, что вдвойне более весело.

Официальный PS1 SDK Psy-Q не удаётся удобно использовать, т.к. многие из утилит в тулчейне собраны под DOS, который был удалён из Windows 10+. Писать код в виртуальной машине не очень здорово, поэтому собрал себе GCC тулчейн для удобного программирования.

GCC: 12.2
Binutils: 2.39
Newlib: 4.2.0.20211231
Target: mipsel-none-elf

Собирал с Ubuntu 22.10

Собрал тулчейн на основе newlib со стандартной библиотекой C++. Изначально я так же собирал с поддержкой компилятора С++, но без стандартной библиотеки, что не очень удобно, т.к. многие стандартные файлы здорово иметь под рукой. Например, <new>, для использования placement new, или <type_traits>, <array> и т.п.

Скачать

Windows x64

mipsel-none-elf-gcc-12.2.0-binutils-2.39-libstdc-windows.tar.gz

Linux x64

mipsel-none-elf-gcc-12.2.0-binutils-2.39-libstdc-linux.tar.gz

Удалось написать простой проект, собрать и запустить в эмуляторе:

0
0
Сборка Cross GCC тулчейна под Debian-based ARM Linux со старым ядром

Так случается в жизни, что небходимо собрать С++ код, написанный по самым свежим стандартам, под систему, в которой (или для которой) доступны только компиляторы устаревшей версии.

В моём случае появилась необходимость получить cross компилятор GCC 11+ версии, собранный с glibc версии именно 2.27. И он обязательно должен знать о Debian multiarch для правильной сборки приложений под Ubuntu, RaspberryPi OS и т.п.

Конфиги в мануале собирают тулчейн с такими компонентами:
gcc: 11.2.0 [C/C++]
Linux kernel: 4.9.301
glibc: 2.27
gdb: 11.2

Хост система

Сборку произвожу в Ubuntu 22.10

Установка софта в хост систему

sudo apt update

sudo apt-get install -y gcc g++ gperf bison flex texinfo \
    help2man make libncurses5-dev python3-dev autoconf \
    automake libtool libtool-bin gawk wget bzip2 xz-utils unzip \
    patch libstdc++6 rsync git meson ninja-build

Сборка crosstool-ng

wget http://crosstool-ng.org/download/crosstool-ng/crosstool-ng-1.25.0.tar.bz2
tar -xf crosstool-ng-1.25.0.tar.bz2
rm crosstool-ng-1.25.0.tar.bz2
cd crosstool-ng-1.25.0
./configure --enable-local
make

Получение патча поддержки debian multiarch для binutils

# В директории crosstool-ng-1.25.0
mkdir -p patches/binutils/2.31.1/
wget https://sources.debian.org/data/main/b/binutils/2.31.1-11/debian/patches/129_multiarch_libpath.patch -P patches/binutils/2.31.1/

Целевая директория

Мои конфиги установят собранные тулчейны в директорию /crossbuild/toolchain Её необходимо предварительно создать и изменить владельца/разрешения так, чтоб пользователь, от имени которого будет запущен билд, имел доступ на запись и чтение в этой директории. Иначе можно поменять эту директорию в конфиге самостоятельно.

Проблемы во время сборки

После чего можно приступать уже к сборке тулчейнов, однако, она скорее всего не будет успешной конкретно с используемой мной версией crosstool-ng, т.к. он не сможет скачать исходники zlib. Выглядит это примерно так:

Исходники crosstool-ng я не хочу править, поэтому просто скачал требующуюся версию zlib сам и положил в папку кеша. Как видно из скриншота, crosstool-ng хочет zlib-1.2.12, качаем:

# В директории crosstool-ng-1.25.0
wget https://zlib.net/fossils/zlib-1.2.12.tar.gz -P .build/tarballs

Сборка arm-linux-gnueabihf тулчейна

# В директории crosstool-ng-1.25.0
wget https://l-proger.ru/wp-content/uploads/2022/12/config_arm_gcc11.txt
cp config_arm_gcc11.txt .config
export DEB_TARGET_MULTIARCH=arm-linux-gnueabihf
./ct-ng build

Сборка aarch64-linux-gnu тулчейна

# В директории crosstool-ng-1.25.0
wget https://l-proger.ru/wp-content/uploads/2022/12/config_aarch64_gcc11.txt
cp config_aarch64_gcc11.txt .config
export DEB_TARGET_MULTIARCH=aarch64-linux-gnu
./ct-ng build

Запаковка тулчейнов в архив

cd /crossbuild/toolchain
tar -czf gcc11.2.0-aarch64-linux-gnu-kernel4.9.301-glibc2.27-gdb11.2.tar.gz ./gcc11.2.0-aarch64-linux-gnu-kernel4.9.301-glibc2.27-gdb11.2
tar -czf gcc11.2.0-arm-linux-gnueabihf-kernel4.9.301-glibc2.27-gdb11.2.tar.gz ./gcc11.2.0-arm-linux-gnueabihf-kernel4.9.301-glibc2.27-gdb11.2


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

0
0
“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, как только её в порядок приведу )

 

0
0
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:ProgramDataOracleJavajavapath ! В нём лежат 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_MACHINESOFTWAREJavaSoftJava Runtime Environment12.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_MACHINESOFTWAREJavaSoftJDK]
“CurrentVersion”=”13.0.0”

[HKEY_LOCAL_MACHINESOFTWAREJavaSoftJDK10.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.

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

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

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

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

0
0
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 Filesmingw-w64x86_64-7.2.0-posix-seh-rt_v5-rev1mingw64binmingw32-make.exe" %*

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

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

@echo off
SET PSYQ_PATH=D:LPSOnepsyq
SET DOSBOX_EXE="C:Program Files (x86)DOSBox-0.74DOSBox.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:LPSOnepsyqPSPATHS.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:LPSOneprojectsPS1Dev>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
0
0