Проблема при симуляции

[tempora]

Как я уже сказал, шаблон делается один раз.

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

Любые регистры конфигурации я отношу к флаговым регистрам,

Вы не поняли - речь идёт о битовых полях, а не о флагах. Где вы видели флаг со значениями 2, 3 или 7?

Имя конфигурационного регистра в общем случае ...

Какой ещё конфигурационный регистр? Откуда вы его взяли? Вы именованные константы за некие регистры приняли?!

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

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

Это называется здравый смысл.

Нет, это определённо как-то иначе называется...

т.к. это может отключать или подключать целые узлы периферии мк.

Ещё раз - битовое поле работает только целиком, отдельные его биты никаких "узлов периферии" не включают.

Для 16 бит это выглядит вот так ...

Для упомянутых в примере 16 бит, это выглядит так: "int iYear = 2013;" и никак иначе, т.к. именно '2013' несут смысловую нагрузку, а не раскладка по битам.

Поэтому может ошибиться в банальностях - забыть бит при инициализации.

Вот именно чтобы не забыть, не ошибиться, и используются именованные константы и/или дефайны, в которых все небходимые биты выставлены заранее!

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

Разумеется в курсе, и решается это значительно проще - заменой имени заголовочного файла.

По-моему у меня её меньше получается в при таком раскладе.

Меньше - чего? Описаний отдельных бит целого числа меньше? Так их вообще не должно быть, как же их у вас меньше? Кроме того, такие вещи принято держать в заголовочных файлах, а вы их в исходниках держите - опять "меньше" не получается. Что-то тут не так, не находите?...

[Вячеслав Мезенцев]

Я смотрю, вы не соображаете о чём пишите и это несоображение ещё тут оправдываете.

1. В таком виде шаблон для конкретного мк сделан, когда дописан окончательно. Никакой недоделки быть не может, т.к. описание для конкретного мк ограничено его datasheet'ом, который не меняется от проекта к проекту.

2. Вы так смело ринулись в комментирование, что забыли показать тот свой набор заголовочников, которые вы просто меняете при смене мк. У меня можно видеть конкретно: ATtiny2313,ATmega48, ATmega16, ATmega32, ATmega128. Когда я создавал свой набор, то прочитал много документации и увидел как меняются названия регистров и как прыгают биты конфигурации от одного мк к другому в одной линейке mega. Вы меняете заголовочники, а я нашёл удобным менять проекты, т.к. не ограничиваюсь одними конфигурационными регистрами, моя программная модель мк ещё поддерживает симуляцию обработки событий, основанную на прерываниях, которые тоже разные.

3. Для начала о "Совершенном коде" Макконнелла. Эта книга написана для прикладников большей своей частью, т.е. для большинства из множества современных программистов. Если вы её понимаете буквально, то я, в отличие от вас, переношу советы на уровень встраиваемых систем, где царят разброд и шатания. Если взять какие-нибудь известные библиотеки по работе с периферией для AVR и сравнить стиль кодинга между собой, то можно сделать вывод, что мало кого интересует совместимость проектов между собой.

Флаги - это индикаторы состояния. Биты тоже индикаторы состояния. Переменная состоит из битов, ячейка ОЗУ состоит из битов. Флаг - это программная модель, описывающая некий набор состояний. В Windows можно написать, что некая величина является флагом: BOOL bFound, при этом фактически она занимает 32 бита, хотя как флаг - это два состояния: TRUE и FALSE. Заметьте, что этот флаг фактически равен нулю при FALSE, то может иметь значения 2, 3, 255 для TRUE. Это флаг? Да. Он может иметь значение 255? Да, может. Отвечая на ваш вопрос, могу уверить, что флаги могут иметь произвольные значения. Главное - как они интерпретируются. Не важно битовое поле у вас или флаг, переменная или регистр, если часть объекта сильно влияет на поведение системы, то нужно описать эту часть - вот так я понимаю такой совет. У Макконнелла от относился к частному случаю в практике прикладников - описание полей некой структуры вплоть до битов. Для меня регистр - это такая же структура, как для кого-то другого нечто большее 8 бит, состоящее из разных типов.

Так вот, конфигурационный регистр, для тех кто в танке, - это такой регистр, который отвечает за конфигурацию чего-либо (идите почитайте datasheet на любой камень). Отличие его в том, что он несёт большую смысловую нагрузку, он сам или его часть аппаратно связаны с мк. Поэтому его представление в комментированном виде проясняет его назначение лучше, чем краткий идентификатор.

Да, имя битового поля ничего не говорит о состоянии отдельных бит поля... и это правильно!

