Начало. Применение GD32F405RG и модуля MSP3520

kurator

Начало. Применение GD32F405RG и модуля MSP3520
В интернете не много информации на микропроцессоры GD32, в частности
GD32F405 и на графические индикаторы, в частности MSP3520, на русском языке.
В этой статье попытаюсь компенсировать данный недостаток и показать
некоторые методы вывода на индикатор

Реклама

shonty

Тема явно заслуживает внимания, а труд уважения.
Пример использование ассемблера под ARM.

Как аргумент холиварщикам, что асм заканчивается на мегах.

Реклама

jcxz

Да уж... Прикольно конечно, но в данном случае применение ассемблера - бессмысленно. Так как применён он в таком месте, где в этом нет нужды.
Вот если-б автор реализовал на нём какой-то алгоритм, требующий максимального быстродействия... Скажем - модулятор или демодулятор. Или фильтр какой. Или какой-то нестандартный алгоритм, нереализуемый на си. Например - какой-то алгоритм с самомодифицирующимся кодом или что-то подобное. Или хотя бы просто - алгоритм требующий активного использования редких команд или каких-то особенностей CPU.
А так....

PS: По тексту видно не очень эффективное программирование на ассемблере:
1. Использование задержек NOP-ами. Имхо - такое на процессорах типа ARM - вообще не комильфо.
2. Функции оформлены без следования стандартным соглашениям вызова. Из-за этого - их нельзя использовать совместно с си-кодом.
3. Неоправданное повсеместное использование MOV32, вместо загрузки констант с адресацией по PC.
4. Использование команд без суффикса 'S' (более длинные команды).
5. Вообще автор выполняет в коде много странных, бессмысленных действий. Типа сохранения LR в начале функции и восстановления в конце. Непонятно с какой целью. Для обучения это явно не гуд.

Например тут:

Код:

lnter_DMA1_Channel5 PROC ;- любое немаскированное прерывание от канала 5 модуля DMA1 
PUSH    {LR} 
MOV32   R0, #DMA1 
LDR     R1, [R0,#DMA_INTF1] 
STR     R1, [R0,#DMA_INTC1]  ;Очистка  прерывания 
MOV32   R0, #NVIC_ICPR2     ; Сбрсить признаки отложенных прерываний 64...96 
MOV     R1, #(1<<(DMA1_Channel5_IRQn - 64)) 
STR     R1, [R0] 
MOV32   R0, #GPIOA 
MOV32   R1, #CS_off      ; CS_off: 1 
STR     R1, [R0,#GPIO_BOP] 
POP     {LR} 
BX     LR 
 
ENDP  

Зачем тут делается PUSH/POP LR?
Также - зачем тут делается очистка запроса прерывания в NVIC? Он уже был очищен, когда CPU перешёл на этот ISR. А такая повторная очистка уже после сброса флагов в регистре периферии (DMA) имхо может привести в какой-то момент к багам: Если новый запрос прерывания успеет прийти между очисткой флагов в регистре DMA и сбросом нового флага запроса в NVIC. Флаг запроса будет стоять в регистре DMA, но не будет вызывать вызова ISR, так как в NVIC запрос уже сброшен.
Также в конце процедуры не выполняются требований Errata2.1.3 Cortex-M3/M4 (отсутствует инструкция барьера).

PPS: Вобщем имхо - код написан весьма грязно.

smacorp

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

Неважно как код действительно написан, всегда найдётся тот, кто знает "как лучше" и наведёт жуткую критику.

Не по этой же ли причине Майкрософт не публикует исходники Windows?

Реклама

Выбираем индустриальные и медицинские источники питания MEAN WELL в открытом исполнении

Использование модульных источников питания открытого типа широко распространено в современных устройствах. Присущие им компактность, гибкость в интеграции и высокая эффективность делают их отличным решением для систем промышленной автоматизации, телекоммуникационного оборудования, медицинской техники, устройств «умного дома» и прочих приложений. Рассмотрим подробнее характеристики и особенности трех самых популярных вариантов AC/DC-преобразователей MW открытого типа, подходящих для применения в промышленных устройствах - серий EPS, EPP и RPS представленных на Meanwell.market.

Подробнее>>

jcxz

smacorp писал(а):

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

Странно... Всегда думал, что это как раз плюс. Ведь читая критику, можно повысить свои знания и профессионализм. Для того и нужна критика.
В нормальных конторах любое важное решение принимается только после обсуждения, на котором автора проекта нещадно критикуют коллеги-оппоненты. И если он успешно защитил своё решение, только после этого оно воплощается в жизнь. А если оппоненты нашли косяки в его проекте, то нормальный человек должен только поблагодарить за это. Потому как это - помощь ему.

А обижаются на критику обычно только мамкины программисты с завышенным ЧСВ. :)))

