asm на AVR, оптимальные конструкции Опции

[_Ivana]

Пишу третий в жизни проект, на AVR, на asm. До того было 2 успешных - на asm и на C. Писать надо именно на asm - по разным причинам. Я понимаю что можно написать на С и посмотреть что там сделает компилятор с оптимизатором, но пока хочется поковыряться самому Общую логику и алгоритм работы уже составил, осталось красиво реализовать это на asm - оптимально не по размеру кода а по скорости при любых ветках ветвлений - то есть, если кусок кода будет делаться 50 тактов в 99 случаях и 1000 тактов в 1, то пусть лучше он каждый раз делается гарантированно по 500 тактов
Возникают в изобилии коротенькие логически законченные куски для перевода в asm. Например

Код

signed long int S = 0;
float s = 0, ds = 0;
signed char P = 0;
......
s = s + ds;
if (s < 0) {
    s = 1 - s;
    S = S - 1;
    P = P - 1;
    if (P < 0) {P = 3}
    }
elseif (s >= 1) {
    s = s - 1;
    S = S + 1;
    P = P + 1;
    if (P > 3) {P = 0}
    }

В asm s и ds будут в формате с плавающей запятой. Думаю что буду использовать sbrc/sbrs их старшего бита - знака мантиссы. Позже напишу код который придумаю - покритикуете помидорами. А вот насчет

Код

    P = P - 1;
    if (P < 0) {P = 3}
..........
    P = P + 1;
    if (P > 3) {P = 0}
    }

придумал - я просто делаю inc/dec rP а потом мне надо найти красивую команду чтобы просто занулить его старшие 6 разрядов - пока точно не знаю какую - and или lsl rP, 6 + lsr rP, 6

Или еще пример

Код

float s, ds;
unsigned char m;
......
if (ds < 1/128) m = 128
elseif (ds < 1/64) m = 64
elseif (ds < 1/32) m = 32
elseif (ds < 1/16) m = 16
elseif (ds < 1/8) m = 8
elseif (ds < 1/4) m = 4
elseif (ds < 1/2) m = 2
else m = 1

Написано коряво, только суть. Теперь буду думать как это красиво на asm написать...

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

Сообщение отредактировал _Ivana - Jan 28 2012, 15:54

[SasaVitebsk]

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

[_Ivana]

Продолжая сумбурные имхоизлияния:
Действительно,

Код

    P = P - 1;
    if (P < 0) {P = 3}
..........
    P = P + 1;
    if (P > 3) {P = 0}

отлично работает как

Код

;dec        R22;
    inc        R22;
    andi    R22, (1<<1) + (1<<0)

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

[_Ivana]

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

Код

;*******************************************************************************
*************
;* Полная компактная и скоростная библиотека арифметических процедур для работы с числом
;* в 32-х разрядном формате стандарта IEEE с плавающей точкой.
;* Автор: 1998,1999 by Jack Tidwell.
;* Исправление ошибок и переработка с целью уменьшения размера кода: Зубовым Сергеем, 2008 г.
;* Размер кода: 208 words (410 bytes)
;* Число с плавающей точкой хранится в четырёх байтах:
;* 1-й - байт порядка (expon1, expon2)
;* cостоит из бит: 7 - знак числа (1 - отрицательное число)
;*                 6 - знак порядка (1 - положительный порядок)
;*                 NEG( 0x40 - 0x0[0..5] ) - значение порядка
;* 2-й - старший байт мантиссы (mant1h, mant2h)
;* 3-й - средний байт мантиссы (mant1m, mant2m)
;* 4-й - младший байт мантиссы (mant1, mant2)
;* Процедуры:
;* FADD - сложение
;* FSUB - вычетание
;* F_MUL - умножение
;* FDIV - длеление
;* FLTNEG - инвертирование знака первого аргумента
;* MINRES - обнуление первого аргумента
;* SWAPACC - обмен содержимым между первым и вторым аргументами
;* ITOF - преобразование формата числа из целого знакового в формат с плвающей точкой
;* FTOI - преобразование формата числа из формата с плвающей точкой в целый знаковый
;*******************************************************************************
**************

