Про быстродействие AVR-ок и нужно ли оно так.

[BerZerK-ku]

Про износ: изнашиваются любые полупроводники. Ресурс огромен в смысле количества переключений, но не бесконечен. Можно ли надеяться что какое-то устройство на мк, от которого требуется надежность, работая на предельной часторе уверенно прослужит годы.

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

[megasvintus]

Что значит за неделю сдохнет? У меня уже год проц 2,2 ГГц пашет по полной программе

[BerZerK-ku]

Что значит за неделю сдохнет? У меня уже год проц 2,2 ГГц пашет по полной программе

Проц 2.2ГГц уже 2 года по полной программе пашет, а вот о долговечности работы МК на 16МГц возникает вопрос.

[Секретный кот]

Между предельной (по даташиту) и разогнанной частотами существует весьма ощутимая разница с точки зрения надежности МП/МК. Правда, боюсь что дело далеко не в износе внутренних транзисторов от повышенного количества открытий/закрытий

[Goodefine]

Ручками выводить значения переменных? Это, пардон, как осуществить без функции sprintf?

Все достаточно просто.
Начал делать после того, как в 2313 sprintf съела 92% кода. И не работала при этом. В итоге получилось примерно так. Простойсчет и вывод переменной, для примера... Код сократился до 45%:

Код: Выделить всё

//объявляем переменные

char j=1;
char buffer [4];
char S =0; //сотни
char D =0; //десяки
char E =0; //единицы

//функция преобразования/////////////////////////////////

void decbin (unsigned int x) {
            
unsigned int i;
            
// Place your code here
for (i=x; i>=100; i=i-100) {S++;};
for (i=x-100*S; i>=10; i=i-10) {D++;};
for (i=x-100*S-10*D; i>=1; i=i-1) {E++;};
}

//////////////////////////////////////////////////////////////////
main {
....
while (1)
      {
      // Place your code here
   j++;
  
   decbin(j);
  
   if (S==0){ //условия для того, чтобы отображалось не "005"  а "5" - нолики убирают...
                buffer[0]=1;
            }
               else {
              buffer[0]=48+S;
                    };
  
    if ((D==0)&&(S==0)){  
                buffer[1]=1;
            }
               else {
              buffer[1]=48+D;
                    };                
      buffer[2]=48+E;

lcd_gotoxy(7,1);
lcd_puts(buffer);

if (j==150) {j=0;}; //считаем до 150

S=0;
D=0;
E=0;

delay_ms(100);
};

....
}

Это для трехзначной переменной. Наращивается элементарно...

[megasvintus]

Понял: вы сделали примерно как в функциях, отображающих значения переменных на сегментных индикаторах. Раскидали символы значения по элементам массива, затем вывели по очереди... У меня были подобные мысли, но думал что осуществлять это сложнее немного.

ЗЫ, вы тот самый Goodefine с сайта радиоспец?

[Goodefine]

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

Изначально для индикаторов и делалось...

...Раскидали символы значения по элементам массива, затем вывели по очереди...

Вывел, в принципе одновременно (одной командой), массив заполнил по очереди...

ЗЫ, вы тот самый Goodefine с сайта радиоспец?

На Радиоспецах может и был, не помню. Сейчас на Паяльнике, в основном...

[ARV]

господи, ну вы тут и наворочали... почитайте мою статеечку, может что-то прояснится... именно для этих целей старался...

P.S. кроме sprintf имеется же еще и itoa в конце концов... она жрет меньше памяти...

[Goodefine]

Что именно наворочали?

[ARV]

Goodefine, наворочали - я имел ввиду раздули проблему на пустом месте.

[Goodefine]

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

Код: Выделить всё

void convert(unsigned int NUM){
 int i, m;
 for(i=MAX_SIZE-1; i>=0; i--){
  // цикл заполнения выходного массива СПРАВА НАЛЕВО
  m = NUM % DIG_BASE; // находим остаток от деления числа на основание
  out[i] = SYMBOLS[m]; // этот остаток есть ВЫВОДИМАЯ ЦИФРА
  NUM /= DIG_BASE;  // уменьшаем число в DIG_BASE раз
 }
}

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

[ARV]

