KnightIgor

Вставлю свои 5 центов. У меня на столе лежат: STM32F103VET GD32F103VET GD32F303VET SCB->CPUID возвращает/содержит: 0x411FC231 для STM32F103VET 0x412FC231 для GD32F103VET 0x410FC241 для GD32F303VET Похоже, это слово не меняется от экземпляра к экземпляру одного типа, а идентифицирует тип. Еще раз повторю кратко свои изыскания из форума "Читайте эту тему": - бинарник на мой проект под STM32F103 взлетел сразу на GD32F103 и 303 за исключением некоторых проблем с I2C: как оказалось, в режиме работы по прерываниям на GD32 нельзя устанавливать биты BUFIE и/или POS еще ДО передачи адреса периферии, что я делал на STM32F103 для особых случаев чтения только одного или только двух байтов - это приводило к зацикливанию прерывания на GD32, т.к. бит SB не сбрасывался. Я перенес эти настройки в другую ветвь обработчика прерывания: STM32F103 было фиолетово, а GD32F103/303 заработал. - встроенный UART загрузчик в GD32 полностью совместим с STM32, ST Loader Demostrator программирует без проблем. - DFU через USB не пробовал ни на каком. - На GD32F103 с питанием от 3.3в ADC температурного датчика уходит на максимум; случайно обнаружил, что при питании от 3.2в температура правильная, а чуть поднял питание - насыщение. - Этой ADC проблемы нет на GD32F303. - В моем проекте не задействованы SPI и большинство таймеров; те, что задействованы, работают ожидаемо. DMA и RTC тоже в порядке. - запись во flash из самой программы работает на GD32 без проблем; есть ощущение, однако, что на GD32 требуется больше времени для записи страницы. Проскакивала информация, что GD32F фактически работает из дополнительной "теневой" RAM, куда при старте копируется содержимое из встроенного SPI flash чипа, и GD32F представляет собой, по сути, гибридную сборку. Благодаря RAM быстродействие GD32F, якобы, выше, чем STM32F, и не нужно циклов ожидания как для flash; GD32F103 имеет максимум частоты в 108MHz. Эти факты я не проверял, но ощущение таки есть, что GD32F103 действительно пошустрей на 72MHz: есть у меня в проекте цикл обработки загруженой конфигурации, я измеряю время этого цикла и вижу примерно на 10% бОльшую скорость его обработки на GD32F в сравнении с STM32F103. Вывод: для проекта мы рассматриваем GD32F103 как полноценную альтернативу STM32F103.

Написал в личку, но ответов пока нет. Пробую здесь напомнить. Мои извинения другим читающим.

По какой оболочкой? Имел проблемы с -O2 оптимизированным кодом под CubeIDE, но тот же абсолютно код, собраный под KEIL с -O2, работает без проблем!

