Category Без рубрики

Наконец изготавливаю новые оси для настольного CNC фрезера )

Разобрался с CAD/CAM софтом и отфрезеровал первые в моей жизни алюминиевые детали по моему проекту )

Оказалось это всё очень просто, что проектировать, что обработку описывать в CAМ софте. Получилось с первого раза )

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

Как доделаю Z ось нужно будет сразу добавить в сетап мой самодельный микро пылесос, а то стружки вагонище. Ну и коробку-глушитель сделать для станка )

0
0

Новый проект Z-оси станка

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

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

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

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

Ретро задротство: пишем простое приложение для 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 в виртуалке только ради сборки.

0
0

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 отличное, а код – говно…

0
0

Программирование и отладка 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

  Найти их все можно в папке msys64mingw64bin

  И казалось бы всё, готово, можно пользоваться. Да, но почти ) 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, на нормальную из архива MinGW64dlllibusb-1.0.dll и всё, программатор открывается.

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

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