Разработка контроллера управления шаговыми моторами

При нулевой скорости ШИМ не останавливается. Обычно ШИМом подстраивают средний ток через обмоку.

STM32 — грамотно включаемся от кнопки

Зачем же 3,3 ? Из литиевого напряжения удобнее 2,5V получать.

Но я не знаю вашей задачи. Так бы ещё вариантов накидал

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

5. Поискать у китайцев, на LCSC, например. Китайцы дофига всего наделали, и скорее всего найдётся чип, который и заряд измерит, и ещё зарядит, и напряжение преобразует... Разве что не отсосёт борщ не сварит)

STM32 — грамотно включаемся от кнопки

1. Сам регулятор напряжения мк. Вы же не от 4,2 В его питаете. 1% точности вполне можно найти

2. В большинстве stm есть внутренни источник напряжения, с которым можно сравнить питание. Не особо точный, но калибруется

3. Есть TLV431 и другие его варианты. +0,1ма к потреблению. Ну и его можно выключать, когда не измеряете батарею

Ремонт клавиатуры синтезатора Yamaha

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

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

Переходим с STM32 на GD32

В даташите про Boot modes написано, что входит. Не знаю, на сколько dfu совместим с stm - не проверял ещё.

Если пользоваться голым уартом, проблем не видел. Проблемы начинаются, когда с уартом нужно что-то синхронизировать в пределах 1 битового интервала.

Переходим с STM32 на GD32

А даташит почитать слабо?

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

Однако время запуска у VF103 тоже адски большое:

Ровно столько же времени требуется, чтобы прочитать 128 кБ на скорости 8 Мбит/с. Делайте выводы.

Переходим с STM32 на GD32

GD32F103RKT6 - 3 МБ

Минимум 16кБ в этой серии. Цифры я не выдумываю, всë в даташите есть.

Переходим с STM32 на GD32

В этом семействе максимум до 3М флеши. 256к кэшируется независимо от конкретного объёма флеши.

Переходим с STM32 на GD32

Не проверял. В даташите посмотрел.

https://habr.com/ru/companies/selectel/articles/851478/comments/#comment_27443304

Переходим с STM32 на GD32

Если предусмотрены wait-state (пара битов в конце FLASH->ACTLR), то кеша нет.

Не факт. У GD они предусмотрены, видимо, чтобы программные задержки были совместимы с кодом для ST. А при выходе за пределы кэша проц увеличивает задержку молча, безо всяких настроек.

Резистор — это просто. Не очень

ГОСТ 21414 с вами не согласен.

Закрываем форточку.

Сторителлинг

Мне кажется, слово "сторителлер" напрашивается на очень русский и очень едкий перевод.

Переходим с STM32 на GD32

API копировать законно. И аппаратный интерфейс - тоже законно, кроме его названия. Незаконно - копировать его реализацию.

Переходим с STM32 на GD32

Только это работает в разы медленней, чем мне надо.

Из прерываний уарта я использую только RXIDLE - по приëму пакета. Всë остальное - аппаратно. Выше мегабита/с по-другому не очень получается.

Переходим с STM32 на GD32

ТЕ и UE - я имел в виду биты управления, а не состояния.

Они у ST и у GD слегка по-разному называются) Хотя суть скопирована почти 1:1

Qucs-S: руководство по использованию SPICE-моделей и созданию библиотек

Поставил я таки в старую систему релиз 24.3.2 из исходников. Прекрасно работает.

Ngspice с моделированием переходных процессов действительно справляется гораздо лучше, чем Qucsator. Но если, например, конденсатор висит в воздухе (при отладке схемы где-нибудь разрыв делаю), Ngspice сразу говорит - сингулярность. Qucsator как-то умел это обходить.

Скомпилилось не сразу. Но по подсказкам компилятора внёс изменения, и всё заработало.

Правки

diff --git a/qucs/components/libcomp.cpp b/qucs/components/libcomp.cpp
index eab40cd5..20c835b7 100644
--- a/qucs/components/libcomp.cpp
+++ b/qucs/components/libcomp.cpp
@@ -27,6 +27,7 @@
 #include <QDir>
 #include <QRegularExpression>
 #include <QDebug>