Пользуясь этим замечанием, вернусь к моим баранам: GD32F. Тут @majorka65 заметил, что от темы Holtek ушли в HAL (хоть и тоже на "H"), но если мы об альтернативах, поговорим дальше о GD32F. Мои изыскания по несовместимости I2C в STM32F1xx и GD32F1xx/3xx нарыли следующее. Проблемы с GD32F возникают, когда мастер (процессор) делает транзакцию чтения; с записью (write only) все в порядке. Изначально мой "драйвер" I2C писался под STM32F. Начиная со страницы 732 мануала Doc ID 13902 Rev 14 описаны различные методы транзакций с выделением особых случаев приема только одного или двух байтов, или же когда осталось принять три последних байта, если изначально надо было принимать больше. Все эти особые случаи и составляют всю сложность алгоритма при работе по прерываниям. Это усугубляется еще и тем, что уже в процессе приема (тактирования по SCL) в особых случаях нужно успевать снимать ACK или предварительно делать STOP, откуда идет рекомендация либо дать прерыванию по I2C наивысший приоритет в системе, либо обрамить критические участки запретом прерываний (чего я очень не люблю). Я делал анализ предстоящей транзакции на предмет особый случаев в прерывании по биту SB (старт сгенерирован) перед передачей адреса ведомого с битом на чтение. При этом либо выставлялся бит POS для приема строго 2-х байтов, либо разрешалось прерывание BUFIE для остальных количеств. BUFIE генерирует прерывание по TXE, RXNE и/или BTF. Это все работало, пока не появился GD32F, который в отличие от STM32F, похоже, НЕ передает адрес, если выставлен бит BUFIE! Это приводило к тому, что бит SB залипал (он сбрасывается при записи адреса в DR), а бит ADDR не устанавливался вообще, и прерывание зацикливалось по SB. Как только я перенес принятие решения об особых случаях в ветвь обработки прерывания от уже установленного бита ADDR, все завелось, как на STM32F, так и GD32F. Конечно, сейчас я понимаю, что момент принятия решения надо было поместить про последнему варианту изначально, так как это более логично, но уж так сложилось. Не могу вынести приговор, какой из процессоров ведет себя неправильно. С одной стороны, STM32F1 более старый, и может чего не досмотрели еще тогда, а в GD32F исправили. С другой стороны, почему GD32F физически не передает адрес, если уже установлено прерывание по буферу, которое реагирует на совсем другие биты, тоже не ясно. Однако, я не случайно тут процитировал @adnega Пока отлаживался, все работало. Затем собрал release с оптимизацией -O2, и... I2C на GD32F перестало работать, хотя на STM32F1 по-прежнему без проблем! Ничто не зацикливается, вылетает по ошибке неопределенного состояния, но делает что-то так, что периферия (не могу сказать, EEPROM или часы RV-3028-C7) садит SDA на ноль, пока не передернешь питание. Та же хрень на оптимизации -O1. Посмотрел на всякие переменные (управляющие структуры). Они volatile... Пока как workaround запретил оптимизацию самого файла драйвера I2C (всегда -O0), и тогда все работает. Такi справи, малята...

Претензии к HAL на ST процессоры имеют место быть: хотя процессоры из одной кузни, спецификация периферии изменялась со временем. Например, тот же ужасный I2C на F1xx/F3xx линейках заменен на более автономный и понятный на F0xx (но самый крутой - это TWI на ATMEL/Microchip). Чтобы поддержать все вариации периферии, нужно постараться, и тут без overhead не обойдешься. Мне довелось работать с EnergyMicro (куплена потом SiLabs-ом) с самого начала их появления. Надо сказать, что скандинавы хороши в таких вещах (тот же Nordic или создатель LwIP и Contiki Адам Дункельс). Периферия EFM32 была продумана до мелочей с самого начала и остается такой и ныне. Меня также приятно поразил стиль и эффективность их HAL, которая транслировалась действительно в минимальный код register = value. Вот если бы они засовывали побольше таймеров в свои процессоры, как это делает ST, я бы остался верен EFM32. Поэтому гнать на HAL как таковую не стОит лишь на опыте с ST.

У меня как KEIL, так и CubeIDE. Текущий проект, в который втулили GD32F, - под CubeIDE, но и под KEIL наблюдается влияние отладчика (разработку поддержки для I2C я делал под ним в далекие годы). Я не разработчик микропроцессоров, но "non intrusive" - это важная характеристика. Помнится, C8051 процессоры от SiLabs имели даже JTAG (у меня был проект с таким процессором и FPGA в связке по JTAG Chain), и там SiLabs делал (маркетинговый) акцент на "non intrusive", и это работало. Мой "драйвер" для I2C для STM32 может работать как по прерываниям, так и по DMA: определяю во время компиляции. В данном проекте эти каналы DMA используются для UART для подержки modbus, поэтому приходится только по прерываниям. Актуализация по GD32F103. Вчера потратил пол-дня и втулил пример из библиотеки поддержки для GD32F1xx с синхронной работой с I2C в проект. Заработало, но удовлетворения не принесло... P.S. Как я писал, канал температуры в ADC в GD32F103 при нормальном питании в 3.3V залипает на максимуме. Тут вдруг попала в руки плата с GD32F303. Бинарник для GD32F103 взлетел на нем моментально, и температурный канал ADC работает правильно. Следом пробежала инфа от дистрибьютора, что GigaDevice рекомендует применять 303 вместо 103.

Основная проблема с STM321xx и аналогично - с GD32F1xx, - разрушающее действие отладчика (not "non intrusive"). Да, да, именно так дела и обстоят, хотя и не должны. Об этом писалось 10-12 лет назад в этом форуме тоже. Самая неприятная вещь, что бит ADDR в регистре SR1 стирается, когда отладчик считывает SR1 и SR2 - именно такая последовательность описана в доке для сброса бита ADDR. Поэтому при отладке исполнение любой команды (хоть одной ассемблерной) после остановки, где еще виден этот установленный бит, тут же его сбрасывает. И понеслась: полное нарушение логики периферии.

