Форум РадиоКот

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

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

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

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

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

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

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

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

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

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

[uquote="smacorp",url="/forum/viewtopic.php?p=4678210#p4678210"]Вот именно по этой причине я никогда не выкладываю исходный код там, где есть возможность его комментировать.[/uquote]Странно... Всегда думал, что это как раз плюс. Ведь читая критику, можно повысить свои знания и профессионализм. Для того и нужна критика.
В нормальных конторах любое важное решение принимается только после обсуждения, на котором автора проекта нещадно критикуют коллеги-оппоненты. И если он успешно защитил своё решение, только после этого оно воплощается в жизнь. А если оппоненты нашли косяки в его проекте, то нормальный человек должен только поблагодарить за это. Потому как это - помощь ему.

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

Добавлено after 1 minute 25 seconds:
[uquote="smacorp",url="/forum/viewtopic.php?p=4678210#p4678210"]Не по этой же ли причине Майкрософт не публикует исходники Windows? [/uquote]Не по этой ли причине в них до сих пор столько багов? Которые живут годами...

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

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

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



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

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

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

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

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

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

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

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

jcxz писал(а):Конструктивную критику конечно.

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

[uquote="shonty",url="/forum/viewtopic.php?p=4678297#p4678297"]Ну так не спорю.. но в последствии же код разбивается на "библиотеки"..
На СИ писать быстрее, потому что на библиотеки уже кто-то потратил время.[/uquote]
Библиотеки и стандартные бывают, на их написание потратили время профессиональные программисты, я просто пользуюсь результатом их труда чтобы тратить меньше времени на написание собственных библиотек. Но даже если забыть про любые библиотеки вообще все равно на С писать быстрее и код получается более надежным, в том числе потому, что компилятор вместе со всевозможными анализаторами будут пытаться подсказывать в сомнительных ситуациях.

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

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

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

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

[uquote="shonty",url="/forum/viewtopic.php?p=4678335#p4678335"]Чем асм-код не надёжнее сишного, если он работает так как нужно))[/uquote]
Любой правильно работающий код одинаково надежный, однако таковой сначала нужно написать )

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

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

[uquote="Adrift",url="/forum/viewtopic.php?p=4678292#p4678292"]ни о какой экономии места говорить особо не приходится, т.к. у мк метр флеша и в других проектах у него минимум F103, где по факту 128КБ флеша, а прошивки меньше в разы как минимум.[/uquote]Код написан неоптимально. Думаю - даже си-компилятор сгенерит намного компактнее.
[uquote="Adrift",url="/forum/viewtopic.php?p=4678292#p4678292"]USB CDC или SDIO + FatFs на ассме думаю можно ждать очень долго и в итоге не дождаться.[/uquote]Ну здесь-то как раз ничего сложного: Включаете си-компилятору опцию генерации листингов и ассемблерный код почти готов. Только слегка доработать напильником.

Добавлено after 6 minutes 25 seconds:
[uquote="shonty",url="/forum/viewtopic.php?p=4678297#p4678297"]Ну так не спорю.. но в последствии же код разбивается на "библиотеки"..[/uquote]Вы видимо не читали мой пост:
[uquote="jcxz",url="/forum/viewtopic.php?p=4678204#p4678204"]2. Функции оформлены без следования стандартным соглашениям вызова. Из-за этого - их нельзя использовать совместно с си-кодом.[/uquote]Код автора не следует стандартным соглашениям вызова. И вообще - написан без какого-то единого стиля использования регистров, сохранения/восстановления контекста на входе/выходе функций и т.п. Чтобы код можно было использовать как библиотеку и вызывать из другого кода, он должен следовать каким-то общим правилам, которые называются "соглашения вызова". И обычно описаны в документации на компилятор. Благодаря им, код, написанный в одном компиляторе, можно вызывать из кода, написанного в другом компиляторе. В обсуждаемом же коде не наблюдается следования каким-то общим "соглашениям вызова". Писано в стиле "кто в лес, кто по дрова". Подозреваю, что автор даже не слышал о таких правилах.

Добавлено after 4 minutes 18 seconds:
[uquote="shonty",url="/forum/viewtopic.php?p=4678297#p4678297"]Не думаю. что автор хотел выставить тут шедевр и раскрыть какие-то эксклюзивные приёмы.
А как шаблон начального уровня вполне.[/uquote]Как "шаблон начального уровня" гораздо лучше подойдёт листинг-выхлоп си-компилятора. Там и качество кода выше и соглашения вызова выполняются. Код автора в данном плане скорее вреден для начинающих.

[uquote="shonty",url="/forum/viewtopic.php?p=4678233#p4678233"]Сильно сомневаюсь в "нормальности" таких контор [/uquote] Вы серьёзно ?

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

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

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

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

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

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

Аlex писал(а):Вы серьёзно ?

Дураков из людей делают
То то все на фриланс и стремятся))

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

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

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

[uquote="Аlex",url="/forum/viewtopic.php?p=4678753#p4678753"]Процесс просмотра, критики и анализа чужого кода на ошибки называется "code review"[/uquote]Кстати да - и code review у нас в конторе - тоже обязательная часть раб. процесса.
Но то, о чём я говорил выше - это ДО реализации какого-то решения. Защита своего варианта решения, до начала чего-то-делания. А code review - уже ПОСЛЕ.

Добавлено after 3 minutes 40 seconds:
[uquote="shonty",url="/forum/viewtopic.php?p=4678789#p4678789"]Спорная надо сказать процедура и не для всех приятная)[/uquote]Над вами эту процедуру проводили посредством трепанации черепа и считываем оттуда прошивки чтоль?

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

[uquote="shonty",url="/forum/viewtopic.php?p=4678840#p4678840"]От "делиться знаниями" - выигрывает в основном хозяин и отстающие работники))
А основной специалист - обесценивается, со всеми вытекающими перспективами [/uquote]Так надо требовать премию и молоко за каждую операцию чтения вашей уникальной прошивки!

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

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

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