Амперметр Atmega. Как устаканить??

[IOPA4]

Наверное не стоит плодить деление...

А, что вы так за МК переживаете. Если есть место, быстродействие удовлетворяет, пусть себе делит на здоровье. Мы тут решаем супер задачу, а мультиметры True RMS
обходятся в основном аналоговой схемой.

[my504]

А, что вы так за МК переживаете.

Я переживаю не за МК, а за свойства того или иного алгоритма.
И с быстродействием все не так однозначно. Дело не столько в быстродействии, сколько в ПОТРЕБЛЕНИИ.
Каждая выполненная инструкция в МК - это определенное количество электроэнергии. Либо можно понизить тактовую у МК, либо быстро исполнять код измерения и падать в сон до следующего измерения.
Из этого следует, что код должен быть плотным. То есть минимальным по количеству исполняемых инструкций.
В части измерения RMS это дает уменьшение тепловыделения балластом питающим МК прямо от сети, либо уменьшение мощности изолирующего источника для измерения тока в высоковольтном фазном проводе. И много чего еще...
Раз уж речь идет о перфекционизме, то не стоит скатываться на решение из кубиков.
Иначе это либо непрофессионально, либо неинтересно (это в случае с хобби).

[my504]

Я это понял.
Можно, где у меня есть вычисления в float, заменить деления умножением.

Деление заменяется умножением, только если это деление на константу.

[mimuh64]

Как то не хотелось подымать тему... но...

Видно хреновый из меня программист.
Сегодня поэкспериментировал, в студии.

Хрен тоже разный бывает, Хреновуха она еще та.... Главное экспериментировать...и дрожжей побольше, ну и сахару...
Ты просто не то нашел...
То что ты сделал это кусок кода из стандартной функции старых версий компилятора HI-TECH... типа такого

{
.....
        ng = (x/og + og)/2.0;
        if(ng == og)
            break;
        og = ng;
    } while(--niter);
return og; 

А ты, например, вот это попробуй (сделай под себя)...

MX_UINT FCM_isqrt(MX_UINT32 FCL_X)
{
    //Local variable definitions
    MX_UINT32 FCL_M;
    MX_UINT32 FCL_B;
    MX_UINT FCR_RETVAL;

    FCL_M = 0x40000; // // 0x40000000 Порядок
    FCR_RETVAL = 0;

    while (FCL_M != 0)
    {
        FCL_B = FCR_RETVAL | FCL_M;
        FCR_RETVAL = FCR_RETVAL ›› 1;

        if (FCL_X ›= FCL_B)
        {
            FCL_X = FCL_X - FCL_B;
            FCR_RETVAL = FCR_RETVAL | FCL_M;
        }
        FCL_M = FCL_M ›› 2;
    }
    return (FCR_RETVAL);
} 

Ни одного явного умножения и деления...
Главное определиться с необходимым порядком вычислений..
Вот что получается...

[МВА]

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

PS. Упс... Заметил, что в функции от mimuh64 когда я присваиваю принудительно 0xFFFFFFFF, результат квадрата равен 255 в то время, как у стандартной функции - 65536. И такая ситуация возникает, когда я присваиваю и 0хFFFF, и 0xFFFFFF. Я думал, что это дело в студии, но протез выдает аналогичные результаты. Хотя без присваивания программа вроде работает адекватно.
Что бы это значило?

[mimuh64]

Что бы это значило?

Это значит не внимательный... Например, что бы это значило -

// 0x40000000 Порядок 

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

ЗЫ да... я бы еще ковырнул тырнет... например там... , в конце...

[МВА]

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

[mimuh64]

Я не думаю, чтобы студия могла ошибиться в этом случае.

Студия не ошибается.... Там такой же компилятор каким и я пользуюсь...
Сделай следующий пример в протеусе (два действия в одном).
1. A=sqrt(0xFFFF);
2. В=sqrt(переменная);
Переменную читай с АЦП

Поставь метки, измерь время и спроси себя почему? в первом случае наносекунды, во втором микросекунды...? Думаю что придет переосмысление - оптимизация при компиляции...

Нельзя так сравнивать как ты сравнивал...

[my504]

Для МК с умножением извлечение квадратного корня последовательным приближением из 32 разрядов в 16 разрядов занимает примерно 160 м. ц. в 16-разрядной платформе и от 200 до 300 в 8-разрядной.
Учитывая, что извлечение корня производится один раз за период накопления, экономия на этой функции выглядит достаточно странной.

[МВА]

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

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

1. A=sqrt(0xFFFF);
2. В=sqrt(переменная);
Переменную читай с АЦП

И еще, стандартная sqrt() - Время выполнения зависит от величины переменной. Я это еще раньше заметил в AVR studio при работе симулятора студии, АЦП все время выдает 0, тогда sqrt() выполняется за 58 тактов (7,25 us при 8 MHz), а при переменной 0xFFFFFFFF - за 750 тактов.