Комментарии 70
Если бы все так просто, сам написал и все работает:
— Ну никому верить нельзя.
— Что за времена пошли, возмущается мужик, застирывая штаны.
— Ведь только пукнуть хотел…
— Никому верить нельзя, даже себе (уже печально)
— Ну никому верить нельзя.
— Что за времена пошли, возмущается мужик, застирывая штаны.
— Ведь только пукнуть хотел…
— Никому верить нельзя, даже себе (уже печально)
не будет мигать лампочкой, но выставит скорость процессора
Может частоту тактирования?
>Нельзя доверять коду, который вы не написали полностью сами.
Осталось немного — написать компилятор. Ах, да, еще ОС, где он будет работать…
Осталось немного — написать компилятор. Ах, да, еще ОС, где он будет работать…
И процессор самому разработать, а то у всех эрраты по сто страниц.
и микрокод, а то там тоже могут быть сюрпризы
ну тут много ума не надо, накатить свою архитектуру можно если есть деньги. Могу точно сказать, если бы у меня были на это деньги этим бы и занялся)
В наше время монструозных IDE и Ардуин (не в обиду его любителям) эта статья прям бальзам на душу) Но, по моему мнению, все же имело смысл коротко объяснить людям про стэк и PUSH/POP, ну или дать линк на толковое описание, а то всякого г… в сети полно.
Это все конечно интересно и увлекательно, ковыряться в нутре у процессора, но вы же отдаете себе отчет, что на таком низком уровне вы не использутее и 10-й части потенциала процессора в своих программах — просто жизни не хватит разобраться во всех его модулях и написать все необходимые драйверы. Новичкам такой путь я точно не стану рекомендовать.
Кстати, говоря о доверии к чужому коду — вы недооцениваете помощь сообщества в выявлении багов. Уверяю, вы наделаете гораздо больше ошибок, чем имеет фреймворк, который используют тысячи пользователей и который развивается не один год.
Сейчас можно писать сложнейшие программы, вообще не вникая в то, что фреймворк делает на низком уровне, в 99% случаев этого не потребуется. И только когда программа не работает как надо и в своем коде вы уверены — есть смысл поискать ошибку во фреймворке, библиотеке, заглянуть в errata на процессор и в крайнем случае, в компиляторе.
Кстати, говоря о доверии к чужому коду — вы недооцениваете помощь сообщества в выявлении багов. Уверяю, вы наделаете гораздо больше ошибок, чем имеет фреймворк, который используют тысячи пользователей и который развивается не один год.
Сейчас можно писать сложнейшие программы, вообще не вникая в то, что фреймворк делает на низком уровне, в 99% случаев этого не потребуется. И только когда программа не работает как надо и в своем коде вы уверены — есть смысл поискать ошибку во фреймворке, библиотеке, заглянуть в errata на процессор и в крайнем случае, в компиляторе.
Я думаю, что автор не предлагает отказаться от FreRTOS и LwIP например. Скорее он хочет показать как можно писать под МК без зоопарка IDE и огромных библиотек по дерганью пинов. На самом деле в некоторых областях и задачах от МК не требуется решения сверх сложных задач, но необходим 100% прозрачный и предсказуемый код.
А кто мешает в любом IDE писать на нативном коде?
Чем кросскомпилятор в IDE хуже установленного через apt?
Чем кросскомпилятор в IDE хуже установленного через apt?
Ну было у меня такое, Во общем, скопилировал, запустил отладчик, отладчик говорит что у меня HardFault. Проанализировав ассемблер и все что только можно я пришел к выводу что HardFault у отладчика встроенного. скачал OpenOcd, запустил и все заработало как по маслу. Дубль 2, отказывается не линковать стандартную библиотеку, в наглую сует свой crt.o. И таких неувязок много.
Компилятор не хуже, но IDE генерят свои коды инициализации, скрипты и т.п. Конечно для начинающего, с одной стороны, проще такой путь, когда думаешь только о своем main.c и больше ни о чем. Но всегда неплохо понимать что творится под капотом, пускай и в общих чертах. Это может оказаться полезным при смене среды разработки когда в новой что-то будет иначе.
Согласен, эти знания лишними не будут, в общих чертах надо иметь представление как организована сборка. По мере усложнения проекта возникают задачи за рамками возможностей IDE, и приходится вручную править шаблонный скрипт линкера и ассемблер инициализации. Но я например первый раз полез в него после 3х лет развития проекта, когда объем кодовой базы уже перевалил за 3Мб :)
Если посмотреть бэкграунд статьи, то автор только начинает изучать встроенное программирование. Но выбранный им путь довольно странный, аргументация тоже.
А задачи, где требуется 100% предсказуемый код, — это все же далеко от DIY. И там готовы оплатить сложность разработки такого кода, но зачем это в хобби, мне не понятно.
А задачи, где требуется 100% предсказуемый код, — это все же далеко от DIY. И там готовы оплатить сложность разработки такого кода, но зачем это в хобби, мне не понятно.
А зачем нужно использовать весь потенциал? Ну разве что задача очень-очень учебная. F7 — 'это полмега RAM. Вот там, где меньшей памятью не обойтись, его и используют. А где полмега не хватает — там уже H7.
Да, чуть обидно, что в процессоре дофига лишней периферии. Но не делать же свой SoC только с тем, что нужно под задачу.
Да, чуть обидно, что в процессоре дофига лишней периферии. Но не делать же свой SoC только с тем, что нужно под задачу.
Ну не пол мега, чуть меньше, а так есть QUAD-spi с 256Мб MMIO, еще SDRAM внешний 512Мб вроде.
Я не об этом. Если мы хотим выпустить 100 тысяч устройств — мы оптимизируем цену устройства. Если мы выпускаем 100 устройств — мы оптимизируем цену разработки. То есть берем SoC подороже, но чтобы все, что может пригодится в нём было. И лучше с запасом.
Ровно поэтому мы сейчас все делаем на H7. Лишние 10-20 баксов за чип — это меньше, чем 1-2 тысячи баксов за разработку новой платы.
Ровно поэтому мы сейчас все делаем на H7. Лишние 10-20 баксов за чип — это меньше, чем 1-2 тысячи баксов за разработку новой платы.
Честно я не призываю к мазохизму, мне просто лень разбираться в IDE и библиотеках HAL. затрачивать энергию на изучение абстрактных методов или же не абстрактных все равно придется, тут кому как удобнее.
Сейчас можно писать сложнейшие программы, вообще не вникая в то, что фреймворк делает на низком уровне, в 99% случаев этого не потребуется. И только когда программа не работает как надо и в своем коде вы уверены — есть смысл поискать ошибку во фреймворке
Но разве не надо понимать как работает фреймворк на том уровне что бы залезть в него да еще и баг найти?
Нельзя доверять коду, который вы не написали полностью сами.
Тому коду, который сам написал, тоже сильно доверять не стоит.
Поиск по хабру даст нам много статей о том, как устроен ARM Cortex. Один дядька даже на ассемблере его разобрал.
Гневный Олег даже про оптимизацию памяти писал. А уж сколько было «стартов на STM32» и «начинаем STM32» не счесть. И, представьте себе, тоже без эклипсов.
Замутите-ка в следующей статье что-нибудь оригинальное. Ну, там межпроцессное взаимодействие систем с повышенной надёжностью или программирование двухядерного МК. Ну или портируйте RTEMS на свою плату, что ли.
Гневный Олег даже про оптимизацию памяти писал. А уж сколько было «стартов на STM32» и «начинаем STM32» не счесть. И, представьте себе, тоже без эклипсов.
Замутите-ка в следующей статье что-нибудь оригинальное. Ну, там межпроцессное взаимодействие систем с повышенной надёжностью или программирование двухядерного МК. Ну или портируйте RTEMS на свою плату, что ли.
Ну или портируйте RTEMS на свою плату, что ли.Там уже есть порт для F4. Перенос на F7 займет день с перерывам на чай-печеньки-котиков. Только зачем? Ардуинщикам оно неинтересно, а те, кто ее использует, могут портануть и без статьи
я как раз заказал себе плату с двумя A7 от ST буду пробовать. Но думаю там сразу с линукса пойду тут как много ядреность я пока не осилю)
Не очень удачное и очень сложное начало для новичка (стеки, ассемблер, линкеры).
Не раскрыта тема потребностей в таком мощном и дорогом МК (Cortex-M7, а тут вы его собрались использовать для включения лампы?) Есть куда более дешевые и популярные варианты, та же Blue Pill.
-mthumb компилируем для armv7
У STM32F746NG архитектура Cortex-M7.
Cortex-M7 имеет архитектуру Armv7E-M, посмотрите вики или сайт ST. Как и М3, не путайте название ядра и понятие архитектуры. П.С.: вроде в опции -mthumb нет смысла, GCC сейчас и так по дефолту генерит код с Thumb2 для armv7, вроде как. Кстати не мешало бы в статье дать краткое упоминание что это такое вообще.
armv7m
Ужасненько. Бессодержательно и с ошибками.
Ну и, с чистого лица, когда рисуешь схему и разводишь плату — сам. Иначе статью надо переименовывать, что тут «типа программирование».
Хотя, пока оживляешь железо, тоже откроется много интересного.
Ну и, с чистого лица, когда рисуешь схему и разводишь плату — сам. Иначе статью надо переименовывать, что тут «типа программирование».
Хотя, пока оживляешь железо, тоже откроется много интересного.
Спасибо за отзыв, все свои ошибки я учту в следующей статье и постараюсь быть более содержательным.
Ну и, с чистого лица, когда рисуешь схему и разводишь плату — сам.В этом ключе моя статья оказывается комплементарной к этой :)
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, но писал из головы, для примера).
Если у вас уже есть система с человеческой системой управления программами — зачем качать что-то по странным ссылкам? apt install gcc-arm-none-eabi binutils-arm-none-eabi
Это не странная ссылка, а сайт производителя.
В пакетах могут быть старые версии, gdb-multiarch, который вы, кстати, забыли, совсем не то же самое что arm-none-eabi-gdb
Это не странная ссылка, а сайт производителя.
Любая ссылка для скачивания софта, кроме репозитория — странная ссылка.
В пакетах могут быть старые версии
А есть ли смысл гоняться за забагованными нестабильными версиями? Чего конкретно не хватает в обычных?
gdb-multiarch, который вы, кстати, забыли
Потому что на первых порах он и не нужен. Для отладки более чем достаточно вывода на UART.
Любая ссылка для скачивания софта, кроме репозитория — странная ссылка.Там https, с чего бы ей быть странной? Ну и не весь софт есть в репозиториях. Какой-то нужно патчить и собирать самому.
А есть ли смысл гоняться за забагованными нестабильными версиями? Чего конкретно не хватает в обычных?Arm делает забагованный софт, а Canonical правит баги в GCC и выкладывает кошерные версии? Я вас правильно понял? Release Notes можете сами посмотреть, что там меняется от версии к версии.
Из последнего, это gdb-multiarch вешал намертво qemu-system-arm с кастомной платформой и RTOS при отладке. Полечилось сменой gdb на «нестабильный забагованный».
Потому что на первых порах он и не нужен. Для отладки более чем достаточно вывода на UART.Не вижу ни одной причины, почему нельзя стразу пользоваться отладчиком вместо печати в консоль. Это стокгольмский синдром от Ардуино?
Это стокгольмский синдром от Ардуино? на самом деле удобно, Black Magic Probe работает через UART, ну технически через USB но создается виртуальный ком порт. И там целый GDB server с поддержкой многих архитектур. Если интересно, проект открытый и можно свой программатор развести на коленке. github.com/blacksphere/blackmagic/wiki
Ну и не весь софт есть в репозиториях.Про тот, которого нет, понятно. Тут без вариантов.
Arm делает забагованный софт, а Canonical правит баги в GCC и выкладывает кошерные версии? Я вас правильно понял?Нет, неправильно. Я говорю про деление на testing / stable ветки. На свежей обкатывают новый функционал и там всегда куча багов, а стабильную шлифуют для устойчивой работы.
Не вижу ни одной причины, почему нельзя стразу пользоваться отладчиком вместо печати в консоль.Потому что это отдельная консольная программа с неочевидным интерфейсом.
Я говорю про деление на testing / stable ветки.Вы бы все-таки посмотрели что там по ссылке лежит.
Потому что это отдельная консольная программа с неочевидным интерфейсом.Какая религия не позволяет пользоваться современной IDE типа Эклипса, где все настраивается в пару кликов?
Вы бы все-таки посмотрели что там по ссылке лежит.Можете вкратце пересказать, на что обратить там внимание? Надеюсь, не на то, что там есть готовые сборки?
На счет скачивания «откуда-то по странным ссылкам» я говорил, что в линуксе так не принято. Если программа есть в репозитории, лучше скачать оттуда. Разве что какие-то баги встречаются или важный функционал завезти не успели — тогда имеет смысл рискнуть со сторонними. Но компилятор — не та область, где критично наличие новомодных свистелок.
Какая религия не позволяет пользоваться современной IDE типа Эклипса, где все настраивается в пару кликов?А зачем, если консоль + редактор перекрывают все потребности? Плюс прозрачность всего, что происходит.
… хотя gdb осваивать когда-нибудь все равно придется…
Можете вкратце пересказать, на что обратить там внимание? Надеюсь, не на то, что там есть готовые сборки?Могу повторить, мне не жалко — Release Notes.
Это начинает напоминает анекдот:
-Армяне лучше чем грузины!
-Чем?
-Чем грузины!
Чем старый компилятор лучше нового?
Тем, что его можно установить одной очевидной командой стандартным способом, я же писал.
А чем новый лучше старого?
А чем новый лучше старого?
Не знаю как там принято в линуксе, но весь стэк разработчика собирается из исходников, так как даже openocd лежит в виде исходника, а то что вы скачаете из репозитория уже слишком старое. Nodejs в репозитории 8.0 лежит, стабильный релиз 12+ по странной ссылке. Это так для сравнения. Тот же всеми любимый nginx собирают из исходника с нужными модулями. Теперь про неочевидный интерфейс отладчика. Он очень очевиден. к примеру
program prog.elf Залили прошивку.program prog.elf reset Залили прошивку и ресетнули чип.reset halt ресетнули чип и остановили ядро.resume Продолжили выполнение кодаstep Тут все очевидно же.то что вы скачаете из репозитория уже слишком старое.Какая разница насколько оно старое, если оно выполняет свою работу?
Какого именно функционала вам не хватает в «старом» компиляторе?
так как даже openocd лежит в виде исходникаТот же самый вопрос: зачем он у вас в виде исходника, когда есть уже собранная и упакованная версия?
Теперь про неочевидный интерфейс отладчика. Он очень очевиден. к примеруЕсли его знать — конечно. Тут примерно та же история, что с консолью в целом. Это крайне эффективный и удобный инструмент — но только когда освоишь.
а ну еще что то типа можно прочитать любой участок памяти или регистр и статус процессораУгу. А учитывая, что gdb-сервер это все-таки сервер, можно даже по удаленке отлаживаться. Я ж не спорю, что штука полезная. Просто не надо все учить одновременно.
а ну еще что то типа можно прочитать любой участок памяти или регистр и статус процессора
С каких пор tar -xvf -C /pat/to/gcc стал неочевидной командой?
Поправили баги, увеличили производительность, добавили предупреждений.
Поправили баги, увеличили производительность, добавили предупреждений.
С момента перехода по ссылке на скачивание.
Поправили баги, увеличили производительность, добавили предупреждений.Это общие слова. Реально-то разница заметна? Или она в пределах пяти процентов объема генерируемого бинарника?
То есть вместо ответа очередные чужие ссылки. Я так и думал, что в своих проектах вы разницы не увидели. А зачем тогда гоняться за новыми версиями?
Я же вам уже писал, почему сменил toolchain из пакетов на «забагованный». Зачем вы выборочно читаете?
Вы про какую-то версию gdb, которая неправильно работала с какой-то версией qemu на какой-то экзотической RTOS? Вы же не забыли отправить эту багу разработчикам?
Или более подробно в ней разобраться, вдруг это какое-то UB в вашем коде?
И даже в лучшем случае — какое отношение эта ошибка имеет к статье? Какого преимущества добьется человек, осваивающий контроллеры по мануалу MTX-Legion'а (а такой мануал, кстати, вполне можно рекомендовать — уж точно лучше недо-учебников, сразу начинающих с Куба) если будет использовать странные способы установки программ?
Или более подробно в ней разобраться, вдруг это какое-то UB в вашем коде?
И даже в лучшем случае — какое отношение эта ошибка имеет к статье? Какого преимущества добьется человек, осваивающий контроллеры по мануалу MTX-Legion'а (а такой мануал, кстати, вполне можно рекомендовать — уж точно лучше недо-учебников, сразу начинающих с Куба) если будет использовать странные способы установки программ?
Привет друг, прочитал твои комментарии, дам ответы тут.
1. Ссылка («Официалка») дана людям которые решат собрать свой компилятор если надо. там как раз исходники а не только бинарник, вообще GCC можно собрать под что хочешь, так на будущее.
2. Почему не использовать уже готовый startup.s? Потомучто если открыть startup.s который поставляется с модными IDE то можно удивить что в них много лишнего, скажем так generic. Например инициализация стак поинтра, или же копированием data в рам. Опять таки, надо знать как делать под себя.
3. Ну и с примером мигания, это еще долеко. мы ведь еще даже не включили самую главную периферию и системные блоки зачем же лезть мигать.
4. Для отладки более чем достаточно вывода на UART, Ну а как отлаживать UART? с этого и началась моя боль, я наткнулся на то что пришлось отлаживать «отладчик» в IDE.
5. Опять компилятор, наоборот в каждой версии правят баги. и очень скрупулезно. по той же ссылке можно найти список фиксов в каждой версии, и ссылка на стабильный релиз.
1. Ссылка («Официалка») дана людям которые решат собрать свой компилятор если надо. там как раз исходники а не только бинарник, вообще GCC можно собрать под что хочешь, так на будущее.
2. Почему не использовать уже готовый startup.s? Потомучто если открыть startup.s который поставляется с модными IDE то можно удивить что в них много лишнего, скажем так generic. Например инициализация стак поинтра, или же копированием data в рам. Опять таки, надо знать как делать под себя.
3. Ну и с примером мигания, это еще долеко. мы ведь еще даже не включили самую главную периферию и системные блоки зачем же лезть мигать.
4. Для отладки более чем достаточно вывода на UART, Ну а как отлаживать UART? с этого и началась моя боль, я наткнулся на то что пришлось отлаживать «отладчик» в IDE.
5. Опять компилятор, наоборот в каждой версии правят баги. и очень скрупулезно. по той же ссылке можно найти список фиксов в каждой версии, и ссылка на стабильный релиз.
Ссылка («Официалка») дана людям которые решат собрать свой компилятор если надо. там как раз исходники а не только бинарник
apt-get source gcc-arm-none-eabi… хотя ковырять исходник gcc у меня смелости не хватит…
Почему не использовать уже готовый startup.s?По-моему, логичнее было бы подробно его разобрать, а потом использовать. Просто основная часть там — таблицы прерываний и тому подобное, которое гвоздями прибито к конкретному контроллеру. Не переписывать же с нуля то, что уже есть.
Собственно, в качестве предложения к вашей следующей статье: вы написали свой startup. Можно сравнить его с «фирменным» и привести к нему. То есть да, мы можем его написать если надо. Но ребята из ST уже проделали ту же работу для сотни камней, давайте ей воспользуемся.
Ну и с примером мигания, это еще долеко. мы ведь еще даже не включили самую главную периферию и системные блоки зачем же лезть мигать.А в F7 нужно еще что-то включать? Я просто только с F103 и L151 работал, там достаточно того кода, что я написал. Ну да, тактирование будет от RC-генератора на какой-то небольшой частоте. Ну да, тайминги подобрали на глазок. Зато хотя бы видно, что камень живой и реагирует на команды. Это потом можно менять системную частоту (и смотреть как меняется частота мигания!).
Как минимум в качестве видимого результата для повышения мотивации это важно. Не просто «мы написали какой-то код, он работает, верьте мне», а «мы написали какой-то код, он криво, но работает, вот доказательство».
Для отладки более чем достаточно вывода на UART, Ну а как отлаживать UART?Ну не знаю, у меня такой проблемы не было. Но тут не уверен, возможно подсматривал чужие решения, а в рамках вашего подхода это все же читерство :) С другой стороны, не менее познавательно сделать программный UART. Правда, без логического анализатора или осциллографа это будет непросто.
Опять компилятор, наоборот в каждой версии правят баги. и очень скрупулезно.Я пользуюсь Линуксом как основной системой и как-то привык к простым решениям. Зачем лазить по интеренетам в поисках программ и кряков к ним, если можно вбить название всех нужных программ в менеджер пакетов, и он сам быстренько все поставит. Зачем компилировать чужие исходники, когда мейнтейнеры дистрибутива это уже сделали. Более того, они эти исходники адаптировали под свою среду (хотя бы пути прописали).
Нет, если хочется научиться собирать что-то из исходников, или нашелся какой-то особенно мерзкий баг — это совсем другое дело.
В общем, как обычно — зависит от цели всего этого. Просто в рамках статьи о разработке под STM32 как-то странно собирать вообще все.
Ну как я уже выше отписался, тот же openocd собирается из исходника с нужными конфигами. Это очень важный процесс так как «собиратор» проверяет наличие нужных библиотек. Насчет кряков, тут их нет все открытое. Насчет лезть в GCC, собрать свой кросс компилятор все должны уметь. Допустим, при желании этот же компилятор можно и на самом F7 запустить если его скомпилировать для хоста. Делов там на 15 минут и то 90% это сама компиляция, за вас уже все сделали.
Вообщем собирать из исходника это не 100500 команд а всего 3 но которые дают возможность выбрать нужный билд с определенной конфигурацией. В этом и кроется удобство данного подхода.
Вообщем собирать из исходника это не 100500 команд а всего 3 но которые дают возможность выбрать нужный билд с определенной конфигурацией. В этом и кроется удобство данного подхода.
И еще раз спрошу: чего именно вам не хватило в готовой сборке? Это ж не троллинга ради, а вдруг там действительно чего-то не хватает полезного, ради чего стоит собрать.
Со сборкой для F7: не спорю, когда-нибудь это может пригодиться. Но не в самом же начале, когда человек про регистры-то не знает!
Поймите правильно: большая часть того, что я сейчас говорю — попытка помочь вам со статьей, а не философские рассуждения «нужно ли это хоть когда-нибудь». И в этом ключе логично идти последовательно, по шагам. Совсем хорошо, когда результат каждого шага виден. Так и тут: мы же с контроллером разобраться пытаемся, а не с программированием и управлением софтом под ПК. Вот и не нужно уделять лишнего внимания малозначимым операциям.
Стандартным способом установили софт, взяли готовую плату, и (уже развернуто, как положено в статье) пишем код, потом смотрим что получилось
Потом говорим, что функционала платы нам недостаточно. Скажем, сложно померить потребляемый ток. Чтобы это поправить, просто жизненно необходимо разработать свою плату с нуля, попутно (опять же, развернуто, как положено в статье) разбирая что и для чего делается. А вот используемый софт — только краем, насколько это требуется донесения основной мысли.
А потом говорим, что неплохо бы сделать переносной стенд для разработки. Давайте подключим SD-карту (кратко, готовыми библиотеками) и будем компилировать с нее исходники. Вот тут подробно и со вкусом бегать по граблям компиляции gcc под arm.
Но не все в кучу! Если цель статьи рассказать о первой программе для контроллера, совершенно излишне рассказывать об установке самой-самой последней версии компилятора. С поставленной задачей справится любая! Зато меньше будет людей, у которых ваш алгоритм не сработает.
Со сборкой для F7: не спорю, когда-нибудь это может пригодиться. Но не в самом же начале, когда человек про регистры-то не знает!
Поймите правильно: большая часть того, что я сейчас говорю — попытка помочь вам со статьей, а не философские рассуждения «нужно ли это хоть когда-нибудь». И в этом ключе логично идти последовательно, по шагам. Совсем хорошо, когда результат каждого шага виден. Так и тут: мы же с контроллером разобраться пытаемся, а не с программированием и управлением софтом под ПК. Вот и не нужно уделять лишнего внимания малозначимым операциям.
Стандартным способом установили софт, взяли готовую плату, и (уже развернуто, как положено в статье) пишем код, потом смотрим что получилось
Потом говорим, что функционала платы нам недостаточно. Скажем, сложно померить потребляемый ток. Чтобы это поправить, просто жизненно необходимо разработать свою плату с нуля, попутно (опять же, развернуто, как положено в статье) разбирая что и для чего делается. А вот используемый софт — только краем, насколько это требуется донесения основной мысли.
А потом говорим, что неплохо бы сделать переносной стенд для разработки. Давайте подключим SD-карту (кратко, готовыми библиотеками) и будем компилировать с нее исходники. Вот тут подробно и со вкусом бегать по граблям компиляции gcc под arm.
Но не все в кучу! Если цель статьи рассказать о первой программе для контроллера, совершенно излишне рассказывать об установке самой-самой последней версии компилятора. С поставленной задачей справится любая! Зато меньше будет людей, у которых ваш алгоритм не сработает.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
STM32 Часть 1: Основы