STM32 Часть 1: Основы

Нельзя доверять коду, который вы не написали полностью сами. — Кен Томпсон
Пожалуй, моя самая любимая цитата. Именно она и стала причиной по которой я решил нырнуть в самую глубь кроличьей норы. Свой путь в мир программирования я начал совсем недавно, прошло всего около месяца и я решил писать статьи для закрепления материала. Все началось с простой задачи, синхронизировать лампы в своей фото студии с помощью Ардуины. Задача была решена, но в фото студию я больше не заходил, времени нет. С того момента я решил основательно заняться программированием микроконтроллеров. Ардуина, хоть и привлекательна в своей простоте, как платформа мне не понравилась. Выбор пал на компанию ST и их популярную продукцию. В тот момент я еще не представлял в чем особо разница, но как типичный потребитель я сравнил скорость «процессора» и количество памяти, купил себе внушительную плату с дисплеем STM32F746NG — Discovery. Я пропущу моменты отчаяния и сразу перейду к делу.

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

Список всего того что понадобится:

  1. Виртуальная машина Ubuntu 16+ ну или что под рукой есть
  2. arm компилятор — скачать по ссылке developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads
  3. openocd отладчик и программатор — скачивать по ссылке не получится, собираем из исходников, инструкция прилагается

    git clone https://git.code.sf.net/p/openocd/code openocd
  4. Текстовый редактор любой по вкусу

После того как все установили и собрали, можем приступать к первому проекту! И нет, это даже не мигание лампочкой. Для начала мы должны вникнуть в процесс инициализации самого мк.

Что нам понадобится:

  1. Makefile
  2. Linker.ld
  3. Init.c

Начнем с последнего пункта Init.c. Первым делом наш мк должен загрузить адрес «stack pointer» это указатель на адрес памяти который используется для инструкций PUSH и POP. Настоятельно рекомендую досконально изучить эти две инструкции, так как я не буду в деталях объяснять все инструкции. Как это реализовать смотрим ниже

extern void *_estack;
void *vectors[] __attribute__((section(".isr_vector"), used)) = {
    &_estack
}

Теперь разберем данный пример. Extern означает, что символ внешний, и этот символ мы объявили в файле Linker.ld, к нему мы еще вернемся чуть позже.

 __attribute__((section(".isr_vector"), used))

Тут мы используем атрибут, который скажет компилятору поместить массив в секцию isr_vector и что даже если мы не используем его в коде, то он все равно должен быть обязательно включен в программу. И первым его элементом будет тот самый указатель.

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

Приведу пример. дано что стэк начинается с 0x20010000 а код программы находиться 0x0800008. то массив можно написать как

void *vectors[] __attribute__((section(".isr_vector"), used)) = {
    0x20010000,
    0x08000008
}

То есть, первым делом контроллер инициализирует стэк, а потом считает адрес первой инструкции и загрузит ее в регистр программного счетчика. Теперь самое главное, в зависимости от модели эти цифры могу быть разные, но на примере stm32f7 я могу уверенно сказать что этот массив должен быть в памяти по адресу 0x08000000. Именно с этого адреса мк начнет свою работу после включения или ресета.

Теперь прервемся и обратим внимание на то как именно положить этот массив в нужную нам секцию. Этим занимается «ld» или линкер. Это программа собирает всю нашу программу воедино и для этого используется скрипт Linker.ld. Привожу пример и дальше разберем его.

MEMORY{
	ROM_AXIM (rx) : ORIGIN = 0x08000000, LENGTH = 1M
	RAM_DTCM (rwx): ORIGIN = 0x20000000, LENGTH = 64K
}

_estack = LENGTH(RAM_DTCM) + ORIGIN(RAM_DTCM);

SECTIONS{
	.isr_vector : {
	KEEP(*(.isr_vector))
	} >ROM_AXIM</code>
}