Сейчас попробую и думаю все получится. И допишу в библиотеку функцию умножения на степень 2. А может и ещё какие.

[_Pasha]

Ы! avr-libc
Берем , курим папочку /libm/fplib/ и, (оно ж уже работает) выбрасываем все ненужные (с субъективной точки зрения) вещи. Я думаю это будет тошонада.

Сообщение отредактировал _Pasha - Jan 29 2012, 11:32

[zombi]

Не буду утверждать на 100% что это правильно, но у меня както исторически сложилось хранить в 1-м байте младший а в 4-м старший байт целого 32-х битного числа.
С float не работал.
Неплохо бы добавить ешё и фукцию преобразования числа в строку ASCII.

Ы! avr-libc
Берем , курим папочку /libm/fplib/ и, (оно ж уже работает) выбрасываем все ненужные (с субъективной точки зрения) вещи. Я думаю это будет тошонада.

Нифига не понял как и что там искать?

[_Ivana]

_Pasha спасибо, покурю. Но одно из требований заказчика - использовать именно данную Tidwell - Зубова библиотеку для плавучки. Уже почти разобрался, дописал функцию.

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

ЗЫ помимо плавучки продолжаю думать над остальными банальными человеческими вещами - как переводить их на РИСК язык команд asm...

[_Pasha]

Нифига не понял как и что там искать?

Непонятно, что непонятно.
avr-libc-1.8.0.tar.bz2 он последний по дате
Открываем 7zip-ом

[sigmaN]

Если честно, то я не понимаю зачем плавучка на AVR и уж тем более(мне кажется) не стоит ради неё так напрягаться, чтобы аж согласовывать форматы на асме и т.д..
ИМХО, потратить те-же силы на перевод расчётов на фиксированную точку будет разумнее и по тактам и в плане опыта работы с фиксированной точкой, который будет применим на любых архитектурах, в отличие от АВР асма.
Может быть ещё раз переговорить с заказчиком по поводу той плавучей библиотеки и её необходимости?

P.S. Использовать плавучку удобно там, где есть FPU или там где есть для неё запас производительности(без FPU) а расчёты нет сил/желания/времени переводить в фиксированную точку. В остальных случаях от плавучки толку ноль, ибо как не крути, а она просто пожирает ресурсы.
Мне кажется, что при условии отсутствия FPU, один и тот-же алгоритм в фиксированной точке всегда обгонит плавучую реализацию(хоть как бы вы ту плавучку не оптимизировали).
Если не прав - старшие товарищи пусть поправят.

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

[_Артём_]

Если честно, то я не понимаю зачем плавучка на AVR

Чтобы считать с использование float, math...
что тут непонятного

не стоит ради неё так напрягаться, чтобы аж согласовывать форматы на асме и т.д..

Да, не стоит

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

Конечно обгонит. И где те алгоритмы?

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

Во дают

Т.е. в масштабах AVR перевод алгоритма в фиксированную точку видится мне не такой уж сложной и трудоёмкой задачей.

Где можно скачать?

[maksimp]

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

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

Есть алгоритмы, где диапазон значений возникающих чисел очень велик. Кодек JPEG в этом смысле удобен - там на всех этапах числа в вполне определённых нешироких пределах. Про другие кодеки точно не знаю но вероятно тоже.
А вот попробуйте найти собственные значения матрицы 10х10. Пусть даже все её элементы - целые от -127 до 127. Для AVR задача вполне по потребностям в памяти.
То есть алгоритм в фиксированной точке всегда обгонит плавучую реализацию, но только если этот алгоритм в фиксированной точке вообще получается.

[_Pasha]

Если честно, то я не понимаю зачем плавучка на AVR

А куда девать численные методы, которые не обязательно сойдутся в диапазоне представления фиксед? Не, я понимаю, CORDICи всякоразные, ЦФ, но есть же много другого. Полиномиальные аппроксимации, например

[Xenia]

Те, кто согласны AVR32 тоже считать AVR-кой , могут использовать серию AT32UC3C, у которой есть аппаратная плавучка.
http://download.savannah.gnu.org/releases/

[_Ivana]

