Контроллеры от GigaDevice GD32F103xxxx. Попытка миграции с STM32F103xxxx

В связи с тем. что последнее время цена на контроллеры растет быстрей чем стоимость битков, а, например, наш основной STM32F103VGT6 стал стоить вместо 500р аж 5000+, да еще с непонятными сроками ожидания от года и более, то мы начали вынужденную миграцию на аналоги. И взгляд пал на GD32, как на наиболее вменяемого и адекватного представителя китайпрома. А главная задача стала сделать универсальную прошивку которая бы одинаково работала как на STM32 так и на GD32. Чтобы можно было не глядя лить в наши машины смерти, не обращая внимания на то на какой архитектуре там мозги.

Купили мы небольшую партию этих чипов на Алиэкспрессе :))) Уже звучит жутко, но вариантов особо не было :)

Итак, на смену STM32F103VGT6 идет GD32F103VGT6 — китайцы не заморачивались вообще с названиями. И то правда. Чего нам париться? Совместимость у него по ногам полная, так что впаиваем его как есть.

А вот дальше начинаются различия. Во первых, памяти у него может быть больше. Аж до трех мегабайт флеша, против мегабайта у STM. Что, впрочем, не более чем потенциальная возможность, в моем случае, т.к. GD32F103VGT6 по объему памяти идентичен STM овскому камню. А еще у китайца тактовая частота выше, 108Мгц против 72Мгц у STM. Подозреваю Errata там тоже исправлена. Но, не факт что это к лучшему :)

Качаю Даташит, User Manual, а также подобие SPL только свою собственную. С примерами и кучей сорцев из которых прям торчат уши STM ;) Где то они даже копирайты не вычистили.

Беглое чтение user manual дает ощущение дежавю. Ну да, почти полная бинарная совместимость с STM32 на уровне регистров их адресов. В некоторых местах, там где им не хватило конфигурационных бит, они использовали то, что у STM32 зовется как Reserved.

STM32

GD32

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

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

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

Беру свой рабочий проект над которым мы копаемся уже несколько лет и, как есть, байт в байт, ничего не правя вообще, заливаю в GD32…

Чем заливаю? Да тем же китайским ST-Link за сто рублей:

ST-Link Utility восприняла ускоглазого сынка как родного. Для нее чужих детей не бывает. :) Все корректно зашилось и … заработало. Подозрительно…

Хм, как прикольно. А что с отладкой? Жму Debug и… все заработало.

Тут, правда, стоит оговориться, что работаю я не с STM TrueStudio, а уже много лет пишу в EmBitz и с недавних пор они используют свой отладчик EbLink и вот ему пофигу что отлаживать, хоть STM хоть GD. Оно там просто работает. Брейкпоинты ставятся, память и регистры видятся, по шагам шагается, флеш прошивается.

С TrueStudio это уже не прокатывает. Они говорят, что мол это не STM и мы этих косоглазых знать не знаем, а что похожи, так это просто совпадение. Для Keil же GigaDevice, я слышал, выкатила плагин.

Диодики моргают, порты считываются, подтяжки встали на нужные уровни. Все пять UART бодро отработали… Аппарат вышел на связь с мозгами и встал в боевой режим и приготовился убивать человеков. Все вроде бы работает. А где секс? Чо секса не будет? Ну воооот.. А я было настроился…

Да щаз! При попытке пошевелить шаговыми движками наша машина смерти рванула с такой прытью, что я думал из нее все гайки ща посыпятся, даром что на нейлоне. Начинаю разбираться. Скорость тиков шаговых двигателей ровно в полтора раза выше. Но при этом мигалка blinker’a, а также все бодрейты уартов тикают штатно. Мигалка ровно раз в секунду на 100мс, а уарты заданы жестко и перебоев со связью нет. Из этого вывод, что как минимум SysTick тикает с правильной частотой. А от него и AHB APB и прочие частоты тоже. Но не может же так быть…

