Если так страшен целый ряд команд в этом месте, то для этого флага можно использовать один байт.
Сколько таких важных флагов в программе? На три байта насобирали?
Ну будет на 21 байт больше. Об этом спорим? Не хватает?
Или хватает, и нужны "шашечки"?

Это было на 51-м, с которым сейчас не работаю. Хотя я помню, где это было, но точный пример не смогу привести, т.к. исправил программу и не обращался на форум. Могу только описать.

if (....проверялось 5-6 условий...) { ...a=1; }

Смотрю в симуляторе. Выполняются все условия. Симулятор выходит на оператор a=1 и после его выполнения a=0 ???
Когда начал разбираться с ассемблерным кодом, то увидел, что компилятор "забыл" обнулить р-р DPTR (есть такой в 51-м) перед его использование , что и привело к такому результату.
Решил проблему заменой одного длинного условного оператор двумя короткими.

Условный оператор был похожим на:

if ((rejym_start==2 && rej__rab==3) || (rejym_start==2 && rej__rab==5) ||
(rejym_start==3 && rej_H_A==0)) {

Эта часть программы была проверена и работала. Когда добавил одно условие в условный оператор, получил неработоспособный код.
О моей ошибке речи быть не может, т.к. выполняется оператор присваивания a=1; с результатом =0;

В следующий раз постараюсь сохранить подобные "глюки".


На десять байт насобирал. Но не об этом речь. Я уже писал, что хотел разобраться ( см. пост №11). И понял, что операций с битами здесь нет (за исключением р-ров 0-0x1F). Есть операций с байтами. Вот и все.

А если под "шашечками" вы подразумеваете уровень активности, то посмотрите на дату регистрации. За это время можно было уже... (если бы это было целью).

Сообщение отредактировал IF_P - Feb 11 2010, 12:15

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

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

P.S.
А упрекать я никого и не собирался. Я так понял, что меня упрекнули в подобных писаниях. Может я и ошибся. Тогда прошу извинить.

Сообщение отредактировал IF_P - Feb 11 2010, 15:16

Цитата(SergeyTT @ Feb 9 2010, 19:52) *
Многократное объявление переменной в разных программных модулях(#include flags.h) здесь до лампады,


Вот сейчас попробовал сделать, как рекомендовал SergeyTT. Выделил глобальные флаги в отдельный хидер, подцепил его к двум файлам, скомпилил. Вроде все нормально - проверил по листнгу.

Так в чем здесь может быть проблема?

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

Если у вас такая задача, то кто вам мешает использовать 51 ядро? Предложений - вагон.
Тот же Atmel, кроме стандартных кристаллов, сейчас предлагает однотактовые. 20-25 мипсов на выходе, ISP и так далее. Памяти много. Есть и cygnal до 100 мипсов.

Если Вам уже надоели разговоры ни о чем, то:
1. Расскажите, что это за структура. Если volatile, то чему удивляетесь?
2. Не совсем понятна причина, по которой взрослые дяди зацикливаются на битовых полях. Например, многоэтажный матюк if(()||()||(()&&()&&()) не потянет за собой в область статических переменных ни единого бита, использование конструкций типа

Это Вам не булева алгебра, все можно навернуть так, что в сумме получается эффективнее работы с флагами
В конце концов

Интересно, сколько будет булевый процессор считать это. И особенно обидно, что нету косвенной адресации бит

+100.
Мне кажется, постепенно все к этому и приходят. Я, к примеру уже пришёл.
Надо давить в себе скрягу.
Если реально просмотреть проекты, то памяти, в последнее время, вполне хватает. Но если даже её требуется много, то всё равно, как правило байты, потраченные на флаги, существенно не влияют на общую картину.


+1000.
Даже используя 51, я бы скорее всего отказался от спец конструкций. Другое дело если бы компилятор сам справился.

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

Тут выбирал МК для одного проекта. Так получается разница м/у STM32F105V и 107 практически стирается. А во втором MAC. Казалось бы дорогостоющая переферия. Я уже не говорю, что эта stm32f105 дешевле at90can128 c двумя CAN контроллерами, а stm32f103 (с одним CAN) - значительно дешевле. Кристаллы не сопоставимы по функционалу и производительности. И, похоже, процесс развития в этой области всё ускоряется. То есть переход с камня на камень дальше будет происходить всё чаще.

Это бесспорно. Ибо при этом можно не парится с атомарностью доступа к битовым полям и просто битовым флагам в байте.
Как тут уже говорил кто-то:"Каждый сам себе злобный Буратино":)