МК ATmega8, компилятор WinAvr. Нужно записать число float в eeprom. Была идея сначала домножить число на 10, потом искать остаток от деления на 100, и писать по 2 цифры с помощью eeprom_write_byte(). Что-то мне подсказывает, что можно проще Может с помощью eeprom_write_block() ? Тогда как?

напр так:

extern eeprom_write_block(unsigned char *dat, unsigned char count);

void write_float2eep(float val)
{
union{
float fnum;
unsigned char vl[sizeof (float)];
}eep;
eep.fnum = val;
eeprom_write_block(eep.vl,sizeof (float));
}

А, почему сразу не так:
eeprom_write_block( (unsigned char *) &val, sizeof (float));

Непонятно как заполняется массив vl. Объясните, пожалуйста где val делится на байты и записывается в массив.

Зачем что-то делить? Память и так зачастую имеет байтовую организацию.
Просто передаётся указатель на память (на массив из 4 байт - он же float), и телемаркет:-)


eeprom_update_block поинтересней

А прочитать как?
ерунду какую-то выводит

Вы в функции



знаете по какому адресу в eeprom запишется массив байт?

Я не знаю. Вы, похоже, тоже. Тогда почему вы чего-то считываете с адреса 0x10?

я писал

Ну тогда сделайте так:

Работает, спасибо.

Когда нужно много чего разного в ЕЕПРОМ писать-читать, всегда использую предложенный здесь подход - объявления union.
Например:

#define ucha unsigned char
...
typedef union {
struct {
ucha csL, csH, N1, N2, N3, Coeff, R1[TABLES_SIZE], R2[TABLES_SIZE], R3[TABLES_SIZE];
}s;
ucha mc[SIZEOFEEPROM];
}Type_My_Data_in_EEPROM;

extern Type_My_Data_in_EEPROM u;

Теперь в программе везде обращаюсь к элементам союза так

u.s.N1
u.s.Coeff
u.s.R1[...]

и только в подпрограммах записи-чтения "вспоминаю", что это еще и массив:

for( i = 2; i < SIZEOFEEPROM; i++ )
{
u.mc[i] = EEPROM_read_byte(i);
cs2 += u.mc[i];
}

Т.е. мне пофиг, каковы данные, входящие в союз - там и байты, и флоаты, и массивы... Важно под их размерчик разместить "поверх" еще и массив ucha mc[SIZEOFEEPROM] (что и есть сутью союза)

А вы не интересовались оверхедом, возникающим при таком "союзном" доступе к данным?

А откуда там оверхэд берется, не подскажете?

Я чё-та не соображу, вы переменную заводите с этим типом(Type_My_Data_in_EEPROM) и она кушает свои честные SIZEOFEEPROM байт оперативки в не зависимости от того, что возможно в конкретный момент времени программе нужны всего пара байт из EEPROM?
Думаю это и есть тот самый оверхед, о котором говорил rezident.

Ну и для чего вся эта лабуда с union, когда можно просто и ясно:

А для чего явное задание адреса цифрами, да еще и без приведения к указателю?

Я просто хотел показать, как писать/читать структуру в/из eeprom. Ясно, что указатель "куда" в eeprom надо как-то по-приличнее определить, но и что-то напутанное собой представляет.

Это с непривычки. ведь читается вполне ясно.

AVR-овские штучки.

Я не утверждаю, а спрашиваю/интересуюсь. Для данных в EEPROM может и не будет оверхеда, а вот для памяти данных при использовании union некоторый оверхед все же возникает.

Нет там никакого оверхеда. Беда в том, что это непереносимая конструкция. Для записи/чтения это не играет никакой роли - все на одной системе под одним компилятором. Вопрос в том, на кой это надо, если безо всяких union работает.

Вообще все это относится к сериализации данных. Про это много чего понаписано.

Конечно нет. И про ОЗУ тут напрасно беспокоятся. Совершенно нормально, что я переношу из ЕЕПРОМ в ОЗУ все оперативные данные, работаю с ними - а при необходимости прячу снова в ЕЕПРОМ. Вытаскивать 1 байт из ЕЕПРОМ во время обработки данны - это чуднО


Почему? Куда непереносимая? Или просто Вы ее не переносите


Ну, я это использую потому, что при чтении из ЕЕПРОМ и записи туда подсчитываю контрольную сумму. И мне удобно обращаться поэлементно к массиву. Если и при Вашем подходе можно подсчитывать побайтно сумму - то признаю с готовностью, что много лет у меня болталась напрасно усложненная конструкция Спасибо за подсказку!

Например, тут : http://www.cplusplus.com/doc/tutorial/other_data_types/

написано: "The exact alignment and order of the members of a union in memory is platform dependant."

Или здесь: http://www.drdobbs.com/184403890



Вас же, наверное, интересует crc всей структуры? Кто тогда мешает сделать:

Ну я немного погодя додумал, что погорячился.

Кстати говоря, никто не мешает натравить на начало структуры поинтер char *ptr и прогнать его по всем байтам. Зачем там массив явно объявлять?
Более того, к этому поинтеру можно скобочки нарисовать ptr[] и синтаксически будет выглядеть как массив
Правда, засада может быть если там в структуре для выравнивания дырки имеются. Но, как уже говорилось, нас то интересует crc всей структуры и ничего не мешает посчитать его в месте с теми дырками и с ними же и хранить в EEPROM. Ну а вообще структуру сделать packed чтоб без дырок была....

В общем я тоже не вижу смысла в юнионе. Одни минусы от его использования получаются.

Убедили меня По второму пункту. Ибо, что касается приведенных ссылок


...то здесь я же говорил: использую массив только при записи-чтении всей структуры в ЕЕПРОМ. И мне в это время до лампочки, какое там выравнивание и размещение. Согласны?


Ну, так кто ж знал Спасибо, буду знать. Если crc() есть во всех компиляторах, то даже переносимость не ухудшится.

Но все же не могу не отметить, что в моем случае (с учетом вышеобозначенного способа использования союза) удобство предложенного уважаемым товарищем ergeeff способа - только в обращении к элементам структуры без лишнего .u

какая-то белиберда. Откровенно железозависимые вещи, которые просто обязаны скрываться за каким-нить write///read(void *src, void * dst, size_t size) зачем туда union - ваще непонятно. Структура - это да, без нее сложно.