Опять углубляюсь в юзермануалы, сравниваю все побитно. Все совпадает. Все значения делителей тактовых частот совпадают. Один к одному, просто у GD множители PLL идут дальше и позволяют множить аж до х32. Проверяю по SysTick, просто инвертируя бит порта по его прерыванию — тикает верно. Проверяю по DWT таймеру — тикает верно. Timer2 тактуется тоже верно. То есть, по всем признакам работы периферии, SysClock идентичная. А работает быстрей.

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

Делаю тупую задержку на цикле:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
void stupid(uint32_t delay)
{
volatile  uint32_t i;
    i = delay;
    while(i)
    {
        i--;
    }
}
 
    while(1)
    {
    stupid(0xFFFF);//delay_us(1000);
    IO_InvertLine(io_Blink1);
    }

Сравниваю моргание на оригинальном STM и на GD — на GD в полтора раза примерно быстрей. И либо даташит врет и на самом деле SysClock работает на 108Мгц, а значения битов делителей значат вовсе не то, что написано и приводят со 108Мгц до стандартных частот шин, либо код и вправду исполняется быстрей за счет выборки команд.
Первый вариант весьма шизофреничен, т.к. какой смысл так извращаться, а на опечатку это не тянет вообще, т.к. это уже заговор какой то. А вот второй… второй может быть вероятен. Просто за счет того, что у GD более быстрая память и он команды из флеша берет быстрей.

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

Ответ должен быть в сравнении битов настройки задержки выборки флеша. Сравниваю в STM32:

Регистр FLASH_ACR по адресу 0x40022000 и там у нас:

Младшие три байта отвечают за задержку. Я частоты конфигурирую ручками. Не верю я CMSISовскому SystemInit. Слишком часто его переписывали то так то эдак. Хрен знает, что там будет в очередной версии, а мне сюрпризы не нужны. Поэтому я иницилизацию частот написал сам, ручками. В моем коде сделано так:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
   #ifndef SYSCLK_FREQ
    #define SYSCLK_FREQ 72000000U
    #warning SYSCLK_FREQ set up to MAX automatically!!! Check this shit!
    #endif
 
    /* Enable Prefetch Buffer */
    FLASH->ACR |= FLASH_ACR_PRFTBE;
 
    /* Flash 2 wait state */
    FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
 
    #if SYSCLK_FREQ<24000000U
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_0; // Если SystemCoreClock <= 24 МГц
    #endif
 
    #if SYSCLK_FREQ>=24000000U && SYSCLK_FREQ<48000000U
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_1; // Если 24< SystemCoreClock <= 48, через такт.
    #endif
 
    #if SYSCLK_FREQ>=48000000U
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;  // Если больше 48, то через два такта.
    #endif

То есть выборка команд будет через два такта. Что же у ГД по этому адресу прячется? Лезем в мануал:

Все то же самое, те же биты отвечающие за задержку чтения из флеша, но с пометочкой, которую я не сразу заметил. О том, что вся эта радость работает только если поставить бит WSEN в FMC_WSEN, а иначе оно не используется. В STM32 никакого такого регистра естественно нет и задержка работает если выставлена. Зачем китайцы встрелили себе в ногу, поломав совместимость в такой простой фигне непонятно. Что им мешало сделать так, чтобы все работало идентично? Ничего не мешало. Но тем не менее. Можно, конечно, тут добавить запись бита в байт по этому адресу, убедившись только, что на STM32 выстрел уйдет в молоко, попав в очередную Reserved секцию.

Окей, добавляем. Поскольку этого адреса у STM32 нет, то я его добавлю вручную, просто через указатель:

1
2
uint32_t *FMC_WSEN;
FMC_WSEN = (uint32_t*)0x400220FC;

Бит WSEN там нулевой, поэтому достаточно по этому указателю записать единичку. Правда запись туда запрещена, нужно сначала разблокировать флеш. Записав два раза в регистр FLASH_KEYR ключевое слово 1 и слово 2. Эти слова есть в хидерах на STM32 и на GD. Они одинаковые для обоих камней. Кому интересно FLASH_KEY1 = 0x45670123, а FLASH_KEY2 = 0xCDEF89AB.

