Да, ручками-то конечно можно определения писать, но не хочется.

Sergey_B, я пожалуй воспользуюсь вашей идеей с USE_PORTA. Для avr-gcc их можно определить автоматом, а для IAR - вручную

Добавил поддержку компилятора от IAR в свои списки линий. В общем работает.
Обновления в Git репозитории:
http://github.com/KonstantinChizhov/AvrPro.../master/avrcpp/

ЗЫ.
Что-то меня не впечатлил этот хвалёный компилятор от IAR Systems для AVR.
Я нашел тоько два вида оптимизации которые он делает лучше чем GCC:
- Common subexpression elimination,
- умеет работать с однобайтовыми указателями.
А в остальном как-то не впечатляет.

Не совсем в тему, но всё-таки местами он (ИАР) гораздо лучше работает.
В mspgcc при всех моих потугах мне так и не удалось достичь иаровского размера бинарника.
Разница как минимум 20%.
Существенно, когда балансируешь на грани невпихуемости.
Хотя, глючки иногда подкидывает специфические и трудноуловимые. Например, коллега целый день бился, пока не поменял bool на char. И это при нулевой оптимизации.
Преимущество ИАРа в том, что его лучше затачивают под конкретную платформу (под каждую из).
Недостаток - при этом он код теряет переносимость, вследствие специфических приёмов.

Вопрос автору этого инструмента: как будет выглядеть после трансляции асм-код для ATmega128 при записи в группу из 4-х бит число 0x0A. Группа такая (начиная с младшего в группе): PA.0, PB.0, PD.3, PD.4? Хотелось бы посмотреть именно "боевой", (не учебный) код, который будет сгенерирован в этом случае. Спасибо.

to Quasy.
Исходный код:


Асм листинг для атмега128:



Как-то так. Писать в виртуальные порты константы не интересно - запись любого набора бит в один порт будет соптимизирована не более чем до:

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

ЗЫ.
Интересно, что вам мешает взять исходный код и поэкспериментировать самостоятельно.

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

Атомарность доступа далеко не всегда нужна. Обеспечивать ее всегда слишком расточительно. Если она всё-таки необходима используйте ATOMIC_BLOCK и иже сним, например:

ATOMIC_RESTORESTATE
{
Pins::Write(0x0A);
}

В чём проблема-то?

А проблема в том, что, в предлагаемом виде генерируемый код фигурально выражаясь, подпадает под статью "Вредительство". По крайней мере в стране эмбедеров ) Применять его пока нельзя. И мне очень бы хотелось посмотреть генерируемый вашим инструментом вариант боевого код с учетом неатомарности. Или вы предлагаете программисту, применяющему ваш код, надеяться что не будет прерываний? Или вы предлагаете самому программисту позаботиться об атомарности? Очень хочется посмотреть вариант Безопасного кода записи в группу. Спасибо.

Дилемма. Без организации критической секции код применять нельзя. С организацией критической секции ваш код займет 11 тактов, что недопустимо. А все потому, что ваш код не научился делать четыре операции SBI/CBI.

Ключевое слово "программисту". Которому голова дана не только чтобы в нее есть.
У меня нет махания ногами в прерываниях. Нафига мне лишний оверхед с вашей атомарностью?
Зал притих - покажите, на примере порта E.

Заботиться об атомарности всё равно прийдётся программисту. Даже операция вида int c = a + b; И всегда есть шанс, что прерывание случится в момент когда первый байт в переменную "с" уже записан, а второй нет. И если в этом перерывании используется эта переменная "с"...
Вы предлагаете использовать везде операции SBI/CBI и выводить значение побитно? А что, если мы будем записывать значение неизвестное во время компиляции побитно? Попробуйте сами написать, хоть на Си, хоть на ассемблере. Покажите как должно быть правильно.

Залу не надо притихать! Он и так 8 страниц переливал из пустого в порожнее и не обсуждал самое главное - безопасность применения. Про PORTE? Ну, вам-то я скажу по секрету: у Atmega 128 (про который речь) его адрес 03 SBI & CBI. У меги128 90% портов в битовом пространстве.




Мы пока говорим про константы. Если настало время - я скажу и про переменные. Там для предложенной группы нет альтернативы варианту с побитовым анализом переменной и операциям SBI/CBI.

А вы все операции с портами ввода-вывода оборачиваете в критические секции? Даже те, которые абсолютно не зависят от прерываний? Надеюсь, что нет.
Тогда какой смысл оборачивать в критические секции операции в "библиотечном" классе? Разумно это отдавать на откуп пользователю

у меня это например реализовано так:

Кто сказал про "класс"? Я просил результирующий асм-код и критикую его. Где будет решаться проблема неатомарности - это я и хотел понять. Причем критика не понедельничного злого бодуна, а вполне конструктивная: я предлагаю путь.

Тут пришёл поручик Ржевский и всё опошлил.

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