4. Давайте договоримся, что вы не будете поток своих мыслей присваивать мне. Это не хорошо. Если вам не понятно что я написал, то можете это уточнить, а не переиначивать. Я сказал о том, что имя TCCR1B ничего не говорит о том из чего оно состоит. Если бы можно было писать так: TCCR1B.WGM12, делая имя составным, то это уже как-то бы решало проблему, но этого нет. На практике для управления битами регистра нужно прописать их вручную. В случае составного имени нам могла бы помочь IDE, подсказывая набор полей для этой структуры, но приходится вписывать всё самостоятельно и вот здесь появляются ошибки разного рода (констант таких очень много и они из-за краткости похожи бывают или отличаются незначительно). Мой способ комментирования позволяет избежать часть из таких ошибок путём явного соответствия (псевдографика) и подробного описания (сам комментарий).

Ещё раз - битовое поле работает только целиком, отдельные его биты никаких "узлов периферии" не включают.

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

Пример: Вывод настроен на прерывание, изменяется логический уровень, возникает прерывание. Вопрос: какой регистр ответственен за индикацию сего факта? Как он называется? XXX Interrupt Flag Register - ? Регистр флагов, садитесь 5. А теперь читаем название совета ещё раз: Документируйте флаги до уровня отдельных битов. Логические флаги физически могут быть битами, могут быть байтами, а могут и 4-мя байтами. Не важно что у вас флаг, важно понимаете ли вы за что он отвечает и что означают его значения. Важно с точки зрения отладки и чтения кода.

Вот именно чтобы не забыть, не ошибиться, и используются именованные константы и/или дефайны, в которых все небходимые биты выставлены заранее!

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

В моём случае есть заготовка с описанием битов и для человека нужно только решить что поставить 0 или 1 в нужной позиции, этот 0 или 1 он потом может посмотреть в отладчике, где они будут такими же, а вот конструкцию из || отладчик не покажет. И при том, где гарантия, что человек не ошибётся в куче этих ||, если их больше чем пару штук? Что если их 8 или 16 и все нужно вписать, а имена отличаются цифрами на конце 00 + 01 + 10. Комментариев нет, таблицы нет, увидел такой код и полез в datasheet искать и читать что же эта длинная строка означает. Я пока не видел, чтобы кто-то использовать набор заголовочников, которые бы содержали сокращения для всех случаев (у вас пока это выглядит как-то неуверенно: кто-то, где-то там, используют). Где конкретные примеры? Кто конкретно? Где? Как это выглядит? Как выглядит в реально работающем коде?

Разумеется в курсе, и решается это значительно проще - заменой имени заголовочного файла...Меньше - чего? Описаний отдельных бит целого числа меньше?

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

Болтолог из вас занятный, покажите какой вы программист. Мне, как практику, это больше интересно.

[tempora]

Я смотрю, вы не соображаете о чём пишите

Очень убедительный аргумент, хоть и с ошибками.

[Halex07]

Тэкс, уважаемые оппоненты - обявляю "Брэк". Хотите продолжить спор - GOTO вот сюда, в ветку, которая самим Мезенцевым для этого и создана. А в теме о Протеусе спор о том, что "на вкус и цвет все фломастеры разные" как то неуместен.
Ну, а тому - что сказано выше подведу итог, именно с точки зрения применяемости в Протеусе.
2 Вячеслав Мезенцев, еще раз повторюсь - ничего супернового и сногсшибательного в программировании Вы не изобрели... "все уже украдено до нас". Вот маленький примерчик куска SPICE модели операционника

*//////////////////////////////////////////////////////////
*LM324 Low Power Quad OPERATIONAL AMPLIFIER MACRO-MODEL
*//////////////////////////////////////////////////////////
*
* connections:      non-inverting input
*                   |   inverting input
*                   |   |   positive power supply
*                   |   |   |   negative power supply
*                   |   |   |   |   output
*                   |   |   |   |   |
*                   |   |   |   |   |
.SUBCKT LM324/NS    1   2  99  50  28
*

Подход к описанию ног ОУ в вашем стиле и стандартен для SPICE. И условное компилирование тоже давно и успешно применяется. Собственный стиль программирования у каждого оттачивается годами и десятилетиями. Если пойдет дальше, то спор можно растянуть до бесконечности даже вокруг операторов FOR и WHILE, и каждый будет отстаивать то, что ему больше нравится.
Безусловно, какое то удобство в вашем подходе к описанию битов есть, особенно для начинающих. Но, впихивать такое в каждый проект - извините. Пока Вы в своем споре дошли до 16 бит... Ну, чтож разрисуйте в том же стиле 32-битный регистр и почувствуйте "полное превосходство" вашего метода. Оплата за такую наглядность - под 40 строк текста - это слишком дорогое удовольствие. Тут уже до Вас упоминалось про злосчастный Code Wizard, собс-но с него то и в этой ветке все и началось. Ну, вот и полетели камни... Там принцип то подхода тот же, да еще и автоматизирован, - подробное расписывание портов и значимых настроек в каждом проекте. Например, для портов Меги16 формируется 24 строки в С-коде. Подробно, наглядно и с расписыванием побитно. И в любом отладчике -будь то Протеус, студия или любой другой эти злосчастные строки придется пролистывать, чтобы добраться действительно до значимых кусков кода, которые Вас интересуют, либо "зарывать" их в какой-нибудь Template, чтоб не мозолили глаза Вот в чем проблема такого подхода. Никто не спорит о значимости комментариев в коде, они нужны всем, вопрос в "необходимости и достаточности" и занимать ими бОльшую часть кода именно по вертикали - это уже "литературное излишество". Наглядность не возрастает, скорее наоборот. За сим все, успехов в разработке!