Спасибо всем отписавшимся, а sigmaN - отдельное
Судя по всему, как я ни ужимаюсь, как ни дописываю дополнительные функции в и так уже "скоростную" плавучую библиотеку - я не влезаю по скорости. Причем, в разы и десятки раз Собственно задача - драйвер железяки, требуется высокоскоростное управление по 2-м каналам ШИМ, выдача кучи дополнительной информации и реакция на входящие параметры, которые будут передаваться как раз в этой плавучке. Плюс это обязательно на ATmega48P с 512 байт ОЗУ и без аппаратной плавучки - ибо их судя по всему у заказчика на складе завались и надо куда-то применить Так что всякие Кортексы, AT32UC3C и прочее с аппаратной плавучкой и щедрыми мегагерцами будут мной осваиваться в других проектах
Хотел вынести расчеты в отдельные периодические "паузы задумчивости" - нельзя, нужна реалтаймовая реакция на датчики обратных связей. Поэтому идея с фиксированной точкой выглядит возможным выходом, тем более что я и так вынужден хранить в плавучке только дробные части чисел а целые - в отдельных байтах, чтобы не терять абсолютную точность!
Так что сегодня пойду обсуждать с руководителем проекта перевод плавучей входящей/исходящей информации в фиксированную точку и внутренние расчеты уже в ней. Далеко не факт что и при этом уложусь, но все интереснее попробовать варианты

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

Сообщение отредактировал _Ivana - Jan 30 2012, 15:49

[_Pasha]

Насколько я помню, вычисления полинома 3 порядка в плавучке отнимают не более 1000 тактов, и это на Си. Может, в консерватории что-то? Упрощения, выборочные переходы к целым итд?

[_Ivana]

вычисления полинома 3 порядка в плавучке отнимают не более 1000 тактов, и это на Си

это, если я не ошибаюсь, и если "в лоб" и все параметры в плавучке - 6 умножений и 3 сложения, не считая перемещений-копирований аргументов и записи промежуточных результатов в ОЗУ. Сильно сомневаюсь что это влезет в 1000 тактов... Может вычисление не "в лоб" а хитрыми итерационными методами?...

А насчет упрощений - вы правы. Например, если частоту расчета взять кратной степени 2, то умножение на dt сведется к делению на 2^N, что проще и быстрее и в плавучке (я ж функцию дописал ) и тем более в фиксе - просто сдвиг вправо... Сейчас частота = 8кГц, удастся ли привести её к 8192 - не знаю, врядли. А чем грозит "допущение", что умножение на dt при 8кГц я буду делать через сдвиг на 13 бит вправо - пока не понимаю
А еще, если убедить заказчика не менять ускорение в процессе движения, то элементарные приращения скорости будут постоянны и предполагаемый тормозной путь я смогу получить накопительно с начала движения а не рассчитывать его каждую итерацию, боясь что изменилось ускорение и теперь он другой... Но согласится ли заказчик на это?...

И конечно же "консерватория". Пытаюсь выжимать требуемую логику за меньше asm команд, собственно про это и тема, в первом посте 2 Си-шных примера, которые хотел перевести максимально компактно на asm - пока не получается красиво.

ЗЫ ступил - через пару минут понял, что полином 3 порядка это 5 умножений и 3 сложения

Сообщение отредактировал _Ivana - Jan 30 2012, 23:08

[_Pasha]

Сильно сомневаюсь что это влезет в 1000 тактов... Может вычисление не "в лоб" а хитрыми итерационными методами?...

Было тут

[_Pasha]

Сильно сомневаюсь что это влезет в 1000 тактов... Может вычисление не "в лоб" а хитрыми итерационными методами?...

Было тут

[sigmaN]

А куда девать численные методы, которые не обязательно сойдутся в диапазоне представления фиксед? Не, я понимаю, CORDICи всякоразные, ЦФ, но есть же много другого. Полиномиальные аппроксимации, например

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

Алсо по поводу залежавшихся ATmega48P. Однозначно нужно определиться выполнима ли задача. Потому что вы можете потратить очень много времени и сил, пытаясь "впихнуть невпихуемое".

