Отправлено: 21.12.16 23:01. Заголовок: перевести байты в ГВ

Вот на ночь глядя адовищно туплю и не могу произвести элементарное действие :(
дана ёмкость носителя в байтах (строка символов) 2945999958016 и необходимо перевести её в гигабайты. Как бы это сделать поизящнее при том что доступны только 16-битные переменные.

( причем в результате на морде прибора получается 2744.59 GB :( и деление на 1024 в калькуляторе как то не помогает получить нужное значение, как они его там получали...)

 Отправлено: 21.12.16 23:28. Заголовок: Посмотрите модуль дл..

Посмотрите модуль для рекордера Epiphan.

 Отправлено: 22.12.16 00:17. Заголовок: сходу модуль не ищет..

сходу модуль не ищется, а как заставить atol возвращать unsigned значения? а то на 4294967295 она бойко возвращает 1.

 Отправлено: 22.12.16 00:27. Заголовок: Crestron 32-битный ж..

Crestron 32-битный же. 65535 - максимальное число, с которым оперируем.

Один путь - разбирать побайтно, а потом собирать обратно также поразрядно.

Epiphan

 Отправлено: 22.12.16 00:31. Заголовок: так вот и как число ..

так вот и как число 65535 получить из atoi? помню как то поборол это давно, но не могу вспомнить когда и где :(
по умолчанию он signed выдаёт, то есть до 32767 нормально, а потом обратный отчет идет.

 Отправлено: 22.12.16 00:33. Заголовок: Если пришло \xFF..

Если пришло \xFF\xFF\xFF\xFF это и будет 65535.

Если у вас Epiphan - берите модуль и пользуйтесь, оно работает.

В каком виде получаете данные в порт?
Определитесь для чего нужны данные - для расчетов или индикации. Это и определит как и чего дальше.

Задачка простая, но нужно решать похожие головоломки постоянно, быстро из головы вылетает.

 Отправлено: 22.12.16 00:56. Заголовок: Ну вот есть строкова..

Ну вот есть строковая переменная "12345", если подать её в atoi то она возвращает 12345. Как сделать так, чтобы и на строку "54321" возвращалось значение 54321? (Понятно, что переменные unsigned)

 Отправлено: 22.12.16 01:01. Заголовок: Itoa(x); ..

Itoa(x);

 Отправлено: 22.12.16 10:55. Заголовок: upd: проблема только..

upd:
проблема только на 2 серии,(на прошивке 4.008.008) на 3 и последней прошивке atoi и atol работает нормально. Странно.

 Отправлено: 22.12.16 15:20. Заголовок: Все зависит от интер..

Все зависит от интерпретации при выводе на экран (дебагер и т.п.) или если вы определили в программе переменную как signed_integer var, то естественно выполняя var=ATOI("54321") вы получаете КАК БЫ отрицательное для программы число, но опять таки отобразить его можно и как 54321.
И не забываем про ATOL() /LtoA()имеющие разрядность LONG INTEGER 4294967295
По поводу GB то конечно это получается последовательным делением значения байт на 1024/1024/1024 Цифра в итоге получается не та что на дисплее, видимо из за округления до размера кластера для данной файловой системы или что то подобного. Тут либо покурить тему с файловой системой или доп.служебной информацией (проще у производителя узнать формулу), либо ввести коэффициент для соответствия информации на дисплее.

 Отправлено: 22.12.16 15:47. Заголовок: да вроде выяснили уж..

да вроде выяснили уже что зависит от контроллера, функция ATOl/ATOI по разному возвращает результат. Про signed/unsigned я вроде вполне конкретно описал, проблема была именно в этой неоднозначности, так как дома модули писал, но на рабочей системе всё работает правильно, и хрен с ним, 2 серия не актуальна сейчас, хотя я на ней S+ отлаживаю, так как быстрее получается.
Тему закрыть можно.

 Отправлено: 22.12.16 16:24. Заголовок: совпадают выши вычис..

совпадают ваши вычисления с табло устройства?

для конкртеной цифры 2744.59 GB, (2945999958016/1024/1024/1024) уж точно не работает :)

а вот (2945999958016/1024/1024/1023.66) даёт 2 744,587554553025 если округлить то выйдет 2 744,59

 Отправлено: 23.12.16 12:33. Заголовок: Самая общая рекоменд..

Самая общая рекомендация, если стоит задача не терять значимые числа - разбивать приходящие данные на десятичные части, суммировать с весовыми коэффициентами.