[EdgeAligned 85]

3 минуты назад, jcxz сказал:

Вот для интереса - глянул сколько весят файлы описания регистров периферии

Окей, а теперь перенесите этот проект на STM32H743, где она только система тактирования займет несколько экранов описания. 

В общем, я придерживаюсь принципа ЗОЛОТОЙ СЕРЕДИНЫ. Не кидаюсь писать километровые описания, но и не переписываю описание в попытке сэкономить несколько килобайт дискового пространства компьютера. 

 

[Arlleex 187]

8 минут назад, jcxz сказал:

Вот для интереса - глянул сколько весят файлы описания регистров периферии (все, суммарно) в том исходном проекте на мой 3D-принтер = 3354 КБ!

Мой файл описания регистров периферии (для того же самого проекта, но переписанного мной) = ~25 КБ.  Всего в ~134 раза меньше.  

Кому нынче важно, сколько занимают исходники на жестком диске компа? Вы же не на дискетах исходники храните.

[EdgeAligned 85]

4 минуты назад, jcxz сказал:

? Я их ниоткуда не выдёргивал. Сам писал. Да и не код это. А всего лишь заголовочный файл.

Я о другом говорю. Представьте, что кто-то из вашего проекта возьмет кусок. Кусок от вашего, кусок от еще чьего-то. И в итоге, эти куски окажутся разными. Появится такая же путаница, о которой вы только что говорили. Человек начнет думать - а почему в одном куске используется стандартный CMSIS-файл, а в другом куске используется собственные описания? Кому верить? Явно человек будет больше доверять стандартному файлу, чем самописному от неизвестного автора. И если у вас текстовые имена различаются, придется повозиться с адаптацией.

И такая же путаница возникнет с рассматриваемым тут самодельным C++-заголовочником. Лично я считаю, что до тех пор, пока производители не выпустят набор описаний в С++ стиле, применение этого стиля очень крайне затруднено в виду несовместимости.

[jcxz 242]

Только что, Arlleex сказал:

Как будто когда сам пишешь, ошибок не допускается. Ну ну.

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

И я знаю, что написание и отладка логики программы занимает многократно (даже на порядки) больше времени, чем описание регистров периферии. И в процессе этого мне 100500 раз придётся обратиться к описаниям регистров периферии. Если на каждом таком обращении я сэкономлю хотя-бы 20% времени (потому как быстрее найду и прочитаю что нужно в удобном мне стиле), то по суммарном результату я могу сэкономить часы если не дни отладки потом.

Скажу даже более - я чаще всего функции ног МК, или распределение других ресурсов (линий прерываний и т.п.) смотрю по своим хидерам, чем по мануалу. Просто - так быстрее получается. Я же сам его составлял. А значит составил так, как мне удобнее с ним работать. А индусы, писавшие мануал, писали его как им удобнее. Но не всегда удобнее мне.

[Arlleex 187]

7 минут назад, jcxz сказал:

Я же вроде и писал же, что против "надёргивательно-кусочного программирования". Мой код не нужно бездумно выдёргивать кусками.

Вы пишете некий монолит - т.е. проект не может существовать без всех файлов, входящих в него, и даже речь не про файлы исходников или каких-то прожект-зависимых вещей. Человек, в нем копающийся, очевидно будет плеваться, приговаривая еще что-то в стиле "ну тогда уж чего еще и stdio.h и всю стандартную библиотеку сам не написал?".

А представьте, вот потратили сколько-то времени на написание проекта. Завтра приходят и говорят - надо этот проект еще на 3 разных МК перетянуть. И вместо того, чтобы брать и перетаскивать, Вы начнете с описания структур регистров - а это пустая трата времени, когда эти самые регистры уже описаны, и для ARM-контроллеров вполне себе (в большинстве случаев) в неком едином стиле.

[jcxz 242]

7 минут назад, Arlleex сказал:

Кому нынче важно, сколько занимают исходники на жестком диске компа? Вы же не на дискетах исходники храните.

Важно самому программисту. Сами же писали: "Чем гуще лес, тем проще в нём заблудиться".

Или вам никогда не приходится потом читать собственных исходников? Чего-то в них переделывать или искать?

[Arlleex 187]

1 минуту назад, jcxz сказал:

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

Про исходники - соглашусь, отчасти. Но тут речь про банальные описания регистров.

[jcxz 242]

5 минут назад, EdgeAligned сказал:

Человек начнет думать - а почему в одном куске используется стандартный CMSIS-файл, а в другом куске используется собственные описания? Кому верить? Явно человек будет больше доверять стандартному файлу, чем самописному от неизвестного автора.

Ну вот те индусы, что изначально писали код для моего 3D-принтера и взяли стандартные описания. 2 или 3 разных. Но все "стандартные". Это чему-то помогло?  

[Arlleex 187]

5 минут назад, jcxz сказал:

Важно самому программисту. Сами же писали: "Чем гуще лес, тем проще в нём заблудиться".