Кстати, алгоритмы обычно обкатывают именно в плавучке, а уже потом анализируют что куда и как и берутся за перевод всего этого дела в фиксированную точку. Там уже и станет понятно возможно ли это впринципе.
Думаю сейчас нужно сконцентрироваться на моделировании всего этого дела где-нибудь в матлабе... Потому как даже если вы откажетесь от меги48 - у вас должны быть весомые аргументы. Иначе заказчик может очень долго стоять на своём, теряя время и деньги. А возможно и сочтёт вас недостаточно квалифицированным.
Также я очень рекомендую ещё раз тщательно пройтись по тех.условиям, плотно пообщаться с технологами. Возможно некоторые требования, как вы и предполагали, удастся либо убрать, либо привести к более удобному виду. Этой важнейшей стадии, ИМХО, часто уделяется недостаточно внимания.

[_Ivana]

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

sigmaN опять все правильно ... Только что говорил с руководителем проекта. Он сказал что заказчик на ограничения по передаче управляющих команд не согласится, от меги48 не откажется и если не будем влезать по скорости - заказчик уже предлагал поставить рядом вторую такую же мегу48 со скоростным протоколом с первой и вынести все расчеты в неё Что нам обоим не очень хочется. Пока выяснили, что в каждом такте выдачи ШИМ команд управления мы ОДНОЗНАЧНО не укладываемся в расчеты, предложил следующую концепцию - мы рассчитываем математику - план действий на некоторое относительно продолжительное время, затем каждый такт управления рассчитываем только необходимое - на основе заранее рассчитанного плана и параллельно делаем долгий расчет для следующего промежутка Может путанно объяснил, но я идею понял и пошёл пробовать реализовывать.

ЗЫ нам все-таки надо как-то "впихнуть невпихуемое"
У нас максимальная частота МК 20МГц, каждые 8 кГц возникает прерывание, на которое приходится максимум - правильно, 2500 тактов. Но модуль связи - приема/выдачи параметров имеет 13 каналов и каждый канал требует по 1МГц - у нас остается только 7МГц - то есть 875 жалких тактов - на несколько умножений, деление, несколько сложений (все в плавучке) не считая остального объема целочисленной математики и остальной логики. В лоб точно не впихнем - будем разделять задачу на долгий расчет стратегии и оперативные тактические расчеты Если не получится и так - нас ждет вторая мега48 рядом и SPI и все прелести обмена

Сообщение отредактировал _Ivana - Jan 31 2012, 22:12

[sigmaN]

Ну удачи Ваи. Надеюсь оно того стоит...
Думаю заказчик ещё не раз пожалеет, что не дал инженерам сразу заложить подходящий под задачу проц, а вместо этого реализовывал свои залежавшиеся меги48.
Главное чтобы вас это не затянуло слишком сильно и контракт был составлен соответствующим образом(с учётом впихивания невпихуемого).
Также нужно серьёзно рассмотреть вариант отказа от проекта.
Иногда отказать от не очень перспективного проекта - это самое правильное решение и лучшая экономия тактов ))

[WHALE]

Может вам стоит подумать об оверклокинге?
Если не использовать EEPROM то мега вполне успешно
гонится мегагерц до 30.

[_Pasha]

Если товарисч заказчег не понимает, я бы ограничил функционал и параллелил уже то, что есть.
Кстати, много залежавшихся 48-х, соединенных в SPI, это уже мультикор

[=GM=]

Продолжая сумбурные имхоизлияния: Действительно,

Код

    P = P - 1;
    if (P < 0) {P = 3}
..........
    P = P + 1;
    if (P > 3) {P = 0}

отлично работает как

Код

    inc        R22;
    andi    R22, (1<<1) + (1<<0)

что и следовало ожидать

В принципе, можно сократить до одной ассемблерной команды, зависит от того, как вы используете Р в дальнейшем.
Идея состоит в использовании битов 7 и 6, например, так
subi r22,-0x40 для инкремента или
subi r22,0x40 для декремента

[demiurg_spb]

зависит от того, как вы используете Р в дальнейшем.