Я продолжаю копать под GD32F103 и буду делиться "находками" здесь. Прежде всего, хочу извиниться перед коллегами за ввод в заблуждение по поводу построения I2C в китайце: он таки аналогичен STM32F1xx, со всеми этими особыми случаями при чтении трех и менее байтов. Тем не менее мой код, которому уже лет 10 и более, работающий по прерываниям на STM32F103, не работает на китайце. Я еще не раскопал точно, в чем проблема, но ловлю композиции битов из SR1 и SR2 (в терминах ST, или STAT0 и STAT1 в терминах GD32F103), которые не возникали под ST, в результате я вылетаю по switch case в ветвь default, которая ловит неожиданности и генерирует ошибку. Раскопки показали также, что одна errata из ST была устранена. По крайней мере, нет необходимости обрабатывать случай, описаный как: Отлаживать I2C сложно, потому как всякие остановки растягивают надолго SCL, что, похоже, вводит в заблуждение как саму машину I2C, так и периферию. Кстати, об отладке. Я тут спрашивал: Покопался в безграничном интернете и нашел решение. Цитата из одного форума: Это завелось, потому я могу теперь отлаживать GD32F103VET под STMCubeIDE. Рекомендую. А, еще надо в настройках debug для OpenOCD выбрать Software System Reset для режима сброса. Так в некоторых форумах стояло, и работает. По ADC: при питании до 3.2V (VREF+ = VDDA) температура измеряется реалистично; при питании в 3.3V значение ADC всегда тупо 4095, потому показывает минусовое значение после пересчета. В моем проекте не очень критично (просто для информации измеряется), придется забить на это. Продолжаю бороться с I2C.

Цитирую Ваше высказывание, которое Вы как-бы забыли "Возможности WinAPI изучили? Про SetCommTimeouts() читали? Раз пишете, о каких-то миллисекундах, отслеживаемых на уровне приложения, значит делаем вывод, что не читали. " Вы обращаетесь лично ко мне. Мы тут все понимаем между строк, и кому все иголки адресованы, и попытка пройти под радаром очевидна.

Под настройки я выделяю одну страницу (они туда помещаются) в 2KiB и стираю постранично: кэширую, изменяю данные, пишу страницу. На это в STM32 надо что-то от 20мс до 40мс. И я уже как бы привык к наблюдаемой задержке в выполнении терминальной команды. Она весьма незначительная, но заметная. Та же кухня на GD32 работает ощутимо медленней. Не сильно, но медленнее на столько, что мне заметно.

Набрел на интересную статью. Цитата: "Как вам такое, Илон Маск"? В моем проекте, где I2C таки не работает, есть запись во Flash для изменения настроек. Многие настройки я изменяю терминальными командами. Теперь я понимаю, почему я заметил, что наблюдается ощутимая задержка при выполнении таких команд.

А что с I2C? Не пользуете в проекте? И под какой IDE пишите (KEIL, если v6)?

Актуализация. Тут мы напаяли GD32F103VET вместо STM32F103VET и тупо залили бинарник, сделаный для STM32 (по UART и STLoaderDemonstrator через встроенный bootloader, который оказался полностью совместим с STM32). 1. Завелось сразу. Тактирование от HSE 12MHz с системным тактом в 72MHz. Похоже, что PLL совместима. 2. Другие вещи как UART и GPIO тоже работают без пререканий. SPI в системе не используется, потому не знаю. 3. Некоторая непонятка с ADC. Вроде работает: каналы, которые цифровывают на плате 4 сигнала и VREF (=VDDA), показывают правильные значения, однако температура (после пересчета, конечно) есть минус 400 с чем-то градусов. Совершенно случайно я понизил напряжение питания до 3.2V, и температура стала реалистичной, а как только питание восстанавливается до 3.3V, температура снова минус 400 с копейками, хотя VREF (=VDDA) показывает правильно в обоих случаях. 4. Совершенно не работает I2C. Если кто помнит, в STM32F1xx ужасно кривой I2C. Об этом писано-переписано тут на форумах, в том числе и мной. Так вот, согласно доку на GD32F1xx, они не стали повторять тот кошмар и сделали I2C проще, похожим на I2C в STM32F0xx (я тоже с ними работаю). А теперь вопрос. STM32CubeIDE и STLink не хотят работать с GD32F - вываливается: Это, конечно, ожидаемо, но у меня вкрадчивый вопрос: никто не убедил ещё STM32CubeIDE на подвиги?

