Изучение PIC C Compiler(CCS C)

[Eddy71]

Чего-то я уперся в форматы данных..

float Ktemp;
int16 Vdiod;

Vdiod = 2485;
Ktemp =(float)(Vdiod / 295);
printf("Vdiod = %Lu\n",Vdiod);
printf("Ktemp = %f\n",Ktemp);
printf("Ktemp = %g\n",Ktemp);
printf("Ktemp = %e\n\r",Ktemp);

В результате на выходе:

Vdiod = 2485
Ktemp = 8.00
Ktemp = 8.00
Ktemp = 8.000000E+00

должно получиться дробное число:
2485 / 295 = 8.423728813559322

Но на печать вылетает нифига не дробное. Понимаю, что компилятор смотрит на циферки, считает, что для экономии программной памяти проще i16/i16 поделить и так и делает. Потом результат записывает в переменную float. Экономно, да. Но дробная часть теряется.

Как его заставить в этом месте не экономить память?

[j-Roger]

или
Ktemp = Vdiod / 295.0;
или
Ktemp =((float)Vdiod) / 295.0;

[Eddy71]

Прикольно, но только что сам до этого дошел. Точка с нулем сработала

[Bill]

или
Ktemp = Vdiod / 295.0;
или
Ktemp =((float)Vdiod) / 295.0;

Во втором варианте '.0' здесь лишние

Ktemp =(float)Vdiod / 295;

[Old_Monster]

Ktemp =(float)(Vdiod / 295);

Хм, я мне с первого взгляда пришло в голову "volatile"....
Когда-то тоже мучился с "оптимизацией" вычислений компилятором.
upd: Правда, не помню - где её ставить. Давно не писал. ЕСЛИ НЕ ОШИБАЮСЬ - это именно отключение оптимизации.
Хотя, по скобкам - у Вас всё считается правильно:
1. делим инт на инт
2. пытаемся преобразовать в float

[wolfeldt]

PCWHD 5.078
https://cloud.mail.ru/public/AwdE/scuJwjwnx
Ошибку с TX буфером в RS232 Проверю позже, после отпишусь.

[ptr]

Прикольно, но только что сам до этого дошел. Точка с нулем сработала

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

[STM32F0]

Во-вторых, не рекомендую на МК пользоваться арифметикой с плавающей запятой. Очень она медленная и отжирает кучу памяти. А ведь почти всегда можно обойтись целочисленной арифметикой.

Где ещё твои рекомендации почитать можно? Ковыряние в числах двойной точности на убитых восьмибитках мало чем уже будет отличаться от ковыряния в типа целочисленной арифметике.

[wolfeldt]

Вообще в CCS есть тип с фиксированной точкой, если кол-во знаков после точки определено. Так же в printf есть модификатор, который позволяет разбивать целое число на 2 части, разделенные точкой.
И что за ненависть к float-ам на МК.
Если задача занимается вычислениями и не требует реал-тайм операций, почему бы и нет, памяти съедает много, это да, но если мк позволяет.
Когда делал хронограф для измерения скорости пули, даже мыслей не возникло с целочисленными делать, так как смысла не было никакого, оптимизация там, где она не нужна.
Так что вот так убеждать что 8 бит Мк не предназначены для операций с плавающей точкой немного не корректно. Тут скорее не к МК, а к задаче
им выполняемой привязано всё.

Ktemp =(float)(Vdiod / 295); ‹- Тут мы сначала делим, а потом приводим тип к float. А так как деление целочисленное, то результат не корректный.

Ktemp =(float)Vdiod / 295.0; ‹- Тут мы сначала приводим тип int16 к float, и затем выполняем деление уже с плавающей точкой, что собственно и нужно. (интересный факт, умножение float быстрей чем сложение =)))

А писать 295.0 , а не 295, это скорее правило хорошего тона и оформления.

[ptr]

И что за ненависть к float-ам на МК.
Если задача занимается вычислениями и не требует реал-тайм операций, почему бы и нет, памяти съедает много, это да, но если мк позволяет.

А где Вы ненависть увидели? Я только рекомендовал не пользоваться ей. Известно, что использование арифметики с плавающей запятой увеличивает размер кода на 3-4 килобайта, а скорость арифметики с плавающей запятой, относительно целочисленной арифметики на long для 8-битных МК, в 3-4 раза медленней.
Хотя не могу не признать, что бывают случаи, когда требуется именно арифметика с плавающей запятой и заменить ее арифметикой с фиксированной запятой чрезвычайно трудоемко или бессмысленно. Но это уже скорее исключение, чем правило.

Если Вы сразу для проекта используете МК с явным излишеством памяти и производительности, то, естественно, можете об этом не задумываться. А вот на младших PIC, ATTiny или STM8 такое расточительство часто вылазит боком.

Если выражаться более конкретно, то для тиражируемых решений выгодней потратить лишние 15-30 минут работы на целочисленную арифметику, чем по доллару на каждый МК в тираже. Для хобби проектов - тем более. Потому как в них, с одной стороны, никогда не известен весь набор функций, возлагаемых на МК и код будет не раз расширятся и улучшаться, с другой стороны - полезно приучать себя сразу писать оптимально, если эта оптимальность не требует увеличения затрат времени на кодирование свыше, чем 50%. Потому что на оптимизацию уже написанного кода потом потратите в разы больше времени, чем на его проектирование оптимальным сразу.

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

P.S. Я в курсе, что некоторые считают, что даже диммер для лампочки надо делать на, как минимум, на STM32. Ну тут уже - "любой каприз за Ваши деньги" )))

P.P.S. Ах да, собственно сама библиотека: https://code.google.com/archive/p/libfixmath/