1
2
FLASH->KEYR = FLASH_KEY1;
FLASH->KEYR = FLASH_KEY2;

Разблокировали запись во флеш, записываем бит WSEN:

1
*FMC_WSEN = (uint32_t)1;

После чего выставляем задержку памяти:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
    #ifndef SYSCLK_FREQ
    #define SYSCLK_FREQ 72000000U
    #warning SYSCLK_FREQ set up to MAX automatically!!! Check this shit!
    #endif
 
    /* Enable Prefetch Buffer */
    FLASH->ACR |= FLASH_ACR_PRFTBE;
 
    /* Flash 2 wait state */
    FLASH->ACR &= (uint32_t)((uint32_t)~FLASH_ACR_LATENCY);
 
    #if SYSCLK_FREQ<24000000U
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_0; // Если SystemCoreClock <= 24 МГц
    #endif
 
    #if SYSCLK_FREQ>=24000000U && SYSCLK_FREQ<48000000U
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_1; // Если 24< SystemCoreClock <= 48, через такт.
    #endif
 
    #if SYSCLK_FREQ>=48000000U
    FLASH->ACR |= (uint32_t)FLASH_ACR_LATENCY_2;  // Если больше 48, то через два такта.
    #endif
 
    LL_RCC_SetSysClkSource(LL_RCC_SYS_CLKSOURCE_PLL);

И включаем снова блокировку флеша, на всякий случай.

1
    FLASH->CR |= FLASH_CR_LOCK;

По идее, можно включить блокировку флеша сразу же после *FMC_WSEN = (uint32_t)1; А для настроек во FLASH_ACR разблокировка не нужна. Но это не работает, должно пройти какое то время, видимо, чтобы бит успел записаться во флеш и только потом включать снова блокировку.

Правда тут тоже не вышло счастья :)))) Оказалось, что с задержкой в два такта GD32 медленней чем STM32 c задержкой в эти же два такта. Тестовый импульс у GD32 на полной скорости у нас был 23мкс, на двух тактах задержки памяти стал 54мкс, а на одном такте задержки 37мкс. В то время как STM32 на двух тактах давал 37мкс.

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

Ковыряясь в даташите на GD32 я увидел, что следующим после FMC_WSEN идет регистр FMC_PID и в нем сидит какое-то число, уникальный номер кристалла (или его памяти). Но у STM32 этот же адрес возвращает какую-то фигню. Которая еще и меняется. Хотя эти адреса никак не документированы. Так что вариант так себе.

Посоветовался с коллегами, покурил даташиты и документацию на ARM ядро и нашел, что по адресу 0xE00FFFD0 и далее прячутся Peripheral ID регистры. Которые содержат циферки присущие только конкретному семейству и производителю. В частности там зашито номер ревизии чипа, JEP 106 код и еще всякая лабуда. Но, главное, что у STM32 и GD32 эти байты различаются, не меняются, всегда одни и те же от чипа к чипу, в отличии от индивидуального 96 битного ID чипа, который уникальный для каждого экземпляра.

Поэтому поглядел под отладчиком что там, да написал простенькую процедурку для опознания где мы:

1
2
3
4
5
6
7
bool UseGD32(void)
{
uint8_t *TestByte;
    TestByte = (uint8_t*)0xE00FFFD0;
    if (*TestByte == 7) return 1;
    return 0;
}

Проверил в железе — работает. Вот и славно. Пляшем дальше! :)

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

  • SysTick
  • USART’ы все
  • Timer2
  • DWT
  • GPIO

Хватаю дисплейный модуль от другого проекта, но с этим же камнем. На нем есть FSMC интерфейс. Я на нем управлял дисплеем. Работает на отлично. Добавляем к списку проверенной периферии FSMC.

  • FSMC

