Два порта контроллера закольцевать еще не предлагали?
Буду первым в этот раз!

Комментарий в стиле клетчатого.
Что ни предложение, то шедевр!
Я плакалъ.

На ассемблере получается очень просто с использованием временного регистра и флага Т:
...
ld temp, x
bst temp, 6
bld x, 7
bst temp, 7
bld x, 6
...
Пробовал получить такую же последовательность команд при помощи IAR-C. Хотя IAR-C в самом принципе флаг Т использует, но как только ни пытался шаманить, так и не смог выдавить такую компактную последовательность.

асм, три инструкции:
bst temp, 7
lsl temp
bld temp, 6

в С не силён, но попробую :)
temp=(temp<<1)|(0x40 & (temp>=128))

Я думаю что установить математическую зависимость между вашим алфавитом и кодами ASCII не проблема... На основании этого можно сделать выборку из массива...

Поганятся остальные биты.


Не годится, потому что это - только лишь логический сдвиг влево.

Длинновато... , да и лишний регистр используем

Дык, не спорю.
Правда мой вариант более универсален. Можно применить к любым битам.


Пытался вышаманить из IAR-C, а там, как на мой взгляд, с asr ещё более проблематично, чем с флагом Т.

Дык с ASR как раз просто,
вот код на С:

А вот результат компиляции:

правда на Gcc, но я думаю на IAR будет аналогично (лень проверять)

А вот с флагом T непонятно...

IAR-C дает следующий результат:

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

А у Вас случайно не стоит опция воспринимать char как unsigned char ?




Отвечу сам...
У Вас таки стоит опция char как unsigned char

Вы так меня заинтриговали, что я даже не поленился включить второй копм
на котором есть IAR и таки проверить соблюдает ли IAR стандарт С (ну хотябы пусть и не
по умолчанию), оказалось соблюдает :

Проверил, стояло дефолтное "Plain 'char' is Unsigned", поменял на "Signed", получилось следующее:

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

А вот с флагом T компиляторонезависимого решения точно не получится
Флаг T это такая фича AVR, и каждый компилятор может ей пользоватся/не пользоваться
на свое усмотрение и с С он никак не связан

То есть нашаманить наверное чего-то и можно, но это будет "странное" решение

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

Наверно согласитесь, что Embedded C все же вещь достаточно специфическая и должна иметь возможность по максимуму использовать возможности конкретно взятого контроллера. Иначе эффективное кодирование может быть не реализованым. Это для ПиСи можна писать "гектарные" программы, не сильно заботясь о "выжимании воды", а микроконтроллер - это такой себе "ночной горшок с ручкой вовнутрь" - чтобы места меньше занимал.

Ведь и переносимость программ, написанных на том же самом С, в определенной степени условна даже внутри семейства, не говоря о разных семействах.


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

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

Как так писать - создать прослойку между железом и программой - операционку. Писать программу уже не под железо а под ОС. То что код будет невсегда максимально эффективным, кого это волнует?