lennart.floreby@home.se wrote:
> Do you mean that some 8051-processors are accessing SFRs via indirect
> adressing?
> If that is the normal case, then writing 0xFD indirectly to port
> address 0xB0 (possibly P3) would make TxD go low on a 8051, but not on
> a 8052.
> 
> One way of checking the memory, i thought of after i wrote the first
> message, is to write to 0x7E and then make a couple of calls and see if
> adress 0x7E changes. If it doesn't, the stack pointer is something like
> 0xFE rather than 0x7E, implying 256 bytes ram. can anyone see a problem
> with this?

  The stack above is just Idata, so you can do a safer presence test with
MOV A,@Ri etc.
  You need to define WHY you want this test, if it is to AutoSize 
buffers, to fit either device, that should be fairly simple.
  In that case, you would always keep the stack in lower memory, and have
optional IDATA arrays that were/not used, if the extra 128 bytes were
found.

-jg

lennart.floreby@home.se wrote:
> Do you mean that some 8051-processors are accessing SFRs via indirect
> adressing?
> If that is the normal case, then writing 0xFD indirectly to port
> address 0xB0 (possibly P3) would make TxD go low on a 8051, but not on
> a 8052.

no, the SFR are only accessible directly ( AFAIK )

> 
> One way of checking the memory, i thought of after i wrote the first
> message, is to write to 0x7E and then make a couple of calls and see if
> adress 0x7E changes. If it doesn't, the stack pointer is something like
> 0xFE rather than 0x7E, implying 256 bytes ram. can anyone see a problem
> with this?
> 

is not a good solution , the 8051/2 stack start with low value (usually 
0x07 ) and move UPward

the simple solution is try to write at address 0xff ( indirect access 
!!! ) a value different to 0xff and try to read back

a good alternative i try testing the Timer2  ( TL2 TH2 register in SFR )
write a value and read back

but the question is : why are you trying to recognize the different chips ?

> Lennart
> 

Do you mean that some 8051-processors are accessing SFRs via indirect
adressing?
If that is the normal case, then writing 0xFD indirectly to port
address 0xB0 (possibly P3) would make TxD go low on a 8051, but not on
a 8052.

One way of checking the memory, i thought of after i wrote the first
message, is to write to 0x7E and then make a couple of calls and see if
adress 0x7E changes. If it doesn't, the stack pointer is something like
0xFE rather than 0x7E, implying 256 bytes ram. can anyone see a problem
with this?

Lennart

ghelbig@lycos.com wrote:
> lennart.floreby@home.se wrote:
>> Hi.
>>
>> I am interested in how a program could detect if it is running on an
>> 8052 compatible device, or just 8051. It should be reliable, i e if the
>> device is not 8052 compatible, the test sihould not hang up the device.
>>
>> One idea I have, is to write to the idata space and read back. But then
>> I need to know that NO 8051-non8052-compatible device has the extended,
>> 256 bytes, internal memory. So that is no good, unless I can get that
>> comfirmed.
>>
>> Any constructive input is appreciated.
> 
> The big difference between the 51 & 52 is 128 vs 256 bytes of IDATA.  I
> don't know of an exception to this; so far, so good.
> 
> Problem is, I can't think of a predictable, safe place to poke to tell
> the various flavors apart.  I've worked with 8051 variants that had
> every possible location filled, and most of the ports had side effects
> from reads or writes.
> 
> So, best of luck with that, OK?
> 

And Timer 2.  You could set it and see if it increments.
Remember the manufacturers have different numbering systems.
some 8051XXXX are really 8052's

lennart.floreby@home.se wrote:
> Hi.
>
> I am interested in how a program could detect if it is running on an
> 8052 compatible device, or just 8051. It should be reliable, i e if the
> device is not 8052 compatible, the test sihould not hang up the device.
>
> One idea I have, is to write to the idata space and read back. But then
> I need to know that NO 8051-non8052-compatible device has the extended,
> 256 bytes, internal memory. So that is no good, unless I can get that
> comfirmed.
>
> Any constructive input is appreciated.

The big difference between the 51 & 52 is 128 vs 256 bytes of IDATA.  I
don't know of an exception to this; so far, so good.

Problem is, I can't think of a predictable, safe place to poke to tell
the various flavors apart.  I've worked with 8051 variants that had
every possible location filled, and most of the ports had side effects
from reads or writes.

So, best of luck with that, OK?

lennart.floreby@home.se wrote:

> I am interested in how a program could detect if it is running on an
> 8052 compatible device, or just 8051. It should be reliable, i e if the
> device is not 8052 compatible, the test sihould not hang up the device.

"8052-compatible" can mean a lot of different things.  With so many 8051 
variations, I suggest you test for the features that you want, such as 
extra timer, RAM. etc.

-- 
Thad

Hi.

I am interested in how a program could detect if it is running on an
8052 compatible device, or just 8051. It should be reliable, i e if the
device is not 8052 compatible, the test sihould not hang up the device.

One idea I have, is to write to the idata space and read back. But then
I need to know that NO 8051-non8052-compatible device has the extended,
256 bytes, internal memory. So that is no good, unless I can get that
comfirmed.

Any constructive input is appreciated.