Хватаю другой проект, на этой же плате. Но уже боевой дисплей от компрессорной установки. Заливаю… Все работает, но жууууутко мееееееедленнно. Я поначалу решил, что я тупо кварц залил флюсом и у меня HSE не поехал. Промыл, просушил. Включил… все жууууутко меееедленно осталось. Странно. К сожалению исходников этого проекта у меня нет, знаю только что он написан на SPL и возможно что-то где-то недоинициализировалось в режиме тактирования. Надыбаю исходники, перепишу и будет ясно в чем был затык. Но я уже четко вижу, что нормально работают каналы DMA. Все не проверял, но UART там сделан через DMA это я знаю точно.

В общем, по мере освоения периферии буду добавлять в этот пост подробности о том, что же у нас по совместимости.

UPD
В комментариях набросили официальную доку по совместимости от GD. Прикладываю ее тут:

Спасибо!!! Вы потрясающие! Всего за месяц мы собрали нужную сумму в 500000 на хоккейную коробку для детского дома Аистенок. Из которых 125000+ было от вас, читателей EasyElectronics!!! Были даже переводы на 25000+ и просто поток платежей на 251 рубль. Это невероятно круто!!! Сейчас идет заключение договора и подготовка к строительству!

А я встрял на три года, как минимум, ежемесячной пахоты над статьями :)))))))))))) Спасибо вам за такой мощный пинок!!!