Узнаваемый стиль @jcxz: в ответе надо сначало обос...ать спрашивающего, а потом можно и по существу. Ладно. Я пишу под lazarus и пользую LazSerial компоненту, которая и обращается к WinAPI и ставит все эти SetCommTimeouts() и подобное. Ожидание событий там происходит в отдельном thread с синхронизацией к основному потоку. Я влез в код (он же открыт) и повысил приоритет потока ожидания, после чего заработало надежнее. Все же, как ни крути, режить задачу на пользовательском уровне (без специфического драйвера порта) окончательно будет невозможно, о чем FTDI в моей цитате и говорит. Поэтому мой вопрос и сконцентрировался на устройстве USB-RS485, которое могло бы поддержать modbus, а уж потом кинуть готовый пакет наверх по USB. Похоже, такого устройства нет.

Я понимаю это так (с учетом картинки из поста @haker_fox): 1. идут байты с меньшими промежутками, чем 1.5t - принимаем байты в буфер; тут пошла пауза, она длится и длится; насчитали паузу >=3.5t - пакет полный, отдаем на обработку вышестоящему уровню. Все хорошо. 2. идут байты с меньшими промежутками, чем 1.5t, - принимаем байты в буфер; пошла пауза, уже >= 1.5t: ага, ждем, что будет дальше... Не прошло и 3.5t, как появляется байт: тогда игнорируем предыдущие байты, считаем этот байт первым в пакете, далее - пункт 1. Я вижу такое построение как возможность для slave типа во время передачи ответа сказать: "ой, не в тему отвечаю, погодь 1.5t, забей на предыдущий базар, шефу наверху пока ничего не сообщай, я быстренько тут перепакую... а, вот, понеслась по-новой". Эффект - вышестоящему уровню ничего не сообщается о сбоях. Всвязи с этой темой - мой вопрос. Для тестирования modbus RTU через PC предлагаются USB-RS485 адаптеры и всякие программы для PC. Есть "классические" адаптеры с FTDI|Silabs чипами, есть дешевые, узнаваемые по дизайну, с CH340. И те, и другие создают виртуальные COM-порты. Очевидно, что PC не является системой реального времени, плюс буферизированный и пакетированный прием по USB - в результате прием в приниципе таки будет работать, если делать паузы по приему на уровне программы на PC достаточно длиными. Это в идеальный условиях, особенно когда периодичность запросов не критична. В системе, которую я помогаю разрабатывать, хочется выжать максимум скорости при опросе датчика. Это означает, что хочется посылать следующий запрос, как только пришел ответ на предыдущий. То есть, на высоких скоростях на линии уже после 1.75мс считать принятый пакет полным, быстренько его куда скинуть и запросить следующий. Очевидно, что для PC эти 1.75мс весьма критичны и размыты. Я сделал программу, которая с помощью multithreading рубает так быстро, как это возможно (загрузка CPU до 40% из-за этого). Однако, как только паралелльно на PC начинает работать программа отображения видео с камеры наблюдения (так надо), начинаются ошибки приема пакетов, т.к. для программы приема возникают паузы более 1.75мс еще внутри пакетов. Это объяснимо и ожидаемо. Об этом в одном немецком форуме писали ( https://www.mikrocontroller.net/topic/181372 ), и там приведена цитата от FTDI: "The only mechanism we have for resolving data loss on a serial link is to use flow control.It is also worth noting that although we do not claim modbus support, it has been reported from other users that although modbus ascii mode works, modbus rtu will not. This is a consequence of RTU mode relying on specific inter byte gaps which USB cannot meet as it is a polled system sending data in packets as opposed to individual bytes." Очевидно, что решением может быть только специализированный USB-RS485 адаптер, который знает о modbus, принимает пакеты и отправляет по USB наверх только полные пакеты. Видел кто такое? Это своего рода gateway, однако я что-то не нашел в приемлемом ценовом классе. Всякие modbus RTU to Ethernet пока не рассматриваются. Что посоветуете?