Добрый день,

STM32F429, Keil 5.16a

Возникла проблема при преобразовании uint32_t в float:

float * value;
uint32_t val = 0xFFFFFFFF;

*value = *(float*)&val;

В результате в *value -1.#QNAN. Что я делаю не так?

В тоже время float a = 0xFFFFFFFF; приводит к значениюю 4.2949673e+009 в переменной а.

Алексей.

Это смотря чего вы хотите добиться. Преобразование чисел делается так


Вы же берете sizeof(float) байт по адресу &val и копируете их по адресу value.

ЗЫ На всякий случай - 4-байтный float число 0xffffffff точно сохранить не сможет, точность будет примерно 7 знаков ~4.2949672*10^9

Мне надо записать и прочитать float в еепром.

Есть функция

uint8_t EEPROM_Read(uint32_t Addr, uint8_t * buf, uint32_t count);

которая читает в uint8_t буфер байты. Если еепром чистая, то в буфере будут все 0xFF.

Функция, которая читает float, выглядит так



Вот она и глючит.

Это не она глючит

ок, не она. А что (кто)?

я ж откуда знаю. У вас проблема в чем? Прочитанное не совпадает с записанным? Или то, что чистая eeprom дает вам NAN?

ЕМНИП, float, в котором все байты 0xFF, - это неправильный float. Вот оно и ругается. Не все возможные коды допустимы для float.

он не ругается, он говорит, что это NaN - Not a number. Это допустимое значение для float...

Вот тут можно поклацать и посмотреть http://www.h-schmidt.net/FloatConverter/IEEE754.html

float a = 0xFFFFFFFF; приводит к значению 4.2949673e+009 в переменной а.











Именно. Причем для приведенного выше примера с присвоением в переменной число.

Ну ладно, это вопрос интерпретации.
Но исходный вопрос как бы иллюстрирует кашу в голове у вопрошающего.. Там надо начинать с начала. Что хотим сделать? Что не получилось? Почему не получилось? Ну и т.д.

И что? Это же преобразование чисел по правилам арифметики, а не интерпретация 4-х байт как float

Забавно, что Вас это удивляет.
Попробуйте понять, почему a и b будут иметь разные значения:

Это же азы. Нельзя же так...

ок, теперь ясно, спасибо.




В переменной "а" не NaN, а число. Пример приведен лишь для этого, впрочем, выше уже все объяснили.

union в помощь.

Стесняюсь спросить, а зачем тут union?

Не стесняйтесь, спрашивайте. ТС хочет писать в епром float, union поможет ему это сделать, я вот даже любезно подыскал исходничек.

Кастингом тоже можно. С union можно напороться на разницу в длине (я не о данном случае, а вообше), а делая кастинг на байтовый указатель, приходится явно указывать длину.

Поделюсь одним своим приемом.

Мне, пока не придумал как все возложить на компилятор, всегда приходилось строить таблицы адресов, по которым в EEPROM хранятся разные параметры.
Вот техника как избежать этого.

1. Объявляется тип структура, которая содержит все поля для записи в EEPROM.
2. Создается указатель типа этой структуры, который равен нулю.
3. Адрес поля структуры является адресом, по которому надо писать в EEPROM. Длина типа поля (или поля структуры) равна количеству байт для записи.

Все просто и легко модифицируемо. Функция записи в EEPROM не заморачивается с другими типами кроме однобайтовых.

Это когда толпа теток в нижнем белье и без?

Оно конечно можно по всякому, но по вашей же ссылке

В белье -- это не наш метод. Только без.

и?
Очевидно ТС не силён в указателях, я предложил решение, на мой взгляд более правильное чем указатели.

За приведение адреса двоичных (не текстовых!) данных к указателю на char бить линейкой по рукам. Есть uint8_t в stdint.h, для поборников чистоты C89 есть unsigned char.

Не более правильное, а альтернативное. Кастинг типов кстати используют чаще чем union в подобных случаях.

Вот объясните, почему кастинг используют, а приведение типов не юзают?

Я все это больше 20 лет по-английски только называю. Так что не все термины помню. Извините если режет слух. Самое шедевральное из русского магазина в Америке:
"Вам сыр писом или послайсать?"

По хорошему все подобные функции должны получать void*. Но почему-то многие пишут их так, что они получают char*. В Си по моему работает неявное приведение, а вот в плюсах приходится писать явно.



Ну если ТС хочет МК и Си, то с указателями таки надо бы разобраться... Ну и насчет правильности можно поспорить. Это же Си, тут операции с указателями - не грязный хак, а основа основ

Именно! в пример - memcpy. Копирует что угодно и сколько угодно, но с размером в байтах. Сам когда-то на заре принмал входящие данные в char*. Давно отказался.
Всякие char, uint8_t и прочее однобайтовое - лишь чтобы статически заререзвировать буфер на этапе компиляции под пока неизвестные данные.

Спорить не надо, потому что это только моё мнение и я не утверждаю что это абсолютная истина.

Граммар наци негодуэ. Тогда уж "тайп каст". Или "кэст" - на мериканский манер. Или вообще "type cast" - буковки-то на клавиатуре присутствуют

Дык уже сказали как правильно. Я кстати учил по-русски, но это еще в СССР было. Забыл.

При этом автор такого исходника свято уверен, что это указатель на байт. Вот за это и бить. "Просто char" - это символ, и должен использоваться только для работы с символами. Для работы с байтами есть uint8_t или, в крайнем случае, unsigned char. Осознанное и правильное использование void * - это уже следующий уровень мастерства.