+#include <memory>
 
 LibComp::LibComp()
 {
diff --git a/qucs/diagrams/diagramdialog.h b/qucs/diagrams/diagramdialog.h
index 1114463d..73561741 100644
--- a/qucs/diagrams/diagramdialog.h
+++ b/qucs/diagrams/diagramdialog.h
@@ -26,6 +26,7 @@
 #include <QDialog>
 #include <QRegularExpression>
 #include <QRegularExpressionValidator>
+#include <memory>
 #include <vector>
 
 class QVBoxLayout;
diff --git a/qucs/extsimkernels/spicelibcompdialog.cpp b/qucs/extsimkernels/spicelibcompdialog.cpp
index 18f46e94..955c304c 100644
--- a/qucs/extsimkernels/spicelibcompdialog.cpp
+++ b/qucs/extsimkernels/spicelibcompdialog.cpp
@@ -281,7 +281,7 @@ int SpiceLibCompDialog::parseLibFile(const QString &filename)
       subcir_start = true;
       subcir_body.clear();
       QStringList pin_names;
-      QStringList tokens = line.split(QRegularExpression("[ \\t]"),Qt::SkipEmptyParts);
+      QStringList tokens = line.split(QRegularExpression("[ \\t]"),qucs::SkipEmptyParts);
       if (tokens.count() > 3) {
         subname = tokens.at(1);
       } else continue;

Переходим с STM32 на GD32

Было у меня 2 задачи:

простая - сформировать таймером сигнал направления передачи для RS485, +-1 бит,
и сложная - сымитировать дифф.сигнал для обмена с MAX17843. +- 1/4 бита.

Мк из разных семейств, но я думаю, всё похоже должно быть и у остальных. Везде UART работал через DMA - один раз запустил вместе со стробом, и забыл до следующей передачи. Синхростарт, естественно, делается с запретом прерываний.

У ST (F105) передатчик UART стартует с задержкой +-1/2 бита, если не отключать UE. Если отключать, то не хуже +-1/16 бита. Отключение TE приводит к фиксированной доп.задержке в 11 бит.

У GD (F405) 11-битная задержка появляется полностью рандомно, независимо от TE и UE. Точная повторяемость получилась, только если UART перед каждой передачей сбрасывать через RCC. И, соответственно, инициализировать заново.

Ферро-Франкенштейн

Помню же, не так давно тут читал про подобную установку. Нашёл.

https://habr.com/ru/articles/800827/

Всё похоже - выпрямитель (правда, с удвоением), тиристор и обратный диод. Без трансформатора, просто катушка. И какие-никакие расчёты есть.

Переходим с STM32 на GD32

Поймал в 400й серии проблему, не описанную в errata - задержка от включения UART до физической передачи плавала случайно от 0 до 11 бит. Пришлось костылить хардкорный сброс UART (вместе с приёмником) перед каждым пакетом.

Но вообще основное отличие GD от остальных флеш-мк в том, что он не флеш-мк. Внутри корпуса 2 кристалла - мк и SPI-флеш. По-моему @BarsMonster его вскрывал, или ещё кто-то, не помню точно. Прошивка из SPI-флеши при старте кэшируется в теневое ОЗУ, и оттуда уже выполняется.

Из-за этого появляется несколько нюансов:

• Время старта прошивки увеличивается, т.к. прошивку ещё надо скопировать.
  

  

  Это в даташите для F103xC

• Кэшируется не вся флеш, а только часть, которая влазит в теневое ОЗУ. Его объём одинаковый у каждой серии, независимо от объёма флеши. Хотя и довольно большой.
  

  

  Вот это, например, в мануале для всей серии F10x

• Зато отсутствие флеши на том-же кристалле позволяет повысить тактовую частоту, и главное - уменьшить время случайного доступа к программной памяти. JMPы, циклы, загрузка длинных констант становятся заметно быстрее.