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

[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`а - решено перейти на другой контроллер. Поэтому и делаю из личных ощущений такое исключение в этом отношении.

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

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

[zltigo]

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

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

Я не привык думать в терминах языка программирования....

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

....который я со своим мировосприятием не чуствую.

Да, я это понял .

[Aesthete Animus]

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

Отсутствие базисного уровня владения языком невозможно прикрыть обширными размышлениями на темы абстрактного программирования

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

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

Вы дважды не обратили внимание на главное

Вы тоже не поняли моей мысли. Именно Вы назвали тему "О подходах к программированию", но при этом все Ваши рассуждения строятся на основе критики отдельно взятой функции. Я из поста в пост говорю, что нельзя зарываться в мелочях и если функция работает и отвечает требованиям задачи, то лучше так и оставить! Я говорю о том, что избыточный код иногда исключает сомнения и сужает ту самую неопределенность, о которой я говорил уже не раз. Но на этот свой тезис я так и не получаю ответа: если Вы именно с этим моим подходом не согласны хочу увидеть критику именно подхода!

2INT1
Тут, видите ли, очередной спор о проблеме мироздания - помочь врядли сможете....

[zltigo]

Ей богу, я уже начинаю терять нить нашего с Вами спора.

Перечитайте с начала .

но при этом все Ваши рассуждения строятся на основе критики отдельно взятой функции.

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

Я из поста в пост говорю, что нельзя зарываться в мелочях и если функция работает и отвечает требованиям задачи, то лучше так и оставить!

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

Я говорю о том, что избыточный код иногда исключает сомнения и сужает ту самую неопределенность,

"Иногда", кое-где, порой, может быть, а вдруг... Сомнения нужно исключать не обилием непонятного (в том числе и компилятору кода) а повышением уровня владения инструментом.

Но на этот свой тезис я так и не получаю ответа: если Вы именно с этим моим подходом не согласны хочу увидеть критику именно подхода!

Именно с этим. И с "советом" использовать ресурсы контроллера на 20% - тоже. Последствия таких действий можете поискать на форуме, например, 99% жалоб на то, что включение оптимизации и ... "глюки". 90% жалоб вообще на "глюки" компиляторов - тоже.

Как показалось, эта ветка скорей философская.

Именно так.

Кому нужны длиннющие посты?, нужно кратко,

Не на все вопросы можно ответить кратко, типа "добавь запятую и не парься"

ведь потенциально могуще помочь, тратят свое время, хотя бы на чтение...

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