А какие есть варианты? МИХО это всегда индекс кольцевого буфера.
В любом случае придётся учитывать смещении при обращении к массиву, так что особого профита тут не получить пока не заморочишься с линкером и не создашь фэйковый алиас со сдвигом относительно реального массива. Слишком много геморроя из-за выигрыша в один такт. Но мысль сама по себе правильная)))

[=GM=]

У товарища автора 13 идентичных каналов. Так что, вряд ли это индекс кольцевого буфера, но если так, то кто мешает использовать 4 ячейки с адресами 0xY00, 0xY40, 0xY80, 0xYC0 в качестве кольцевого буфера для хранения чего-то-там. В конце концов, чего не сделаешь на асме ради скорости.

[MaslovVG]

ЗЫ ступил - через пару минут понял, что полином 3 порядка это 5 умножений и 3 сложения

А если преобразовать полином к виду ((ах+в)x+c)x+d то получим три умножения три сложения

[=GM=]

Ещё вот подумал об использовании фиксированной точки по сравнению с плавающей. В большинстве практических задач известен диапазон обрабатываемых величин и, как ни странно, диапазон не такой уж большой. Если взять к примеру 40-битную фиксированную точку, то диапазон предcтавимых чисел составит 240 дБ. Можно с Сатурна сообщения обрабатывать :-). В то же время быстродействие обработки фиксточки на порядок выше по сравнению с плавающей. Так что, стоит покумекать и принормировать свою задачу к определенному диапазону.

[_Ivana]

=GM= P в моем случае - это фаза (четверть) периода синуса - при движении шагового двигателя по микрошагам и на определенном этапе вползания в следующий шаг. Чтобы хранить только четверть таблицы синуса и получать из неё любые значения. В любом случае - спасибо за идею инкрементировать 8-битную ячейку одним числом, чтобы зациклить это на 4 - я ощущаю острый недостаток знаний именно подобных asm "фишек". Но вопрос с Р я как раз решил, ибо он простой, один такт роли в данном случае не сыграет. А остальные чисто логические вещи продолжаю грызть с переменным успехом и медленно....
А насчет фиксированной точки - заказчик категорически хочет выдавать/получать все 13 каналов только в плавучке (у него куча девайсов под это заточены), а переводить внутри в фиксу а потом обратно - что-то не решаюсь Пока пошел другим путем - выносить долгие расчеты в т.н. "внешний контур", который может думать подольше - с недостатком в виде отставания и может какими ещё... Вроде даже придумал алгоритм - http://electronix.ru/forum/index.php?showt...99193&st=45 , осталось только проверить что он будет хорошо сходиться при любых условиях.

MaslovVG именно такие конструкции я и смутно предполагал, но не хватило смекалки навскидку додуматься

[sigmaN]

В плавучке...Ойй не нравится мне ваш заказчик... )
Кстати, а как там насчёт использования специализированного драйвера мотора? Тоже нет? Ну ладно. А то у меня просто сложилось впечатление, что управление мотором у вас мало того что забирает много ресурсов, так ещё и не ясно будет ли всё это работать как надо. Я про резонанс, рассинхронизацию и всё такое прочее..

А насчет фиксированной точки - заказчик категорически хочет выдавать/получать все 13 каналов только в плавучке (у него куча девайсов под это заточены), а переводить внутри в фиксу а потом обратно - что-то не решаюсь

Ну а что делать, если везде вас обложили, а по быстродействию без вариантов.

Ещё вот подумал об использовании фиксированной точки по сравнению с плавающей. В большинстве практических задач известен диапазон обрабатываемых величин и, как ни странно, диапазон не такой уж большой. Если взять к примеру 40-битную фиксированную точку, то диапазон предcтавимых чисел составит 240 дБ. Можно с Сатурна сообщения обрабатывать :-). В то же время быстродействие обработки фиксточки на порядок выше по сравнению с плавающей. Так что, стоит покумекать и принормировать свою задачу к определенному диапазону.

+100500

[maksimp]

Ещё вот подумал об использовании фиксированной точки по сравнению с плавающей. В большинстве практических задач известен диапазон обрабатываемых величин и, как ни странно, диапазон не такой уж большой. Если взять к примеру 40-битную фиксированную точку, то диапазон предcтавимых чисел составит 240 дБ. Можно с Сатурна сообщения обрабатывать :-). В то же время быстродействие обработки фиксточки на порядок выше по сравнению с плавающей. Так что, стоит покумекать и принормировать свою задачу к определенному диапазону.

