DEV Community: Alexey Bolshakov

FMix: пакетный менеджер для Forth

Alexey Bolshakov — Mon, 18 May 2026 23:12:43 +0000

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

В Elixir есть Mix. В Rust есть Cargo. В Ruby есть Bundler и RubyGems. В Haskell есть Cabal и Stack. В JavaScript есть npm, pnpm и Yarn. В Go есть modules.

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

Но у старых языков программирования часто другая история.

Когда многие из них создавались, такой подход ещё не был стандартом. Код распространялся иначе, проекты были устроены иначе, а экосистемы развивались без привычных сегодня package managers и build tools.

И это до сих пор чувствуется.

Почему я задумался об этом

Для одного из своих проектов я использую Forth.

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

Но когда я начал писать на Forth что-то более-менее похожее на проект, мне быстро стало не хватать привычных вещей:

создать новый проект;
описать зависимости;
скачать зависимости;
запускать тесты;
иметь понятную структуру проекта;
подключать библиотеки из Git;
не держать всё вручную в голове.

Да, можно использовать git submodules, можно копировать файлы руками, можно придумывать свои соглашения. Но для меня это не очень удобный путь. Я хотел что-то ближе к тому, к чему привык в современных языках.

Я нашёл библиотеку f.4th, связанную с theforth.net. Это полезный инструмент, но у него другой подход: библиотеки и версии хранятся на своём сервере.

Мне же хотелось уметь подтягивать зависимости прямо из Git-репозиториев. Например, указать GitHub URL, ветку или тег, и получить библиотеку в проект.

Так появилась идея сделать fmix.

Что такое FMix

fmix — это небольшой build tool и package tool для Forth, вдохновлённый Elixir Mix.

Репозиторий: github.com/VitaSound/fmix

Он не пытается быть большим фреймворком. Его задача проще: дать Forth-проекту минимальный набор привычных инструментов.

Сейчас fmix умеет:

fmix new example
fmix packages.get
fmix test
fmix version

То есть можно создать новый пакет, подтянуть зависимости, запустить тесты и посмотреть версию инструмента.

Создание проекта

Новый проект создаётся так:

fmix new example
cd example

После этого появляется базовая структура проекта:

example/
  example.4th
  package.4th
  README.md
  tests/
  forth-packages/

package.4th — это файл описания пакета. В нём указывается имя, версия, лицензия, основной файл и зависимости.

Пример:

forth-package
    key-value name example
    key-value version 0.1.0
    key-value license COPL
    key-value description example
    key-value main example.4th

    key-list dependencies f git https://github.com/VitaSound/f tag 0.2.4
    key-list dependencies ttester git https://github.com/VitaSound/ttester tag 1.1.0
end-forth-package

Мне нравится, что сам файл тоже написан в стиле Forth. Это не JSON, не YAML и не TOML, а маленький декларативный Forth-формат.

Зависимости из Git

Главная причина, по которой я начал делать fmix, — это зависимости из Git.

В package.4th можно указать зависимость так:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git branch main

Или так, если нужна конкретная версия через tag:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git tag 0.1.0

После этого достаточно выполнить:

fmix packages.get

Зависимости будут установлены в локальную папку проекта:

./forth-packages/

Структура позволяет хранить разные версии одной библиотеки рядом друг с другом:

forth-packages/
  f/
    0.2.4/
  ttester/
    1.1.0/

Подключать зависимость можно обычным require:

require ./forth-packages/f/0.2.4/f.4th

Поддержка theforth.net

Хотя мне хотелось Git-зависимостей, я не хотел полностью отказываться от существующей экосистемы.

Поэтому fmix также умеет работать с пакетами из theforth.net через f.4th.

Например:

key-list dependencies f 0.2.4

Таким образом, в одном проекте можно использовать и Git-зависимости, и пакеты из theforth.net.

Тесты

Ещё одна базовая вещь, которой мне не хватало, — запуск тестов.

В fmix есть команда:

fmix test

Она запускает тесты из директории tests/.

Можно запустить и конкретный файл:

fmix test tests/some_test.4th