Разберемся, что тут происходит. MEMORY определяет секции памяти а SECTIONS определяет секции. тут же мы видим и наш _estack и то что он равен сумме начала памяти и ее длины, то есть конец нашей памяти. Также определена секция .isr_vector в которую мы положили наш массив. >ROM_AXIM в конце нашей секции означает что эта секция должна быть помещена в секцию памяти которая начинается с 0x08000000 как того требовал наш мк.

Мы поместили массив куда надо теперь надо какую нибудь инструкцию нашему мк для работы. Вот дополненный init.c:

extern void *_estack;

void Reset_Handler();

void *vectors[] __attribute__((section(".isr_vector"), used)) = {
    &_estack,
    &Reset_Handler
};

void __attribute__((naked, noreturn)) Reset_Handler()
{
    while(1);
}

Как я уже упомянул ранее, вторым адресом должен быть указатель на первую функцию или инструкцию. И опять атрибуты, но тут все просто, функция не возвращает ни каких значений и следует ни каким ABI при входе, то есть голая «naked». В такие функции обычный пихают ассемблер.

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

arm-none-eabi-gcc -c init.c -o init.o -mthumb

arm-none-eabi-gcc -TLinker.ld -o prog.elf init.o -Wl,--gc-sections -nostartfiles -nodefaultlibs -nostdlib

И тут мы видим много непонятного. по порядку:

  1. -mthumb компилируем для armv7, который использует только thumb инструкции
  2. -TLinker.ld указываем скрипт линкера. по дефолту он скомпилирует для исполнения в среде линукс
  3. -Wl,--gc-sections -nostartfiles -nodefaultlibs -nostdlib убираем все стандартные библиотеки, файлы инициализации среды С и все другие вспомогательные библиотеки типа математики.

Загружать такое в мк конечно толку нет. Зато есть толк в просмотре и изучении бинарника.

objcopy -O ihex prog.elf prog.bin

hexdump prog.bin

И тут мы увидим вывод. «00000000: 00 01 00 02 09 00 00 08» что будет символизировать нам об успехе. Это моя первая статья и я не вполне смог раскрыть весь материал и суть, поэтому в следующей я более подробно опишу механизмы и мы друзья сможем перейти к программе которая не будет мигать лампочкой, но настроим тактирование самого процессора и шин.

Similar posts

AdBlock has stolen the banner, but banners are not teeth — they will be back

More
Ads