В плавучке мантисса занимает 23 бита плюс один не хранимый всегда равный 1. Итого 3 байта. Чтобы перемножить два числа нужно перемножить мантиссы. AVR выполняет умножение байт на байт за одну команду, чтобы перемножить два 3-байтовых числа нужно 9 команд умножения. И порядки сложить.
В плавучке вычисление spline = ds + tmp * (cs + tmp * (bs + as*tmp)); - то есть 6 операций - занимает 860 тактов (см ссылку выше в теме). то есть 146 тактов на операцию.

А чтобы перемножить два 40 битных числа с фиксированной точкой, то есть 5 байтных, нужно 25 команд умножения. Каждая команда умножения даёт два байта результата, которые нужно прибавить к промежуточному результату (для всех кроме 5 первых умножений). То есть нужно почти в 2 раза больше команд сложения ещё, 40 штук вроде. Итого уже 25*2+40*1=90 тактов. Это без учёта пересылок, вызова функций и т.д.

Таким образом 40 битная фиксированная точка может оказаться и вовсе не быстрее плавучки. И по крайней мере не на порядок быстрее.

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

Выглядит сомнительно. Плавучка не теряет точности целой части от того что появляется дробная. Вы точно убедились что это необходимо?

А ещё в требуемой заказчиком mega48P запросто может нехватить программной памяти! Её там всего 4 кб. Мало.

[_Ivana]

Выглядит сомнительно. Плавучка не теряет точности целой части от того что появляется дробная. Вы точно убедились что это необходимо?

При увеличении абсолютного значения числа его точность (ака точность дробной части) теряется. Поэтому необходимо.

А ещё в требуемой заказчиком mega48P запросто может нехватить программной памяти! Её там всего 4 кб. Мало.

Что делать - будем пытаться вписаться. Тем более, что на самом деле её там всего 512 байт
http://www.ekits.ru/index.php?productID=2567

[sigmaN]

Программная память = flash в данном случае. И её действительно всего 4КБ

[_Ivana]

Верно - я прокололся Просто чаще встречался с ограничениями в нехватке ОЗУ, вот и тут не вдумавшись подумал что речь про неё, ан нет. Гарвардская архитектура, однако А программной памяти там да - 4кб, и туда ещё надо будет засунуть модуль связи, математику расчета движения, ПИД-регулятор тока, сервисные функции индикации и таблицу синуса... Тоже придется проявлять чудеса впихивания.

На крайний случай конечно остается вариант тяжеловесную внешнюю связь вынести во вторую мегу48 с транзитом в основную управляющую тоже мегу48 по SPI - если не будем влезать, то попробуем так. А может и 3 меги затребуем - пусть осваивает складские запасы

[=GM=]

В плавучке мантисса занимает 23 бита плюс один не хранимый всегда равный 1. Итого 3 байта. Чтобы перемножить два числа нужно перемножить мантиссы. AVR выполняет умножение байт на байт за одну команду, чтобы перемножить два 3-байтовых числа нужно 9 команд умножения. И порядки сложить. В плавучке вычисление spline = ds + tmp * (cs + tmp * (bs + as*tmp)); - то есть 6 операций - занимает 860 тактов (см ссылку выше в теме). то есть 146 тактов на операцию.
А чтобы перемножить два 40 битных числа с фиксированной точкой, то есть 5 байтных, нужно 25 команд умножения. Каждая команда умножения даёт два байта результата, которые нужно прибавить к промежуточному результату (для всех кроме 5 первых умножений). То есть нужно почти в 2 раза больше команд сложения ещё, 40 штук вроде. Итого уже 25*2+40*1=90 тактов. Это без учёта пересылок, вызова функций и т.д.
Таким образом 40 битная фиксированная точка может оказаться и вовсе не быстрее плавучки. И по крайней мере не на порядок быстрее