[tempora]

Никакой недоделки быть не может, …

Как же, как же, помним! "Этого не может быть, потому что этого не может быть никогда", - достопамятные строки отставного урядника Войска Донского.

Когда я создавал свой набор, то прочитал много документации ...

Аргументы из серии "я учил" также малоубедительны.

флаг фактически равен нулю при FALSE, то может иметь значения 2, 3, 255 для TRUE.

Это просто перл! Флаг может иметь только два значения - TRUE или FALSE, всё остальное - от незнания предмета. Как сугубому практику, можно было бы и простить... если бы не отягчающие обстоятельства.

Я пока не видел, чтобы кто-то использовать набор заголовочников ...

IAR, на который вы так любите ссылаться, имеет под каждый м/к объявления всех его регистров и битов, согласно ДШ. Неужто "пока не видел"?

Если бы можно было писать так: TCCR1B.WGM12, делая имя составным, то это уже как-то бы решало проблему, но этого нет.

Это вас, любезный, кто-то жестоко... обманул - "этого" очень даже есть!

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

Снова паранойя о якобы идентификаторе конфигурационного регистра. В третий раз повторяю - идентификаторы в примерах выше, не для регистров - для значений битовых полей.
И уж кто бы сомневался, что задание регистра вот так:

ADMUX = BIN8(01001111); // BIN8() не зависит от уровня оптимизации
//           ||||||||
//           76543210
//           |||||||+- 0, rw, MUX0:  -+ - Analog Channel Selection Bits
//           ||||||+-- 1, rw, MUX1:   |
//           |||||+--- 2, rw, MUX2:   |
//           ||||+---- 3, rw, MUX3:   |
//           |||+----- 4, rw: MUX4:  _|
//           ||+------ 5, rw, ADLAR:    - ADC Left Adjust Result
//           |+------- 6, rw, REFS0: -+ - Reference Selection Bits
//           +-------- 7, rw, REFS1: _|

намно-о-ого "короче" и "понятнее" , чем так:

ADMUX = adcVRef_AVCC | adcMUX32x200;

… показать тот свой набор заголовочников ...
... я пока не видел ваших заголовочных файлов ...
... Где заголовочные файлы?

А взамен я получу вот эти вот шедевры? :

    //TCCR0 = BIN8(00000000); // BIN8() не зависит от уровня оптимизации
    //           ||||||||
    //           76543210
    //           |||||||+- 0, rw, CS00:  -+ - Управление тактовым сигналом
    //           ||||||+-- 1, rw, CS01:   |
    //           |||||+--- 2, rw, CS02:  _|
    //           ||||+---- 3, rw, WGM01: -+ - Waveform Generation Mode
    //           |||+----- 4, rw, COM00: -+ - Compare Match Output Mode
    //           ||+------ 5, rw: COM01  _|
    //           |+------- 6, rw, WGM00:    - Waveform Generation Mode
    //           +-------- 7, w, FOC0:       - Force Output Compare

Благодарю покорно.

[tempora]

Тэкс, уважаемые оппоненты - обявляю "Брэк".

Упс, долго отвечал. Но, практически в точку попал - каких-то 20-25 минут рассеяние.

Хотите продолжить спор, ...

Нет никакого спора. Да и сказанного всеми в сумме - уже достаточно, чтобы понять, в чем недостаток такого подхода.

[Вячеслав Мезенцев]

tempora, вы почему такой стеснительный? Не бойтесь, я посмотрю ваш код внимательно и, как инженер, расскажу все плюсы и все минусы. Меня так учили.

Что до холиваров, то, думаю, какой-нить модератор найдёт время и перенесёт последние сообщения в тот мой топик.

Halex07, я знаю про spice-модели, когда-то мы их даже моделировали (радиоинженер по основной специальности). Я не приписывал себе изобретательства такой возможности вообще, я лишь показал как это можно сделать для конкретного применения и как это выглядит, и как используется. Я не предлагаю так писать, поскольку это уже написано, я предлагаю уже использовать готовое. Я вижу что народ пишет, когда выкладывает свои произведения на форумах, почему бы не договориться о каком-то общем виде? Ведь если это работает, то не всё ли равно для некоторых как это написано? Когда вы сторонний код используете, то часто ли вы его причесываете под себя? Драйвера, интерфейсы и пр. Не многие отважатся с нуля написать целую систему, большинство будут искать запчасти и из них сооружать проект, дописывая где нужно свой функционал. Просто на C++ не часто пишут под мк, хотя серьёзные вещи написаны и с его помощью.

