Pull to refresh

Comments 15

мой первый (отвратительный) пост,
Это вы зря. Конечно, косяки и спорные моменты там есть, но, как по мне, одна из лучших статей по старту. Самое приятное, что не стали полагаться на «магию» IDE, Куба, даже стартап с нуля написали. Потом, конечно, стоит к «магии» прийти, но уже на своих условиях.
Ах да. Вы два раза жалуетесь на «низкое качество предыдущей статьи». Безотносительно к объективности этого, второй раз точно лишний.
Еще хорошо бы в конце выложить архив с тем, что сделано в рамках статьи. Не всегда очевидно, в какое место предполагается встроить очередной кусок кода из текста.
Ну и объявлять вектора прерываний, как мне кажется, немного поспешили. Без теории или описания задачи непонятно зачем они вообще нужны. Вводить их лучше бы на одну-две «главы» позже, когда будет работа с ними.
Статья получалась сумбурной, поэтому и предупреждаю. А так вектора это поинтеры, пока еще не прерывания) Спасибо за отзыв и помощь с ошибками.
Вектора это не поинтеры (переменные для хранения адреса чего угодно), это адреса, куда прыгнет контроллер по событию.
Но прерывания это отдельная и довольно интересная тема, предпосылки к рассмотрению которой вы пока не затронули. И прерываниями не пользуетесь — так стоило ли вообще вводить этот термин?
не ну грубо назвать их поинтером тоже можно, так проще.
Все же не стоит. По крайней мере мне это слух режет.
Поинтер это переменная, указатель из оперативки на оперативку. По крайней мере, обычно. А таблица векторов прерываний это гвоздями прибитая доска с адресами.

Если честно, не понял для кого эта статья. Поясню.
Если целевая аудитория — новички, то зачем их сейчас грузить всем этим? Куб позволяет сделать очень быстрый старт, минуя эти дебри. Более того, такой вход может на всегда отбить желание входить в STM32 дальше.
Если целевая аудитория — профи, то крайне сомневаюсь что она им как-то интересна. Проекты без HAL, написанные подобным образом, крайне тяжелы для поддержки. Особый мрак — интииализация и сам проект на асаемблере. Возможно быстро и круто, но чтобы перенести на другое железо или изменить конфиг, проще написать с нуля.
Единственные, кто возможно будет рад статье — те, кто уже не одну собаку съел на STM32 и кому будет интересно заглянуть под капот куба.
В общем… за труд спасибо, но практическая польза сомнительна.

Проекты без HAL, написанные подобным образом, крайне тяжелы для поддержки.
Дорогой читатель, я совсем не долго программирую в целом, но успел застать конфуз компаний которые работали с SPL. и вот когда STM выпустили STM32F7, на них не распространялась поддержка SPL, только HAL. Всех поставили перед фактом, что если надо то портируйте, колдуйте. Так вот учась на ошибках людей которые инвестируют время в «Библиоитэки» я инвестировал его в изучение устройства. и теперь мне достаточно просто открыть референс мануал и разрабатывать.

Это насчет вашего «переноса». Теперь насчет переноса в реальности, дело в том что переносимость это маркетинг, с реальностью который связан очень плохо. И при переносе с f4 на f7 я бы провел древе-индейский ритуал «Нахуа». Это когда все племя пытается получить ответ на вопрос «Зачем».

Практическая польза? я пишу для себя, что бы запоминать материал.
Ну, ок. Жду урока так… надцать, где вы научите без Хала ТСР-стек написать
Это не самое страшное, а наоборот самое увлекательное. сам жду. об этом я наверно статью дольше писать буду чем саму имплементацию стэка.

Я пару месяцев назад вполне являюсь ЦА этой статьи.
Я новичёк в СТМ32 и программировании МК, но опытный прораммист. Я никуда не спешу, и не хочу просто подрыгать ножкой светодиода. Мне нужно понять, как всё устроено изнутри, как работают прерывания, какие области памяти существуют и в чём их различие.
Это не помешает мне использовать HAL в своих проектах, но зато я буду хорошо знать, как это хал работает. К тому же, его код весьма не идеален. И, возможно, я захочу что-то соптимизировать или починить какой-то баг.

Зря вы так. Мне, например, цикл статей интересен. Более того, я надеюсь, автор продолжит его писать. А совсем хорошо если еще сделает его более плавным и последовательным. Например, я уже написал ему, что прерывания он объявил рановато, можно было ввести их позже, когда будет видна необходимость.
И если курс статей дойдет до какого-то практического результата вроде мигания диодом или настройки периферии, буду рекомендовать его новичкам. Именно потом, что автор внятно объясняет что и за чем используется. В его статье почти нет «магии». Хотя, конечно, некоторые теоретические тонкости было бы неплохо расписать подробнее. Пожалуй, отдельным постом оформлю.
это «спешал» чтобы быстрее опечатки поправили? :) Что при первом прочтении нашел — пометил. А их там много.
Предложения, какие темы стоило бы осветить подробнее (если хотите, можно в личке списаться):
1. Пару слов о стеке. Либо ссылку, где это рассматривается. Почему он «растет вниз» и для чего вообще нужен. Про хранение адресов возврата и локальных переменных. Вообще-то, по-хорошему, стоит это изучать на более простых контроллерах, но раз уж начали с «монстра»…
2. Адресация ОЗУ и ПЗУ. Почему выполнение начинается с «волшебного адреса» 0x08000000.
3. Затронута интересная тема с перемещением кода в ОЗУ для последующего выполнения. Правда, рановато: без настройки тактирования и объяснения про пропуск тактов чтения флеша не очевидно, почему оперативка быстрее.

Написано мало и сумбурно. Хотя тема поднята интересная.
Пеши исчо

Sign up to leave a comment.

Articles