Возник вопрос по сабжу (решил быстренько слепить термометр на 7-сегментном индикаторе). Если с целыми положительными температурами вопросов не возникло (сдвинул результат преобразования на 4 бита вправо) и получил градусы.
То с отрицательными появились непонятки.
Обычно на форумах вижу преобразование из отрицательных значений через побитовую инверсию с добавлением единицы к результату. Вроде как работает в протеусе, хотя при некоторых значениях получается на 1 больше почему то.
Но главная непоянтка с долями градуса.

ИИ в гугле советует сделать всё просто:

int16_t raw_temp = (raw_data_byte2 << 8 ) | raw_data_byte1; // Combine bytes
float temp_C = (float)raw_temp / 16.0; // For 12-bit (0.0625)

Получаем результат с плавающей точкой. Но мне не хотелось бы к плавучке приходить из за сложностей потом на разряды индикатора её выдёргивать.

А инверсия побитовая с добавлением единицы у меня почему то даёт не тот результат..

Как правильно тот скратчпад 16 бит преобразовать из отрицательных температур?

frac - дробная часть, tmp - целая часть, для отрицательных температур очищайте знаковые старшие биты.

Лет 15 назад я делал термометр на Tiny2313 и DS18B20-

Спойлер

Вложение:

Схема термометра.PNG [34.82 KiB]
Скачиваний: 241

Нормально он минус показывает..

Спойлер

Модель в протеусе сделана на AT90S2313, "в железе" работает на Tiny2313.
Прошивка позволяет работать с одним и двумя термодатчиками.

Под ассемблером там проблем нет.
Вроде и под Си ардуиняче чего то было...

а там вроде старший байт заполнен раскопированным битом знака обзовем unsigned char h_raw
а младший байт (unsigned char l_raw) это само значение signed c младшим битом ценой в 0.5C
по сути это означает что если загрузить это в signed int16 и разделить на 2
то знак будет знаком, а модуль будет модулем. а младший выдвинутый бит если задвинуть с младшей стороны в char и умножить на 5 - дробной частью.

а если хотим модуль на коленке без abs() и прочей высшей математики , а с простейшей аля asm,
то примерно так думаю сойдет:

ну понятно что там всего 2 или 3 переменные (регистра) нужны,
остальные для наглядности исключительно..


не проверял, если накосячил скандачка спросони ... вобщем настоящий кот поленится пинать

Как вариант. Проверяется принятый результат, знак запоминается. Если отрицательный, конвертируется. Умножается на 10 и сдвигом делится на 16. К полученному результату прибавляется значение флага C для правильного округления.

Спойлер

Код:

; Считанные данные находятся в R11:R12
; ZH=0
LCD_CONVERT:
   CBI   ACSR,MINUS   ; очистить признак минусового результата
   
   CLR   R10
   
   TST   R11
   BRPL   GO_PLUS
   COM   R11
   COM   R12
      
   ADC   R12,ZH
   ADC   R11,ZH
   SBI   ACSR,MINUS   ; установить признак минусового результата
GO_PLUS:
   RCALL   MULT10
;R10,R11,R12 результат старший-младший
   LSR   R10
   ROR   R11
   ROR   R12

   LSR   R10
   ROR   R11
   ROR   R12

   LSR   R10
   ROR   R11
   ROR   R12

   LSR   R10
   ROR   R11
   ROR   R12
; разделить полученное значение на 16, чтобы
; получить десятичный эквивалент результата
   ADC   R12,ZH
   ADC   R11,ZH
   ADC   R10,ZH      ; округление результата

   RCALL   KALK1
   RET   
;************************************************

Короче, психонул и решил начать с ..протеуса. Думаю, а вдруг это он мне мозг выносит?
Решил выплёвывать в терминал получаемые два байта скратчпада температуры.



24,6 - 0x0188
24,5 - 0x0188
24,4 - 0x0180
24,3 - 0x0180
24,2 - 0x0180
24,1 - 0x0180
24,0 - 0x0180



Короче, выходит моделька DS18b20 дробную часть как то странно выдаёт.

У него ж точность ±1.5℃ в расширенном диапазоне температур, а воспроизводимость ±0.5℃. Зачем вообще пытаться из этого УГ пытаться получить температуру?
Возьмите уж NTC…

Добавлено after 1 minute 27 seconds:
Mursik, а это точно B, а не S?

а в чём собственно вопрос ?
для начала как обычно смотрим даташит...



видим что при отрицательных температурах получаем отрицательное число (единица в первом разряде).

а далее всё как обычно... работа со знаковыми переменными...

//DEC -0...-2.147.483.648 | 0...2.147.483.647
//HEX -80 00 00 00...ff ff ff ff | 0...7f.ff.ff.ff

Проверил у себя,шаг в свойствах DS18B20 поставил 0,0625,работает норм,вот снижал от 24,5 до 23,9 с шагом 0,0625


А здесь снижаю с -0,0625 до -0,625

Продолбался с протеусом (v9), плюнул, стал из даташита ту таблицу тупо в программе подсовывать вместо полученного с датчика значения - получил заданные значения.
Стало быть моделька в протеусе врёт.
На опцию "granularity" в настойках модель не реагирует - выдаёт сильно грубый шаг.

Первое действие
temp=(~temp)+1
разделяем старшую часть и младшие 4 бита (включено 12 разрядное преобразование)
temp_h = temp >> 4
temp_l = temp & 0x000f
далее декодирование целой части в код сегментов целых
Записать коды сегментов "минус" и "запятая" в соответствующие знакоместа дисплея
Получить значение дробной части в целых числах исходя из веса разрядов в ранее выделенной младшей тетраде данных
бит 3 = 5000
бит 2 = 2500
бит 1 = 1250
бит 0 = 625
далее обработать получившийся результат для вывода в раздел индикатора, выделенный для дробной части.
Воть как то так ...

Блин, вы серьёзно ?
Если на Сях, то всё очень просто. Тупо берём и считываем с датчика 2 байта в знаковую переменную. И всё, получаем температуру с необходимым разрешением и знаком.
Для перевода в градусы, просто делим значение на 16 (для "B", разрешение 0.0625) или на 2 (для "S", разрешение 0.5).
Всё.

Беда такого деления в плавучем результате. Если куда printf() плевать оно конечно само разгребет, но если ручками на 7-сегментный индикатор раскладывать, тут тут геморно с флоат воевать

Алгоритм со времён ассемблера однако.
Где там быстро математику сделать?
Заодно и в сегментный код перекинуть проще.

Вот в баском,переменные только Т=два байта,остальные один байт,проверил в протеусе.