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

[Aesthete Animus]

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

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

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

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

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

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

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

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

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

[rezident]

Насчет ANSI C, то он насколько я знаю убнуляет в том числе автоматические переменные.

Ошибаетесь. Автоматические это то же что и локальные переменные, выделяемая для них память находится на стеке или в регистрах. Они и еще регистровые (register) переменные не инициализируются нулями в отличие от глобальных и статических (static).

В любом случае, когда не уверен, то лучше сделать все вручную.

А вот это правильно.

[zltigo]

"В любом случае, когда не уверен, то лучше сделать все вручную"

А вот это правильно.

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

[Aesthete Animus]

Они и еще регистровые (register) переменные не инициализируются нулями в отличие от глобальных и статических (static).

Почитал документацию... Посыпаю голову пеплом...

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

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

[zltigo]

А твердость знаний приобретается отнюдь не зубрежкой документации...

Зачем зубрежкой? Зубрежки категорически не надо. Так почитать всю перед сном разок для общей ориентировки. Ну а потом чтение избранных мест документации при необходимости и в случае возникновения неуверенности.

[rezident]

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

Скобки в сложных выражениях и (ре)инициализация переменных никогда лишними не бывают. В таких случаях лучше перебдеть...или перебдедь?... в общем перестраховаться, чем недобд... тьфу... короче лучше, чем наоборот

[zltigo]

Скобки в сложных выражениях и (ре)инициализация переменных никогда лишними не бывают.

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

[Aesthete Animus]

Зачем зубрежкой? Зубрежки категорически не надо. Так почитать всю перед сном разок для общей ориентировки. Ну а потом чтение избранных мест документации при необходимости и в случае возникновения неуверенности.

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

Ей богу, развели мы тут очередные религиозные споры...

Сообщение отредактировал Aesthete Animus - Jan 4 2008, 14:08

[zltigo]

Ей богу, развели мы тут очередные религиозные споры...

Это для этой темы оффтопик, конечно, но отнюдь не религиозные споры. Отнюдь. С этим я, как модератор, справлюсь - выделю в отдельную тему.

Будьте уверены, когда Автор разберется в этом таймере, он пройдется по коду и удалит все лишнее.

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

Код

Лично я делаю так:
/******************************************************
*   Преобразует в строку length младших битов         *
*   слова word. Строка dest должна иметь размер       *
*   по меньшей мере length + 1                        *
******************************************************/
char* bitwise(uint32_t word, char* dest, uint8_t length)
{
    register uint8_t i;
    for (i = 0; i < length; i++)
        dest[length - i - 1] = word & (1UL << i) ? '1' : '0';          
    dest[length] = '\0';
    return dest;
}

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

Код

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 платформы - я просто прочитал и поправил на лету явное бросающееся в глаза.
Еще раз - это не "наезд", такие-же ляпы найти можно у абсолютно любого - это просто констатация факта, что "откладывание на потом" совершенно губительно.

