All posts by l-proger

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

И вот

И вот

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

Понял как выводится дефолтный текст (шрифт грузится из 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 в виртуалке только ради сборки.

  А вот и есть: рукожопость.  Если внутри 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 отличное, а код – говно…

  Официально программирование/отладка поддерживается хорошо лишь с 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]

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

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

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

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

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

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

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

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

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

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

Приступим:

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

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

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

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

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

Как чекаютятся репозитоии в 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, что проблематично, но не возможного же не бывает…

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

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

 
   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

    sudo make install

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

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

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

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

Для генерации разрешения 800×600 необходимо во-первых заменить параметры таймингов в файле 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