Нещо бъркаш в сметките - според мен е около 2 пъти по-бърз

Ако имаш математическата библиотека на сорс я постни, да тествам и с нея.

Не знам дали е 2 пъти, ама при мен излизат 137 милисекунди, а ти говориш за микро.... ?!?

при теб (както и при мен) функцията се вика 142'000 пъти

моята честота е 96, а твоята 80

моето време е 54 секунди, а твоето 137

смятам го на око като x2

Е, това е друго...

Библиотеката имаш ли я?

при мен,
tot=142000 (вътрешния цикъл го намалих на 1000)
времето е 11.238668s. за едно извикване на testCalcSpeed()

PIC32MX695F512L, 80MHz, без никакви прекъсвания

relsys,

току-що проверих в настройките на проекта - всичко е по подразбиране освен едно - Floating point: FPv4-SP (Soft ABI). Библиотеката е стандартната математическа библиотека на GNU-C99.

Имам чувството, че за да получиш този резултат, си компилирал с опция за софтуерна емулация на float изчисленията... провери си настройките! Резултата на колегата Cino е това, което се очаква от този процесор.

Един съвет, ако не са ти го дали вече, при положение, че ползваш флоат а не дабъл, много по-бързо би било да минеш в целочислени сметки
ако имаш МЦУ с ФПУ е друга работа...
но пак да натъртя - точността не е много по различна с флоат и фисираната запетя

Ами да, а и никога не съм я ползвал моята библиотека реално преди, не знам как се държи. При мен се наложи да махна 'f' в края на имената на sinf, cosf....

Охоооо,

това което ти се струва съвсем безобидно (да махнеш f просто за да тръгне програмката) променя нещата доста - функциите без f са за двойна точност. Като ползваш тях при всяко викане на синус или косинус първо се преобразува аргумента към double, после се изпълнява функцията във варианта с двойна точност който е по-тежък и накрая резултата се преобразува обратно във float...

Явно затова при теб е 12 пъти по-бавно от колкото при колегата Cino

ко? не!
Не знам къде ги четете, ама няма таквизи неща...

Значи стандартната библиотека за математики е libm, но за АРМ специално не се ползва оригинала а порт... Най-често това е newlib
При мен е сравнително прясна версия (2.2.0) и като гледам какъв листинг сътвори дълбоко се съмнявам колко е оптимизирана... Масово твоя код (както и тригонометрията) викат __aeabi_fmul и __aeabi_fdiv за умножение и деление, а последното ми намирисва че пак са забравили да я портнат щото не виждам да ползват инструкции за деление изобщо.

Тъй че ако така съдиш за архитектурата, мнооо си се объркал...

От къде да дръпна библиотеката на сорс файл?

За тригонометрични сметки ако се гони скорост ще има прекалено голяма грешка, пък и ще яде доста памет за да се вкарат в таблици всичките там sin/cos/tg функции.

Сега се присетих за една библиотека която може и да свърши работа:
http://dec64.com/
Само, че трябва да се портва ...

аз не казвам че е идеалното решение, ама требе да прецени кое му триява повечче - точност или бързодействие..
по-точно каква точност отнесено към какво бързодействие
иначе поне за синус/цосинус - те са периодични функции, и само за първия квадрант му трябват таблици
тангенса за малки ъгли е = ъгъла..
и така нанатък и така нататък

ама както и да е, не искам да му разводнявам темата на човеко - мерете цикли на пикове до посиняване

Така поставена задачката няма да даде много полезни резултати. По-добре е да се анализира самата формула чисто математически , като необходими операции (мул,див,син,косин,тан,ехп и т.н.), брой итерации, минимално допустима точност и т.н. От там , според архитектурата на процесора, ще може лесно да се прецени от какъв порядък ще са нужните тактове, съответно и времето според честотата. Отделно ,че самата формула/алгоритъм може да се преобразува във вид удобен за конкретния контролер. Това ще даде границата за най-добрия резултат (най-лошия е безграничен).
В случая не се знае какво точно ще се изтества - контролера, компилатора или програмиста.