[defunct 0]

Да скорее всего так и будет. Просто хочется сделать запас определенный. ВОт этого я и бось - что длительность одного цикла обсчета приблизится к времени отсчета данных АЦП. Причем не обязательно будет использоваться именно ПИД алгоритм, еще есть цель реализовать dq преобразование... вычисление синуса и косинуса.. Поэтому в основном мне и нужен ассемблер. (Я в учебных целях. Есть большое желание реализовать dq преобразование).

Обоснование типа "нужна быстрая математика поэтому - ассемблер" - бредовое.

Вообще-то если нужна быстрая математика брать нужно проц (DSP) где есть реализованные аппаратно требующиеся мат. функции - например проц где синус вычисляется за такт и т.п..

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

 

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

 

А про эффективность и удобство языков хорошо сказано здесь:

 

http://tempo.nnm.ru/kak_prostrelit_sebe_nogu

 

По-русски это удобство превращается вот во что:

1. или написать

y = sin( x );

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

 

2. или неделю промудохаться над реализацией одной только этой строчки на АСМ.

 

Потом, что касается программы на Си - на ней компилятор создает машиный код, но как посчитать например время выполнения одного цикла ПИД алгоритма?

Элементарно - с помощью обычного секундомера:

 

Засечь время, запустить 1 млн циклов, затем разделить полученный интервал времени на млн. - получите время на цикл.

не нравится 1 млн. (тест длится сильно долго или сильно быстро) измените это число.

 

Помоему это очевидно.

 

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

На самом деле не важен, просто закладывайте проц с запасом.

(если пользоваться правилом - всегда закладывать проц с 50% запасом, то достаточно очень грубой оценки производительности - те самые +/-50%)

 

Вот Вы говорите у Вас сейчас есть AVR32 (150Mhz) и LPC ARM ~60Mhz.

У первого есть набор DSP инструкций, у второго такого набора нет. Разница по производительности более чем 2.5 раза. А цена - практически одинаковая.

Так какой смысл такты считать?

[Иван_Я 0]

А если надо работать в нереальном времени? Шутка.

 

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

 

Что такое программирование в реальном времени? Надо обрабатывать высокочастотные процессы? А почему "в учебных целях" нельзя обрабатывать низкочастотные процессы?

 

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

 

А какова частота опроса ADC?

 

) да нет) надо обрабатывать сигналы промышленной частоты (50 Гц). на счет частоты опроса - миимальное количество точек на период - 64.

 

ну да.. можно конечно и на практике оценить...

 

 

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

 

А если надо работать в нереальном времени? Шутка.

 

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

 

Везде говорят, что выполнение программы на Ассемблере сокращает вермя ее выполнения раза в 2. Поэтому и Ассемблер.

 

И потом, ладно, написали программу на Си, а как вести отладку в дизассемблере, если не знать Ассемблер данного проца. Ведь чтобы написать оптимизированную программу даже на СИ надо знать все особенности данного проц. в том числе и его систему команд на Ассемблере.

[scifi 1]

Первое суеверие победили, отлично :-) Осталось победить остальные.

 

Везде говорят, что выполнение программы на Ассемблере сокращает вермя ее выполнения раза в 2. Поэтому и Ассемблер.

Не нужно верить всему, что говорят. Тут очень многое зависит от конкретной ситуации.

 

И потом, ладно, написали программу на Си, а как вести отладку в дизассемблере, если не знать Ассемблер данного проца.

Вы удивитесь: подавляющее большинство программистов процессора x86 не знают его ассемблера и не переживают по этому поводу. Пишут программы на Си и Си++, отлаживают их и не знают печали.

Хотя в Embedded, конечно, ситуация несколько иная. Я частенько заглядываю в дизассемблер, иногда и глюки компилятора выскакивают... Но такты процессора точно не считаю.

 

Ведь чтобы написать оптимизированную программу даже на СИ надо знать все особенности данного проц. в том числе и его систему команд на Ассемблере.

Мне кажется, Вы не с того начинаете. Ведь задача стоит не "написать оптимизированную программу", а "написать работающую программу". Помните слова уважаемого человека Дональда Кнута: "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." ("Нам следует забывать о малых оптимизациях, скажем, 97% времени: преждевременная оптимизация - корень всех зол")

[Sasha_sasha 0]

Элементарно - с помощью обычного секундомера:

 

Засечь время, запустить 1 млн циклов, затем разделить полученный интервал времени на млн. - получите время на цикл.

