[_Ivana 0]

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

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

 

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

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

 

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

 

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

Изменено 30 января, 2012 пользователем _Ivana

[_Pasha 0]

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

Было тут

[_Pasha 0]

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

Было тут

[sigmaN 0]

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

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

 

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

 

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

Думаю сейчас нужно сконцентрироваться на моделировании всего этого дела где-нибудь в матлабе... Потому как даже если вы откажетесь от меги48 - у вас должны быть весомые аргументы. Иначе заказчик может очень долго стоять на своём, теряя время и деньги. А возможно и сочтёт вас недостаточно квалифицированным.

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

[_Ivana 0]

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

 

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

 

ЗЫ нам все-таки надо как-то "впихнуть невпихуемое" :)

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

Изменено 31 января, 2012 пользователем _Ivana

[sigmaN 0]

Ну удачи Ваи. Надеюсь оно того стоит...

Думаю заказчик ещё не раз пожалеет, что не дал инженерам сразу заложить подходящий под задачу проц, а вместо этого реализовывал свои залежавшиеся меги48.

Главное чтобы вас это не затянуло слишком сильно и контракт был составлен соответствующим образом(с учётом впихивания невпихуемого).

Также нужно серьёзно рассмотреть вариант отказа от проекта.

Иногда отказать от не очень перспективного проекта - это самое правильное решение и лучшая экономия тактов ))

[WHILE 0]

Может вам стоит подумать об оверклокинге?

Если не использовать EEPROM то мега вполне успешно

гонится мегагерц до 30.

[_Pasha 0]

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

Кстати, много залежавшихся 48-х, соединенных в SPI, это уже мультикор :)

[=GM= 0]

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

    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 0]

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

А какие есть варианты? МИХО это всегда индекс кольцевого буфера.

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

[=GM= 0]

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

[MaslovVG 0]

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

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

[=GM= 0]

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

[_Ivana 0]

=GM= P в моем случае - это фаза (четверть) периода синуса - при движении шагового двигателя по микрошагам и на определенном этапе вползания в следующий шаг. Чтобы хранить только четверть таблицы синуса и получать из неё любые значения. В любом случае - спасибо за идею инкрементировать 8-битную ячейку одним числом, чтобы зациклить это на 4 - я ощущаю острый недостаток знаний именно подобных asm "фишек". Но вопрос с Р я как раз решил, ибо он простой, один такт роли в данном случае не сыграет. А остальные чисто логические вещи продолжаю грызть с переменным успехом и медленно....

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

 

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

 

 

[sigmaN 0]

В плавучке...Ойй не нравится мне ваш заказчик... )

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

 

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

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

 

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

+100500