44 thoughts on “Контроллеры от GigaDevice GD32F103xxxx. Попытка миграции с STM32F103xxxx”

  1. Статейку лучше было бы разместить на dihalt.ru с тэгом ‘последний герой труда’. Статья помечена ‘ARM учебный курс’, думаю единственное, что тут можно почерпнуть — не используй в своих проектах всякое китайское говно.

    1. Ну… как бы гигадевайс это вполне себе бренд. Только раньше они флеш делали. Это раз. Во вторых, гд32 превосходит стм32 почти во всем. По крайней мере в этих семействах. Ну третье… стм32 сейчас купить просто нельзя. Нигде их тупо нет. Вообще. Везде срок ожидания от года и цена при этом космическая.

      1. А F0 семейство? Оно же посвежее чем F1 и должно быть более доступно при схожих характеристиках.
        Также, ЕМНИП, потоньше техпроцесс там.

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

    1. Можно. Работаю. Только там подкрутить надо одну настройку, чтобы Куб и чужого ребенка распознал. Высплюсь, дам ссылку на подкрутку.

  2. Самое для меня смешное, что у них есть девайсы из которого Cortex M достали, RISC-V засунули, а всю обвязку не тронули вообще. Очень смешные кадаврики получились. Вроде и RISC-V а вся периферия, вообще вся, STM32-совместимая.

      1. Потенциальный профит — РИСКи будут со временем дешевле: открытое ядро, платить АРМу не надо, все дела. Понятно, что пока они в экспериментальной стадии развития, то дешевле не будут — не те тиражи — но может быть, когда нибудь…

      2. Потенциальный профит — в будущем они, вероятно, будут дешевле. Открытая архитектура, АРМу платить не надо, все дела. Но это всё из серии «может быть, когда-нибудь». Пока что они в экспериментальной стадии, и тиражи не те, чтобы быть дешевле.

  3. Я тут давече именно этой темой и занимался: диверсификация поставщика STM32F. Кое-какие результаты раскопок тиснул в форум electronix.ru.

    Коротко: бинарник для STM32F103VET запустился на GD32F103VET на ура за исключением I2C. Когда начал разбираться, показалось, что GD и вправду почистил errata STM32 I2C в некоторых местах, но и добавил своё. Не буду вдаваться в подробности, но скажу, что устанавливать биты POS и/или BUFIE еще до начала передачи адреса (ID) I2C периферии в GD32F нельзя: бит SB (старт) не сбрасывается после передачи адреса (ID), и логика (прерывание) зацикливается. Это странно, т.к. POS или BUFIE никак не связаны с передачей адреса, а лишь перемещают NAK и разрешают прерывание по приему, что правильно работает на STM32F1хх. К счастью, логику можно построить с установкой POS/BUFIE и после передачи адреса, что работает как на GD32F1xx, так и на STM32F1xx. Ноги предыдущей логики росли с давних времен (примерно 2009) и базировались на примерах для STM32.

    Еще интересен момент, что бинарник прекрасно работает и на GD32F303VET, который внутри имеет Cortex-M4.

    Ага, еще по ADC. Температурный датчик (канал ADC) всегда показывает 0xFFF. Но это при нормальном питании в 3.3V. Случайно обнаружил, что при 3.2V все работает правильно; на 303 такого эффекта нет.

    В некоторых форумах на иностранных языках было упоминание, почему GD шустрее STM: якобы, GD, на самом деле, всегда работает из теневого (дополнительного) RAM, куда при старте копируется содержимое… SPI-Flash, которая и есть та странная насадка на основной кристалл. То есть, по крайней мере GD32F1хх — это такой гибрид.
    Я пока не занимался проверкой этого утверждения, но я точно заметил, что запись во flash из самой программы работает явно медленнее (по ощущениям — на 30-40%), чем на STM32F, а камень в целом шустрее.

    Сейчас жду образцы GD32F130K8U6, которые по пинам и всему есть аналог STM32F051K8U (используем во многих проектах), но в GD ядро -M3, а не -M0.

    Разработку я веду как в (стареньком) KEIL, так и STMCubeIDE. В последнем пришлось чуть подправить один файл конфигурации, чтобы он не отвергал китайца, но это, вроде, касалось работы с STLink; J-Link V9 работает без проблем, хотя может правка делает свое дело и для него. Я сейчас за другим компом пишу, точную ссылку на правку в STMCubeIDE тисну, как доберусь до рабочего компа.

    1. Как и обещал для STMCubeIDE цитата с одного форума:

      Yes, hate the blue pill with clone MCU on it. In my case I have a CKS32F103… instead of STM32F103…
      However, if you do end up with one, there is a way to get it working with OpenOCD. >>
      1. Use OpenOCD as your debugger (GDB will not work)
      2. Find the config file : stm32f1x.cfg
      Location is similar to this : >>
      C:\ST\STM32CubeIDE_1.3.0\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.debug.openocd_1.3.0.202002181050\resources\openocd\st_scripts\target
      3. Add the following near the top of stm32f1x.cfg (before the first If – statement):
      set CPUTAPID 0
      The zero tells OpenOCD to ignore id numbers, which means all clones or genuine MCUs will work.
      4. Save the changes. Now your flash and debug should work.

      Note: If you change to OpenOCD without changing “stm32f1x.cfg”, you will get the following Error: “UNEXPECTED idcode: 0x2ba01477…. Expected: 0x1ba01477”, and you will again be stuck.

      Information Source: http://openocd.org/doc/html/TAP-Declaration.html#TAP-Declaration-Command

      1. Увы, это не работает для версии CubeIDE 1.10.1
        По крайней мере у меня не заработало. Пишет Could not verify ST device!
        Подскажите, пожалуйста, где что взять и какой версии, чтобы гарантировано заработало.

  4. «свой отладчик EbLink» — это ж сервер — софтина, не дивайс ;-)
    У IAR-а iLink — дивайс
    Ща только дошло — «еблинк» ((-8Ж

  5. Я копаю тему GD32 далее.
    По поводу там проекта с FSMC у Di Halt, который жутко медленный. Цитата из мануала на GD32F103:

    «No waiting time within first 256K bytes when CPU executes instructions. A long delay when CPU fetches the instructions out of the range.»

    Я тут давече с GD32F130 возился, чтобы оценить, можно ли им заменить STM32F051, т.к. по ногам он один-в-один. Залил прошивку. Вроде запустился, но вот терминал (у меня все проекты имеют терминал по UART1 для контроля/настроек) работает очень медленно: строки выводятся так, словно я снова в конце 80-х сижу у СМ-1420 у монитора с зеленым экраном, который подключен токовой петлей на 9600. Тот был быстрее.

    В мануале тоже фразочка, что первые 32K — zero state, а вот вторые 32K — «A long delay». Посмотрел свою карту памяти: аккурат моя поддержка терминала (UART, FIFO…) разместилась там.

    Поэтому, если и брать GD32 на замену, то только, если код меньше половины памяти.

    Не оставляя надежды на альтернативу для STM32F051, я еще заполучил GD32E230. У того тоже 64К, распиновка F051 и нет замечания по поводу long delay. Тот же код (почти) завелся, и задержки терминала нет: всё шустро, но судя во всему, E230 по периферии — это такой гибрид F051 и F10x: ADC, I2C и таймеры не запустились, а покопаться не могу: KEIL его знать не хочет. Отложил до времён….

  6. Эх вот бы статеек про усб без всяких HAL… перефирию настроить да байты погонять.. FSMC долго ждал да дождался, мощно получилось у Вас. Может и до усб очередь дойдет. Надежда умирает последней!!

  7. При замене STM32F103VBT6 на GD32F103VBT6 отказался работать на выход порт PB2.
    При отладке выяснилось, что на работу PB2. Влияют настройки порта PB1 !!!
    Как только PB1 настроен как вывод с альтернативной функцией. PB2 перестает работать.
    Ребята попробуйте эту багу. У всех такая беда или только я такой счастливый.

  8. Связался с диллерами GigaDevices. Переслали интересный документ
    compatibility sumup between GD32 and STM32_V2.0
    Это оказалось нечто среднее между инструкцией перехода с STM32 на GD32 и
    Erarta! На сайте GD данный документ я нагуглить не смог.
    Моя проблема с выходом порта PB2 там как раз описана.
    Документ может реально спасти много вашего времени.
    Положил документ себе на ЯДиск. https://disk.yandex.ru/i/FwHNMyGbu4o8MQ

      1. сейчас трудно. Брал в декабре.
        GD32F150С, GD32F103R, GD32F103V, GD32F207V
        были в наличии. И цены не дорогие были.
        Сейчас цены задраны на все!! на 103 особенно.
        Контроллеры GD32F(130)150С — по цене очень интересны.
        И контроллеры очень неплохие. Нет совместимости с STM32 полной
        поэтому почти некому они не нужны. Если партии плат большие то очень
        выгодно получиться на них перейти.

    1. на самом деле там их больше — это я искал на lcsc.com

      RX32F103CBT7 datasheet partially in English
      APM32F103C8T6 datasheet in Chinese
      HK32F103 HK32F103C8T6 37 pages datasheet in Chinese
      MS32F103C8T6 58 pages datasheet in Chinese
      MG32F103C9T6 datasheet in Chinese
      FCM32F103CBT6 you can guess

  9. Здравствуйте. А какой размер flash у вас занят в GD32F103VG ? У меня, если размер начинает превышать 256к, все начинает жутко тормозить, даже прерывания от таймеров с задержкой происходят.

    1. Мало. До 100к точно. У ГД хитрая память. Там она сделана на внешнем чипе который нахлобучен на основной сверху. Возможно с этим и связано. Дальние адреса он не может кэшировать.

  10. А кто знает есть ли подобные аналоги китайской промышленности для операционных усилителей: общего назначения, инструментальные и т.д. ? Например аналог AD, Texas и другие.

  11. Добрый день! Подскажите, пожалуйста, есть проект на STM32F103VCT6, из-за отсутствия их пришлось перейти на GD32F103VCT6. Раньше по USART1 по протоколу Modbus болтал с HMI. При мигрировании на GD32 USART1 отвалился. Судя по гайдам на ногах, где у STM32 USART1 у GD32 сидит USART0. В проекте UART написан через HAL в STM32Cube, соответственно USART0 он не знает. Как вы вышли из положения в своём проекте? Спасибо.

    1. В данном случае проблема не в том что тут 0, а там 1, потому как адреса регистров 0 у ГД соответствует 1 у ст. Там один к одному, разница только в названиях в даташите, то есть не существенная. Скорей всего он отвалился по другой причине.

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

      1. Благодарю за ответ, к сожалению, в разработке под STM32 я новичок и это разовая задача, HAL сильно ускорял работу.

Добавить комментарий

Ваш e-mail не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.