arm-none-eabi-gdb and Python 3.8 issue

In this post, I’m going to show, how to fix an issue with arm-none-eabi-gdb from ARM GNU Toolchain, and old Python 3.8 or Python 3.6 dependencies

Not a long time ago, I’ve updated my home computer with fresh Xubintu 24.04 LTS, so I need to reinstall/resetup my develop enviroment for STM32

If you had an experience with installation of ARM GNU Toolchain on Linux, I guess you also had a painfull experience with ancient and non-working installation instruction for Linux provided by ARM. In general, installtion procedure is quite simple: just unpack an archive, than add «bin» directory into PATH variable.

But! The main issue is a GDB binary with python-based TUI (terminal user interface). It is linked with the old Python 3.8 library, and legacy (plus removed in fresh distros) libncurses5 library.

On the previous Xubuntu 22.04, I’ve used a solution with a custom repository, but for the current Xubintu 24.04 Python 3.8 doesn’t exist, and libncurses5 package has been removed from repositories. How can we solve this problem?

After a litte search, I’ve found a suitable solution on StackOverflow. Just build your own GDB with actual Python for you system! It is quite simple!

I’ve checked this instruction, and did a small change in the tutorial: replaced final «make install» command on a deb-file generation, because simple «make install» just copies compiled binary and other files into your system directories without any control. Please, DON’T DO IT on modern repository-based Linux systems! All software MUST BE installed using a system package manger.

OK. Let’s installation begin! I’m going to do all my action in «/storage/Temp» directory.

Part I. GDB compilation

At first, let’s install all required packages for a compilation

Then, fetch fresh sources for GDB

Unpack it

Create a directory for compilation

And the directories for a future package’s tree

Move to the build directory

And run pre-configuration. Please mention «—prefix» option. It points on our «package’s tree» dir

Run compilation process

And finally, make an «installation»

Well, let’s check what we have in our installation dir

Great! We have «arm-none-eabi-gdb» binary. But we have to check, which kind of libraries linked to our binary.

Success! Our custom GDB binary linked with the fresh system Python, and libncurses libraries! Save this command output, it will be usefull for future steps.

Part II. Build custom «deb» package file

Now we can build our custom «deb» package for the installation.

Add follwing text into «control» file

Also, I have to mention, how to collect a list of packages for the «Depends» option. Look at the output of «ldd» command. It contains list of required shared libraries. Just get the library name from the output (for example, I will use «libexpat»), and find similar in the installed packages.

OK, we have «libexpat1» and «libexpat1-dev». The second is just for compilation from sources, and not needed for the our binary package. Re-check our choice, by listing all files, related to the «libexpat1» package. Yes, it includes /usr/lib/x86_64-linux-gnu/libexpat.so.1 file, so we can add «libexpat1» into «Depends» section.

Right now we have a «package installation tree» in «/storage/Temp/arm-none-eabi-gdb» directory. And on this step, better to check, have we intersections with already installed files in our system, or not. Our package tree has «gdb» directory in /storage/Temp/arm-none-eabi-gdb/usr/share/. And it contains something.

But our current system directory also has same directory and files in /usr/share/!

Unfortunallty, I don’t know, how package mainteiner have to resolve similar issues. I’ve removed confilcting directories and files form «package installation tree»

Well, it is time to build the package. Move to the top directory

And build the package

Recheck what the package contains

Now, we can install it using dpkg

Check it

ICOM PCR-1000. Внешнее управление

Лет 10 назад, до тех времен когда получили широкое распостранение USB донглы rtl-sdr, единственной возможностью слушать желаемые частоты в эфире, была покупка сканирующего радиоприемника. А еще хотелось, чтобы им можно было управлять с компа, ибо крутить валкодер своего Degen DE1103 весело, но утомительно.

И вот я, долго выбирая, остановился на брутальном кирпиче ICOM PCR-1000. Диапазон от 100 кГц до 1.3 ГГц. Управление с компа. Сказка!

Поигрался я им, поигрался, и потребность иметь компьютер для управления приемником начинала раздражать. Иногда хотелость что-то послушать вдали от цивилизации, а цивилизацию в виде ноутбука приходилось тащить с собой. И как-то он оказался запихнут в дальний ящик. Я конечно его извлекал, делал ему модификацию с выводм ПЧ наружу, для ее оцифровки и добавления панорамного SDR. Но все же потребность в куче проводов, и каки-то болтающихся проводов идущих к компу, утомляет.

В прошлом году, я захватил из дома в Вильнюс этот приемник, дабы дореализовать одну интересную идею. А именно — независимый модуль управления PCR-1000.

Требования я сформулировал следующие:

  • Подключение к компьютеру по USB
  • Возможность управлять приемником с панели управления
  • Возможность переключаться между режимами управления с панели и управлением с компьютера.
  • Возможность батарейного питания.
  • Возможность подключения внешних динамиков, ибо громкость встроенного зачастую недостаточна.
  • (опиционально) вывод звука на компьютер через USB, c с представлением в системе как звукового источника

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

И вот в феврале этого года я допилил беспроблемную работу сквозь STM32F4. На удивление все пошло достаточно легко.

В настоящий момент моя прошивка умеет передавать все команды от компа к приемнику, и отображать выставленные параметры. Так же от приемника я принимаю уровень сигнала, и так же показываю его на экране.

Снял небольшое видео, о том как оно все работает.

Из неприятного — наблюдатся глюки с отображением значнений ширины фильтра. Подебажив это дело, я обнаружил, что PythonPCR какого-то черта в отсылает команду установки параметров мало того что обрезаную (нет установки фильтра), так еще и без финальных «\r\n» символов.

Это дерьмо сбивало парсинг, и на экране я получал мусор. Сейчас я решил обрабатывать лишь корректные полные команды. Но это вызывает иногда неотрисовку значений фильтра и модуляции. Буду думать.

А пока, вполне оптимистично!

Нехватка магии в волшебной палочке

Выходные пролетели, а SPI в stm32f103 под libopencm3 все так и не заводится.

Ну ладно, я первый раз не заметил что в конфигах секции данных для mapple и bluepill отличаются.

Но чего потом, оно не заводится даже с примерами из гитхаба — не ясно.

Причем у меня есть мой код использующий spl, и он рабочий. Я тупо переписал инициализацию, а логический анализатор даже поднятие CS не показывает.

STM32F411 «Black Pill» USB & Libopencm3 bug

Небольшая заметка по результатм исследования бага с неработающей инициализацией USB с библиотекой LibOpenCm3 для китайской платки WeAct «Black Pill» v2.0.
Если не у вас не работают примеры для USB, и система даже не проводит энумерацию подключенного устройства, то вам надо:

  1. Заинклюдить otg_fs.h
    #include <libopencm3/usb/dwc/otg_fs.h>
  2. После вызова функции usbd_init отключить VBUS sensing
    OTG_FS_GCCFG |= OTG_GCCFG_NOVBUSSENS | OTG_GCCFG_PWRDWN;
    OTG_FS_GCCFG &= ~(OTG_GCCFG_VBUSBSEN | OTG_GCCFG_VBUSASEN);

Фикс-реквест все еще с 2020 года ждет мержа.
https://github.com/libopencm3/libopencm3/pull/1256