Както казах важен е диапазонът на величината. Ако той е целочислен, то "навън" няма причина да се ползва флоат. Но да кажем че ако заради идиотско задание се налага, то конвертирането на int към float не е проблем. Особено както в случая се говори за температура...
Освен това в повечето случаи конверсията за "навън" обикновено е към стринг. Което е още една причина да се избягва флоат, ако не се налага

Миро, С тия камбанарии се превърнахте тука в едни владики дето забравиха "на кого се молят".
Аз нямам какво да добавя, опитах се да изложа аргументите си и да загатна че има и софтуер при който излизането "навън обикновено" не е стринг.

Ей това "достатъчно е", когато трябва да го предадеш на някой друг(примерно друг екип от 30-50 инженера) е свързано с написването на малка спецификацийка. Умножи броя на спецификацийките съобразени с "диапазона" по 100 или по 1000 и ще разбереш идиотизма на използването на стандартизиран интерфейс под формата на float(IEEE-754).
Защото в тоя случай няма да е "достатъчно" само да си избереш "мерната единица"(предполагам имаш предвид прецизността), ще трябва и да уточниш и малки подробности, като каква стратегия за закръгляване си избрал например.
Темата от опит да се отлепят релетата от "float при микроконтролери не се използва" няма да отиде към "float е задължителен". Просто трябва от време на време да се слиза от камбанарията.

Zdrav, дилемата не е "оптимизация vs съвместимост" както го приемаш. Едното не пречи на другото. И това е идеята на С/С++.
В тубата има множество интервюта и лекции на Строуструп, в много от които той обяснява мотивацията да създаде езика. В основата са няколко принципа и типовете. Така че типовете не са случайно нещо, напротив те са част от причината да има С/С++.
Както знаеш има и е имало езици без типове преди Ц-то. Ако типовете са нещо, което създава объркване в колектива, то може би този колектив е по-добре да работи на език без типове. Няма типове - няма проблем? Разбира се, има ситуации в които типовете повече пречат. И в такива ситуации е удоволствие да ползваш езици без типове. Примерно на PHP с няколко реда може да свършиш нещо дето на С/С++ ще отнеме десетки страници код. Но общото мнение на всички е, че макар липсата на типове да позволява по-абстрактно и по-лесно програмиране в такива ситуации, това не решава проблема със съвместимостта. Напротив. Много по-трудно се поддържат големи проекти.
Типовете освен всичко останало са създадени точно, за да няма конфликти между програмистите. И както казва Строуструп не е достатъчно само типове, трябва програмистите да могат създават свои типове, а не както да кажем във фортран. Такава е "камбанарията" на С/С++. Ако искаш да няма проблем в колектива - правиш си специализиран тип. В случая тип за температура. Специално в С++ имаш възможност и да си правиш собствени литерали, така че нямаш проблем да ползваш константи от типа 15.0С или 72F. Може да ползваш каквито си искаш мерни единици. Може да сериализираш типа от каквото искаш и до каквото искаш. Наличието на тип не само, че не пречи. Напротив той е създаден точно за това. Това му е смисълът. Не само хората (програмистите) да не се бъркат, но даже и инструментите да са наясно кога температурата трябва да е по Фаренхайт или по Келвин. Кога трябва да се запише/прочете като флоат, кога като инт и кога като стринг или дабъл.
И на всичкото тия възможности да ми твърдиш, че програмистите щели да се объркат... Сори, ама за мен това не са програмисти. Това са идиоти
А що се относя до оптимизацията и до ефикасността. Това е нещо, което зависи от имплементацията на типа/класа. Не е нужно да се знае навън. Може да си имплементираш както си искаш. Но все пак работейки на език, при който ефикасността е един от основните принципи - някак си не върви да правиш неефективни имплементации. А и въпросът не е само до ефективност. Значи пак казвам, че типът малко или много се въвежда с цел да може инструментите да помагат на програмистите. Когато имаш присвояване или каквато и да е операция, инструментът (компилатор, статичен анализ и т.н) да може да прецени ефекта. Но за да се случи това, трябва типът и диапазона на стойностите му да са добре подбрани. Примерно компилаторът няма как да знае че няма отрицателни температури по Келвин. Но ще те предупреди, ако ползваш тип без знак и имаш операции, които могат да доведат до отрицателен резултат. Демек задължение на програмиста е да избере тип, който да съответства по диапазон и който да е ефективен. Така С/С++ ще му помага по-добре. Ако се хвърля на флоат за величини, които нямат нищо с тоя диапазон няма как инструментите да му помагат особено.

