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

[Aesthete Animus]

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

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

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

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

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

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

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

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

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

[Aesthete Animus]

Только бога ради, не воспринимайте ниженаписанное, как личный наезд - просто иллюстрация к утверждению, что "Автор потом...". Вы написали некую, функцию, добились ее рабоспособности и даже выложили на всеобщее обозрение. Однако не верю, что Вы после того, как "заработало" хоть несколько раз ее просмотрели, ибо в противном случае она просто обязана была выглядеть иначе. Например, так:

Код

char* bitwise(uint32_t word, char* dest, uint8_t length)
{
    dest += length;
    *dest = '\0';
    while( length-- )
    {    *--dest = (word & 1) + '0';
        word >>= 1;
    }
    return dest;
}

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

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

Да, Ваш код более короткий и наверное более быстрый, написан он надо сказать изящно. Но скажите мне, так ли уж страшна потеря десятка операций в данном случае. Когда я пишу код я прежде всего руководствуюсь его выразительностью. Даже в данном случае, проще понять что происходит у меня в коде, нежели у Вас. Я противник запутанных выражений, возможностью коих нас наградил Риччи с сотоварищами и избегаю конструкций наподобее dest[++i] или while(length--). Ежели для решения задачи так страшна потеря этих нескольких тактов, то наверное надо не заниматься бесконечной отладкой каждой фукнции, а возможно, следует пересмотреть всю архитектуру системы.

Кстати, эту фукнцию я приводил в теме, до конца тему не прочитав и не поняв сути. За то прошу меня простить.

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

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

Изыски в решении задачи подчас просто необходимы, но не надо ими злоупотреблять. Решение должно быть "грубым" (в терминах грубых систем), платформа для этого - избыточной. Я к примеру никогда не использую ресурсы контроллера более чем на 20 процентов (за исключением SRAM`ма) и не советую эту цифру поднимать выше 80 процентов. Если система перестает работать из-за паразитной задержки в несколько тактов, то эта система "жесткая" и ее стоит изменить.