Конструктивную критику конечно.

Добавлено after 1 minute 25 seconds:

smacorp писал(а):

Не по этой же ли причине Майкрософт не публикует исходники Windows?

Не по этой ли причине в них до сих пор столько багов? :)))

Которые живут годами...

Реклама

shonty

jcxz, вы черезмерно категоричны :)))

Потому что ценность материала в его существовании в принципе.

Я из тех "специалистов", которые предпочитают изучать тему "с конца", а не искать качественную литературу по КР580ВМ80А, чтобы программировать STM :)))

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

:beer:

Добавлено after 1 hour 26 minutes 30 seconds:

jcxz писал(а):

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

Сильно сомневаюсь в "нормальности" таких контор :)))

Реклама

Распродажа паяльного оборудования ATTEN!
Паяльные станции, паяльники и аксессуары по самой выгодной цене.

По промокоду radiokot скидка 10%

Adrift

shonty писал(а):

Как аргумент холиварщикам, что асм заканчивается на мегах.

Сам факт того, что кто-то написал прогу на ассме для ARM, а у автора и несколько законченных проектов есть - не аргумент. Лично я вижу одни контраргументы, потому что очевидно времени на написание было затрачено существенно больше, ни о какой экономии места говорить особо не приходится, т.к. у мк метр флеша и в других проектах у него минимум F103, где по факту 128КБ флеша, а прошивки меньше в разы как минимум. Оптимизаций по скорости тоже не наблюдается, может хоть перенести на другие мк будет проще? Например, на более простые и мелконогие M0/M23 с сильно урезанным набором инструкций? Нет, придется все переписывать. Или, например, что будет если случайно вывести часть текста за пределами экрана? Какие-то рантайм проверки там есть? Может компайл-тайм? А что насчет более сложной периферии? USB CDC или SDIO + FatFs на ассме думаю можно ждать очень долго и в итоге не дождаться. И это еще мк с достаточно простой периферией, китайцы ее из первых серий STM32 заимствуют, а на самих STM32 она уже несколько раз эволюционировала.

shonty

Adrift писал(а):

очевидно времени на написание было затрачено существенно больше,

Ну так не спорю.. но в последствии же код разбивается на "библиотеки"..
На СИ писать быстрее, потому что на библиотеки уже кто-то потратил время.

Adrift писал(а):

Оптимизаций по скорости тоже не наблюдается,

И это я заметил, и множество нопов видел..
Не думаю. что автор хотел выставить тут шедевр и раскрыть какие-то эксклюзивные приёмы.
А как шаблон начального уровня вполне.

jcxz писал(а):

Конструктивную критику конечно.

Конструктивной критики не бывает :)))

Критика всегда деструктивна. Хотя бы потому, что у критикующего априори доминирующий статус :)))

Adrift

shonty писал(а):

Ну так не спорю.. но в последствии же код разбивается на "библиотеки"..
На СИ писать быстрее, потому что на библиотеки уже кто-то потратил время.

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

Adrift писал(а):

И это я заметил, и множество нопов видел..
Не думаю. что автор хотел выставить тут шедевр и раскрыть какие-то эксклюзивные приёмы.
А как шаблон начального уровня вполне.

Да, но из этого шаблона начального уровня, как и из других проектов автора, не понятно почему написание проектов для ARM целиком на ассме в принципе является целесообразным. Я же начал с того, что аргументов не видно, потому и холивара никакого быть не может.

Реклама

shonty

Adrift писал(а):

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

Ну можно с этого утверждения холивар начать :)))

Имею ввиду надёжность кода. Чем асм-код не надёжнее сишного, если он работает так как нужно))
Хотя возможно я ещё мелко плавю)) Си не знаю, но по форуму видно, что и у сишников проблем не меньше. И компиляторы не решают)

Adrift

shonty писал(а):

Чем асм-код не надёжнее сишного, если он работает так как нужно))

Любой правильно работающий код одинаково надежный, однако таковой сначала нужно написать )

shonty писал(а):

Хотя возможно я ещё мелко плавю)) Си не знаю, но по форуму видно, что и у сишников проблем не меньше. И компиляторы не решают)

Тут многие раньше писали на ассме для AVR/PIC, потом на С для AVR/PIC, наконец на C/C++ для ARM, а если С даже не знаешь, то как сравнивать? ) Более того, поскольку вы на ассме для простенького AVR пишете, то имеет еще и смутное представление о том с чем пришлось бы столкнуться на ARM со значительно более сложной периферией. По форуму видно, что далеко не все такой переезд пережили, даже если для AVR они писали на С. А проблемы у любых начинающих(и не очень) будут, на чем бы они не писали, однако если на С у народа может быть проблема как запустить связку SPI + DMA + графический дисплей, то на ассме они бы до сих пор порты настраивали чтобы светодиодом помигать )