Или вам никогда не приходится потом читать собственных исходников? Чего-то в них переделывать или искать?

А чего в них разбираться? Хоть там 100 тыщ строк - посмотрите, из чего он (файл) состоит. В основном лишь блок регистров периферии, а потом блоки описания битов каждого регистра. Есть позиция бита, есть маска. Больше ничего оттуда не нужно, вот совершенно.

Крайний раз я сам описывал регистры и биты в них для какого-то STM8, но лишь потому, что а) проект был простой, мне нужно было 3 или 4 периферийных блока, б) я не нашел готовый хедер.

[jcxz 242]

4 минуты назад, Arlleex сказал:

Про исходники - соглашусь, отчасти. Но тут речь про банальные описания регистров.

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

Вот не поверю, что вы прочитали один раз описание какой-то периферии и больше не обращаетесь к нему - всё помните.

А также я часто использую куски кода из своих предыдущих проектов.

[EdgeAligned 85]

А, ну это дело привычки. Кто как привык.

Вот тут на форуме недавно один господин выкладывал свой код, так у него прямо в текст исходинков под комменты были скопированы описания битов из стандартного файла. Я спрашиваю - а зачем? Он отвечает, десткать, а вдруг программист уйдет, и другому будет легче разобраться. Так я говорю - блин, чел, эти описания же лежат в страндартном файле! Но тот господин, похоже, не понял этого.

[jcxz 242]

2 минуты назад, Arlleex сказал:

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

Вот блоков описания битов и не нужно. Одни минусы в этом. Нужны только регистры.

[EdgeAligned 85]

1 минуту назад, jcxz сказал:

. Пока пишешь и отлаживаешь проект. На перечитывание их тратиться времени кратно больше, чем на начальное описание.

Тяжело в ученье, не спорю. Я тоже вот многократно перечитываю, пока изучаю. На одном мониторе открыта IDE, на другом мониторе - пдф-ка мануала. Еще и 12-дюймовый планшетник использую, чтобы не крутить во все стороны. Ну а че поделать, приходится.

3 минуты назад, jcxz сказал:

Вот блоков описания битов и не нужно. Одни минусы в этом.

странный подход, странный. А как вы пишите? Магические цифры? Тоесть, не SPI_CR1_SPE, а (1 << 0)? прикольно конечно, экстравагантно. Но именно от такого подхода предостерегают многие именитые программисты в своих книгах, которые мне доводилось читать.

[jcxz 242]

4 минуты назад, Arlleex сказал:

А чего в них разбираться? Хоть там 100 тыщ строк - посмотрите, из чего он (файл) состоит. В основном лишь блок регистров периферии

Ок, например - возьмём описания регистров периферии ядра. NVIC, MPU, etc. Взяли вы от STM32 описания всех регистров. Там и эти есть. А завтра вам нужно писать код на NXP или Infineon или TI. Там тоже берёте описание "от производителя". Но ведь там описание регистров ядра почти наверняка отличается. Даже имена регистров там могут быть другими.

Как будете тут поступать?

А у меня, с моими описаниями - проблем нет, так как описание регистров ядра просто одинаковы. Соответственно и код, работающий с этой периферией я просто копирую из проекта в проект. Почти ничего не меняя. А там довольно большой объём кода. На одном только этом, я экономлю времени больше, чем потрачу даже на десять самостоятельных описаний регистров.

[Arlleex 187]

2 минуты назад, jcxz сказал:

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

Вот не поверю, что вы прочитали один раз описание какой-то периферии и больше не обращаетесь к нему - всё помните.

А также я часто использую куски кода из своих предыдущих проектов.

Смотря какая периферия. Для такой как GPIO, которая используется в 100% проектов, я сделал небольшие макрос-обертки и да, я не заглядывал в описание GPIO-блока конкретного МК уже довольно давно - зачем?

Касательно другой периферии: да, я подсматриваю в референс. А как без этого? Никак. Разве что если это уже было когда-то написано, а сейчас надо перетянуть в другой проект, поправив максимум какой-нибудь DMA-канал или лапы МК.

И да - разработка драйверов нижнего уровня работы с регистрами в моем типовом проекте - это доли процентов общего объема прикладного кода. Но бывают и исключения - от проекта зависит.

6 минут назад, jcxz сказал:

Вот блоков описания битов и не нужно. Одни минусы в этом. Нужны только регистры.

Почему?

4 минуты назад, jcxz сказал:

Ок, например - возьмём описания регистров периферии ядра. NVIC, MPU, etc. Взяли вы от STM32 описания всех регистров. Там и эти есть. А завтра вам нужно писать код на NXP или Infineon или TI. Там тоже берёте описание "от производителя". Но ведь там описание регистров ядра почти наверняка отличается. Даже имена регистров там могут быть другими.

Как будете тут поступать?

При разработке CMSIS-заголовков авторы не лепили описание всего и вся в один хедер. Описание регистров разделено, поэтому описание регистров ядра МК берется из файла, который не поставляется вендором МК. Он един для всех МК на этом ядре.