Доброго времени!
Уж на что в GCC некомфортно получается работать с флешом и еепром, но по сравнению с продукцией hi-tech это - вершина сервиса!
Кто-нить красиво работает в HTC? Имеется ввиду инициализация, работа со структурами... при наличии только EEPROM_READ(address) и __EEPROM_DATA(...).
Грустно все это...
Полная версия этой страницы: Hi-Tech C & EEPROM & FLASH
Форум разработчиков электроники ELECTRONIX.ru > Микроконтроллеры (MCs) > Все остальные микроконтроллеры > PIC
Цитата(_Pasha @ Sep 29 2008, 18:52) 
Доброго времени!
Уж на что в GCC некомфортно получается работать с флешом и еепром, но по сравнению с продукцией hi-tech это - вершина сервиса!
Кто-нить красиво работает в HTC? Имеется ввиду инициализация, работа со структурами... при наличии только EEPROM_READ(address) и __EEPROM_DATA(...).
Грустно все это...
Уж на что в 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++);} //Чтение
}
// Восстанавливам данные из 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++);} //Чтение
}
И чего грустить.
Цитата(DL36 @ Sep 30 2008, 10:00)
И чего грустить.
Вот чего:
Код
/*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));
}
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 (...)
И это при том, что параметров может быть несколько десятков.
Проктологи отдыхают...
Цитата(_Pasha @ Sep 30 2008, 10:30)
А потом эту структуру инициализируем черт знает чем __EEPROM_DATA (...)
И это при том, что параметров может быть несколько десятков.
Проктологи отдыхают...
Я ведь привел инициализацию сложной структуры, любого размера, из ЕПРОМ.И это при том, что параметров может быть несколько десятков.
Проктологи отдыхают...
Практически я делаю так, поскольку вычислять где и что лежит не интересно, и имеется запись тех же параметров в структуру. Под отладчиком пишу где и что надо, снимаю дамп и переписываю его в исходники.
Код
/*####################################################################
* EEPROM DATA Фактически это номер ячейки памяти с которой выполняем старт чтения
*####################################################################*/
#define NuStartEEprom 0 // Тут первое чтение Именно это значение подставляется
// в процедуру чтения и записи
#define NU_DET+sizeof(NuStartEEprom) // Запись, чтение следующей структуры
...
...
...
* EEPROM DATA Фактически это номер ячейки памяти с которой выполняем старт чтения
*####################################################################*/
#define NuStartEEprom 0 // Тут первое чтение Именно это значение подставляется
// в процедуру чтения и записи
#define NU_DET+sizeof(NuStartEEprom) // Запись, чтение следующей структуры
...
...
...
Так, что вроде никаких проблем, держать переменные в ЕПРОМ
тоже вроде возможно но смысла я не вижу, поскольку будет большое время доступа.
Цитата(DL36 @ Sep 30 2008, 12:01)
держать переменные в ЕПРОМ тоже вроде возможно...
А как? просветите, плз. Читал-перечитал TFM - не нашел.
Полазил по форумам. Нашел, что eeprom - qualifier все-таки есть. А в мануале на PICC-18 v9.61 про него ничего нет. Что за чушь - не пойму
Цитата(_Pasha @ Sep 30 2008, 20:11)
Полазил по форумам. Нашел, что eeprom - qualifier все-таки есть. А в мануале на PICC-18 v9.61 про него ничего нет. Что за чушь - не пойму
В про многого нет, обычно работают в СТД. Хотя и тут есть ограничения, лично я нарвался на проблему 24 битных указателей, так до конца и не смог решить.
Сейчас перехожу на 24-е и с30, по крайней мере таких проблем с компилером нет.
Спасибо за консультацию. 
Вот, наконец-то, нормальное решение. И удобно, и максимально близко к WINAVR, используемому гораздо чаще, чем hi-tech. Работает на основе стандартного макроса offsetof.
Ессно, это примитив для чтения/записи блока.
P.S. вначале написал, а потом нашел оч. красивую статью: статья
Код
#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]));
}
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. вначале написал, а потом нашел оч. красивую статью: статья
Цитата(_Pasha @ Nov 18 2008, 10:50)
Вот, наконец-то, нормальное решение. И удобно, и максимально близко к WINAVR, используемому гораздо чаще, чем hi-tech. Работает на основе стандартного макроса offsetof.
Ессно, это примитив для чтения/записи блока.
P.S. вначале написал, а потом нашел оч. красивую статью: статья
Код
#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]));
}
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 возвращает смещение поля, за размером надо следить самому.
Пока не могу сообразить где есть привязка к базовому адресу, начала расположения структуры в ЕПРОМ.
Цитата(DL36 @ Nov 19 2008, 10:32)
offsetof возвращает смещение поля, за размером надо следить самому.
Пока не могу сообразить где есть привязка к базовому адресу, начала расположения структуры в ЕПРОМ.
Пока не могу сообразить где есть привязка к базовому адресу, начала расположения структуры в ЕПРОМ.
У меня вполне логичное правило: размером читаемого блока является размер переменной, в которую выполняется чтение. С записью - тоже пляшем от размера переменной.
Привязкой лучше сделать 0х00, потому что намного удобнее "накрыть" структурой всю систему параметров, и пусть там будет несколько наборов, CRC и прочее. Т.е. это выглядит как глобальный хедер, из которого можно добраться до любого параметра.
И логика в этом есть - библиотечные функции, если они по-местному читают еепром, это не есть правильно с точки зрения портабельности.
Лучше как-нить через
Код
extern int get_timeout (void);// а здесь уже читаем откуда угодно
например так.
ПыСы чтение флеша с набором констант, ессно, аналогично
Цитата(_Pasha @ Nov 19 2008, 11:02)
У меня вполне логичное правило: размером читаемого блока является размер переменной, в которую выполняется чтение. С записью - тоже пляшем от размера переменной.
Привязкой лучше сделать 0х00, потому что намного удобнее "накрыть" структурой всю систему параметров, и пусть там будет несколько наборов, CRC и прочее. Т.е. это выглядит как глобальный хедер, из которого можно добраться до любого параметра.
И логика в этом есть - библиотечные функции, если они по-местному читают еепром, это не есть правильно с точки зрения портабельности.
Привязкой лучше сделать 0х00, потому что намного удобнее "накрыть" структурой всю систему параметров, и пусть там будет несколько наборов, CRC и прочее. Т.е. это выглядит как глобальный хедер, из которого можно добраться до любого параметра.
И логика в этом есть - библиотечные функции, если они по-местному читают еепром, это не есть правильно с точки зрения портабельности.
Да, согласен сделать подобную структуру будет правильно. Но есть еще размер переменной и не всегда это байт.
Цитата(DL36 @ Nov 19 2008, 11:59)
Но есть еще размер переменной и не всегда это байт.
Дык я для блочной пересылки свои функции и использую
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.