Здравствуйте, уважаемые, помогите советом!

Начинаю работать с ARM, установил YAGARTO.
Как только пытаюсь использовать функции типа sin, cos - линкер выдает undefined reference to `sin'
в math.h они объявлены external:

extern double cos _PARAMS((double));
extern double sin _PARAMS((double));

То есть в стандартной библиотеке не реализованы матфункции? Что я не понимаю?

добавте при линковке ключик -lm

Надо указать линкеру, чтоб линковал математическую библиотеку. Ключ -lm.

Гарантировать правильную работу floating point должен адеквтный стартап, но для того, чтобы перестал ругаться линкер отредактируйте в мэйкфайле строчку

MCFLAGS = -mcpu=$(MCU) -lm

Это заставит компилятор добавить к списку библиотечных файлов еще
arm-elf\lib\libm.a


ps: ой, уже натовечали... А вопрошавший может сказать про то, заработало ли без поддержки стартапа?
Как я понял, при компиляции для freestanding environment приходится свой собственный стартап подсовывать (я, во всяком случае, поступил именно так).

pps: успел сам проверить... коллосаль! у меня с моим стартапом заработало! Во всяком случае, функция sin (не в прерывании) работает... Правда, добавило 10 килобайт.

стартап то тут причем?

Скорее всего стартап в данном случае непричем... Просто во всех остальных компиляторах, что я встречал (и использовал для embedded) стартап участвовал в настройках FP калькулятора и/или режимов сопроцессора где он был (в x86).
С тем как это в gcc для arm устроено я еще не успел разобраться.

Если для плавучки использовать коды операции из множества undefined instruction, то в стартапе надо прописАть адрес обработчика соотв. исключения. А более стартап никаким макаком... 

Причем ключик должен быть обязательно после, а не до объектных файлов, в которых используются библиотечные функции.

Огромное спасибо!
С ключом -lm все линкуется как надо.
И, действительно, только когда ключ стоит после объектных файлов. (Если не сложно, объясните, почему так? Ведь если поменять порядок объектных файлов при линковке ничего не меняется?..)

Остался, правда, еще один непонятный момент еще на этапе компиляции:
main.c: In function 'main':
main.c:550: warning: implicit declaration of function 'sin'
main.c:550: warning: incompatible implicit declaration of built-in function 'sin'

такая реакция на вызов функции, хотя я ее не определяю, просто вызываю, x=sin(y);

а math.h сверху подключен?

Используйте Rowley Crosstudio. Это оболочка + gcc.
Оболочка формирует нужные ключи.

30-дневная версия здесь: http://www.rowley.co.uk/arm/
Ну и местные закрома, ясное дело.

да, туплю, закомментирован был)

потому что библиотека - это не объектный файл, а архив объектных файлов. И именно такой порядок описан в документации:

Понятно, спасибо

Появился еще ряд вопросов)

Увеличиваю частоту на выходе фапч с 200 до 240 МГц. Ожидаю, что время выполнения моего кода должно пропорционально сократиться. Однако сокращается оно не на 20, а на доли процента... Рассчитывается преобразование фурье, работа алгоритма с периферией никак не связана.

На данный момент у меня на 200Мгц на вычисление sin тратится в среднем 50 мкс, то есть 10000 циклов... Не много ли это? От чего зависит скорость работы с fp помимо оптимизации самого кода, что бы почитать на эту тему? В документации на Newlib (http://sources.redhat.com/newlib/) ничего интересного не нашел =/

Главное, чтоб знать в каком направлении двигаться: может быть Newlib не самая лучшая библиотека для работы с fp или переход на другую ничего не даст?

А измеритель времени не от тех же клоков запитан случайно?


Это похоже на нормальное значение, хотя библиотеки RVCT работают примерно вдвое быстрее. Просто sin/cos по определению тормозные и мало подходят для работы в реальном времени.

А я, кажется, догадываюсь почему: в newlib-е libm раздваивается
(в math и mathfp) и вызов sin() считает синус два раза, очевидно для
проверки, что бы не ошибиться :)

10,000 клоков не предел, в DM6446 sin() (из DDR2, cache off,
release, no dbg info) считает здак 45,000 клоков и ничего,
только чип горячий и дым из эмулятора...

нет, от RTC


А есть ли способ ускорить работу, пожертвовав точностью? (Есть еще мысль таблицей задать, но уж больно некрасивое решение).


ээ.. то есть??

Есть, и использование таблицы - один из наиболее распространенных. Что же в ней некрасивого?

Можно, например, ограничится одним битом и считать что синус на [0, pi) равен 1, а на [pi,2*pi) равен 0. Но это путь скорби. Обычно, всё-же, сначала задаются необходимым значением точности, а потом ищут вычислитель, который зту точность обеспечит вместе с заданным временем вычисления - т.е. жертвуют деньгами вместо точности.

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

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

Что, конечно, неудивительно само по себе, но что бы так много - 95 на переход, от 125 до 250 на LDM-ы в эпилогах (STM-ы в прологах укладываются за около 20 тактов). Понятно, что тайминг операций с памятью прямо пропорционален отношению частоты ЦПУ и частоты памяти и если включить кэш (я пока не научился работать с CP15) то времена должны улучшиться (в том числе и скорость переходов, так как она косвенно зависит от скорости обмена с памятью), но пока не знаю на сколько.

Вот эти операции и определяют, в итоге, скорость (точнее, медленность) симуляции плавающей точки, где на каждый чих (e.g. целое -> вещественное) свой вызов подпрограммы, т.е. переход, пролог и эпилог. Суммируя, ARM без аппаратной плавающей точки для вычисленений с этой самой точкой можно использовать только от отчаяния. Более подходящее применение - целочисленное преобразование.


Как-так само-собой получилось, ни причины, ни логики не смог увидеть. Может быть, экпериментирование с разными способами. Только вот в math некоторые функции (kf_...) проектировал явно бухгалтер. Еще одна спорная вещь - использование полиномиальной аппроксимации для тангенса. В C&W используется дробно-рациональная аппроксимация, т.е. меньше коэффициентов (6) плюс деление, что м.б. быстрее чем Хорнер с 13-ю коэффициентами, - как сделано в mathfp.

Спасибо, информацию принял к сведению. У меня правда уже есть сомнения относительно моих 10000 циклов на sin, проверю. Не уверен, что частота была действительно 200 МГц, еще не научился правильно ей управлять..