Jump to content

    

KnightIgor

Участник
  • Content Count

    731
  • Joined

  • Last visited

Everything posted by KnightIgor


  1. Мне нравится фраза "есть мнение". Попахивает... историей, богатой бездоказательными утверждениями. Ну, это так, ничего личного, просто ассоциации. Ничто не мешает. Однако производители изначально приняли решение в пользу *.asm. И кто-то в процессе накосячил, добавив (или убрав) цифирьку в имени вектора. Вся история, однако тема длится уже три страницы. Если бы это был Instagram, я бы уже деньжат срубил
  2. Занесло всех довольно далеко. 1. Я бы не сказал, что у меня как ТС имеется проблема. Ее (уже) нет. Я напоролся на непонятку, обнаружил синтаксическое несовпадение и по доброте душевной и в качестве взаимопомощи ОБРАТИЛ ВНИМАНИЕ сообщества на это, чтобы другие не наступали на те же грабли. 2. Ассемблер или нет: я начал работать с Cortex с самого начала их появления, еще ДО того, как появилась CMSIS. Если горячая молодежь вникнет в историю вопроса, то увидит, как пришли к CMSIS, и какие требования к ее структуре. Одно из требований: производитель прилагает к своим процессорам два файла: startup_<обозначение_процессора>*.s и system_<обозначение_процессора>*.c, которые стандартизируют его первоначальную настройку и запуск. Оттуда и есть пошла земля армовская. Вывод по 2-му пункту: хотите - придерживайтесь стандарта, нет - пишите свое. Однако хочется спросить здесь всех, кто пишет свое: пусть поднимут руки те, кто работает в ST|MicroChip|Texas|FreeScale|NXP и самом ARM.
  3. Спасибо, особенно в нынешних условиях это очень актуально.
  4. Флаг в руки. Заодно черкните походя свою операционку, например.
  5. Синтаксисы ассемблеров gcc и KEIL сильно отличаются. Стартап и лежит в проекте: его туда копирует сам KEIL или STM32CubeIDE при создании проекта. Под "подключается откуда-то" имеется ввиду, что обе оболочки тянут этот файл из своего репозитория (Packs в KEIL и нечто подобное в STM32CubeIDE).
  6. Коллеги! Хочу просто поделиться граблей, вдруг кто столкнется. Портировал большой проект из 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) {
  7. И вправду! А как к решению пришли?
  8. Есть и такой. Но я не уверен, что он правильный.
  9. Ага. А я систему уравнений сокращал ручками и напортачил по ходу: глаз замылился. Теперь перепроверил: ответ сошелся. Спасибо!
  10. Да: вариант ответа 29 есть! Респект! Расскажи!
  11. Привет, коллеги. Тут есть задачка по математике, непосредственно к электронике отношения не имеет, но т.к. я тусуюсь здесь, решил сюда и спросить. Итак, 7-й класс школы. Задача: Есть мешочек с фишками четырех разных цветов: RGB и черный. Сколько там каких - не видно. 1. Если достать 27 фишек, то одна будет точно зеленой. 2. Если достать 25 фишек, то одна будет точно красной. 3. Если достать 22 фишки, то одна будет точно черной. 4. Если достать 17 фишек, то одна будет точно синей. Вопрос: какое минимальное количество всех фишек должно быть в мешочке? Мои рассуждения: это задача вовсе не на вычисление вероятностей. Речь идет о таком составе мешочка, чтобы вышеуказанные условия хоть когда-нибудь выполнились. Я ее, вроде, решил. Не подбором, а.... не хочу навязывать свой метод. НО. Результат не сходится с предложенными 4-мя вариантами ответа (multiply choice).
  12. Похоже, я раскопал сам. Оказалось, все есть на борту. Под 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)
  13. Добрый день! (с) С. Капица. Не доводилось кому портировать библитотечные файлы .lib от KEIL в библиотеки .a для gcc? TIA
  14. Блин, ошибся: Uвых = -V1*(R2/R1) - инвертирующий усилитель, если V2 заземлить. Отсюда для дифференцирующего, при взаимно равных парах резисторов: Uвых = (V2 - V1)*(R2/R1).
  15. А как возможно вообще 50kOhm? Это схема усилителя, и расчет должен вестить "по переменке". Выходное сопротивление - надо мысленно замкнуть источник питания, а в данной схеме - еще и R5 по причине C4, накоротко. В этом случае выходное сопротивление есть параллельное соединение сопротивления коллектора Uc/Ic и R4. Поэтому оно никак не может быть выше 1K.
  16. Я с этого и начал в ответе для TC, а потом взыграло мое преподавательское прошлое, и понесло....
  17. Ua = V2*R4/(R3+R4). Как объяснили товарищи, идеальный (или очень правильный) операционный усилитель с обеспеченной отрицательной обратной связью (ООС через R2) делает все возможное, чтобы разница напряжений на его прямом (неинвертирующем) и инверсном входах стремилась к нулю. Это значит, что напряжение в точке 'a' равно напряжению на неинвертирующем входе, а это V2 с коэффициентом R4/(R3+R4), что есть формула резистивного делителя. Теперь о дифференцирующем усилителе вообще (а схема вверху - это оно и есть). Мысленно приравняем Uвых = 0. Тогда потенциал Ua можно выразить и как Ua = V1*R2/(R1+R2). Если Uвых <> 0, то оно "добавится" к потенциалу в точке 'a' (закон Кирхгофа для замкнутого контура): Ua = V1*R2/(R1+R2) + Uвых. Если вместо Ua подставить верхнюю формулу, то V2*R4/(R3+R4) = V1*R2/(R1+R2) + Uвых или Uвых = V2*R4/(R3+R4) - V1*R2/(R1+R2). То есть, напряжение на выходе зависит от разницы (потому дифференциальный - разностный усилитель) напряжений V2 и V1 с коэффициентами. Если взять R1=R3 и R2=R4, то это более наглядно: Uвых = V2*R2/(R1+R2) - V1*R2/(R1+R2) = (V2 - V1) * R2/(R1+R2)
  18. Как я указал в моем вопросе, "Я работаю с STM32CubeIDE". Возможно, новая версия eclipse еще не докатилась до названной оболочки от ST. До сего времени я по аналогии с оболочкой KEIL безуспешно искал настройку, которая позволяла бы внести в список подсветки пользовательские слова, к коим я относил bool, true и false, которые на настоящий момент в STM32CubeIDE версии 1.5.0 (обновилась пару недель назад) все еще рассматриваются как обычный текст в отличие от int, char или даже uint8_t или uint32_t, которые не являются встроенными типами или ключевыми словами и произрастают из stdint.h, но тем не менее подсвечиваются (правда, по-умолчанию иным цветом, чем ini или const, но это уже не важно).
  19. И шо-таки вы здесь нам так возмущаетесь? Азохен вей, поберегите нервы! Не нравится вопрос - пройдите мимо, интернет большой! > Конкретно для "bool, "false" может быть "others".< Если изменить цвет others, меняется цвет ВСЕГО обычного текста программы: что bool, что false, что A = B; и т.д. и т.п.
  20. Эта опция у меня включена, и всякие там int и const подсвечиваются, как и ранее. bool, true и false по-прежнему как обычный текст. "Проблема" осталась.
  21. Я не считаю, определены ли, я это вижу опытным путем, т.к. я их использую в программе без излишних телодвижений кроме, может быть, #include <stdbool.h>. Однако они не подкрашиваются как другие, а мне бы хотелось. Вот uint8_t, к примеру, подкрашивается, хотя не является встроенным типом, а определен в stdint.h. Касаемо ЦЕЛОЙ красочной темы: я не хочу изгаляться и извращаться. Мне бы только быстро и просто список раскраски дополнить... А файлик киньте, буду благодарен.
  22. Это, конечно, левой ногой с вертушки в глаз тому, кто держит доску. bool, false и true уже определены. Если я их переопределю, начнется ругня.
  23. На такой вопрос от 2008 года я уже набрел на этом форуме, но ответа там не было. Я в ту ветку написал, но последняя запись там - от 2017, потому не бейте ногами, что я замутил эту тему вновь. Вопрос прост: в STM32CubeIDE, которая базируется на eclipse, я хочу конкретно подкрасить bool, false и true (а может и еще что). В отличие от KEIL IDE, где просто надо добавить эти слова в соответствующий список, в eclipse как-то все сложно: поиск google дает какие-то java скрипты, которые не ясно мне, куда писать и как исполнять. Потому вопрос: как добавить свое в список ключевых слов в редакторе, заточенном под C\C++? Если можно, объяснить как для чайников.
  24. Прохожу тот же путь. Скачайте STM32CubeIDE.
  25. Спустя 12 лет от поста меня тоже заинтересовал вопрос, как добавить свое ключевое слово для раскраски. Например, я хочу, чтобы bool, а также false и true подсвечивались другим цветом. Как это сделать в eclipse? Я работаю с STM32CubeIDE. В KEIL все было очень просто, а поиск для eclipse все время выводит на какие-то скрипты, которые я не знаю, куда записать и как исполнить. Подскажете?