во-первых, я не считаю сам и не призываю никого считать мой код каким-то совершенством. не нравится - не пользуйтесь. чем плохо деление? все равно где-то в программе наверняка деление потребуется (не все же можно умножением реализовать) - значит, подпрограмма деления все равно будет в коде... и тогда мой код окажется намного оптимальнее вашего.
во-вторых, мой код не меняется, если надо преобразовывать числа long - всего лишь переменные другого типа надо использовать вместо int - чего не скажешь о вашем.
в-третьих, мой код может так же элементарно выводить в шестнадцатеричном или двоичном формате, а ваш - нет.
в-четвертых, моя функция очень близка к itoa по своей сути, т.е. вполне может подготовить строку для вывода на LCD - нужно лишь нолик в нужном месте добавить, чтобы получить ASCIIZ-строку из массива...
в пятых, повторяю - наворочали было сказано о теме износа полупроводников...

[Goodefine]

Ну вот, второй раз на форуме ответил, а уже успел насолить уважаемому мной ARV...
Давайте, все-таки отделим мух от котлет.

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

Если так, то я согласен, но из сообщения:

...господи, ну вы тут и наворочали... почитайте мою статеечку, может что-то прояснится... именно для этих целей старался...

после приведенного кода это никак не следует. Не проясняет и ситуацию:

Goodefine, наворочали - я имел ввиду раздули проблему на пустом месте.

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

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

Возьмем простой пример. Мне требуется разделить X на Y и вывести результат на дисплей. Как Ваша функция поможет сэкономить время/ресурсы?

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

Снова не понял. Меняем int x на long x и все. Почти: наращиваются разряды элементарно, практически копирайтом...

в-третьих, мой код может так же элементарно выводить в шестнадцатеричном или двоичном формате, а ваш - нет.

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

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

А в массив числа можно просто так ложить (речь НЕ только о цифрах), чтоб осмысленную строку получить?

во-первых, я не считаю сам и не призываю никого считать мой код каким-то совершенством.

Дык, и я не считаю (в смысле свой код), просто иногда с каждым новым ответом возникает все больше вопросов...
P.S. Меня мой преподаватель по математическому моделированию расстрелял бы за выражение "намного оптимальнее". Он месяц успокоится не мог, когда Лужков как то на всю страну подобную связку употребил...

[ARV]

Ну вот, второй раз на форуме ответил, а уже успел насолить уважаемому мной ARV...

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

Давайте, все-таки отделим мух от котлет.

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

Если так, то я согласен, но из сообщения:

...господи, ну вы тут и наворочали... почитайте мою статеечку, может что-то прояснится... именно для этих целей старался...

после приведенного кода это никак не следует. Не проясняет и ситуацию:

Goodefine, наворочали - я имел ввиду раздули проблему на пустом месте.

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

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

что ж, если найдете, чему можно поучиться у меня - буду рад если не найдете - наверное, рады будете вы

Возьмем простой пример. Мне требуется разделить X на Y и вывести результат на дисплей. Как Ваша функция поможет сэкономить время/ресурсы?

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

Снова не понял. Меняем int x на long x и все. Почти: наращиваются разряды элементарно, практически копирайтом...

наверное, копи-пастом все же? (уродливо написано на русскоанглийском...) только любая правка черевата появлением новых ошибок... т.е. чем меньше меняешь в коде для получения другого результата - тем лучше, имхо. в моем случае можно определить новый тип #define my_type int и везеде (где надо) использовать вместо int новый тип my_type - после этого замена единственной строки определения #define my_type long сразу меняет все, что надо... вероятность ошибки сведена к минимуму... согласны, что это удобно?

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

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

А в массив числа можно просто так ложить (речь НЕ только о цифрах), чтоб осмысленную строку получить?

это не понял... что вы имеете ввиду? в массив можно ложить (или класть?) все, что угодно...

[megasvintus]

Что самое интересное- еще пару месяцев назад, я даже и не подозревал, что МНЕ когда-то может не хватить, казавшейся тогда монстром, меги 16, не говоря уж о других камешках... Нет, ее пока хватает, но границы возможностей уже четко нарисовались.

Эх, был бы камешек за небольшую цену хотя бы на 60-80 MIPS-ов. (это я мечтаю)

[Goodefine]

...исправил введенный текст... как видно, исправил недостаточно корректно...

Тогда все понятно. А я, грешным делом, подумал, что страшное сотворил...

...согласны, что это удобно?...

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

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

Чистое любопытство: а что она (программа) должна делать, чтобы оптимума достичь (с делением при конвертации)?

