то что вы скачаете из репозитория уже слишком старое.
Какая разница насколько оно старое, если оно выполняет свою работу?
Какого именно функционала вам не хватает в «старом» компиляторе?
так как даже openocd лежит в виде исходника
Тот же самый вопрос: зачем он у вас в виде исходника, когда есть уже собранная и упакованная версия?
Теперь про неочевидный интерфейс отладчика. Он очень очевиден. к примеру
Если его знать — конечно. Тут примерно та же история, что с консолью в целом. Это крайне эффективный и удобный инструмент — но только когда освоишь.
а ну еще что то типа можно прочитать любой участок памяти или регистр и статус процессора
Угу. А учитывая, что gdb-сервер это все-таки сервер, можно даже по удаленке отлаживаться. Я ж не спорю, что штука полезная. Просто не надо все учить одновременно.
Вы бы все-таки посмотрели что там по ссылке лежит.
Можете вкратце пересказать, на что обратить там внимание? Надеюсь, не на то, что там есть готовые сборки?
На счет скачивания «откуда-то по странным ссылкам» я говорил, что в линуксе так не принято. Если программа есть в репозитории, лучше скачать оттуда. Разве что какие-то баги встречаются или важный функционал завезти не успели — тогда имеет смысл рискнуть со сторонними. Но компилятор — не та область, где критично наличие новомодных свистелок.
Какая религия не позволяет пользоваться современной IDE типа Эклипса, где все настраивается в пару кликов?
А зачем, если консоль + редактор перекрывают все потребности? Плюс прозрачность всего, что происходит.
… хотя gdb осваивать когда-нибудь все равно придется…
Ссылка («Официалка») дана людям которые решат собрать свой компилятор если надо. там как раз исходники а не только бинарник
apt-get source gcc-arm-none-eabi
… хотя ковырять исходник gcc у меня смелости не хватит…
Почему не использовать уже готовый startup.s?
По-моему, логичнее было бы подробно его разобрать, а потом использовать. Просто основная часть там — таблицы прерываний и тому подобное, которое гвоздями прибито к конкретному контроллеру. Не переписывать же с нуля то, что уже есть.
Собственно, в качестве предложения к вашей следующей статье: вы написали свой startup. Можно сравнить его с «фирменным» и привести к нему. То есть да, мы можем его написать если надо. Но ребята из ST уже проделали ту же работу для сотни камней, давайте ей воспользуемся.
Ну и с примером мигания, это еще долеко. мы ведь еще даже не включили самую главную периферию и системные блоки зачем же лезть мигать.
А в F7 нужно еще что-то включать? Я просто только с F103 и L151 работал, там достаточно того кода, что я написал. Ну да, тактирование будет от RC-генератора на какой-то небольшой частоте. Ну да, тайминги подобрали на глазок. Зато хотя бы видно, что камень живой и реагирует на команды. Это потом можно менять системную частоту (и смотреть как меняется частота мигания!).
Как минимум в качестве видимого результата для повышения мотивации это важно. Не просто «мы написали какой-то код, он работает, верьте мне», а «мы написали какой-то код, он криво, но работает, вот доказательство».
Для отладки более чем достаточно вывода на UART, Ну а как отлаживать UART?
Ну не знаю, у меня такой проблемы не было. Но тут не уверен, возможно подсматривал чужие решения, а в рамках вашего подхода это все же читерство :) С другой стороны, не менее познавательно сделать программный UART. Правда, без логического анализатора или осциллографа это будет непросто.
Опять компилятор, наоборот в каждой версии правят баги. и очень скрупулезно.
Я пользуюсь Линуксом как основной системой и как-то привык к простым решениям. Зачем лазить по интеренетам в поисках программ и кряков к ним, если можно вбить название всех нужных программ в менеджер пакетов, и он сам быстренько все поставит. Зачем компилировать чужие исходники, когда мейнтейнеры дистрибутива это уже сделали. Более того, они эти исходники адаптировали под свою среду (хотя бы пути прописали).
Нет, если хочется научиться собирать что-то из исходников, или нашелся какой-то особенно мерзкий баг — это совсем другое дело.
В общем, как обычно — зависит от цели всего этого. Просто в рамках статьи о разработке под STM32 как-то странно собирать вообще все.
Про тот, которого нет, понятно. Тут без вариантов.
Arm делает забагованный софт, а Canonical правит баги в GCC и выкладывает кошерные версии? Я вас правильно понял?
Нет, неправильно. Я говорю про деление на testing / stable ветки. На свежей обкатывают новый функционал и там всегда куча багов, а стабильную шлифуют для устойчивой работы.
Не вижу ни одной причины, почему нельзя стразу пользоваться отладчиком вместо печати в консоль.
Потому что это отдельная консольная программа с неочевидным интерфейсом.
1. Виртуальная машина Ubuntu
2. arm компилятор — скачать по ссылке
Если у вас уже есть система с человеческой системой управления программами — зачем качать что-то по странным ссылкам? apt install gcc-arm-none-eabi binutils-arm-none-eabi
указатель на адрес памяти который используется для инструкций PUSH и POP. Настоятельно рекомендую досконально изучить эти две инструкции, так как я не буду в деталях объяснять все инструкции.
Согласен, что рассказывать в данной статье про устройство стека неуместно. Но не лишним было бы привести ссылку на другие источники информации. Справедливости ради, мне бы самому стоило привести эту ссылку здесь, но искать лень
Ардуина, хоть и привлекательна в своей простоте, как платформа мне не понравилась. Выбор пал на компанию ST и их популярную продукцию.
Не самое удачное решение. Лучше было начать с той же AVR (не Ардуины!), просто потому что само ядро куда проще. А уже зная особенности работы с контроллерами, адаптировать эти знания под ARM. Впрочем, и так результат весьма неплохой!
init.c:
А чего не воспользовались готовыми startup.s и заголовочными файлами? Все равно их содержимое — перечисление периферии и возможностей камня, собственно кода там считай нет. Не прописывать же адреса регистров и флагов вручную!
Загружать такое в мк конечно толку нет. Зато есть толк в просмотре и изучении бинарника.
Ну вот, на самом интересном месте! Мигание лампочкой как раз стоило бы добавить. Хотя бы чтобы показать, что все описанные трудности были не напрасны, вот он готовый HelloWorld. Тут можно даже оставить тактирвоание по умолчанию, не рассматривать тонкости настройки портов и т.д. Просто:
RCC->AHBENR |= RCC_AHBENR_GPIOBEN;
GPIOB->MODER = (0b01 << 2*8);
//GPIOB->OSPEEDR - на единицах герц можно оставить дефолтное значение
while(1){
GPIOB->ODR ^= (1<<8); //в рабочем коде так делать не стоит, но для тестов сойдет.
volatile uint32_t i; //чтобы компилятор не "оптимизировал" пустой цикл
for(i=0; i<100000; i++){} //точное число итераций подобрать экспериментально - для тестов сойдет
}
(это для STM32L151, но писал из головы, для примера).
Интересно, как такая штука будет реагировать на повреждения… Я так понимаю, ее хотят со временем перенести на лобовое стекло, а туда летит всякий мусор.
Да и от сбоев электроники никто не застрахован. Или, скажем, кончилось время аренды — затемняем переднее стекло полностью.
Это на работу машины могло не хватить, а на звонок хватит с запасом.
Непонятна фраза про «112 на максимальной мощности»: если проблемы с сетью, то телефон и все остальные будет на максимальной мощности пробовать.
А внутри модуля нет смысла от длинных переменных. Его можно достаточно легко охватить взглядом или памятью.
Ну и в любом случае, не так много ситуаций, когда у одного явления несколько равноправных имен.
Согласен, но нужно это только при стыковке разных модулей. Скажем, при передаче в функцию, ну или иногда в глобальных переменных. Внутри блока хватит комментария, что, мол, все переменные напряжения считаются амплитудными.
Но они будут внутри процедуры, то есть наружу будут торчать только «единицы по умолчанию». А внутри процедуры на десяток строк можно и попроще переменные назвать.
По картинке похоже что за вертикальное перемещение лапы отвечает 2 моторчика, получается 2*6 = 12, а не 18. Ну и если для простого удержания веса модели нужна полная мощность всех 6 ног, как он двигаться-то будет? Сколько помню, простейший алгоритм движения — поочередное перемещение двух троек ног, значит нагрузка еще вдвое меньше.
Если под kvU имеется в виду напряжение в киловольтах, то так делать без особой нужды (экономии скорости или памяти там) не стоит. Лучше использовать все единицы в системе Си, без дробных и кратных. И с формулами не напортачишь, и разбираться в каких же единицах оно хранится в файле не придется. Ну и что если одно число будет, скажем, 6.8e-11 Ф, а второе 1.2e+7 Гц. Потери точности при перемножении чисел с плавающей точкой не выше, чем с фиксированной, а складывать их все равно не имеет физического смысла.
Но когда использование float обходится слишком дорого, можно и указывать размерность в имени макроконстанты, которую потом переводить во внутреннее представление с самыми странными коэффициентами:
Вы так говорите «трансформатор постоянного тока» как будто такие вообще бывают. Трансформатор (в электронике или электротехнике) это несколько обмоток на общем сердечнике, он по определению работает только с переменным током. Если же говорить о преобразователях постоянного тока, так это довольно сложная конструкция, которая вполне может содержать трансформатор.
Ну и хранить амплитудное значение отдельно от действующего… а зачем? Они же пропорциональны.
Какого именно функционала вам не хватает в «старом» компиляторе?
Тот же самый вопрос: зачем он у вас в виде исходника, когда есть уже собранная и упакованная версия?
Если его знать — конечно. Тут примерно та же история, что с консолью в целом. Это крайне эффективный и удобный инструмент — но только когда освоишь.
Угу. А учитывая, что gdb-сервер это все-таки сервер, можно даже по удаленке отлаживаться. Я ж не спорю, что штука полезная. Просто не надо все учить одновременно.
А чем новый лучше старого?
На счет скачивания «откуда-то по странным ссылкам» я говорил, что в линуксе так не принято. Если программа есть в репозитории, лучше скачать оттуда. Разве что какие-то баги встречаются или важный функционал завезти не успели — тогда имеет смысл рискнуть со сторонними. Но компилятор — не та область, где критично наличие новомодных свистелок.
А зачем, если консоль + редактор перекрывают все потребности? Плюс прозрачность всего, что происходит.
… хотя gdb осваивать когда-нибудь все равно придется…
… хотя ковырять исходник gcc у меня смелости не хватит…
По-моему, логичнее было бы подробно его разобрать, а потом использовать. Просто основная часть там — таблицы прерываний и тому подобное, которое гвоздями прибито к конкретному контроллеру. Не переписывать же с нуля то, что уже есть.
Собственно, в качестве предложения к вашей следующей статье: вы написали свой startup. Можно сравнить его с «фирменным» и привести к нему. То есть да, мы можем его написать если надо. Но ребята из ST уже проделали ту же работу для сотни камней, давайте ей воспользуемся.
А в F7 нужно еще что-то включать? Я просто только с F103 и L151 работал, там достаточно того кода, что я написал. Ну да, тактирование будет от RC-генератора на какой-то небольшой частоте. Ну да, тайминги подобрали на глазок. Зато хотя бы видно, что камень живой и реагирует на команды. Это потом можно менять системную частоту (и смотреть как меняется частота мигания!).
Как минимум в качестве видимого результата для повышения мотивации это важно. Не просто «мы написали какой-то код, он работает, верьте мне», а «мы написали какой-то код, он криво, но работает, вот доказательство».
Ну не знаю, у меня такой проблемы не было. Но тут не уверен, возможно подсматривал чужие решения, а в рамках вашего подхода это все же читерство :) С другой стороны, не менее познавательно сделать программный UART. Правда, без логического анализатора или осциллографа это будет непросто.
Я пользуюсь Линуксом как основной системой и как-то привык к простым решениям. Зачем лазить по интеренетам в поисках программ и кряков к ним, если можно вбить название всех нужных программ в менеджер пакетов, и он сам быстренько все поставит. Зачем компилировать чужие исходники, когда мейнтейнеры дистрибутива это уже сделали. Более того, они эти исходники адаптировали под свою среду (хотя бы пути прописали).
Нет, если хочется научиться собирать что-то из исходников, или нашелся какой-то особенно мерзкий баг — это совсем другое дело.
В общем, как обычно — зависит от цели всего этого. Просто в рамках статьи о разработке под STM32 как-то странно собирать вообще все.
Нет, неправильно. Я говорю про деление на testing / stable ветки. На свежей обкатывают новый функционал и там всегда куча багов, а стабильную шлифуют для устойчивой работы.
Потому что это отдельная консольная программа с неочевидным интерфейсом.
Любая ссылка для скачивания софта, кроме репозитория — странная ссылка.
А есть ли смысл гоняться за забагованными нестабильными версиями? Чего конкретно не хватает в обычных?
Потому что на первых порах он и не нужен. Для отладки более чем достаточно вывода на UART.
Если у вас уже есть система с человеческой системой управления программами — зачем качать что-то по странным ссылкам? apt install gcc-arm-none-eabi binutils-arm-none-eabi
Согласен, что рассказывать в данной статье про устройство стека неуместно. Но не лишним было бы привести ссылку на другие источники информации. Справедливости ради, мне бы самому стоило привести эту ссылку здесь, но искать лень
Не самое удачное решение. Лучше было начать с той же AVR (не Ардуины!), просто потому что само ядро куда проще. А уже зная особенности работы с контроллерами, адаптировать эти знания под ARM. Впрочем, и так результат весьма неплохой!
А чего не воспользовались готовыми startup.s и заголовочными файлами? Все равно их содержимое — перечисление периферии и возможностей камня, собственно кода там считай нет. Не прописывать же адреса регистров и флагов вручную!
Ну вот, на самом интересном месте! Мигание лампочкой как раз стоило бы добавить. Хотя бы чтобы показать, что все описанные трудности были не напрасны, вот он готовый HelloWorld. Тут можно даже оставить тактирвоание по умолчанию, не рассматривать тонкости настройки портов и т.д. Просто:
(это для STM32L151, но писал из головы, для примера).
Да и от сбоев электроники никто не застрахован. Или, скажем, кончилось время аренды — затемняем переднее стекло полностью.
Непонятна фраза про «112 на максимальной мощности»: если проблемы с сетью, то телефон и все остальные будет на максимальной мощности пробовать.
Ну и в любом случае, не так много ситуаций, когда у одного явления несколько равноправных имен.
Но когда использование float обходится слишком дорого, можно и указывать размерность в имени макроконстанты, которую потом переводить во внутреннее представление с самыми странными коэффициентами:
Ну и хранить амплитудное значение отдельно от действующего… а зачем? Они же пропорциональны.