WinAVR + float == просто беда Опции

[ARV]

уважаемые профессионалы! помогите понять, что происходит.
есть такой код (это уже извраты в процессе отладки, не обращайте внимание на volatile и прочие несуразности):

Код

volatile static int16_t arg;
volatile static float argf;

int16_t get_temp(uint8_t chanel);

int16_t get_temperature(uint8_t chanel){
    arg = get_temp(chanel);
    argf = arg; // уже на этом операторе argf получает дикое значение, если arg == 92.
    argf = argf - config.offset[chanel];
    argf = argf * config.gain[chanel];
    argf = argf / 1000;
    return argf;
}

config.offset и config.gain имеют тип float

казалось бы все нормально... ан нет! если get_temp возвращает 82, то на выходе имеем нормальное значение 16. если же get_temp возвращает 92, то argf получает значение с 9 нулями!!! разумеется, функция возвращает какую-то ересь...

самое смешное заключается в том, что если get_temp вернет число, например, 100, то результат снова имеет разумный вид...

собираю проект в WinAVR 20100110. раньше доверял этой версии, как самому себе... отлаживаю в протеусе...

может, я где-то туплю по-черному?!

P.S.
похоже, разобрался... ступил. если подключить библиотеку математики (опция -lm) глюки пропадают. при этом очень заметно сокращается объем прошивки!
но не понятно, почему никаких ошибок и варнингов на отсутствие библиотеки...

[alx2]

но не понятно, почему никаких ошибок и варнингов на отсутствие библиотеки...

Видимо, те же символы линкер находил в какой-то еще из используемых Вами библиотек, и код там не очень адекватный...

Смотрите map-файл, там много полезной информации о том, откуда что взяли...

Сообщение отредактировал alx2 - Aug 19 2016, 04:51

[ARV]

код там не очень адекватный...

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

[demiurg_spb]

код вполне адекватный

Вам не про Ваш код говорили, про код, реализующий операции над флоатами не из libm...
По поводу доверия к этой весьма древней сборке.
В ней полно проблем, которые уже давно устранены в более свежих сборках (есть совсем свежак от этого лета).

https://sourceforge.net/projects/mobileches...hots%20(Win32)/

[ARV]

В ней полно проблем, которые уже давно устранены в более свежих сборках (есть совсем свежак от этого лета).

https://sourceforge.net/projects/mobileches...hots%20(Win32)/

у меня вечно какие-то проблемы с новыми сборками...
во-первых, я привык к понятию апгрейда, т.е. накатыванию свежего поверх старого с получением плюшек. в случае avr-gcc это не прокатывает: старый код перестает компилироваться (хоть и по банальным причинам, но все-таки), куда-то что-то пропадает и т.п.
во-вторых, по неизвестным причинам некоторые вещи меняются крайне радикально и в не удобную сторону. например, avr-size вдруг начинает выводить информацию вообще каким-то странным форматом, что не только сналету не понятно, какой объем кода получился, но и после детального анализа вопросы остаются...
в третьих, Eclipse... я установил в него плагин AVR и успешно им пользуюсь с WinAVR. после установки новой версии компилятора у меня вечно проблемы с интеграцией в Eclipse с существующими плагинами...

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