Allocate the global variables to XDATA in small memory model

Dont know where to ask this question, Does any one knows how many times a microprocessor, e.g., 8051 can be programmed, practically, not theoretically?
is it beter or worse than, e.g. the avr or e.g. the pic?

Hi dear friend agin

if any one have a link
for this particular
conversion asm
to c conversion for 8052
thanks

hi great friend

i want to know how to make the coin sensing machine of exact rupees like the one
for pepsi coin machine and that returns pepsi as output.
help me out imedietly,

Thanks

is any man here??????

why you no treply

well, it doesn't help that you've rudely butted-in on someone else's thread, and your questions are entirely unrelated to the topic of the thread!

So anyone looking at the list of topics won't realise that you have added unrelated questions in this thread!

Your questions also don't seem to have anything to do with Keil software tools - so they are Off-Topic for this forum - see: http://www.keil.com/forum/

What research of your own have you done so far?

If that's what you need, then you must expect to pay for it!

In which case, see: http://www.keil.com/condb

You can use #pragma to set the memory model on a file-by-file basis. Try

#pragma LARGE

at the top of the file with the variables to go into xdata. If the module also contains code, and you don't want the code to compile in the large memory model, you might surround just the variables with the #pragma.

Note that the compiler has to know that these variables live in xdata so that it can generate proper code. Linker tricks alone won't work.

--

And for the other question: the number of times a particular part can be programmed depends on the memory technology used to manufacture that part. See the data sheet for your particular variant. "The 8051" is a processor core, and can be "reprogrammed" an unlimited number of times; it's the flash (or other memory technology) that limits reprogramming.

Common guaranteed erase cycle times for parts with integrated program flash are 10,000 or 100,000 cycles. Larger values exist.

I'm not sure what you mean by the distinction between "practical" and "theoretical". Those erase cycle times are lower limits (if the vendor is honest and competent). So, "practically", you might say you're likely to get away with some more programming cycles. They have to leave some margin for manufacturing variability and error in the design. But "practically", it would be extremely foolish to expect a part to work any longer than its rated duration, even if you think you could get away with it most of the time. "Theoretically", there's always going to be some few bad parts that don't meet the design spec.

At least for really old chips, the specification may be only 1000 rewrite cycles. It is these great improvements in number of rewrite cycles for the flash technology which allow USB thumb drives.

The stated rewrite count is normally a statisticial minimum for the full temperature range, which means that a device operating in room temperature will normally support many more programming cycles.

As Drew Davis notes, the figures are statistical minimums, i.e. the majority of all chips will manage that number of rewrites with a certain probability. Most memory manufactorers (and some microcontroller manufacturers) have test specifications for their reliability tests directly available on their web servers. Alas, some manufacturers do not want the test routines and the results of the tests known without an NDA agreement :(

Hi,
I tried #pragma LARGE just before the variables, and then #pragma SMALL before the code start, like:
<1>
<2>#pragma LARGE
<3>unsigned char message[8];
<4>unsigned char checksum;
<5>
<6>#pragma SMALL
<7>void message_process(void)
<8>{
<9> unsigned char i;
<10>
<11> checksum = 0;
<12> for( i=0; i<8; i++)
<13> checksum += message[i];
<14>}

but it doesn't work!
The compiler complained:
FUNC.C(6): error C252: misplaced primary control, line ignored

How to set LARGE for variables only, and then set back to SMALL for code?

Thanks!

Looks like bad advice from me. The manual entry from the error message says:

Description Primary controls must be specified at the start of the C module before any #include directives or declarations.

And early on, in Compiling Programs / Directives, the manual says

Some directives may be specified only once at the beginning of a source file. If one of these directives is specified more than once, the compiler generates a fatal error and aborts compilation.

So, it looks like the memory model is one of these primary directives that can only be specified once per file.

If you need to split the functions from the data, I suppose you'll have to break it into two files.

It seems I have to modify the variables one by one, no choice!

Thank you very much!

Yes, I think you're right!

There are different versions of the runtime support libraries for each memory model - so I think the tools may get confused if you mix different models in the same project!

As it's only the globals, and for only one "module" of your project, it shouldn't be too hard to apply the 'xdata' keyword...?

this may seem more cumbersome, but I think it will be easier and safer in the end.

just a suggestion, but that is how I would do it to avoid the pesky little 'forgets'

In the below you can use your own names whatever you prefer. I show just unsigned char, you will, of course have to make all.

a .h module you include in all sources
#define UX8 unigned chat xdata
#define UD8 ondigned char

then do a global replace of unsigned char with U_8
then in every module replace U_8 with UX* or UD8

by this anything you 'forget' will come up as an error

Erik

WTF is unigned chat
WTF is ondigned

???

thumbs used for typing

WTF is unigned char
WTF is unsigned

I am sorry, sometimes in the preview I see what I ment, not what I typed, my bad :(

Erik