Hi-Tech C & EEPROM & FLASH, как красиво работать ? Опции

[_Pasha]

Доброго времени!
Уж на что в GCC некомфортно получается работать с флешом и еепром, но по сравнению с продукцией hi-tech это - вершина сервиса!
Кто-нить красиво работает в HTC? Имеется ввиду инициализация, работа со структурами... при наличии только EEPROM_READ(address) и __EEPROM_DATA(...).
Грустно все это...

[DL36]

Доброго времени!
Уж на что в GCC некомфортно получается работать с флешом и еепром, но по сравнению с продукцией hi-tech это - вершина сервиса!
Кто-нить красиво работает в HTC? Имеется ввиду инициализация, работа со структурами... при наличии только EEPROM_READ(address) и __EEPROM_DATA(...).
Грустно все это...

Например так

Код

//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
// Восстанавливам данные из EEPROM
//
//+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
void initSetNU(void)
{ unsigned char i, *p, n, N;
  i = sizeof(NUcanal);                    // Размер структуры
  p = (unsigned char*)(NUcanal);            // Указатель на место размещения в памяти
  n = NuCanalStartEEprom;                 // Размещение в ЕПРОМ

  while (i--)
    {*(p++)=eeprom_read(n++);}          //Чтение
}

И чего грустить.

[_Pasha]

И чего грустить.

Вот чего:

Код

/*My extension to working with EEPROM*/
void eeprom_read_block(void* dest, void*src, size_t size);

/*
total parameter set, stored in EEPROM, fits in single record - the simplest way to operate instead of fixed address definition
*/
typedef struct
{
  int fld1;
  long fld2;
} complex_type_t;

complex_type_t* eep_image;
int requested_field;

void main(void)
{
/* blah blah blah*/
eep_image = (complex_type_t*) 0;
eeprom_read_block(&requested_field,&(eep_image->fld1),sizeof(requested_field));
}

А потом эту структуру инициализируем черт знает чем __EEPROM_DATA (...)
И это при том, что параметров может быть несколько десятков.
Проктологи отдыхают...

[DL36]

А потом эту структуру инициализируем черт знает чем __EEPROM_DATA (...)
И это при том, что параметров может быть несколько десятков.
Проктологи отдыхают...

Я ведь привел инициализацию сложной структуры, любого размера, из ЕПРОМ.
Практически я делаю так, поскольку вычислять где и что лежит не интересно, и имеется запись тех же параметров в структуру. Под отладчиком пишу где и что надо, снимаю дамп и переписываю его в исходники.

Код

/*####################################################################
* EEPROM DATA Фактически это номер ячейки памяти с которой выполняем старт чтения
*####################################################################*/
#define NuStartEEprom 0         // Тут первое чтение Именно это значение подставляется
                              // в процедуру чтения и записи
#define NU_DET+sizeof(NuStartEEprom)  // Запись, чтение следующей структуры
...
...
...

Так, что вроде никаких проблем, держать переменные в ЕПРОМ
тоже вроде возможно но смысла я не вижу, поскольку будет большое время доступа.

[_Pasha]

держать переменные в ЕПРОМ тоже вроде возможно...

А как? просветите, плз. Читал-перечитал TFM - не нашел.

[_Pasha]

Полазил по форумам. Нашел, что eeprom - qualifier все-таки есть. А в мануале на PICC-18 v9.61 про него ничего нет. Что за чушь - не пойму

[DL36]

Полазил по форумам. Нашел, что eeprom - qualifier все-таки есть. А в мануале на PICC-18 v9.61 про него ничего нет. Что за чушь - не пойму

В про многого нет, обычно работают в СТД. Хотя и тут есть ограничения, лично я нарвался на проблему 24 битных указателей, так до конца и не смог решить.
Сейчас перехожу на 24-е и с30, по крайней мере таких проблем с компилером нет.

[_Pasha]

Спасибо за консультацию.

[_Pasha]

Вот, наконец-то, нормальное решение. И удобно, и максимально близко к WINAVR, используемому гораздо чаще, чем hi-tech. Работает на основе стандартного макроса offsetof.

Код

#include <stddef.h>
typedef struct
{
  int fld1;
  unsigned char fld2[45];
} complex_type_t;

typedef struct
{
int memb1,memb2;
complex_type_t record;
} paramset_t;

void main(void)
{
/* blah blah blah*/
unsigned char tmp;
tmp = eeprom_read(offsetof(paramset_t,record.fld2[6]));
}

Ессно, это примитив для чтения/записи блока.
P.S. вначале написал, а потом нашел оч. красивую статью: статья

[DL36]

Вот, наконец-то, нормальное решение. И удобно, и максимально близко к WINAVR, используемому гораздо чаще, чем hi-tech. Работает на основе стандартного макроса offsetof.

Код

#include <stddef.h>
typedef struct
{
  int fld1;
  unsigned char fld2[45];
} complex_type_t;

typedef struct
{
int memb1,memb2;
complex_type_t record;
} paramset_t;

void main(void)
{
/* blah blah blah*/
unsigned char tmp;
tmp = eeprom_read(offsetof(paramset_t,record.fld2[6]));
}

Ессно, это примитив для чтения/записи блока.
P.S. вначале написал, а потом нашел оч. красивую статью: статья

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

[_Pasha]

offsetof возвращает смещение поля, за размером надо следить самому.
Пока не могу сообразить где есть привязка к базовому адресу, начала расположения структуры в ЕПРОМ.

У меня вполне логичное правило: размером читаемого блока является размер переменной, в которую выполняется чтение. С записью - тоже пляшем от размера переменной.

Привязкой лучше сделать 0х00, потому что намного удобнее "накрыть" структурой всю систему параметров, и пусть там будет несколько наборов, CRC и прочее. Т.е. это выглядит как глобальный хедер, из которого можно добраться до любого параметра.
И логика в этом есть - библиотечные функции, если они по-местному читают еепром, это не есть правильно с точки зрения портабельности.
Лучше как-нить через

Код

extern int get_timeout (void);// а здесь уже читаем откуда угодно

например так.
ПыСы чтение флеша с набором констант, ессно, аналогично

[DL36]

У меня вполне логичное правило: размером читаемого блока является размер переменной, в которую выполняется чтение. С записью - тоже пляшем от размера переменной.

Привязкой лучше сделать 0х00, потому что намного удобнее "накрыть" структурой всю систему параметров, и пусть там будет несколько наборов, CRC и прочее. Т.е. это выглядит как глобальный хедер, из которого можно добраться до любого параметра.
И логика в этом есть - библиотечные функции, если они по-местному читают еепром, это не есть правильно с точки зрения портабельности.

Да, согласен сделать подобную структуру будет правильно. Но есть еще размер переменной и не всегда это байт.

[_Pasha]

Но есть еще размер переменной и не всегда это байт.

Дык я для блочной пересылки свои функции и использую