Change History (14)
comment:1 by , 9 months ago
comment:2 by , 9 months ago
Способ кодирования отрицательных значений переменной .18.0 - дополнительный код
comment:4 by , 9 months ago
Уже не первый раз возникает необходимость запрашивать из плат знаковые значения, и каждый раз для этого приходится добавлять всякий хитрый код, как в данном случае. А все потому, что в протоколе обмена с платами при указании типов переменных не подумали о знаке (не предусмотрели знаковых типов).
Как думаешь, имеет смысл дополнить протокол знаковыми типами целых чисел?
follow-up: 6 comment:5 by , 9 months ago
Уже не первый раз
Да вроде бы не так и много таких значений в платах, температуры и токи в платах питания, да и всё.
Гораздо чаще встречаются числа с фиксированной точкой, которых тоже нет в протоколе.
comment:6 by , 9 months ago
Replying to san:
Гораздо чаще встречаются числа с фиксированной точкой, которых тоже нет в протоколе.
Как это нет? Все имеющиеся числовые типы - как раз с фиксированной точкой. Вот как раз чисел с плавающей точкой у нас нет. Но вроде бы и потребности в них пока не встречалось...
follow-up: 8 comment:7 by , 9 months ago
Ну я в том смысле что сама позиция точки не передаётся вместе со значением.
comment:8 by , 9 months ago
Replying to san:
позиция точки не передаётся вместе со значением.
Она потому и не передается, что позиция фиксирована.
Числа с фиксированной точкой хранят только мантиссу. Числа с плавающей точкой хранят и мантиссу, и порядок (положение точки). Чисел с плавающей точкой у нас не предусмотрено.
follow-up: 10 comment:9 by , 9 months ago
Ну чтобы корректно вывести число с фиксированной точкой, нужно знать её положение. Мы могли бы добавить в протокол тип данных который хранит и мантису и порядок в представлении с фиксированной точкой.
comment:10 by , 9 months ago
Replying to san:
Мы могли бы добавить в протокол тип данных который хранит и мантису и порядок
Это называется число с плавающей точкой. Добавить?
follow-up: 12 comment:11 by , 9 months ago
Нет, я именно о числах с фиксированной точкой. Например, значение 12.44 В. сейчас мы передаём как двухбайтное значение 1244, и в веб интерфейсе гвоздями забито, что последние 2 разряда этого значения нужно отделить в дробную часть. А могли бы передавать как байт целой части (12) и байт дробной части (44), тогда бы значение сразу отображалось правильно.
Но я тут вспомнил что мы те-же значения передаём ещё и в SNMP, где подобного типа нет, так что предлагаю оставить как есть.
comment:12 by , 9 months ago
Replying to san:
Нет, я именно о числах с фиксированной точкой.
Числа с фиксированной точкой у нас заложены в протокол с самого начала, еще ~11 лет назад. Единственное упущение - там ничего не говорится о наличии или отсутствии знака. Де-факто существующая реализация трактует их как беззнаковые (то есть представляющие лишь числа от нуля и больше).
Например, значение 12.44 В. сейчас мы передаём как двухбайтное значение 1244, и в веб интерфейсе гвоздями забито, что последние 2 разряда этого значения нужно отделить в дробную часть. А могли бы передавать как байт целой части (12) и байт дробной части (44), тогда бы значение сразу отображалось правильно.
??? Так оно и сейчас сразу отображается правильно...
Ты сейчас, насколько я понял, говоришь о другом - о разных вариантах представления одного и того же числа (двоичный, двоично-десятичный и т.п.). Я не вижу никакого практического смысла в использовании представлений, отличных от двоичного. Только лишняя работа по перекодированию...
Но я тут вспомнил что мы те-же значения передаём ещё и в SNMP, где подобного типа нет,
Подобного чему? Двоично-десятичному? Наверное нет. А чисто двоичные числа с фиксированной точной там есть.
так что предлагаю оставить как есть.
Так мой-то вопрос был не о новом формате представления существующего типа, а о новом типе (знаковом)!. А в SNMP как раз есть знаковые и беззнаковые типы...
follow-up: 14 comment:13 by , 9 months ago
??? Так оно и сейчас сразу отображается правильно...
Нет, если разработчик платы не сообщит где стоит точка, то отображаться число будет как 1244, а не как 12.44. По нашему протоколу передаётся только мантисса и без дополнительного уточнения от разработчика невозможно узнать положение точки.
comment:14 by , 9 months ago
Replying to san:
??? Так оно и сейчас сразу отображается правильно...
Нет, если разработчик платы не сообщит где стоит точка, то отображаться число будет как 1244, а не как 12.44.
Почему 1244? Почему не 1244000? Почему не 1.244? Почему на 0.00001244? Разработчик платы же не сообщил, где точка! На самом деле отображаться может как угодно. :)
Ты здесь опять говоришь не о том. Формат фиксированной точки предполагает, что положение точки (ну или порядок) заранее известно, поэтому его и не требуется указывать в представлении значения. В данном же примере ты говоришь, что позиция точки неизвестна (разработчик не сообщил). В этом случае числа с фиксированной точкой использоваться не могут, в каком бы формате значение не было представлено. В подобном случае правильно отображено может быть только число с плавающей точкой, так как положение точки указано в его представлении.
Но, ты уже высказал мнение, что типы с плавающей точкой нам не нужны...
Прошу сообщить способ кодирования отрицательных значений, используемый в переменной .18.0 плат RP-400 и RP-650.