Для тестов используется ttester. Если ttester есть в зависимостях проекта, fmix берёт его из ./forth-packages. Если нет — использует версию из установленного FMIX_HOME.

Для меня это важно: тесты должны запускаться одной командой. Даже если проект маленький.

Что было исправлено в последних версиях

fmix пережил уже несколько поколений изменений.

Первые версии я писал сам. Но я не очень сильный Forth-разработчик, поэтому многие вещи давались тяжело. Одну крупную переработку я сделал с помощью Gemini. Последнюю версию я уже доводил с помощью Cursor.

В последних релизах было исправлено довольно много практических проблем.

Появился GitHub Actions CI: workflow собирает GForth 0.7.9 из исходников и запускает:

gforth fmix.4th -e version
gforth fmix.4th -e test

Позже появился release pipeline: при push version tag автоматически создаётся GitHub Release, а текст релиза берётся из файла .github/RELEASE_NOTES_X.Y.Z.md.

Также были исправлены проблемы с путями. Раньше часть логики была завязана на PWD, теперь проект определяется через текущую директорию запуска. Это важно, потому что FMIX_HOME указывает на установленный fmix, а команды должны работать с текущим проектом.

Были исправлены ошибки при установке зависимостей:

git clone теперь проверяет результат;
неуспешные shell-команды завершают GForth с exit code 1;
перед git clone создаются родительские директории;
git fetch и checkout выполняются так, чтобы ошибка не маскировалась;
для Git-команд используется GIT_TERMINAL_PROMPT=0, чтобы команда не зависала в non-interactive окружении.

Ещё одна важная вещь — валидация входных данных. fmix проверяет имена пакетов, версии, пути, Git URL и Git refs перед тем, как вызывать cp, sed или git. Это не сложная система escaping, а простой whitelist, но он отсекает пробелы, ;, $, backticks, pipes и другие shell metacharacters.

Неожиданная проблема: терминал

Отдельная история была с терминалом. Перед тем, как пользоваться командой fmix в консоли, ее нужно прописать как alias.

Так вот при запуске через простой alias вроде:

alias fmix='gforth "$FMIX_HOME/fmix.4th" -e'

после выполнения команд терминал иногда оставался в плохом состоянии. На prompt появлялись странные символы вроде:

