[Forger 17]

2 hours ago, VladislavS said:

Куда-то вас занесло. 

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

Ну, религия такая или хобби - оптимизация ради оптимизации. Что ж поделать )))

[x893 34]

23 minutes ago, Forger said:

Ну, религия такая или хобби - оптимизация ради оптимизации. Что ж поделать )))

Катеричность высказываний * Знания = const

[KnightIgor 2]

On 3/26/2021 at 5:04 PM, VladislavS said:

И вам не хворать.

Спасибо, особенно в нынешних условиях это очень актуально.

[KnightIgor 2]

On 3/28/2021 at 7:31 AM, VladislavS said:

Куда-то вас занесло. У ТС проблема в том что в стартапах от разных тулчейнов разные имена процедур обработки прерываний. В одном из стартапов накосячено, ибо в заголовочном файле от производителя все эти имена есть, надо их использовать. Кто конкретно делал этот косячный стартап дело десятое. Я же предлагаю использовать один стартап для разных тулчейнов, чтобы подобные несоответствия не вылазили. Причём тут RTOS-ы вообще?

Занесло всех довольно далеко.

1. Я бы не сказал, что у меня как ТС имеется проблема. Ее (уже) нет. Я напоролся на непонятку, обнаружил синтаксическое несовпадение и по доброте душевной и в качестве взаимопомощи ОБРАТИЛ ВНИМАНИЕ сообщества на это, чтобы другие не наступали на те же грабли.

2. Ассемблер или нет: я начал работать с Cortex с самого начала их появления, еще ДО того, как появилась CMSIS. Если горячая молодежь вникнет в историю вопроса, то увидит, как пришли к CMSIS, и какие требования к ее структуре. Одно из требований: производитель прилагает к своим процессорам два файла: startup_<обозначение_процессора>*.s и system_<обозначение_процессора>*.c, которые стандартизируют его первоначальную настройку и запуск. Оттуда и есть пошла земля армовская.

Вывод по 2-му пункту: хотите - придерживайтесь стандарта, нет - пишите свое. Однако хочется спросить здесь всех, кто пишет свое: пусть поднимут руки те, кто работает в ST|MicroChip|Texas|FreeScale|NXP и самом ARM.

[Eddy_Em 1]

Нет там никакого стандарта. Разве что рекомендуется CMSIS использовать вместо "магических чисел". А все остальное — от лукавого.

Кому как нравится, тот так и работает. Вот у меня, например, сишный стартап — не вижу смысла корячиться в этом деле с асмом. gcc сейчас достаточно вменяемый, чтобы вообще ничего не писать на асме, кроме уж крайне специфических инструкций. А еще при работе с STM32 я не использую чужие библиотеки (и уж тем паче уродство вроде SPL или hal).

[Darth Vader 0]

2 часа назад, KnightIgor сказал:

Одно из требований: производитель прилагает к своим процессорам два файла: startup_<обозначение_процессора>*.s и system_<обозначение_процессора>*.c

Есть мнение, что язык написания файла startup_<обозначение_процессора> не имеет принципиального значения. И строгого требования к написанию его именно на ассемблере и ни на чём ином нет. Это отдано на откуп производителя. Ни что не мешает условному производителю Х выложить для своего МК на ядре Cortex файлы поддержки в виде пака/SPL/HAL с файлом  startup_<обозначение_процессора>.с или  startup_<обозначение_процессора>.срр. 

[one_eight_seven 3]

9 hours ago, KnightIgor said:

Одно из требований: производитель прилагает к своим процессорам два файла: startup_<обозначение_процессора>*.s и system_<обозначение_процессора>*.c

Startup File startup_<device>.s (deprecated) (arm-software.github.io)
Собственно,  asm уже устарел, а для  cortex-A отсутствует и в 'deprecated' статусе.

6 hours ago, Darth Vader said:

 Ни что не мешает условному производителю Х выложить для своего МК на ядре Cortex файлы поддержки в виде пака/SPL/HAL с файлом  startup_<обозначение_процессора>.с или  startup_<обозначение_процессора>.срр

Для соответствия CMSIS, о чём и говорил товарищ, которому вы отвечали,- всё-таки кое-что мешает.

Изменено 6 апреля, 2021 пользователем one_eight_seven

[KnightIgor 2]

13 hours ago, Darth Vader said:

Есть мнение, что язык написания файла startup_<обозначение_процессора> не имеет принципиального значения. И строгого требования к написанию его именно на ассемблере и ни на чём ином нет. Это отдано на откуп производителя. Ни что не мешает условному производителю Х выложить для своего МК на ядре Cortex файлы поддержки в виде пака/SPL/HAL с файлом  startup_<обозначение_процессора>.с или  startup_<обозначение_процессора>.срр. 

Мне нравится фраза "есть мнение". Попахивает... историей, богатой бездоказательными утверждениями. Ну, это так, ничего личного, просто ассоциации.

Ничто не мешает. Однако производители изначально приняли решение в пользу *.asm. И кто-то в процессе накосячил, добавив (или убрав) цифирьку в имени вектора. Вся история, однако тема длится уже три страницы. Если бы это был Instagram, я бы уже деньжат срубил

Изменено 6 апреля, 2021 пользователем KnightIgor

[Darth Vader 0]

9 часов назад, KnightIgor сказал:

Однако производители изначально приняли решение в пользу *.asm.

В предыдущем сообщении дали ссылку на сайт ARM, откуда видно, что в настоящее время ассемблерный стартап признан устаревшим, а рекомендуемым является стартап на Си. Так что не вижу повода утверждать, что startup.c - это нестандартная кустарщина, а startup.s - железобетонный стандарт, один на все времена.

[Forger 17]

14 minutes ago, Darth Vader said:

в настоящее время ассемблерный стартап признан устаревшим, а рекомендуемым является стартап на Си.

Да, для некоторых граждан это болезненный факт, но ничего не поделать. Надо смириться и жить дальше ))

[KnightIgor 2]

On 4/6/2021 at 8:21 PM, Darth Vader said:

В предыдущем сообщении дали ссылку на сайт ARM, откуда видно, что в настоящее время ассемблерный стартап признан устаревшим, а рекомендуемым является стартап на Си. Так что не вижу повода утверждать, что startup.c - это нестандартная кустарщина, а startup.s - железобетонный стандарт, один на все времена.

 Устаревшим, но все последние версии STMCubeIDE копируют в проект именно *.s файлы. Работаем с тем, что есть.