Аргументы из серии "я учил" также малоубедительны.

Это аргумент из серии - я написал заготовки проектов для 4 мк серии mega и одного tiny, прочитав их описания и сделав сравнения. Все заготовки компилируются в двух компиляторах одновременно, работают в железе и Proteus. Я не словоблуд, я - практик. Все проекты единообразны, т.е. выполнены в одном стиле. Вот после этого "я учил" у меня и есть некоторое мнение по этим вопросам.

IAR, на который вы так любите ссылаться, имеет под каждый м/к объявления всех его регистров и битов, согласно ДШ. Неужто "пока не видел"?

Согласно какого datasheet? Уж мне-то не известно как вообще обстояли дела с переводом исходников от разных компиляторов? Все мои проекты из этой серии компилируются одновременно в gcc и iar, но это не моя заслуга и тем более так было не всегда. Не так давно это было головной болью, чтобы перетащить проект с одного компилятора на другой и дело тут даже не во flash. У IAR'а не так давно заголовочные файлы, где описывались регистры, отличались от gcc'шных, т.е. эти самые именованные константы кое-где имели другие имена, поэтому нельзя было просто так один и тот же исходник без правок или условий скомпилировать в другом компиляторе. Сейчас почти всё синхронизировалось, есть небольшая проблема с описанием обработчиков прерываний, но это решаемо.

Это вас, любезный, кто-то жестоко... обманул - "этого" очень даже есть!

Я в детские игры типа угадаек не играю. Либо это нестандарт, тогда программист, использующий это, сам себя наказал непереносимостью, либо мы говорим не про gcc или iar для avr.

В третий раз повторяю - идентификаторы в примерах выше, не для регистров - для значений битовых полей.

Когда битовое поле состоит из набора битов, но часть из них находится в одном регистре, а другая - в другом, что вы сделаете в такой ситуации? Такая ситуация не редкость для AVR, там есть "битовые поля" одного назначения, разбросанные по регистрам. Вот почему я хотел посмотреть на примеры вашей реализации вашего подхода, мне было интересно как вы смогли такие ситуации обойти, а если не смогли и оставили всё как есть, то и сравнивать не с чем.

Вообще же, вы оба за деревьями леса не увидели. Тот мой топик не "битовую раскраску" поясняет, это лишь частный случай подхода к документированию кода инициализации MCU. Я там собрал множество других плюшек и показал их в работе с разным окружением, в т.ч. свои реализации некоторых вещей. Моя цель - показать ещё один вариант заготовок проектов для написания кода для avr, куда "из коробки" уже включены некоторые удобные вещи, собранные из интернета или написанные мной.

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

Что касается этой темы, то у меня в есть по крайней мере два интересных примера, которые показывают удобство отладки в Proteus через виртуальный нуль-модем и терминал. Это примитивный файловый менеджер и аналог тетриса. Оба этих примера включают в себя класс CConsole, который предназначен для работы с ANSI терминалами. Можно делать вывод с мк более информативным.

[tempora]

вы почему такой стеснительный?

Не путайте теплое с мягким.

Когда битовое поле состоит из набора битов, но часть из них находится в одном регистре, а другая - в другом, что вы сделаете в такой ситуации?

Считаете такую ситуацию крепким орешком? Сочувствую.
Однако, это вполне соответствует предыдущим показательным выступлениям.

[dosikus]

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

Подобное еще допустимо на 8ми битках, и то с натягом .
Мало кто оценит сие. Кто выше уровнем имеет и пользует свое .
Хомячкам подавай кликально-визуальное , да и не будут они опускаться до структуры регистра .
Кстати вы мне напоминаете разработчиков ДРАКОНА , стараясь упростить создаете монсторов..

[dosikus]

Я сказал о том, что имя TCCR1B ничего не говорит о том из чего оно состоит. Если бы можно было писать так: TCCR1B.WGM12, делая имя составным, то это уже как-то бы решало проблему, но этого нет. На практике для управления битами регистра нужно прописать их вручную. В случае составного имени нам могла бы помочь IDE, подсказывая набор полей для этой структуры, но приходится вписывать всё самостоятельно и вот здесь появляются ошибки разного рода (констант таких очень много и они из-за краткости похожи бывают или отличаются незначительно). Мой способ комментирования позволяет избежать часть из таких ошибок путём явного соответствия (псевдографика) и подробного описания (сам комментарий).

Чем не устраивает стандартное описание бит регистров ?
Модуль_регистр_бит ?