[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 процентов. Если система перестает работать из-за паразитной задержки в несколько тактов, то эта система "жесткая" и ее стоит изменить.

[zltigo]

..написан он надо сказать изящно.

Он не написан изящно - вполне лобовой естественный код. Писался без раздумий. Просто без путанных избыточных конструкций.

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

Вы очень заблуждаетесь. Я потратил на обозрение кода в той ветке достаточно много времени (много больше, чем на написание более простого) пытаясь вникнуть в суть. Компилятор тоже Вас плохо понял - сравниваем:

Код

    132          char* bitwise(unsigned long word, char* dest, unsigned char length)
   \                     bitwise:
    133          {
   \   00000000   93BA               ST      -Y, R27
   \   00000002   2E3A               MOV     R3, R26
   \   00000004   2F79               MOV     R23, R25
   \   00000006   2E28               MOV     R2, R24
   \   00000008   01C8               MOVW    R25:R24, R17:R16
   \   0000000A   01D9               MOVW    R27:R26, R19:R18
   \   0000000C   010A               MOVW    R1:R0, R21:R20
    134              register unsigned char i;
    135              for (i = 0; i < length; i++)
   \   0000000E   E050               LDI     R21, 0
   \   00000010   2366               TST     R22
   \   00000012   F0D9               BREQ    ??bitwise_0
   \   00000014   01F0               MOVW    R31:R30, R1:R0
   \   00000016   0FE6               ADD     R30, R22
   \   00000018   1FF5               ADC     R31, R21
   \   0000001A   9731               SBIW    R31:R30, 1
    136                  dest[length - i - 1] = word & (1UL << i) ? '1' : '0';
   \                     ??bitwise_1:
   \   0000001C   E001               LDI     R16, 1
   \   0000001E   E010               LDI     R17, 0
   \   00000020   E020               LDI     R18, 0
   \   00000022   E030               LDI     R19, 0
   \   00000024   2F45               MOV     R20, R21
   \   00000026   ........           CALL    ?L_SHL_L03
   \   0000002A   2308               AND     R16, R24
   \   0000002C   2319               AND     R17, R25
   \   0000002E   232A               AND     R18, R26
   \   00000030   233B               AND     R19, R27
   \   00000032   2B01               OR      R16, R17
   \   00000034   2B02               OR      R16, R18
   \   00000036   2B03               OR      R16, R19
   \   00000038   F011               BREQ    ??bitwise_2
   \   0000003A   E301               LDI     R16, 49
   \   0000003C   C001               RJMP    ??bitwise_3
   \                     ??bitwise_2:
   \   0000003E   E300               LDI     R16, 48
   \                     ??bitwise_3:
   \   00000040   8300               ST      Z, R16
   \   00000042   9553               INC     R21
   \   00000044   9731               SBIW    R31:R30, 1
   \   00000046   1756               CP      R21, R22
   \   00000048   F348               BRCS    ??bitwise_1
    137              dest[length] = '\0';
   \                     ??bitwise_0:
   \   0000004A   E000               LDI     R16, 0
   \   0000004C   01F0               MOVW    R31:R30, R1:R0
   \   0000004E   0FE6               ADD     R30, R22
   \   00000050   1FF0               ADC     R31, R16
   \   00000052   8300               ST      Z, R16
    138              return dest;
   \   00000054   0180               MOVW    R17:R16, R1:R0
   \   00000056   2D82               MOV     R24, R2
   \   00000058   2F97               MOV     R25, R23
   \   0000005A   2DA3               MOV     R26, R3
   \   0000005C   91B9               LD      R27, Y+
   \   0000005E   9508               RET
    139          }

и вполне понятный мне и много более понятный компилятору код:

Код

    143          char* bw(unsigned long word, char* dest, char length)
   \                     bw:
    144          {
    145              dest += length;
   \   00000000   E070               LDI     R23, 0
   \   00000002   0F46               ADD     R20, R22
   \   00000004   1F57               ADC     R21, R23
    146              *dest = '\0';
   \   00000006   01FA               MOVW    R31:R30, R21:R20
   \   00000008   8370               ST      Z, R23
   \   0000000A   2366               TST     R22
   \   0000000C   F069               BREQ    ??bw_0
   \                     ??bw_1:
   \   0000000E   956A               DEC     R22
    147              while( length-- )
    148              {    *--dest = (word & 1) + '0';
   \   00000010   2F70               MOV     R23, R16
   \   00000012   7071               ANDI    R23, 0x01
   \   00000014   5D70               SUBI    R23, 208
   \   00000016   01FA               MOVW    R31:R30, R21:R20
   \   00000018   9372               ST      -Z, R23
   \   0000001A   01AF               MOVW    R21:R20, R31:R30
    149                  word >>= 1;
   \   0000001C   9536               LSR     R19
   \   0000001E   9527               ROR     R18
   \   00000020   9517               ROR     R17
   \   00000022   9507               ROR     R16
    150              }
   \   00000024   2366               TST     R22
   \   00000026   F799               BRNE    ??bw_1
    151              return( dest );
   \                     ??bw_0:
   \   00000028   018A               MOVW    R17:R16, R21:R20
   \   0000002A   9508               RET
    152          }

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

Я противник запутанных выражений...

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

..а возможно, следует пересмотреть всю архитектуру системы.

Слова, слова, слова,... правильные слова. Плохо, когда даже правильными словами начинают манипулировать.

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

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

Я к примеру никогда не использую ресурсы контроллера более чем на 20 процентов (за исключением SRAM`ма) и не советую эту цифру поднимать выше 80 процентов.

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

Если система перестает работать из-за паразитной задержки в несколько тактов, то эта система "жесткая" и ее стоит изменить.

Об использовании совершенно правильных слов уже писал выше.

[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", русском.... Я могу в душе быть великим поэтом, но если результаты своих поэтических размышлений я смогу изложить только на уровне "моя-твоя-непонимай", то оценить это не сможет никто.

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

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

[INT1]

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

[Aesthete Animus]

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

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

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

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

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

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

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