KnightIgor

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

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

Занесло всех довольно далеко. 1. Я бы не сказал, что у меня как ТС имеется проблема. Ее (уже) нет. Я напоролся на непонятку, обнаружил синтаксическое несовпадение и по доброте душевной и в качестве взаимопомощи ОБРАТИЛ ВНИМАНИЕ сообщества на это, чтобы другие не наступали на те же грабли. 2. Ассемблер или нет: я начал работать с Cortex с самого начала их появления, еще ДО того, как появилась CMSIS. Если горячая молодежь вникнет в историю вопроса, то увидит, как пришли к CMSIS, и какие требования к ее структуре. Одно из требований: производитель прилагает к своим процессорам два файла: startup_<обозначение_процессора>*.s и system_<обозначение_процессора>*.c, которые стандартизируют его первоначальную настройку и запуск. Оттуда и есть пошла земля армовская. Вывод по 2-му пункту: хотите - придерживайтесь стандарта, нет - пишите свое. Однако хочется спросить здесь всех, кто пишет свое: пусть поднимут руки те, кто работает в ST|MicroChip|Texas|FreeScale|NXP и самом ARM.

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

Флаг в руки. Заодно черкните походя свою операционку, например.

Синтаксисы ассемблеров gcc и KEIL сильно отличаются. Стартап и лежит в проекте: его туда копирует сам KEIL или STM32CubeIDE при создании проекта. Под "подключается откуда-то" имеется ввиду, что обе оболочки тянут этот файл из своего репозитория (Packs в KEIL и нечто подобное в STM32CubeIDE).

Коллеги! Хочу просто поделиться граблей, вдруг кто столкнется. Портировал большой проект из KEIL в STM32CubeIDE. За исключением бОльшей строгости gcc в сравнении с пофигистом armcc, портировка не очень сложная. Все завелось с пол-оборота. Пока не воткнул USB (STM32F103VET): попал в HardFault. Поставил там bx lr, чтобы под отладчиком понять, откуда прилетело, и с удивлением обнаружил, что влетаю туда периодически и спорадически с совершенно разных, надежных по коду, мест. Понял, что это не проблема нарушения стека или чего-то еще, а какая-то синтаксическая ошибка портирования. И нашёл: eсли в startup_stm32f10x_hd.s из CMSIS под KEIL имя слабоопределенного вектора прерывания есть "USB_LP_CAN1_RX0_IRQHandler", то под STM32CubeIDE автоматически присоединяемый файл startup_stm32f103vetx.s обзывает вектор как "USB_LP_CAN_RX0_IRQHandler". Как очевидно, дело было не в HardFault, а в фактическом отсутствии обработчика прерывания от USB. Чтобы сохранить совместимость исходника для обоих IDE, сделал: // Compatibility with gcc: another name for the interrupt: void USB_LP_CAN_RX0_IRQHandler (void) __attribute__((alias("USB_LP_CAN1_RX0_IRQHandler"))); void USB_LP_CAN1_RX0_IRQHandler(void) {

И вправду! А как к решению пришли?

Есть и такой. Но я не уверен, что он правильный.

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

Да: вариант ответа 29 есть! Респект! Расскажи!

Привет, коллеги. Тут есть задачка по математике, непосредственно к электронике отношения не имеет, но т.к. я тусуюсь здесь, решил сюда и спросить. Итак, 7-й класс школы. Задача: Есть мешочек с фишками четырех разных цветов: RGB и черный. Сколько там каких - не видно. 1. Если достать 27 фишек, то одна будет точно зеленой. 2. Если достать 25 фишек, то одна будет точно красной. 3. Если достать 22 фишки, то одна будет точно черной. 4. Если достать 17 фишек, то одна будет точно синей. Вопрос: какое минимальное количество всех фишек должно быть в мешочке? Мои рассуждения: это задача вовсе не на вычисление вероятностей. Речь идет о таком составе мешочка, чтобы вышеуказанные условия хоть когда-нибудь выполнились. Я ее, вроде, решил. Не подбором, а.... не хочу навязывать свой метод. НО. Результат не сходится с предложенными 4-мя вариантами ответа (multiply choice).

Похоже, я раскопал сам. Оказалось, все есть на борту. Под KEIL в каталоге, где armcc.exe, есть fromelf.exe. Если его натравить на созданную для/под KEIL библиотеку .lib, строкой fromelf --elf library.lib --output library.elf, то компоновщик ST32CubeIDE поймет library.elf (можно включить через Свойства Проекта -> C/C++ Build ->Settings->[Tool Settings]->MCU GCC Linker->Miscellaneous->Additional object files)

Добрый день! (с) С. Капица. Не доводилось кому портировать библитотечные файлы .lib от KEIL в библиотеки .a для gcc? TIA

Блин, ошибся: Uвых = -V1*(R2/R1) - инвертирующий усилитель, если V2 заземлить. Отсюда для дифференцирующего, при взаимно равных парах резисторов: Uвых = (V2 - V1)*(R2/R1).