не нравится 1 млн. (тест длится сильно долго или сильно быстро) измените это число.

 

Помоему это очевидно.

Не факт... Попробуйте сами так сделать...

 

Вот Вы говорите у Вас сейчас есть AVR32 (150Mhz) и LPC ARM ~60Mhz.

У первого есть набор DSP инструкций, у второго такого набора нет. Разница по производительности более чем 2.5 раза. А цена - практически одинаковая.

Так какой смысл такты считать?

С чего это цена одинаковая? Как минимум в три раза разница.

 

Мне думается, автор темы не пока не совсем представляет чего он сам хочет сделать и в процессе этих разговоров стимулирует МЫСЛИТЕЛЬНЫЕ процессы...

[Иван_Я 0]

Я представляю что надо сделать и я об этом писал уже. Надо реализовать ЦОС dq преобразование. Примеры есть от Texas на ассемблере. Был и есть интерес реализовать этот же алгоритм на LPC или AVR32 с учетом их специфики и систем команд. Я понял,что на Ассемблере писать можно. Всем спасибо за свои предложения.

Изменено 13 февраля, 2009 пользователем Иван_Я

[sergeeff 1]

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

[MrYuran 16]

Я понял,что на Ассемблере писать можно. Всем спасибо за свои предложения.

Но не нужно.

Алгоритм такой:

1. Пишете и отлаживаете алгоритм на си.

2. Если всё устраивает - конец, задача решена.

3. Оптимизируете узкие места.

4. goto 2

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

[defunct 0]

Не факт... Попробуйте сами так сделать...

Разве бы я советовал то в чем не был уверен или то что никогда не пробовал? :)

Всегда так и оцениваю. Разве только секундомер с требуемой точностью/разрешением реализую в той же программе:

 

starttime = GetTime();

for( n = N; n; n--)
    f(n);

duration = GetTime() - starttime;
f_time = duration / N;

 

С чего это цена одинаковая? Как минимум в три раза разница.

Смотря с чем сравнивать. Если с МК с ARM ядром и такой же периферией как в AP7000 то цена будет примерно одинаковой.

А если брать что NGW100 от производителя - $50.

плата с любым LPC в той же конфигурации будет не дешевле. Отсюда вывод о цене.

[kons 0]

Ассемблер ARM (не в Thumb варианте) - вообще самый гуманный из ассемблеров, и по простоте может сравниться только с asm PDP11, но с тем всерьез не работал. По опыту, всякие FIR, корреляторы и т.п., написанные под ARM7 на asm могут работать раз в 5-10 быстрее написанных на с. Кстати, подобные вещи и для нормальных DSP поставляются тоже в виде библиотек на asm - только так можно всерьез задействовать все "фишки" процессора типа 2-4 MAC за такт и т.д.

 

Обоснование типа "нужна быстрая математика поэтому - ассемблер" - бредовое.

Вообще-то если нужна быстрая математика брать нужно проц (DSP) где есть реализованные аппаратно требующиеся мат. функции - например проц где синус вычисляется за такт и т.п..

Оно так, оно конечно...Но если вы мне подскажете DSP-однокристалку в TQFP-68, max 100, чтобы у нее все было на борту, архитектура не убогая (не DSPIC), и по цене как SAM7 (TI при тех же RAM/FLASH дороговаты), я буду благодарен. Подумайте, если задача вписывается в 5 DSP-шных MIPS (это 30-50 ARM-овских), то...почему бы и не ARM? Тем более, что в реальности на asm требуется написать только маленькую библиотечку.

 

Но в случае автора:

надо обрабатывать сигналы промышленной частоты (50 Гц). на счет частоты опроса - миимальное количество точек на период - 64.

Есть глубокое подозрение (опять же по опыту ЦОС на ARM), что при частоте дискретизации 3200 Гц можно прекрасно обойтись без asm модулей.

[_Pasha 0]

архитектура не убогая (не DSPIC)

Убогая или наоборот - а заточена как раз на эти задачи, т.е то, что автору надо.  А на асме эти модули потому, что MAC-инструкции имеют столько "побочных эффектов", что не ложатся в квадратную голову компиляторов. Так и смысла нету в высокоуровневом программировании - все равно в матричных операциях не будет архисложностей. Меня самого сначала раздражало то, что во всех Сях для DSPIC невозможно добиться от компилера использования DSP-класса инструкций "не по назначению". Теперь - абсолютно все равно. Кесарю-кесарево, слесарю-слесарево.