0c0c
[?2004l

Особенно это проявлялось в WSL.

В версии 0.4.4 я перешёл на launcher script bin/fmix. Он восстанавливает TTY после команд, сбрасывает bracketed paste mode и немного очищает накопившийся ввод из /dev/tty. На самом деле все эти вещи я бы точно не разрешил самостоятельно. Я терпеливо помогал нейросети раз за разом пробовать некоторые гипотезы, чтобы исправить эту проблему. В отличие от тех ИИ, что я пробовал раньше, в этот раз я только один раз решил прервать ИИ и создать новый контекст, потому что она как будто зациклилась в бесконечном исправлении.

Однако, получилось и теперь вместо alias рекомендуется использовать:

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

И запускать просто:

fmix

Установка

Сейчас установка выглядит так:

git clone https://github.com/VitaSound/fmix.git ~/fmix

Затем нужно добавить в shell config (например .bashrc):

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

После этого команда начнет работать прямо в консоли:

fmix version

Важно: сейчас fmix рассчитан на Linux, Git, sed, cp и GForth 0.7.9.

Я не рекомендую использовать GForth более ранних версий и версию из Snap. Snap запускает программы в изолированном окружении, из-за чего текущая директория и пути могут не совпадать с тем, что ожидает shell session. Это ломает команды вроде new и packages.get.

Лучше использовать GForth из apt, локальную сборку или tarball с официальной страницы GForth.

Зачем это всё

Мне кажется, что старым языкам очень нужны такие инструменты, чтобы соответсвовать современным реалиям.

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

Новому человеку проще попробовать язык. Опытному пользователю проще начать новый проект. Библиотеки проще переиспользовать. Тесты проще запускать.

Это не меняет сам язык, но меняет опыт работы с ним. Позволяет взять старый инструмент в новые проекты.

В случае Forth это особенно интересно. Forth часто воспринимается как что-то старое, странное и нишевое. Но, возможно, часть этой «старости» находится не только в языке, а в отсутствии привычной современной обвязки.

Если добавить удобные инструменты, язык может ощущаться совсем иначе.

Что дальше

fmix пока маленький и экспериментальный.

Сейчас он умеет создавать пакеты, подтягивать зависимости из Git и theforth.net, запускать тесты.

В будущем хочется улучшать совместимость, добавить документацию, и, возможно, добавить больше команд вокруг разработки Forth-пакетов.

Но уже сейчас мне стало гораздо удобнее работать над своими Forth-проектами. Но это уже совсем другая история

Ссылки

FMix: a package manager for Forth

Alexey Bolshakov — Mon, 18 May 2026 23:12:32 +0000

In modern programming languages, we almost always expect the language to come with a convenient tool for working with projects.

Elixir has Mix. Rust has Cargo. Ruby has Bundler and RubyGems. Haskell has Cabal and Stack. JavaScript has npm, pnpm and Yarn. Go has modules.

We are used to being able to create a project with one command, describe dependencies in one file, fetch them from the network, run tests, and prepare a release. It feels like a basic part of the ecosystem, not a luxury.

But older programming languages often have a different story.

When many of them were created, this approach was not yet a standard expectation. Code was distributed differently, projects were structured differently, and ecosystems grew without the package managers and build tools we now take for granted.

And you can still feel it today.

Why I Started Thinking About This

For one of my projects I use Forth.

Forth is a very interesting language. It is minimalistic, direct, and unusual. There is something very attractive about it: you are close to computation, close to the stack, and close to the actual hardware of the computer, which I sometimes build myself.

But when I started writing something in Forth that looked more or less like a project, I quickly began missing the usual things:

creating a new project;
describing dependencies;
downloading dependencies;
running tests;
having a clear project structure;
connecting libraries from Git;
not having to keep everything manually in my head.

Yes, you can use git submodules, copy files by hand, or invent your own conventions. But for me, this is not a very convenient path. I wanted something closer to what I am used to in modern languages.

I found the f.4th library, which is connected to theforth.net. It is a useful tool, but it follows a different approach: library code and versions are stored on its own server.

I wanted to be able to pull dependencies directly from Git repositories. For example, specify a GitHub URL, a branch or a tag, and get the library into the project.

That is how the idea for fmix appeared.

What Is FMix

fmix is a small build tool and package tool for Forth, inspired by Elixir Mix.

Repository: github.com/VitaSound/fmix

It does not try to be a large framework. Its goal is simpler: to give a Forth project a minimal set of familiar tools.

Right now fmix can do this:

fmix new example
fmix packages.get
fmix test
fmix version

In other words, you can create a new package, fetch dependencies, run tests, and check the tool version.

Creating a Project

A new project is created like this:

fmix new example
cd example

After that, you get a basic project structure:

example/
  example.4th
  package.4th
  README.md
  tests/
  forth-packages/

package.4th is the package description file. It contains the name, version, license, main file, and dependencies.

Example:

forth-package
    key-value name example
    key-value version 0.1.0
    key-value license COPL
    key-value description example
    key-value main example.4th

    key-list dependencies f git https://github.com/VitaSound/f tag 0.2.4
    key-list dependencies ttester git https://github.com/VitaSound/ttester tag 1.1.0
end-forth-package

I like that the file itself is also written in a Forth-like style. It is not JSON, YAML, or TOML. It is a tiny declarative Forth format.

Dependencies from Git

The main reason I started making fmix was Git dependencies.

In package.4th, you can define a dependency like this:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git branch main

Or like this, if you need a specific version via a tag:

key-list dependencies ftest git https://github.com/VitaSound/ftest.git tag 0.1.0

After that, you only need to run:

fmix packages.get

Dependencies will be installed into the local project directory:

./forth-packages/

This structure makes it possible to keep different versions of the same library side by side:

forth-packages/
  f/
    0.2.4/
  ttester/
    1.1.0/

You can include a dependency with the usual require:

require ./forth-packages/f/0.2.4/f.4th

Support for theforth.net

Although I wanted Git dependencies, I did not want to completely abandon the existing ecosystem.

So fmix can also work with packages from theforth.net through f.4th.

For example:

key-list dependencies f 0.2.4

This means one project can use both Git dependencies and packages from theforth.net.

Tests

Another basic thing I was missing was running tests.

fmix has this command:

fmix test

It runs tests from the tests/ directory.

You can also run a specific file:

fmix test tests/some_test.4th

Tests use ttester. If ttester exists in the project dependencies, fmix loads it from ./forth-packages. If not, it uses the version from the installed FMIX_HOME.

For me, this matters: tests should run with one command. Even if the project is small.

What Was Fixed in Recent Versions

fmix has already gone through several generations of changes.

I wrote the first versions myself. But I am not a very strong Forth developer, so many things were difficult for me. I made one major refactoring with the help of Gemini. I finished the latest version with Cursor.

The latest releases fixed quite a few practical problems.

GitHub Actions CI was added: the workflow builds GForth 0.7.9 from source and runs:

gforth fmix.4th -e version
gforth fmix.4th -e test

Later, a release pipeline was added: when a version tag is pushed, a GitHub Release is created automatically, and the release text is taken from .github/RELEASE_NOTES_X.Y.Z.md.

Path handling was also fixed. Previously, part of the logic depended on PWD. Now the project is detected from the directory where the command is started. This matters because FMIX_HOME points to the installed fmix, while commands should operate on the current project.

Several dependency installation problems were fixed:

git clone now checks its result;
failed shell commands make GForth exit with code 1;
parent directories are created before git clone;
git fetch and checkout are executed so that failures are not hidden;
Git commands use GIT_TERMINAL_PROMPT=0, so the command does not hang in a non-interactive environment.

Another important thing is input validation. fmix validates package names, versions, paths, Git URLs, and Git refs before calling cp, sed, or git. It is not a complex escaping system, but a simple whitelist. It rejects spaces, ;, $, backticks, pipes, and other shell metacharacters.

An Unexpected Terminal Problem

There was a separate story with the terminal. Before using the fmix command in the console, it had to be configured as an alias.

When running through a simple alias like this:

alias fmix='gforth "$FMIX_HOME/fmix.4th" -e'

the terminal sometimes ended up in a bad state after commands finished. Strange symbols appeared in the prompt, for example:

0c0c
[?2004l

This was especially visible in WSL.

In version 0.4.4, I switched to the bin/fmix launcher script. It restores the TTY after commands, resets bracketed paste mode, and briefly drains queued input from /dev/tty. To be honest, I would definitely not have solved all of that on my own. I patiently helped the neural network try hypothesis after hypothesis to fix the problem. Unlike the AI tools I had tried before, this time I only had to stop the AI once and create a new context because it seemed to get stuck in an endless correction loop.

But it worked, and now instead of an alias it is recommended to use:

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

And then run it simply as:

fmix

Installation

Right now installation looks like this:

git clone https://github.com/VitaSound/fmix.git ~/fmix

Then add this to your shell config, for example .bashrc:

export FMIX_HOME="$HOME/fmix"
export PATH="$FMIX_HOME/bin:$PATH"

After that, the command should work directly in the console:

fmix version

Important: at the moment fmix expects Linux, Git, sed, cp, and GForth 0.7.9.

I do not recommend using earlier versions of GForth or the Snap version. Snap runs programs in a confined environment, so the current directory and paths may not match what the shell session expects. This breaks commands like new and packages.get.

It is better to use GForth from apt, a local build, or a tarball from the official GForth page.

Why This Matters

I think old languages really need tools like this to fit modern realities.

They do not have to be huge. They do not have to be perfect. But they should at least cover the basic scenarios. When a language has convenient tooling around projects, it becomes friendlier.

It is easier for a newcomer to try the language. It is easier for an experienced user to start a new project. Libraries are easier to reuse. Tests are easier to run.

This does not change the language itself, but it changes the experience of working with it. It allows an old tool to be used in new projects.

In the case of Forth, this is especially interesting. Forth is often seen as something old, strange, and niche. But maybe part of that “oldness” is not only in the language itself, but also in the absence of familiar modern tooling around it.

If we add convenient tools, the language can feel very different.

What Is Next

fmix is still small and experimental.

Right now it can create packages, fetch dependencies from Git and theforth.net, run tests, and publish releases through GitHub Actions.

In the future, I would like to improve compatibility, add documentation, and maybe add more commands around Forth package development.

But even now, it has become much more convenient for me to work on my Forth projects. But that is another story.

AD9833 DDS Generator Board

Alexey Bolshakov — Thu, 19 Mar 2026 16:52:05 +0000

A frequency generator board based on the AD9833 chip. Purchased as a frequency-tunable clock signal source. The board is equipped with a 25 MHz oscillator. It can generate signals from 0 to 12.5 MHz (though waveform quality may not be satisfactory across the entire range). The waveform can be switched between sine, sawtooth, and square wave. All necessary signals are brought out to pin headers. Controlled via SPI interface.

Architecturally, it contains one 28-bit phase accumulator register, two frequency tuning registers, and two phase offset registers. Only one pair (frequency/phase) can be active at a time. This allows for frequency modulation without phase discontinuity or phase modulation, if needed. However, there is no dedicated hardware input for selecting the register pair – switching is possible only via SPI commands.

Oscilloscope waveforms follow below.

Test setup

To control the DDS, commands must be sent via SPI. I am using an STM8 (STM8S105K4T6) with its hardware SPI. It was crucial to find the correct SPI operating mode. For the STM8 (and likely for STM32 as well), this is Mode 2 (CPOL = 1, CPHA = 0). For more details, refer to the documentation.(RM0016 - STM8S Series and STM8AF Series 8-bit microcontrollers (20.4 SPI registers)). Oscilloscope: C1-112A, 10 MHz bandwidth; probe: generic Chinese P6100 type, rated for 100 MHz. Multimeter: Aneng M20, used as a frequency counter.

I did not write firmware for the microcontroller in the conventional sense. Instead, I flashed the STM8 with the eForth system and connected to it via a serial console. From the console, I sent SPI commands directly, after pre-defining the necessary intermediate words. It looked roughly like this:

...

: word.hi $0100 / ;
: word.lo $00ff and ;

: spi_wr8 SPI_DR c! TXE? ;
: spi_wr16  dup word.lo swap word.hi spi_wr8 spi_wr8 ;
: spi_wr16n dup word.lo swap word.hi nss.lo spi_wr8 spi_wr8 BSY? nss.hi ;
: spi_wr32n nss.lo spi_wr16 spi_wr16 bsy? nss.hi ;

...

$2100 spi_wr16n         // reset
$5c20 $4a3d spi_wr32n   // freq0
%0111111111111111 %0100000000000000 spi_wr32n   // freq0
%0111111111111111 spi_wr16n %0100000000000000 spi_wr16n
$9c29 $8a3d spi_wr32n   // freq1
$c000 spi_wr16n         // phase0f
$e000 spi_wr16n         // phase1
$2000 spi_wr16n         // sine
$2020 spi_wr16n         // square
$2002 spi_wr16n         // saw

It turned out that I used the system interactively, rather than reflashing the firmware each time. This approach reminds me of working with the Erlang virtual machine, where you can debug and modify running code on the fly on production.

Oscilloscope Waveforms

Sine 1 KHz

10 KHz, 50 KHz, 100 KHz, 500 KHz, 2 MHz, 4 MHz, 8 MHz
10 KHz

50 KHz

100 KHz

500 KHz

2 MHz

4 MHz

8 MHz

Saw 1 KHz

10 KHz, 50 KHz, 100 KHz, 500 KHz, 2 MHz, 4 MHz, 8 MHz
10 KHz

50 KHz

100 KHz

500 KHz

2 MHz

4 MHz

8 MHz

At 2 MHz, floating peaks on the sawtooth waveform are already visible. At 4 MHz, they become very pronounced. And at 8 MHz, we end up with 25/8 = 3.125 samples per period.

Purely to explore my oscilloscope and probes, I also tried the square wave mode. However, I couldn't be bothered to recalculate the frequency grid. In square wave mode, the period is twice as long, so the resulting frequencies were different.

5 kHz

25 KHz, 250 KHz, 1 MHz, 2 MHz, 4 MHz
25 KHz

250 KHz

1 MHz

2 MHz

4 MHz

4 MHz more wide

Starting from 1 MHz, jitter is obviously present; at 2 MHz, it becomes visible on the oscilloscope waveform.

By the way (for those who aren't aware), it's important to note that at high frequencies, to avoid degrading signal edges, you should use the probe in 10:1 attenuation mode. This reduces the probe's loading effect on the circuit (and it's even better to avoid using alligator clips altogether). However, this will require increasing the oscilloscope's input amplifier gain by a factor of 10 to compensate for the attenuation.

Also, don't forget to adjust the probe compensation for accurate waveform display, using a small dielectric (non-metallic) screwdriver.

For comparison, here's a photo showing the same signal — a 2 MHz square wave — captured with the probe set to 1X versus 10X attenuation.

2 MHz - 1х

2 MHz - 10х

By the way, the original probe that came with the C1-112A is also quite decent.

2 MHz - 10х

Conclusions

I acquired this board for experiments in the field of hybrid sound synthesis for my synthesizer project. In the future, I plan to use it for a DCO (Digitally Controlled Oscillator) module — but not with a fixed Master Clock frequency; rather, with a frequency that is a multiple of the generated note frequency. This way, the DAC in the DCO can utilize its full scale and DAC resolution without skipping steps. All of this is part of the effort to combat generation accuracy loss and aliasing... But that's a whole different story.

Links

1 The original version of this article

https://mysku.club/blog/aliexpress/79168.html

2 My Telegram channel "Programmer's Tips": https://t.me/ProProgs

3 eForth - Forth for microcontrollers

https://github.com/TG9541/stm8ef/wiki/STM8-eForth-Programming

4 Links about my synth project

https://github.com/UA3MQJ/fpga-synth/wiki

https://github.com/VitaSound/hdl-modules

https://soundcloud.com/vitasynth

http://www.youtube.com/channel/UCGi-A9KGhKhKzVT_baVw3HA

https://vk.com/vitasound

https://boosty.to/vitasound

Плата DDS генератора AD9833

Alexey Bolshakov — Thu, 19 Mar 2026 16:35:39 +0000

Плата с DDS генератором частоты на базе микросхемы AD9833. Приобретена в качестве источника тактового сигнала, перестраиваемого по частоте. На плате установлен генератор на 25 МГц. Может генерировать сигналы от 0 до 12.5 МГц (но не во всем диапазоне вас устроит форма сигнала). Можно переключать форму сигнала: синус, пила, меандр. Всё, что нужно, выведено на штыревые контакты. Управляется по SPI. Архитектурно содержит один 28-битный регистр аккумулятора, два регистра приращения, два регистра фазы. В один момент времени может быть выбрана только одна из двух пар. Это позволит, если необходимо, сформировать частотную модуляцию сигнала без разрыва фазы или фазовую модуляцию. Однако, отдельного входа выбора пары нет, переключение возможно только командами по SPI.

Далее осциллограммы

Стенд

Для управления DDS нужно подавать команды по SPI. Использую STM8 (STM8S105K4T6) и его аппаратный SPI. Очень важно было найти правильный режим работы SPI. Для STM8 (и наверняка для STM32) это будет mode 2 (CPOL = 1 and CPHA = 0). Подробнее, см. документацию(RM0016 - STM8S Series and STM8AF Series 8-bit microcontrollers (20.4 SPI registers)). Осциллограф С1-112А полоса 10 МГц, щуп китайский на 100 китайских МГц (P6100). Мультиметр Aneng M20 в качестве частотомера.

Прошивку для микроконтроллера в привычном для всех виде я не писал. Просто поставил на микроконтроллер STM8 систему eForth и далее подключался к нему через консоль. И уже в консоли отправлял команды через SPI, задав перед этим необходимые промежуточные слова. Выглядело это примерно вот так

...

: word.hi $0100 / ;
: word.lo $00ff and ;

: spi_wr8 SPI_DR c! TXE? ;
: spi_wr16  dup word.lo swap word.hi spi_wr8 spi_wr8 ;
: spi_wr16n dup word.lo swap word.hi nss.lo spi_wr8 spi_wr8 BSY? nss.hi ;
: spi_wr32n nss.lo spi_wr16 spi_wr16 bsy? nss.hi ;

...

$2100 spi_wr16n         // reset
$5c20 $4a3d spi_wr32n   // freq0
%0111111111111111 %0100000000000000 spi_wr32n   // freq0
%0111111111111111 spi_wr16n %0100000000000000 spi_wr16n
$9c29 $8a3d spi_wr32n   // freq1
$c000 spi_wr16n         // phase0f
$e000 spi_wr16n         // phase1
$2000 spi_wr16n         // sine
$2020 spi_wr16n         // square
$2002 spi_wr16n         // saw

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

Осциллограммы

Синус 1 КГц

10 КГц, 50 КГц, 100 КГц, 500 КГц, 2 МГц, 4 МГц, 8 МГц
10 КГц

50 КГц

100 КГц

500 КГц

2 МГц

4 МГц

8 МГц

Пила 1 КГц

10 КГц, 50 КГц, 100 КГц, 500 КГц, 2 МГц, 4 МГц, 8 МГц
10 КГц

50 КГц

100 КГц

500 КГц

2 МГц

4 МГц

8 МГц

На 2 МГц уже видно плавающие пики пилы. На 4 МГц видно уже очень отчетливо. Ну и на 8 МГц у нас получается 25/8 = 3,125 отсчета на период.

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

5 КГц

25 КГц, 250 КГц, 1 МГц, 2 МГц, 4 МГц
25 КГц

250 КГц

1 МГц

2 МГц

4 МГц

4 МГц более развернуто

Начиная с 1 МГц, ясное дело - джиттер, на 2 МГц его видно на осциллограмме.

Кстати (для тех, кто не в курсе), важно, что на высоких частотах, чтобы не портить фронты, нужно использовать щуп в режиме 1:10, чтобы он меньше влиял на схему (а еще лучше не использовать крокодил). Но потребуется усилить сигнал в 10 раз уже на входном усилителе осциллографа.

Так же, не стоит забывать подстраивать делитель для правильного отображения, диэлектрической отверточкой.

Для сравнения, фото, как выглядит один и тот же сигнал - меандр 2 МГц, но 1Х или 10Х

2 МГц - 1х

2 МГц - 10х

Кстати, родной щуп от С1-112А тоже неплох

2 МГц - 10х

Выводы

Эту плату я брал для экспериментов в области создания гибридного синтеза звука своего синтезаторного проекта. В дальнейшем планируется использовать для модуля генератора DCO (Digital VCO) но не с фиксированной частотой Master Clock а с частотой, кратной частоте генерации, для того, чтобы DAC в DCO использовал всю свою шкалу и разрядность, не пропускал шаги. Все это в рамках борьбы с потерей точности генерации, борьбы с алиасингом... Но это уже совсем другая история

Ссылки

1 Исходная версия этой статьи

https://mysku.club/blog/aliexpress/79168.html

2 Мой канал в TG "Советы программиста" https://t.me/ProProgs

3 eForth - язык Forth для микроконтроллеров

https://github.com/TG9541/stm8ef/wiki/STM8-eForth-Programming

4 Ссылки по моему синтезаторному проекту

https://github.com/UA3MQJ/fpga-synth/wiki

https://github.com/VitaSound/hdl-modules

https://soundcloud.com/vitasynth

http://www.youtube.com/channel/UCGi-A9KGhKhKzVT_baVw3HA

https://vk.com/vitasound

https://boosty.to/vitasound