Comments 70

    +1
    Если бы все так просто, сам написал и все работает:

    — Ну никому верить нельзя.
    — Что за времена пошли, возмущается мужик, застирывая штаны.
    — Ведь только пукнуть хотел…
    — Никому верить нельзя, даже себе (уже печально)
      0
      Мне кажется было так

      Верить нельзя никому. Даже собственной ж… е. Хотел пе.нуть и обос.ался.
    0
    не будет мигать лампочкой, но выставит скорость процессора


    Может частоту тактирования?
      0
      Так и есть, исправлено
      +9
      >Нельзя доверять коду, который вы не написали полностью сами.
      Осталось немного — написать компилятор. Ах, да, еще ОС, где он будет работать…
        +7
        И процессор самому разработать, а то у всех эрраты по сто страниц.
          +1
          и микрокод, а то там тоже могут быть сюрпризы
            0
            И, разумеется, никакого микрокода. Процессор должен быть RISC, причем максимально дубовый и надёжный.
              0
              6502 уже такой есть)
              0
              Ну можете смеяться, но как раз работаю в компании у которой есть свое ядро, свой микрокод, компилятор и ОС. Разве что своего языка не сделали…
                0
                Я тоже работал в такой компании. Для компании это дело нехитрое, хитрое — это когда такое для хобби)
              0
              ну тут много ума не надо, накатить свою архитектуру можно если есть деньги. Могу точно сказать, если бы у меня были на это деньги этим бы и занялся)
                0
                Винт: чтобы накатить ее на FPGA, даже денег особенно не надо.
                  0
                  Ну нормальный FPGA стоит не мало. а так до циклонов еще не добрался, не настолько я еще умен) надо подучиться, хотел бы графический контроллер делать на FPGA
            +3
            В наше время монструозных IDE и Ардуин (не в обиду его любителям) эта статья прям бальзам на душу) Но, по моему мнению, все же имело смысл коротко объяснить людям про стэк и PUSH/POP, ну или дать линк на толковое описание, а то всякого г… в сети полно.
              0
              я обязательно напишу об этом подробнее, но после работы над ошибками в этой статье)
              +2
              Это все конечно интересно и увлекательно, ковыряться в нутре у процессора, но вы же отдаете себе отчет, что на таком низком уровне вы не использутее и 10-й части потенциала процессора в своих программах — просто жизни не хватит разобраться во всех его модулях и написать все необходимые драйверы. Новичкам такой путь я точно не стану рекомендовать.

              Кстати, говоря о доверии к чужому коду — вы недооцениваете помощь сообщества в выявлении багов. Уверяю, вы наделаете гораздо больше ошибок, чем имеет фреймворк, который используют тысячи пользователей и который развивается не один год.

              Сейчас можно писать сложнейшие программы, вообще не вникая в то, что фреймворк делает на низком уровне, в 99% случаев этого не потребуется. И только когда программа не работает как надо и в своем коде вы уверены — есть смысл поискать ошибку во фреймворке, библиотеке, заглянуть в errata на процессор и в крайнем случае, в компиляторе.
                +2
                Я думаю, что автор не предлагает отказаться от FreRTOS и LwIP например. Скорее он хочет показать как можно писать под МК без зоопарка IDE и огромных библиотек по дерганью пинов. На самом деле в некоторых областях и задачах от МК не требуется решения сверх сложных задач, но необходим 100% прозрачный и предсказуемый код.
                  +2
                  А кто мешает в любом IDE писать на нативном коде?
                  Чем кросскомпилятор в IDE хуже установленного через apt?
                    0
                    Ну было у меня такое, Во общем, скопилировал, запустил отладчик, отладчик говорит что у меня HardFault. Проанализировав ассемблер и все что только можно я пришел к выводу что HardFault у отладчика встроенного. скачал OpenOcd, запустил и все заработало как по маслу. Дубль 2, отказывается не линковать стандартную библиотеку, в наглую сует свой crt.o. И таких неувязок много.
                      +1
                      Компилятор не хуже, но IDE генерят свои коды инициализации, скрипты и т.п. Конечно для начинающего, с одной стороны, проще такой путь, когда думаешь только о своем main.c и больше ни о чем. Но всегда неплохо понимать что творится под капотом, пускай и в общих чертах. Это может оказаться полезным при смене среды разработки когда в новой что-то будет иначе.
                        0
                        Согласен, эти знания лишними не будут, в общих чертах надо иметь представление как организована сборка. По мере усложнения проекта возникают задачи за рамками возможностей IDE, и приходится вручную править шаблонный скрипт линкера и ассемблер инициализации. Но я например первый раз полез в него после 3х лет развития проекта, когда объем кодовой базы уже перевалил за 3Мб :)
                      +1
                      Если посмотреть бэкграунд статьи, то автор только начинает изучать встроенное программирование. Но выбранный им путь довольно странный, аргументация тоже.
                      А задачи, где требуется 100% предсказуемый код, — это все же далеко от DIY. И там готовы оплатить сложность разработки такого кода, но зачем это в хобби, мне не понятно.
                        0
                        у меня много свободного времени )
                          0
                          А Хабр это только для DIY? Извините, был не в курсе)
                        0
                        А зачем нужно использовать весь потенциал? Ну разве что задача очень-очень учебная. F7 — 'это полмега RAM. Вот там, где меньшей памятью не обойтись, его и используют. А где полмега не хватает — там уже H7.

                        Да, чуть обидно, что в процессоре дофига лишней периферии. Но не делать же свой SoC только с тем, что нужно под задачу.
                          0
                          Ну не пол мега, чуть меньше, а так есть QUAD-spi с 256Мб MMIO, еще SDRAM внешний 512Мб вроде.
                            0
                            Я не об этом. Если мы хотим выпустить 100 тысяч устройств — мы оптимизируем цену устройства. Если мы выпускаем 100 устройств — мы оптимизируем цену разработки. То есть берем SoC подороже, но чтобы все, что может пригодится в нём было. И лучше с запасом.

                            Ровно поэтому мы сейчас все делаем на H7. Лишние 10-20 баксов за чип — это меньше, чем 1-2 тысячи баксов за разработку новой платы.
                          0
                          Честно я не призываю к мазохизму, мне просто лень разбираться в IDE и библиотеках HAL. затрачивать энергию на изучение абстрактных методов или же не абстрактных все равно придется, тут кому как удобнее.
                            +1
                            Сейчас можно писать сложнейшие программы, вообще не вникая в то, что фреймворк делает на низком уровне, в 99% случаев этого не потребуется. И только когда программа не работает как надо и в своем коде вы уверены — есть смысл поискать ошибку во фреймворке


                            Но разве не надо понимать как работает фреймворк на том уровне что бы залезть в него да еще и баг найти?
                            +10
                            Нельзя доверять коду, который вы не написали полностью сами.
                            Тому коду, который сам написал, тоже сильно доверять не стоит.
                              0
                              Ну тут тоже правда)
                              +7
                              Поиск по хабру даст нам много статей о том, как устроен ARM Cortex. Один дядька даже на ассемблере его разобрал.
                              Гневный Олег даже про оптимизацию памяти писал. А уж сколько было «стартов на STM32» и «начинаем STM32» не счесть. И, представьте себе, тоже без эклипсов.
                              Замутите-ка в следующей статье что-нибудь оригинальное. Ну, там межпроцессное взаимодействие систем с повышенной надёжностью или программирование двухядерного МК. Ну или портируйте RTEMS на свою плату, что ли.
                                0
                                Ну или портируйте RTEMS на свою плату, что ли.
                                Там уже есть порт для F4. Перенос на F7 займет день с перерывам на чай-печеньки-котиков. Только зачем? Ардуинщикам оно неинтересно, а те, кто ее использует, могут портануть и без статьи
                                  0
                                  я как раз заказал себе плату с двумя A7 от ST буду пробовать. Но думаю там сразу с линукса пойду тут как много ядреность я пока не осилю)
                                  +1

                                  Не очень удачное и очень сложное начало для новичка (стеки, ассемблер, линкеры).
                                  Не раскрыта тема потребностей в таком мощном и дорогом МК (Cortex-M7, а тут вы его собрались использовать для включения лампы?) Есть куда более дешевые и популярные варианты, та же Blue Pill.


                                  -mthumb компилируем для armv7

                                  У STM32F746NG архитектура Cortex-M7.

                                    0
                                    Cortex-M7 имеет архитектуру Armv7E-M, посмотрите вики или сайт ST. Как и М3, не путайте название ядра и понятие архитектуры. П.С.: вроде в опции -mthumb нет смысла, GCC сейчас и так по дефолту генерит код с Thumb2 для armv7, вроде как. Кстати не мешало бы в статье дать краткое упоминание что это такое вообще.
                                      0

                                      Да, вы правы, перепутал.


                                      The Cortex-M0 / M0+ / M1 implement the ARMv6-M architecture,[9] the Cortex-M3 implements the ARMv7-M architecture,[10] and the Cortex-M4 / Cortex-M7 implements the ARMv7E-M architecture.[10]
                                        0
                                        да если указать какой мк типа mcpu=cortex-m7 или указать архитектуру
                                        0
                                        armv7m
                                        0
                                        Ужасненько. Бессодержательно и с ошибками.
                                        Ну и, с чистого лица, когда рисуешь схему и разводишь плату — сам. Иначе статью надо переименовывать, что тут «типа программирование».
                                        Хотя, пока оживляешь железо, тоже откроется много интересного.
                                          0
                                          Спасибо за отзыв, все свои ошибки я учту в следующей статье и постараюсь быть более содержательным.
                                            0
                                            Ну и, с чистого лица, когда рисуешь схему и разводишь плату — сам.
                                            В этом ключе моя статья оказывается комплементарной к этой :)
                                            +1
                                            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, но писал из головы, для примера).
                                              0
                                              Если у вас уже есть система с человеческой системой управления программами — зачем качать что-то по странным ссылкам? apt install gcc-arm-none-eabi binutils-arm-none-eabi

                                              Это не странная ссылка, а сайт производителя.
                                              В пакетах могут быть старые версии, gdb-multiarch, который вы, кстати, забыли, совсем не то же самое что arm-none-eabi-gdb
                                                0
                                                Это не странная ссылка, а сайт производителя.

                                                Любая ссылка для скачивания софта, кроме репозитория — странная ссылка.
                                                В пакетах могут быть старые версии

                                                А есть ли смысл гоняться за забагованными нестабильными версиями? Чего конкретно не хватает в обычных?
                                                gdb-multiarch, который вы, кстати, забыли

                                                Потому что на первых порах он и не нужен. Для отладки более чем достаточно вывода на UART.
                                                  0
                                                  Любая ссылка для скачивания софта, кроме репозитория — странная ссылка.
                                                  Там https, с чего бы ей быть странной? Ну и не весь софт есть в репозиториях. Какой-то нужно патчить и собирать самому.
                                                  А есть ли смысл гоняться за забагованными нестабильными версиями? Чего конкретно не хватает в обычных?
                                                  Arm делает забагованный софт, а Canonical правит баги в GCC и выкладывает кошерные версии? Я вас правильно понял? Release Notes можете сами посмотреть, что там меняется от версии к версии.
                                                  Из последнего, это gdb-multiarch вешал намертво qemu-system-arm с кастомной платформой и RTOS при отладке. Полечилось сменой gdb на «нестабильный забагованный».
                                                  Потому что на первых порах он и не нужен. Для отладки более чем достаточно вывода на UART.
                                                  Не вижу ни одной причины, почему нельзя стразу пользоваться отладчиком вместо печати в консоль. Это стокгольмский синдром от Ардуино?
                                                    0
                                                    Это стокгольмский синдром от Ардуино? на самом деле удобно, Black Magic Probe работает через UART, ну технически через USB но создается виртуальный ком порт. И там целый GDB server с поддержкой многих архитектур. Если интересно, проект открытый и можно свой программатор развести на коленке. github.com/blacksphere/blackmagic/wiki
                                                      0
                                                      Black Magic Probe работает через UART
                                                      Он работает через JTAG\SWD. Соединение до хостовой машины действительно через UART, но это не то, когда пишут «отладка через UART»
                                                        0
                                                        Не ну понятно что здоровый человек использует дебаг порт, я имел в виду что к хосту по UART подключаем. Хотя есть индивиды которые и SWD опустили до «UART дебагера» через SWO.
                                                      0
                                                      Ну и не весь софт есть в репозиториях.
                                                      Про тот, которого нет, понятно. Тут без вариантов.
                                                      Arm делает забагованный софт, а Canonical правит баги в GCC и выкладывает кошерные версии? Я вас правильно понял?
                                                      Нет, неправильно. Я говорю про деление на testing / stable ветки. На свежей обкатывают новый функционал и там всегда куча багов, а стабильную шлифуют для устойчивой работы.
                                                      Не вижу ни одной причины, почему нельзя стразу пользоваться отладчиком вместо печати в консоль.
                                                      Потому что это отдельная консольная программа с неочевидным интерфейсом.
                                                        0
                                                        Я говорю про деление на testing / stable ветки.
                                                        Вы бы все-таки посмотрели что там по ссылке лежит.
                                                        Потому что это отдельная консольная программа с неочевидным интерфейсом.
                                                        Какая религия не позволяет пользоваться современной IDE типа Эклипса, где все настраивается в пару кликов?
                                                          0
                                                          Вы бы все-таки посмотрели что там по ссылке лежит.
                                                          Можете вкратце пересказать, на что обратить там внимание? Надеюсь, не на то, что там есть готовые сборки?
                                                          На счет скачивания «откуда-то по странным ссылкам» я говорил, что в линуксе так не принято. Если программа есть в репозитории, лучше скачать оттуда. Разве что какие-то баги встречаются или важный функционал завезти не успели — тогда имеет смысл рискнуть со сторонними. Но компилятор — не та область, где критично наличие новомодных свистелок.
                                                          Какая религия не позволяет пользоваться современной IDE типа Эклипса, где все настраивается в пару кликов?
                                                          А зачем, если консоль + редактор перекрывают все потребности? Плюс прозрачность всего, что происходит.
                                                          … хотя gdb осваивать когда-нибудь все равно придется…
                                                            0
                                                            Можете вкратце пересказать, на что обратить там внимание? Надеюсь, не на то, что там есть готовые сборки?
                                                            Могу повторить, мне не жалко — Release Notes.
                                                            Это начинает напоминает анекдот:
                                                            -Армяне лучше чем грузины!
                                                            -Чем?
                                                            -Чем грузины!
                                                            Чем старый компилятор лучше нового?
                                                              0
                                                              Тем, что его можно установить одной очевидной командой стандартным способом, я же писал.
                                                              А чем новый лучше старого?
                                                                0
                                                                Не знаю как там принято в линуксе, но весь стэк разработчика собирается из исходников, так как даже openocd лежит в виде исходника, а то что вы скачаете из репозитория уже слишком старое. Nodejs в репозитории 8.0 лежит, стабильный релиз 12+ по странной ссылке. Это так для сравнения. Тот же всеми любимый nginx собирают из исходника с нужными модулями. Теперь про неочевидный интерфейс отладчика. Он очень очевиден. к примеру

                                                                program prog.elf Залили прошивку.
                                                                program prog.elf reset Залили прошивку и ресетнули чип.
                                                                reset halt ресетнули чип и остановили ядро.
                                                                resume Продолжили выполнение кода
                                                                step Тут все очевидно же.
                                                                  0
                                                                  то что вы скачаете из репозитория уже слишком старое.
                                                                  Какая разница насколько оно старое, если оно выполняет свою работу?
                                                                  Какого именно функционала вам не хватает в «старом» компиляторе?
                                                                  так как даже openocd лежит в виде исходника
                                                                  Тот же самый вопрос: зачем он у вас в виде исходника, когда есть уже собранная и упакованная версия?
                                                                  Теперь про неочевидный интерфейс отладчика. Он очень очевиден. к примеру
                                                                  Если его знать — конечно. Тут примерно та же история, что с консолью в целом. Это крайне эффективный и удобный инструмент — но только когда освоишь.
                                                                  а ну еще что то типа можно прочитать любой участок памяти или регистр и статус процессора
                                                                  Угу. А учитывая, что gdb-сервер это все-таки сервер, можно даже по удаленке отлаживаться. Я ж не спорю, что штука полезная. Просто не надо все учить одновременно.
                                                                  0
                                                                  а ну еще что то типа можно прочитать любой участок памяти или регистр и статус процессора
                                                                    0
                                                                    С каких пор tar -xvf -C /pat/to/gcc стал неочевидной командой?

                                                                    Поправили баги, увеличили производительность, добавили предупреждений.
                                                                      0
                                                                      С момента перехода по ссылке на скачивание.
                                                                      Поправили баги, увеличили производительность, добавили предупреждений.
                                                                      Это общие слова. Реально-то разница заметна? Или она в пределах пяти процентов объема генерируемого бинарника?
                                                                          0
                                                                          То есть вместо ответа очередные чужие ссылки. Я так и думал, что в своих проектах вы разницы не увидели. А зачем тогда гоняться за новыми версиями?
                                                                            0
                                                                            Я же вам уже писал, почему сменил toolchain из пакетов на «забагованный». Зачем вы выборочно читаете?
                                                                              0
                                                                              Вы про какую-то версию gdb, которая неправильно работала с какой-то версией qemu на какой-то экзотической RTOS? Вы же не забыли отправить эту багу разработчикам?
                                                                              Или более подробно в ней разобраться, вдруг это какое-то UB в вашем коде?
                                                                              И даже в лучшем случае — какое отношение эта ошибка имеет к статье? Какого преимущества добьется человек, осваивающий контроллеры по мануалу MTX-Legion'а (а такой мануал, кстати, вполне можно рекомендовать — уж точно лучше недо-учебников, сразу начинающих с Куба) если будет использовать странные способы установки программ?
                                                                                0
                                                                                Оно лежит в бэклоге, можете спать спокойно %)
                                                          0
                                                          Привет друг, прочитал твои комментарии, дам ответы тут.
                                                          1. Ссылка («Официалка») дана людям которые решат собрать свой компилятор если надо. там как раз исходники а не только бинарник, вообще GCC можно собрать под что хочешь, так на будущее.

                                                          2. Почему не использовать уже готовый startup.s? Потомучто если открыть startup.s который поставляется с модными IDE то можно удивить что в них много лишнего, скажем так generic. Например инициализация стак поинтра, или же копированием data в рам. Опять таки, надо знать как делать под себя.

                                                          3. Ну и с примером мигания, это еще долеко. мы ведь еще даже не включили самую главную периферию и системные блоки зачем же лезть мигать.

                                                          4. Для отладки более чем достаточно вывода на UART, Ну а как отлаживать UART? с этого и началась моя боль, я наткнулся на то что пришлось отлаживать «отладчик» в IDE.

                                                          5. Опять компилятор, наоборот в каждой версии правят баги. и очень скрупулезно. по той же ссылке можно найти список фиксов в каждой версии, и ссылка на стабильный релиз.
                                                            0
                                                            Ссылка («Официалка») дана людям которые решат собрать свой компилятор если надо. там как раз исходники а не только бинарник
                                                            apt-get source gcc-arm-none-eabi

                                                            … хотя ковырять исходник gcc у меня смелости не хватит…
                                                            Почему не использовать уже готовый startup.s?
                                                            По-моему, логичнее было бы подробно его разобрать, а потом использовать. Просто основная часть там — таблицы прерываний и тому подобное, которое гвоздями прибито к конкретному контроллеру. Не переписывать же с нуля то, что уже есть.
                                                            Собственно, в качестве предложения к вашей следующей статье: вы написали свой startup. Можно сравнить его с «фирменным» и привести к нему. То есть да, мы можем его написать если надо. Но ребята из ST уже проделали ту же работу для сотни камней, давайте ей воспользуемся.
                                                            Ну и с примером мигания, это еще долеко. мы ведь еще даже не включили самую главную периферию и системные блоки зачем же лезть мигать.
                                                            А в F7 нужно еще что-то включать? Я просто только с F103 и L151 работал, там достаточно того кода, что я написал. Ну да, тактирование будет от RC-генератора на какой-то небольшой частоте. Ну да, тайминги подобрали на глазок. Зато хотя бы видно, что камень живой и реагирует на команды. Это потом можно менять системную частоту (и смотреть как меняется частота мигания!).
                                                            Как минимум в качестве видимого результата для повышения мотивации это важно. Не просто «мы написали какой-то код, он работает, верьте мне», а «мы написали какой-то код, он криво, но работает, вот доказательство».
                                                            Для отладки более чем достаточно вывода на UART, Ну а как отлаживать UART?
                                                            Ну не знаю, у меня такой проблемы не было. Но тут не уверен, возможно подсматривал чужие решения, а в рамках вашего подхода это все же читерство :) С другой стороны, не менее познавательно сделать программный UART. Правда, без логического анализатора или осциллографа это будет непросто.
                                                            Опять компилятор, наоборот в каждой версии правят баги. и очень скрупулезно.
                                                            Я пользуюсь Линуксом как основной системой и как-то привык к простым решениям. Зачем лазить по интеренетам в поисках программ и кряков к ним, если можно вбить название всех нужных программ в менеджер пакетов, и он сам быстренько все поставит. Зачем компилировать чужие исходники, когда мейнтейнеры дистрибутива это уже сделали. Более того, они эти исходники адаптировали под свою среду (хотя бы пути прописали).
                                                            Нет, если хочется научиться собирать что-то из исходников, или нашелся какой-то особенно мерзкий баг — это совсем другое дело.
                                                            В общем, как обычно — зависит от цели всего этого. Просто в рамках статьи о разработке под STM32 как-то странно собирать вообще все.
                                                              0
                                                              Ну как я уже выше отписался, тот же openocd собирается из исходника с нужными конфигами. Это очень важный процесс так как «собиратор» проверяет наличие нужных библиотек. Насчет кряков, тут их нет все открытое. Насчет лезть в GCC, собрать свой кросс компилятор все должны уметь. Допустим, при желании этот же компилятор можно и на самом F7 запустить если его скомпилировать для хоста. Делов там на 15 минут и то 90% это сама компиляция, за вас уже все сделали.

                                                              Вообщем собирать из исходника это не 100500 команд а всего 3 но которые дают возможность выбрать нужный билд с определенной конфигурацией. В этом и кроется удобство данного подхода.
                                                                0
                                                                И еще раз спрошу: чего именно вам не хватило в готовой сборке? Это ж не троллинга ради, а вдруг там действительно чего-то не хватает полезного, ради чего стоит собрать.
                                                                Со сборкой для F7: не спорю, когда-нибудь это может пригодиться. Но не в самом же начале, когда человек про регистры-то не знает!
                                                                Поймите правильно: большая часть того, что я сейчас говорю — попытка помочь вам со статьей, а не философские рассуждения «нужно ли это хоть когда-нибудь». И в этом ключе логично идти последовательно, по шагам. Совсем хорошо, когда результат каждого шага виден. Так и тут: мы же с контроллером разобраться пытаемся, а не с программированием и управлением софтом под ПК. Вот и не нужно уделять лишнего внимания малозначимым операциям.
                                                                Стандартным способом установили софт, взяли готовую плату, и (уже развернуто, как положено в статье) пишем код, потом смотрим что получилось
                                                                Потом говорим, что функционала платы нам недостаточно. Скажем, сложно померить потребляемый ток. Чтобы это поправить, просто жизненно необходимо разработать свою плату с нуля, попутно (опять же, развернуто, как положено в статье) разбирая что и для чего делается. А вот используемый софт — только краем, насколько это требуется донесения основной мысли.
                                                                А потом говорим, что неплохо бы сделать переносной стенд для разработки. Давайте подключим SD-карту (кратко, готовыми библиотеками) и будем компилировать с нее исходники. Вот тут подробно и со вкусом бегать по граблям компиляции gcc под arm.
                                                                Но не все в кучу! Если цель статьи рассказать о первой программе для контроллера, совершенно излишне рассказывать об установке самой-самой последней версии компилятора. С поставленной задачей справится любая! Зато меньше будет людей, у которых ваш алгоритм не сработает.

                                                    Only users with full accounts can post comments. Log in, please.