CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to support@ccsinfo.com

Can one determine Chip ID (16F62xA/16F648A)

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
dman66



Joined: 01 Nov 2006
Posts: 2

View user's profile Send private message

Can one determine Chip ID (16F62xA/16F648A)
PostPosted: Wed Nov 01, 2006 6:02 pm     Reply with quote

Hi all,

Right now my code is less than 2K so it fits in either a 16F628A or a 16F648A. About half of our boards were populated with 16F628A and the other half with 16F648A.

At runtime is there any possible way to know which part I'm running on?

GETENV() appears to be mainly compile time (i.e. DEVICE, PROGRAM_MEMORY, etc.)

I know on the 16F877, for instance, I can use read_program_memory(). This call doesn't work on the 628A/648A.

Any other ideas?

dman
PCM programmer



Joined: 06 Sep 2003
Posts: 21708

View user's profile Send private message

PostPosted: Thu Nov 02, 2006 12:48 am     Reply with quote

I think you can only read the Device ID when those PICs are in program
mode. You can't do it with user code at runtime. Here is one way that
might work:

The RAM memory map for the 16F628A is different from the 16F648A,
with respect to Bank 2. The smaller PIC has a hole in the bank 2 RAM,
from addresses 0x150 to 0x16F. The 16F648A doesn't have a hole
there -- it has RAM. According to the data sheet, if you try to read the
RAM in that address range in the 16F628A, you will read 0's.

So you could do a simple test. Try to write 0x55 to RAM address 0x150.
If you read back 0x55, then you have a 16F648A. If you read 0x00,
then you have a 16F628A. If you read something else -- I'm not sure,
maybe it's a bad chip. You will need to decide what to do in that case.

You can use the #locate directive to declare a test variable.
Code:
#locate ram_test_byte = 0x150

Then write a 'ram_test' routine which will test it as described above.

You should test this method before you implement it in production units.
This is just an idea. I haven't done this yet myself.
dman66



Joined: 01 Nov 2006
Posts: 2

View user's profile Send private message

PostPosted: Thu Nov 02, 2006 11:01 am     Reply with quote

This is brilliant - I thought about that too, but didn't realize that unimplemented RAM in the 627A/628A would return 0.

I tried it out and it works like a charm

Thanks!
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group