| View previous topic :: View next topic |
| Author |
Message |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
 Posted: Wed Aug 18, 2004 2:05 pm |
 |
|
| Quote: |
In the CCS ICD.EXE, under the 'Advance' button, you can get the PIC
device ID by pressing 'Device ID'. Where do these numbers come from ?
How unique are they ? Is it possible to read them in the code ? |
Get the Programming Specification for your PIC on this page:
http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1407
It should give the addresses of the Config Registers where the Device ID
and Revision numbers can be found.
I have a 18F458 on my test board. The programming spec says
the Device ID registers are at 0x3FFFFE and 0x3FFFFF. This is shown
in table 5-2 of the programming specification, at the link below:
http://ww1.microchip.com/downloads/en/DeviceDoc/39576b.pdf
I then made a test program, to see if I could read those registers at runtime.
It works. It displays the following:
dev ID 1 = 64
dev ID 2 = 08
If you look at Table 5-1, it shows how to interpret those numbers.
The values show that I have a PIC18F458 with silicon revision 4.
I can also confirm they are correct by invoking the Connect command
for my ICD2 in the Programmer menu of MPLAB 6.42. It reports:
Target Device PIC18F458 found, revision = 0x4
| Code: | #include <18F458.h>
#fuses XT, NOWDT, PUT, NOPROTECT, NOLVP
#use delay(clock = 4000000)
#use rs232(baud = 9600, xmit=PIN_C6, rcv=PIN_C7)
#define DEVID1_ADDR 0x3FFFFEL
#define DEVID2_ADDR 0x3FFFFFL
//========================================
void main()
{
char devid1, devid2;
devid1 = read_program_eeprom(DEVID1_ADDR);
devid2 = read_program_eeprom(DEVID2_ADDR);
printf("dev ID 1 = %x\n\r", devid1);
printf("dev ID 2 = %x\n\r", devid2);
while(1);
} |
-------------
Edit:
Changed the PROTECT fuse to NOPROTECT. There is no need for code
protection in this test program.
Last edited by PCM programmer on Sun Aug 16, 2009 12:24 pm; edited 1 time in total |
|
 |
lehmannjl
Joined: 16 Oct 2006
Posts: 3
|
| reading DEVID1 & 2 |
| Posted: Mon Jun 02, 2008 9:53 am |
|
|
I used the code as posted on a 18F4550 but I only get FF and not the correct signature which should be 12h for DIVID2 and 000xxxxxb for DIVID1 (where xxxxx is the revision).
Any idea what could be wrong ?
_________________
Regards,
Jean-Luc |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
| Posted: Mon Jun 02, 2008 12:16 pm |
|
|
I tested this with vs. 4.073 just now on a PicDem2-Plus board, and I get
the following output from the 18F4550:
| Code: |
dev ID 1 = 02
dev ID 2 = 12
|
Are you testing this with actual hardware ?
What's your compiler version ? |
|
|
lehmannjl
Joined: 16 Oct 2006
Posts: 3
|
|
| Posted: Tue Jun 03, 2008 1:48 am |
|
|
I am using version 4.071
I use this on a specific hardware which basically consist of the 18F4550 and a USB interface. There are also 6 LEDs which I use to display the device ID read.
_________________
Regards,
Jean-Luc |
|
|
lehmannjl
Joined: 16 Oct 2006
Posts: 3
|
|
| Posted: Tue Jun 03, 2008 3:33 am |
|
|
Oops ! my mistake, I must have been asleep last evening, when I wrote the code. My LED display routine was incorrect, everything works fine now. Thanks for helping.
_________________
Regards,
Jean-Luc |
|
|
muhibraza1
Joined: 26 Jul 2013
Posts: 23
|
|
| Posted: Sat Sep 27, 2014 12:25 am |
|
|
| Quote: |
#define DEVID1_ADDR 0x3FFFFEL
#define DEVID2_ADDR 0x3FFFFFL
|
Hi PCM Programmer, wanted to know why did you put an "L" in the device address ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sat Sep 27, 2014 1:02 am |
|
|
An 'L' in a constant, in C, forces it to be treated as a 'long'. Read a C textbook....
It's actually unnecessary with these numbers, since they are so large, that they will automatically be treated as 'long', but it is always the safer way to work, if you want to be 'sure' that a value _will_ be treated as a long value.
It becomes vital, when numbers are smaller, where (for instance), if you are feeding values into the pwm duty function, and if you feed in (say) 256, then 255, as constants, the PWM output duration , will go up!....
The reason is that '256', gets treated as a long automatically, so the pwm function uses 10bit operation, but '255' gets treated as a 'short', and the function then switches to 8bit operation. Defining these constants as 256L, and 255L, avoids this happening. So people who are used to this as a problem, will 'get into the habit' of adding the 'L', when defining values. One character, saves a lot of later grief....  |
|
|
muhibraza1
Joined: 26 Jul 2013
Posts: 23
|
|
| Posted: Sat Sep 27, 2014 4:09 am |
|
|
| Oh right... I have read C textbooks but I never found this detail... could you suggest a good book about it ? |
|
|
Ttelmah
Joined: 11 Mar 2010
Posts: 19504
|
|
| Posted: Sat Sep 27, 2014 4:17 am |
|
|
Kerninghan and Ritchie.....
They are the people who wrote the language, and it really is the vital textbook for CCS C.
Page 35 (in the original first edition):
"Long constants are written in the style 123L."
Then in the appendix (page 180):
"2.4.2 Explicit long constants
A decimal, octal or hexadecimal integer immediately followed by l (letter l) or L is a long constant."
In the second edition, these are pages 37, and 193 instead.
It is not a friendly book, but it is the best source of knowledge, especially since CCS follows it very closely. |
|
|
muhibraza1
Joined: 26 Jul 2013
Posts: 23
|
|
| Posted: Sat Sep 27, 2014 5:23 am |
|
|
Thanks  |
|
|
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
