О подходах к программированию, Вынесено из темы "Какой-то бред..." Опции

[Aesthete Animus]

Для тех, кто читает не всё:
порты - по Atmel (default value);
глобальные переменные - по АНСИ СИ.

Да действительно, прежде всего стоит смотреть в даташит, какие начальные значения у регистров - тут уж посыпаю голову пеплом. Насчет ANSI C, то он насколько я знаю убнуляет в том числе автоматические переменные. В любом случае, когда не уверен, то лучше сделать все вручную.

При этом не забудьте убрать цикл "while (1)" из мейна.

А это для чего? что оно мне даст?
куда же я тогда возвращаться-то буду... в "никуда" получается...

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

Хочу заметить, что всякие задержки в прерываниях (наподобее delay_us) крайне не рекоммендуются, прерывание - это критическая часть кода, из которого следует выходить как можно скорее.

Вот это мне тоже, кстати, не совсем понятно... Звучит как заученная фраза из книжек.
А если мне нужно по возникновении прерывания выполнить массу всего? Что мне тогда делать...?

Тут уж я научен горьким опытом. Прерывание опасно тем, что создает многопоточность, но при этом с непресдсказуемым вызовом "потоков". Если нужно выполнить какое-то критичное по времени действие, то делайте его в прерывании; если вы к примеру семплируете звук в реалтайме, то обрабатывайте событие АЦП то-же в прерывании. В прерывании должен содержаться минимальный код, в крайнем случае, код прерывания должен выполняться минимальное время. Во всех остальных случаях в мейне должен крутиться цикл с провркой флагов. Притом, не забывайте, что для всез прерываний есть аппаратные флаги, таким образом, нет необходимсоти делать софтовый флаг, который будет устанавливаться в прерывании.

Насчет инициализации таймеров, могу сослать на соседнюю тему - http://electronix.ru/forum/index.php?showtopic=41239# - там я писал про инициализацию таймера для отсчета секунды. То, что там написано, конечно, не истина в последней инстанции, но, во всяком случае, у меня работает.

[Aesthete Animus]

Разница отнюдь не в поминаемые "несколько тактов" и даже не десятков тактов.

И что мы теряем? Надо оптимизировать не какие-то проходные функции, а действительно критический код.

В оценке степени запутанности мы с компилятором и Вы диаметрально расходимся

Насчет понятности Вашего кода - это тоже спорно. Я не привык думать в терминах языка программирования, и в моем случае это правильно. Я не хочу зацикливаться в мелочях, которые ни на что не влияют. Смотрю на Вашу строчку (word & 1) + '0' и думаю, зачем такая "наихитрейшая хитрость"? Для меня подобные вещи не более чем изыски, которых я избегаю в практической работе. Вам, я думаю, понравится такой код

Код

#include <stdio.h>

main(argc, argv)
int argc;
char **argv;
{
    while (*argv != argv[1] && (*argv = argv[1]) && (argc = 0) || (*++argv
    && (**argv && ((++argc)[*argv] && (**argv <= argc[*argv] ||
    (**argv += argc[*argv] -= **argv = argc[*argv] - **argv)) &&
    --argv || putchar(**argv) && ++*argv--) || putchar(10))));
}

А почему для SRAM сделано исключение зачем-то? Гулять, так гулять!
Если системе оставляют 80% на "всякий случай", то это свидетельстует об одном - разработчик так-же, как и в лучае инициализации на "всякий случай" чего не поподя (с чего эта ветка и началась) не имеет твердого понятия о том, что делает. Вот такое закономерное движение от непонимания-неуверенности в простом к непониманию-неуверенности в сложном .

На моей предыдущей работе были довольно специфичные задачи. У нас никогда не стоял вопрос цены контроллера. Если не хватает Flash памяти, используем более емкий контроллер (например мега128). Не хватает SRAM`а - подключаем внешний. Нужно производить много вычислений с плавающей точкой - переходим на ARM, который имеет сопроцессор. Если бы мы пытались вжать все скажем в мегу32 и тем самым тратили время на бесконечную оптимизацию, мы бы не могли делать того, что делаем.

Повторяю, решение должно быть грубым! По крайней мере у меня, никогда не известна конечная задача и постоянно имеется неопределенность. Из этого постоянно приходится закладывать избыточность платформы. Можно оптимизировать каждую функцию, но это совершенно иной уровень задачи, как правило стоят проблемы на много более верхнего уровня, которые нельзя решить, если мы будем зарываться в каждой мелочи и экономить каждые двадцать, тридцать тактов. Такие потери обычно не критичны!

Сейчас я временно работаю в другой организации. Здесь задачи порядком по проще, и определенность другого рода - я не знаю, что еще начальник захочет, чтобы я впихнул в контроллер. Здесь мне пришлось столкнуться именно с проблемой SRAM`а - решено перейти на другой контроллер. Поэтому и делаю из личных ощущений такое исключение в этом отношении.

Ресурсов контроллера должно хватать для обеспечения функционирования критических задач при пиковой нагрузке. Все остальные при этом могут и подождать и/или иметь допустимые потери в обслуживании.

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