1) Ну да, надо 9 команд умножения и 6 сложения, чтобы перемножить 3-байтные мантиссы двух чисел с плавающей запятой. Но это не всё, ещё со знаком повозиться, еще надо 48-битную мантиссу результата отнормировать, и экспоненту подправить, ещё надо сравнить с мин. и мах. числом...Вы всё же посмотрите на подпрограммы умножения двух чисел с плавающей запятой. Что интересно, сложение в плавучке не такое простое дело, как может показаться. Надо мантиссы выровнять, сложить, результат пронормировать...

2) Теперь про 40-битные числа с фиксированной точкой. Ну 40 я взял от фонаря, вы и ухватились, а если бы я сказал 64? Поэтому давайте подойдём к вопросу с разумных позиций. Для хранения плавточки нужно 32 бита, т.е. 4 байта., вот и возьмём для фиксточки те же 32 бита. Диапазон представления тоже не маленький 192 дБ. Сигналы с Луны можно обработать :-). Умножение 32х32 я бы точно уложил в 100 тактов, ну а сложение - 4 такта. Вгрубе для вычисления spline хватит 300 тактов против ваших 900 (это ещё проверить бы надо), в ТРИ раза, не хило, хоть и не на порядок.

[_Ivana]

Возможно вас это позабавит, но я написал на 1С симулятор работы с моим МК, плавучей библиотекой, ОЗУ.... С выводом любой - текстовой и графической отладочной информации, статистики и прочего по результатам работы алгоритма, возможностью сначала написать и отладить алгоритм в человеческой математике, проверить графически результаты его работы и там же перевести и посмотреть в математике МК. Ошибки ловятся на ура - я просто не представляю, как бы я их ловил в АВР-студио, без графики, с долгим временем симулирования. А если добавить в мой симулятор регистры и asm команды (что несложно но врядли нужно), будет почти труЪ

[sigmaN]

1С? Нда.. Месье однако знает толк в извращениях и совсем не слыхал про протеус для симуляции МК. И про маткад для

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

[_Ivana]

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

[ReAl]

Оффтоп — просто вспомнилось.
Где-то когда-то в эхах прозвучало по поводу какого-то вируса «в отместку я антивирус написал на Clipper-е»

[Ruslan1]

Маленькое замечание.
В старозатертые времена у Майкрочипа предлагалась даже специальная ассмовская библиотека плавучки, оптимизированная под скорость. Она вся была написана под внутренний формат представления данных (порядок следования битов был иной чем в 754-м стандарте). Причем варианты (если правильно помню) были и под 4 байта и под 3 байта. Для общения с внешним миром были функции конвертации этого внутреннего формата в стандартный IEEE.
Может и Атмел такое сделал под свои камни, а вам только поискать нужно?

[demiurg_spb]

Может и Атмел такое сделал под свои камни, а вам только поискать нужно?

Нет. Атмел ничего "такого" не делал.
Максимум fixed-point арифметика в avr-gcc.

[Ruslan1]

Нет. Атмел ничего "такого" не делал.
Максимум fixed-point арифметика в avr-gcc.

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

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

PPS Ну нет так нет.

[_Ivana]

С наличием плавучей библиотеки то как раз проблем нет - она дадена. Только конечно некоторые простые функции придется ещё дописать. И самое что меня больше всего в ней беспокоит, это следующие вопросы
1) выдает ли она когда нибудь -0 в качестве результата (ноль с выставленным байтом знака)
2) как она пережевывает этот -0 в качестве входящего параметра
3) как она пережевывает +- бесконечность в качестве входящего параметра для арифметических операций и что выдает
4) как переводит в целое число если оно не вмещается в подготовленные для него 3 байта
Ну и ещё некоторые вопросы. Часть из них можно проверить, но есть ли гарантия что поведение при проверке будет аналогичное всегда при любых случаях?

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

ЗЫ ну и конечно если библиотека работает в своем формате, это потребует перевода всех входных и выходных параметров из IEEE и обратно - а это должно быть оправдано только существенной прибавкой скорости выполнения операций в ней, иначе как-то необоснованно получается.

[_Pasha]

Хм. хотя они вроде сразу нормальный Си предлагали, наверное тогда да, никто на ассемблере и не извращался в AVR.

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