xdata/idata/data differences

Hi,

I'm wondering what the differences are when I declare a variable with one of the modifiers, eg

  1. BYTE xdata temp;
  2. BYTE idata temp;
  3. BYTE data temp;
  4. BYTE temp;

I notice that some data types aren't allowed to be placed in xdata, for example BOOL. I get an error telling me it's in a different/ illegal memory space.

I also notice that there are code size differences. When I put variables in xdata/idata(1/2), my code seems to be larger by a few bytes than if I were to put them in data or not specify them(3/4). I'm wondering if there are any functional differences. I'm trying to keep my code as small as possible now so should I not put anything in xdata/ idata? What are the guidelines?

btw I'm programming in C and using Keil uVision2 as my IDE.

Thanks.

Reply to
galapogos
Loading thread data ...

You are apparently programming for an 8051-type processor.

To answer the question, read the processor data sheet to familiarize yourself with the processor memory architecture.

The data area is the smallest, but most efficiently accessed area. Idata is the next most efficient. Xdata is by far the largest. To help keep the code small place the most frequently used data into data or idata. Use functions instead of duplicated code. Using bit types can help keep the code small. Use qualified pointers rather than generic pointers.

Many of these suggestions make the code less portable and harder to support. My recommendation is to not use them until you need to, and then restrict it to isolated areas of code.

--
Thad
Reply to
Thad Smith

The Keil manuals do an excellent job of detailing how memory spaces and data types are handled, and it actually offers guidelines.

Why not RTFM?

-a

Reply to
Andy Peters

Why are you trying to hide that your using an 8051 ??

Reply to
Donald

You need to not only read the Keil manual, but the chip data sheet too. The chip has several memory spaces, some overlap

xdata (upto 64K external RAM) ,pdata (256 bytes external RAM) bdata (256 bits)

data(128 bytes Internal RAM), idata (256 bytes Internal RAM) code (upto 64K code)

Xdata is more inefficient to use, therefore it makes bigger code. I assume BOOL works out to "bit" the CPU does not has opcode to access bits in xdata.

Reply to
Neil

Sorry for not mentioning, but I'm programming for a Cypress EZUSB series MCU which is in fact a 8051 type processor. This particular MCU actually stores the firmware code in external NAND flash chips, which it then loads into internal memory upon startup.

Reply to
galapogos

I'm not, I just forgot to mention.

Reply to
galapogos

In message , galapogos writes

formatting link

See the C51 primer

In some what of a need of a re-write but the basics are there.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris Hills

data 128 Bytes directly addressable on-chip RAM. idata 256 Bytes indirectly addressable on-chip RAM. pdata 256 Bytes external RAM. xdata 64KB extended RAM space. code 64KB program memory. bdata 16 Bytes bit-addressable RAM; mixed bit/byte access.

far 16MB data/const memory on extended devices or variable banking on classic devices; 64KB object size. near 64KB direct addressable memory on 251 devices huge 16MB indirectly addressable memory; any size object. edata 96 Bytes extended bit-addressable RAM on 251.

Karthik Blaaguru

Reply to
karthikbalaguru

If you read through the Cx51 Manual, you will get many info. But the basic idea is simple - Try to always explicitly specify a memory selector for any variable based on its usage to optimize your application.

Karthik Balaguru

Reply to
karthikbalaguru

The assembler/utilities manual is better for the architecture.

--
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Reply to
Chris Hills

formatting link
-> this has some good info.

Karthik Balaguru

Reply to
karthikbalaguru

Thanks for all the help/links. I'll get right to reading those docs...

Reply to
galapogos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.