Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

All about memories (RAM, EEPROM, FLASH)

Status
Not open for further replies.

fajarelektro

Member level 1
Joined
Oct 26, 2007
Messages
36
Helped
4
Reputation
8
Reaction score
3
Trophy points
1,288
Activity points
1,493
All about memories

Dear All,

I am curious about some 'memories' that our uc has. There are Flash, EEPROM, and RAM right? The EEPROM is pretty clear to me, as it only intended as a data storage for something you need to save.

What I am curious is if we compile the source code, we have a *.hex file in which we will put inside the uc right? Where actually we put this? Is it inside the Flash? I always belief so..am I right?

What I am also curious is so many times I make the *.hex file larger than the flash available @ the uc. And it is still running well. Any idea why? The windows explorer can show the file size, and then it is bigger KB than the Flash available.

Thank you in advance. :)

Kindest Regards,




FE
 

Re: All about memories

Hi,

Yes you are right about the types of memory - your .hex code is placed in Flash memory.

EEPROM is typicaly written to by the running program, although you can program it with data when you 'flash' the chip. Like the flash program code, eeprom data is retained when the power is off.

Ram is used for work areas when the power is on.

When you write your program code, in Pics and I expect most other chips, you have to specify what type of chip you are using - this ensures you do not exceed the flash memory size.
Also most programmers would not allow you to load in a file that is bigger than the chips it senses in the programmer.

Think your program size calculations must be a bit out somewhere :? :|
 

Re: All about memories

fajarelektro said:
What I am also curious is so many times I make the *.hex file larger than the flash available @ the uc. And it is still running well. Any idea why? The windows explorer can show the file size, and then it is bigger KB than the Flash available.
The Hex file is in a "human readable" format where each byte is represented by 2 ACII characters (Hex value). Each line of data also has a header and a checksum. Therefore, the hex file will always be at least twice the size the of the binary image.
 

So the hex file is smaller than the one inside the flash..?

And is it possible if my flash is small, then I use an external flash to save the hex file, and then run my code from there..? If yes, how to configure the uC in doing so?

Added after 5 minutes:

and how to know if it is fully loaded or not? (the hex) :)
 

Hi,


So the hex file is smaller than the one inside the flash..?

No, as GSM Man said, the .hex file is about 2 times larger than what is programmed into the flash memory.

And is it possible if my flash is small, then I use an external flash to save the hex file, and then run my code from there..? If yes, how to configure the uC in doing so?

Well that is how they used to do it many years ago, where you had three separate chips, the cpu chip, Rom chip ( similar to flash) and Ram chip.

Adding external flash is possible but then you are not really talking about a modern single chip uC.

Today you select a single uc chip with enough memory onboard, although you can add extra external eerpom or ram chips for very large applications like data loggers.
 

So to summarize, first we must have a rough idea about how big would the program memory should be.. ;)

after that, we select the uc that fits.

My last question is: since it is possible to use external flash to store program memory, anybody can tell me how? I am familiar with AtmelAVR and MicrochipPics.

It is useful in cases where you want to still load your firmware while your main program is still running (load it to the flash). And also useful in case I have only a board (fixed one) that it is the only option to use this board, no change is allowed.

Thank you friends :)
 

Hi,

So to summarize, first we must have a rough idea about how big would the program memory should be...after that, we select the uc that fits.

Afraid that is over simplifying the chip selection - there are many other parameters you must also consider, like the size of the Ram, EEprom, I/O functions and number of I/O pins needed.

Program memory size can rarely be established in that way, as your program invariably becomes much more complex that originally intended.

In reality - it is your own programming experience that will tell you what memory size chip you need - invariably you will always buy one with much more memory that you currently envisage you need - if you do need more then you select a uc with even larger flash memory.
If you look at the list of chips available you will see that each type usually has several different memory sizes.


It is useful in cases where you want to still load your firmware while your main program is still running (load it to the flash). And also useful in case I have only a board (fixed one) that it is the only option to use this board, no change is allowed.

While I did say it was possible, afraid you have taken me too literally, in normal use you would never do that for a typical uC project.
The main reasons against doing that would be the over complex hardware and software, plus the relatively slow speed the program code was accessed from an external chip would seriously degrade the uC performance
 

    fajarelektro

    Points: 2
    Helpful Answer Positive Rating
visit here
**broken link removed**

hope it help understanding Intel .HEX files
 

erio said:
visit here
**broken link removed**

hope it help understanding Intel .HEX files

Makasih erio :)

But it would be too complex then for me..and the Hex file is depending on which microcontroller I use, isnt it?In my case, I am using AVR and PICs.
 

fajarelektro said:
erio said:
visit here
**broken link removed**

hope it help understanding Intel .HEX files

Makasih erio :)

But it would be too complex then for me..and the Hex file is depending on which microcontroller I use, isnt it?In my case, I am using AVR and PICs.

Sama2 Fajar..:)
yes it is, the HEX file is microcontroller specific, but the concept is same..i am using PIC and 8051.
sorry for my terrible english, hope you get it..
 

erio said:
fajarelektro said:
erio said:
visit here
**broken link removed**

hope it help understanding Intel .HEX files

Makasih erio :)

But it would be too complex then for me..and the Hex file is depending on which microcontroller I use, isnt it?In my case, I am using AVR and PICs.

Sama2 Fajar..:)
yes it is, the HEX file is microcontroller specific, but the concept is same..i am using PIC and 8051.
sorry for my terrible english, hope you get it..

Nah, my english is also not that good :eek: :eek: :eek: :eek: My Indonesian is good :D
Nicepost :) Maybe I will study the link for the PIC hex code. But it is too closely related to the assembly code. In that case I must see the disassembly listing.

And the 'Free Intel hex file editor' there is a dead link.
 

yeah...maybe the site is very old and the author is not maintenance this site anymore.

(sama2 belajar bro..hehehehe)
 

Status
Not open for further replies.

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top