Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
I am relatively new, not only to Atmel but also to Embedded system.
typedef struct eventdata
{ uint8_t unit_add;
uint8_t card_add;
uint8_t event_no; //Event counter
uint8_t type; //Event type
uint8_t year; //rtc yesr
uint8_t month; //rtc month
uint8_t day; //rtc day
uint8_t hour; //rtc hour
uint8_t min; //rtc min
uint8_t sec; //rtc sec
uint16_t voltage[24]; // adc counts of 24 channels in an
array
} ED; // total data = 58 bytes
Because of issues of structure packing it is better to define
structure items from
the largest to the smallest, ie. uint16_t should be first. This is
more important
on 32bit processors and up than on the 8bit AVRs.
ED ramdata; // current event data in ram
ED temp_ramdata; // load eeprom data to this event
data for sending to uart
ED EEMEM eepdata[60]; // 60 events data on EEprom
But now I am supposed to save around 500 events.
So Internal EEPROM cannot be used. So we decided to use EXternal EEPROM on
I2C bus.
You still might want to buffer a couple of blocks of data in internal
EEPROM as it will be
faster to write than the external one. That will give you some
recovery options if power
fails while you are writing data. Depending on how important your
data is, give lots
of consideration to power fail and recovery. Also keep in mind that
EEPROMs, both the
internal and the external ones, have limited write life times.
http://www.ramtron.com/
makes EEPROM (F-RAM) parts that have no write limits.
1. How to declare ED EEMEM eepdata[60];
http://www.embedded.com/columns/technicalinsights/18312031?_requestid=1358170
explains how to use offsetof() from stddef.h for this problem.
offsetof() also removes
issues of structure alignment issues, if you don't mind a few bytes being wasted
in your memory.
how to use above commands in external EEPROM.
The library you found should document that. Most likely you need to
buffer you data in RAM,
and the library will have the equivalent read/write commands as the
internal ones.
I am feeling now, the external EEPROM data handling is very difficult.
Solving these types of challenges is what keeps working on Embedded Systems
from ever getting boring. Look at how the internal EEPROM AVR-LibC works, to
get some ideas of how to make your external lib. work.
--
http://www.wearablesmartsensors.com/
http://www.softwaresafety.net/
http://www.designer-iii.com/
http://www.unusualresearch.com/
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, 4 May 2009, Bob Paddock wrote:
uint16_t voltage[24]; // adc counts of 24 channels
in an array } ED; // total data = 58 bytes
Because of issues of structure packing it is better to define
structure items from
the largest to the smallest, ie. uint16_t should be first. This is
more important
on 32bit processors and up than on the 8bit AVRs.
You could just mark the struct as packed, eg..
typedef struct eventdata {
...
} __attribute__ ((packed)) ED;
--
Daniel O'Connor software and network engineer
for Genesis Software - http://www.gsoft.com.au
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
signature.asc
Description: This is a digitally signed message part.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, 4 May 2009, David Kelly wrote: On Mon, May 04, 2009 at 10:21:50PM +0930, Daniel O'Connor wrote: On Mon, 4 May 2009, Bob Paddock wrote: ? ? ? ? ? ? ? ?uint16_t voltage[24]; ? // adc counts of 24 channels in an array } ED; ? ? ? ? ? // total data = 58 bytes Because of issues of structure packing it is better to define structure items from the largest to the smallest, ie. uint16_t should be first. This is more important on 32bit processors and up than on the 8bit AVRs. I suspect this is a homework assignment and the structure was provided. Ah hmm.. The typedef names are fairly poor practise then. If I was defining the ED structure then I'd store 4 bytes of seconds since some epoch rather than 6 bytes of year, month, day, hour, minute, second. Much simpler, and routines to convert from seconds are readily available in OS's and spreadsheets. It's OK so long as you don't have to deal with leap seconds :( (ie dictate that it is in UTC, and make the recipient of your data do the work) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: This is a digitally signed message part. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, May 04, 2009 at 10:21:50PM +0930, Daniel O'Connor wrote:
On Mon, 4 May 2009, Bob Paddock wrote:
? ? ? ? ? ? ? ?uint16_t voltage[24]; ? // adc counts of 24 channels
in an array } ED; ? ? ? ? ? // total data = 58 bytes
Because of issues of structure packing it is better to define
structure items from the largest to the smallest, ie. uint16_t
should be first. This is more important on 32bit processors and up
than on the 8bit AVRs.
I suspect this is a homework assignment and the structure was provided.
You could just mark the struct as packed, eg..
typedef struct eventdata {
...
} __attribute__ ((packed)) ED;
Yup. Should also verify that sizeof(ED) == 58 in the code.
When allocating memory and calculating offsets into the EEPROM one
should use sizeof(ED) rather than a hard coded constant.
If I was defining the ED structure then I'd store 4 bytes of seconds
since some epoch rather than 6 bytes of year, month, day, hour, minute,
second. Much simpler, and routines to convert from seconds are readily
available in OS's and spreadsheets.
--
David Kelly N4HHE, dke...@hiwaay.net
Whom computers would destroy, they must first drive mad.
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
so your external EEPROM will be accessed by functions you write. The
compiler does not know how to interface to the external EEPROM.
The functions you will need will take a pointer to your data structure
and then pack it into the external EEPROM, the other will take a
pointer and extract the data from the EEPROM into the structure. Both
of these functions will need some method for addressing your EEPROM's
internal memory
I would suggest that instead of an external I2C EEPROM, that you get a
SD card and put a file system on it and append to a text file for your
log, Ahh, 1GB of space to work with and CHEAP.
EVEN if you don't use a filesystem it would be effective.
Steve
On May 4, 2009, at 1:55 AM, Prashant D. Kharade wrote:
Hello,
I am relatively new, not only to Atmel but also to Embedded system.
I am doing my first embedded project, 24 channel Data-Logger system.
This is Time based data logging system.
We are supposed to log the data after every 15 min.
After each 15 min, 58 bytes of data is supposed to be saved.
The data structure is as follows.
typedef struct eventdata
{ uint8_t unit_add;
uint8_t card_add;
uint8_t event_no; //Event counter
uint8_t type; //Event type
uint8_t year; //rtc yesr
uint8_t month; //rtc month
uint8_t day;//rtc day
uint8_t hour; //rtc hour
uint8_t min;//rtc min
uint8_t sec;//rtc sec
uint16_t voltage[24]; // adc counts of 24 channels in an array
} ED; // total data = 58 bytes
ED ramdata; // current event data in ram
ED temp_ramdata; // load eeprom data to this event data for
sending to uart
ED EEMEM eepdata[60]; // 60 events data on EEprom
I am saving this in EEPROM of Atmega128 microcontroller. Each event
require 58bytes. Atmega128 has max 4K EEPROM.
So I can save 4K/58 = 70 events at max.
But now I am supposed to save around 500 events.
So Internal EEPROM cannot be used. So we decided to use EXternal
EEPROM on I2C bus.
I found the readymade library from Peter Fleury on the net.
But I faced following problems.
1. How to declare ED EEMEM eepdata[60]; (60 events data on EEprom)
on External memory.
2. Whenever a time event occurr all the data is stored in RAM (ED
ramdata). Then in a single command this data was transferred to the
EEPROM as follows
eeprom_write_block((const void*)ramdata,
(void*)eepdata[event_count-1], sizeof(ED));
Now if I use the external EEPROM, how shall I send structure type
ED ?
3. Infact, I have stored data such as calibration, initial data in
structures. And transfer the data very easily from RAM to EEPROM
viceversa.
4. When any data to be read from EEPROM, I used the command
eeprom_read_block((void*)temp_ramdata,(const
void*)eepdata[t_event_no-1], sizeof(ED));
I do not know how to declare EEPROM variables, or how to use above
commands in external EEPROM.
I am feeling now, the external EEPROM data handling is very difficult.
How to make it simple. Could you please suggest some good logical
ideas.
Thanks
Prashant
No virus found in this outgoing message.
Checked by AVG - www.avg.com
Version: 8.5.287 / Virus Database: 270.12.16/2094 - Release Date:
05/03/09 16:51:00
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
___
AVR-GCC-list mailing list
AVR-GCC-list@nongnu.org
http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, May 04, 2009 at 11:06:06AM -0700, Steven Michalske wrote: so your external EEPROM will be accessed by functions you write. The compiler does not know how to interface to the external EEPROM. IIRC the compiler doesn't know internal AVR EEPROM either. AVR EEPROM is not mapped in CPU address space but it faked into the load map for debugging and device programming. [85 lines deleted under top-post] -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On May 4, 2009, at 11:33 AM, David Kelly wrote: On Mon, May 04, 2009 at 11:06:06AM -0700, Steven Michalske wrote: so your external EEPROM will be accessed by functions you write. The compiler does not know how to interface to the external EEPROM. IIRC the compiler doesn't know internal AVR EEPROM either. AVR EEPROM is not mapped in CPU address space but it faked into the load map for debugging and device programming. Good catch Dave, avr libc has macros for accessing the AVR eeprom. Look at http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html for insperation on writing your own macros. You can add another section to your linker script for the external eeprom if you wanted to as well. Steve [85 lines deleted under top-post] -- David Kelly N4HHE, dke...@hiwaay.net = = == Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
On Mon, May 04, 2009 at 11:46:40AM -0700, Steven Michalske wrote: On May 4, 2009, at 11:33 AM, David Kelly wrote: IIRC the compiler doesn't know internal AVR EEPROM either. AVR EEPROM is not mapped in CPU address space but it faked into the load map for debugging and device programming. Good catch Dave, avr libc has macros for accessing the AVR eeprom. Look at http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html for insperation on writing your own macros. You can add another section to your linker script for the external eeprom if you wanted to as well. Did that on a project some time ago. The advantage is to initialize the EEPROM at device programming time. You can get addresses off your structures initialized in the EEPROM but have to use them as offsets when using EEPROM routines rather than as pointers into RAM or FLASH. Other than the ability to initialize EEPROM with an AVR programming tool there isn't much difference in use of internal vs external EEPROM. The OP might consider writing to FLASH for his data logger assignment. Is harder to use as one must write bigger blocks at a time. Might be a wear limit depending on how many write/erase cycles are needed. -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
Re: [avr-gcc-list] External EEPROM verses internal EEPROM data handling
Yes, I thought about adding another section for this. I found a lot of external eeproms annoying because they didn't want to write a byte at a time. What about using internal flash? You can jump to the bootloader section execute spm and then return, and in this way on a 64kb chip or so, write your events to flash. This is going to be slower, and has some limitations, but it's a possible option. Sean On 5/4/09, Steven Michalske smichal...@gmail.com wrote: On May 4, 2009, at 11:33 AM, David Kelly wrote: On Mon, May 04, 2009 at 11:06:06AM -0700, Steven Michalske wrote: so your external EEPROM will be accessed by functions you write. The compiler does not know how to interface to the external EEPROM. IIRC the compiler doesn't know internal AVR EEPROM either. AVR EEPROM is not mapped in CPU address space but it faked into the load map for debugging and device programming. Good catch Dave, avr libc has macros for accessing the AVR eeprom. Look at http://www.nongnu.org/avr-libc/user-manual/group__avr__eeprom.html for insperation on writing your own macros. You can add another section to your linker script for the external eeprom if you wanted to as well. Steve [85 lines deleted under top-post] -- David Kelly N4HHE, dke...@hiwaay.net = = == Whom computers would destroy, they must first drive mad. ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list ___ AVR-GCC-list mailing list AVR-GCC-list@nongnu.org http://lists.nongnu.org/mailman/listinfo/avr-gcc-list
