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

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

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

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

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

Было тут

Было тут

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

+100500