...это не понял... что вы имеете ввиду?...

Это к тому, что если хочу слово "Hello" вывести, в массив придется все-равно нужную последовательность чисел ложить (класть) - не понял в чем глобальное преимущество метода с ноликом, дающим возможность в ASCII выводить... Любая последовательность чисел, меньших 255 и есть ASCII-строка. Вопрос в том, сколько в ней смысла. А к цифрам можно 0x30 и так прибавить...

моя толерантность соизмерима разве что с моей скромностью ГЫЫЫЫЫ

[ARV]

Goodefine, разговор постепенно перетекает в русло общих рассуждений...
я не знаю, что программа должна делать для оптимальности... наверное, в первую очередь она должна делать задуманное программистом. просто ваш пример с выводом результата X/Y на дисплей - бессмыслица, для этих целей программы не пишут. но тем не менее, мне кажется, что компактность кода для моего алгоритма и для вашего будет в мою пользу, хотя для некоторых (возможно, очень многих) значений X и Y по быстродействию ваш будет впереди.

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

что касается "простых" функций - то ваша функция наоборот более сложна. она использует алгоритм, сложность (объемность) которого зависит от числа конвертируемых разрядов, и для, скажем, числа long может превысить разумные пределы. кстати, попробуйте подсчитать количество итераций циклов для конвертации числа 9999 по вашему алгоритму и по моему - без учета времени их исполнения пока что... а когда вы поселитесь в матрице и начнете в одной программе конвертировать числа в разные системы счисления - ваша программа превратится в изобилие функций, каждая из которых работает по своему "уникально быстрому" алгоритму, но в целом программа станет крайне неудобной, плохо читаемой...

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

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

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

[tych]

Goodefine, разговор постепенно перетекает в русло общих рассуждений...

Причем не в разделе - МЯЯЯУ!

[Goodefine]

ARV, согласен, разговор ушел далеко от основной темы... Согласен и с многими Вашими утверждениями. Поэтому, все что я сейчас напишу, так это не спора ради, а для выражения несколько другой точки зрения, которая существует, несмотря на то, имеет она право на это или нет...

я не знаю, что программа должна делать для оптимальности... наверное, в первую очередь она должна делать задуманное программистом

Оптимумы можно искать по разным критериям: производительность кода, объем, читаемость, легкость в сопровождении и т.д... Считать критерием чужую архитектуру мозга... не знаю...

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

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

и в этом контексте безусловно подход с использованием гибкого изначально алгоритма (пусть даже немного медленного) следует признать более правильным

Я бы не сказал, что пакет функций намного менее гибок... Про читабельность - ИМХО, описатели в универсальных функциях наглядности не добавляют...

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

Разве корелляция сложности вычисления со сложостью задачи это плохо для алгоритма?

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

Любая серьезная программа и есть такое изобилие. Одной больше или меньше...

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

Это где такие таблицы используются, если не секрет?

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

Дык она для семисегментника и писалась, просто вместо стандартного вывода массива на дисплей, результат прогонялся через функцию конфигурирования порта...

применимость естественно определяется конкретными условиями...

100% !

[ARV]

Goodefine, если даже tych возмущается несоответствием постов теме - это уже о многом говорит!

я всю жизнь стараюсь программировать под девизом, прочитанным еще в институте: "человек должен думать, а машина - работать". т.е. любая оптимальность мною трактуется в первую очередь как уменьшение труда человека. отсюда стремление делать и применять гибкие алгоритмы. и часто удается удачно совместить гибкость и лаконичность, мне кажется, рассматриваемые в нашей беседе примеры функций этому подтверждение. корелляция сложности вычислений со сложностью задачи, несоменно, будет и есть. но в данном случае упоминание об этом неуместно: сложность задачи преобразования вместо int числа long практически не возрастает, алгоритм, основанный на циклическом делении остается 100% прежним. скажем, для моих функций все ограничивается правкой 2-х строк-описателей переменных, для вашего же изменения более существенны, причем они касаются и самого алгоритма - в нем появятся новые циклы, условия и т.п. при этом количество вычислений так же растет неравномерно (не прямо пропорционально росту числа разрядности числа): в моем случае число делений всегда пропорционально числу значащих разрядов в числе, в вашем - я, честно говоря, не вникал, но судя по всему это не так.

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

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