8051/8052 hardware detection

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.

Reply to
lennart.floreby
Loading thread data ...

"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
Reply to
Thad Smith

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?

Reply to
ghelbig

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

Reply to
Neil

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

Reply to
lennart.floreby

no, the SFR are only accessible directly ( AFAIK )

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 ?

Reply to
mmm

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

Reply to
Jim Granville

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.