jcxz

Adrift писал(а):

ни о какой экономии места говорить особо не приходится, т.к. у мк метр флеша и в других проектах у него минимум F103, где по факту 128КБ флеша, а прошивки меньше в разы как минимум.

Код написан неоптимально. Думаю - даже си-компилятор сгенерит намного компактнее.

Adrift писал(а):

USB CDC или SDIO + FatFs на ассме думаю можно ждать очень долго и в итоге не дождаться.

Ну здесь-то как раз ничего сложного: Включаете си-компилятору опцию генерации листингов и ассемблерный код почти готов. Только слегка доработать напильником.

Добавлено after 6 minutes 25 seconds:

shonty писал(а):

Ну так не спорю.. но в последствии же код разбивается на "библиотеки"..

Вы видимо не читали мой пост:

jcxz писал(а):

2. Функции оформлены без следования стандартным соглашениям вызова. Из-за этого - их нельзя использовать совместно с си-кодом.

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

Добавлено after 4 minutes 18 seconds:

shonty писал(а):

Не думаю. что автор хотел выставить тут шедевр и раскрыть какие-то эксклюзивные приёмы.
А как шаблон начального уровня вполне.

Как "шаблон начального уровня" гораздо лучше подойдёт листинг-выхлоп си-компилятора. Там и качество кода выше и соглашения вызова выполняются. Код автора в данном плане скорее вреден для начинающих.

Аlex

shonty писал(а):

Сильно сомневаюсь в "нормальности" таких контор :)))

Вы серьёзно ?

Цитата:

Процесс просмотра, критики и анализа чужого кода на ошибки называется "code review" (или "ревью кода"). Это важная часть разработки программного обеспечения, которая помогает улучшить качество кода, найти ошибки и поделиться знаниями между разработчиками.
Что такое code review?

Code review — это процесс, при котором один или несколько разработчиков проверяют код, написанный другим разработчиком, чтобы:
Найти ошибки (баги).
Убедиться, что код соответствует стандартам и best practices.
Проверить, что код решает поставленную задачу.
Поделиться знаниями и опытом.

Основные этапы code review:
Подготовка:
Разработчик пишет код и создаёт pull request (PR) или merge request (MR).

Проверка:
Другие разработчики просматривают код, оставляют комментарии и предлагают улучшения.

Исправление:
Автор кода вносит изменения на основе комментариев.

Утверждение:
После исправлений код утверждается и сливается в основную ветку.

shonty

Аlex писал(а):

Вы серьёзно ?

Дураков из людей делают :)))

То то все на фриланс и стремятся))

Добавлено after 4 minutes 30 seconds:

Аlex писал(а):

и поделиться знаниями между разработчиками.

а вот это много где практикуется..
Спорная надо сказать процедура :)))

и не для всех приятная)

jcxz

Аlex писал(а):

Процесс просмотра, критики и анализа чужого кода на ошибки называется "code review"

Кстати да - и code review у нас в конторе - тоже обязательная часть раб. процесса.
Но то, о чём я говорил выше - это ДО реализации какого-то решения. Защита своего варианта решения, до начала чего-то-делания. А code review - уже ПОСЛЕ.

Добавлено after 3 minutes 40 seconds:

shonty писал(а):

Спорная надо сказать процедура :)))

и не для всех приятная)

Над вами эту процедуру проводили посредством трепанации черепа и считываем оттуда прошивки чтоль? :)))

shonty

От "делиться знаниями" - выигрывает в основном хозяин и отстающие работники))
А основной специалист - обесценивается, со всеми вытекающими перспективами :)))

jcxz

shonty писал(а):

От "делиться знаниями" - выигрывает в основном хозяин и отстающие работники))
А основной специалист - обесценивается, со всеми вытекающими перспективами :)))

Так надо требовать премию и молоко за каждую операцию чтения вашей уникальной прошивки! :)))

PS: Имхо - как раз наоборот - не обесценивается, а оценивается по заслугам. Откуда вашему хозяину галеры знать - чего вы стоите? Он же наверняка не спец. в вашей области. А как увидит, что к вам выстроилась очередь как к наставнику, будет вас ценить. Только сразу соглашаться делиться не нужно - обязательно нужно поломаться, набить себе цену, плюшек/премий потребовать! Чтобы на шею не садились и почитали Наставника.

shonty

jcxz писал(а):

Только сразу соглашаться делиться не нужно - обязательно нужно поломаться, набить себе цену, плюшек/премий потребовать!

у меня это всё уже в прошлом :)))

Я на пенсии)

Начало. Применение GD32F405RG и модуля MSP3520

Кто сейчас на форуме