Надявам се Коко да е получил отговор на въпроса си( струва ми се че да -в едно две предишни мнения), защото за да не отварям нова тема, ще задълбая яко в офтопик тука.
Като споменахте за 'експорта навън' и юзър дефинираните типове в едно изречение - се сетих да питам: каква е добрата практика за екпортване през сериен порт на данни записвани и съхранявани в
бит фийлдс.
Например: програмиС от"Меден рудник" Пловдивско решава да съхрани инструкция, състояща се от буква(A-Z) следвана от пет цифри (0-9)
и понеже е майна-тарикат , ползва бит фийлдс, в резултат на което инструкцията вместо в стандартните 7 байта, се събира в 4 байта ( 'куул' ...)


В следващия момент обаче това трябва да се експортира към файл или през сериен порт, в резултат на което всяка инстанция на WORD .... WORD.simbol , WORD.numsign ... etc. се трансформира към char (1 байт всяка) и ползата от файдата става нула.
Има ли някакъв свестен метод за екпортване на бит фийлдс през сериен порт или употребата им е само вътрешна?

Не е ясно в колко байта се събира. Пакетирането е implementation defined и зависи от ред неща...




Ако гониш универсалност май няма.Трябва поле по поле сам да си сглобиш експорта/импорта. Както се прави в множеството протоколи

Ако ползваш компилатор, при който имаш контрол върху пакетиране, подравняване и т.н., тогава си знаеш как точно ти изглежда структурата в паметта и евентуално може да експортваш цялата структура, или парчета от нея. Парчетата може да си ги правиш по различен начин с union и т.н.

Ако съм разбрал правилно, трябва да се направи union :

Така вече може после да си ги аксесваш както искаш данните, побайтово, побитово. За UART обикновено има вградени модули в контролера които приемат данните побайтово (от чарс).


Да и това го има. Точно със 64 бита пакети съм наблюдавал страннности примерно на XC8 за microchip Редеше ги разбъркано. Че и за дупки имам спомен.
Предполагам всеки компилатор може от настройките да се настройва.

Значи - излиза че в реденето с бит-филдс на данни, които после ще предаваме през чужд готов протокол няма много смисъл.
И обратното - придобива смисъл там където ще предаваме през някакъв свой супер къстъм протокол (пр. Filibeto Serial) където ние контролираме как да изглежда пакета и как да се сериализира. И тогава вече редим с бит-филдс, за да изглежда точно по тоя начин.

Ако няма да ползваш eeprom-a за друго, махни address и сложи index. И махни от там извеждането на дисплея. Ето така:


По този начин write_EEPROM(0, var1) и write_EEPROM(1, var2) ще запише двете променливи. Същото и при четене.

То има и елементарен начин, обаче никой не поглежда документацията и примерите на EEPROM библиотеката.



https://www.arduino.cc/en/Tutorial/Libr ... /EEPROMPut
https://www.arduino.cc/en/Tutorial/Libr ... /EEPROMGet

Протоколът описва формата на данните. А как той ще се добие е задача на програмиста. Като цяло при микроконтролерите се работи на ниско ниво. В случая с битовите полета трябва да се познава и документацията на компилатора. Пакети до 1байт (char) са безпроблемни. Създаването / използването на библиотека е обвързано много със тези специфики.

Всеки компилатор по правило си има директиви за пакетиране и подравняване. Като искаш да имаш контрол над тези неща, ползваш директивите и готово.

eeproma няма да се ползва за нищо друго,само трябва да се запомнят двете настроени стойност и при всяко включване да се ги прочита.
Температурните диапазони на Temp_regulation Т1 ще е от 50 до 60 градуса,а на Temp_regulation Т2 ще е от 60 до 80 градуса и ще се показва реално измерена температура в мащаб до десети от градуса.Пак казвам че този код е в доста груб и начален вид,просто не знаех как да направя това записване и четене на тези променливи и пуснах кода за да добиете престава какъв е замисъла.

Десети от градуса ти трябват само за ректален термометър.

Не съм съгласен. При бавно изменение на температурата, по-висока резолюция дава възможност за по-кратко време да се види тенденцията на изменение на стойността.

Започва да ме гони параноята. Имам мания за преследване. Сякаш настикаш постояно F5 за да рефрешваш форума, за да не си съгласен с мен.
Шегувам се разбира се.
Има проблеми, като https://en.wikipedia.org/wiki/Bose%E2%8 ... condensate при които ти трябва точност и прецизност. Обаче на него му трябва за температури от 50*С до 80*С, където +/-1 няма значение. Освен това ме съмнява да си има лаборатория в която да си калибрира термометрите. Ако термометрите не са калибрирани няма значение дали показват 65*С или 65.123456*С ако реалната температура всъщност е 63.000000*С.