> Hi Piclisters,
>
> I'd like to know if someone on this list has ever done something with
> serielizeing their productions. I have to give a PIC16F83 a
> serialnumber/unique adress
> at program time. Does anybody know how i can do this?

I have done this once. I wrote a small C program that generated a single
line of object code (Intel INHX16, with checksum and all), containing four
retlw-coded 8 bit numbers. The assembly source contained a call/retlw-type
access to a table that was not there (it was #defined out for production,
but filled with a dummy set of four retlw's for development), only its
1st label, at the address where the C program placed the table later.

The C program would take the input INHX16 object, add its line, and output
it. The programmer would then program this and bleep (for the operator to
change chips). The C program also built a list of codes generated (2 files:
one with all the codes generated, one per line, one with 1 code: the last
one). This was run in a batch script under DOS, the targets were PIC 16C54s.
I only had ~50 chips to program but it worked fine.

>I have done this once. I wrote a small C program that generated a single
>line of object code (Intel INHX16, with checksum and all), containing four
>retlw-coded 8 bit numbers. The assembly source contained a call/retlw-type
>access to a table that was not there (it was #defined out for production,
>but filled with a dummy set of four retlw's for development), only its
>1st label, at the address where the C program placed the table later.
>The C program would take the input INHX16 object, add its line, and output
>it. The programmer would then program this and bleep (for the operator to
>change chips). The C program also built a list of codes generated (2 files:
>one with all the codes generated, one per line, one with 1 code: the last
>one). This was run in a batch script under DOS, the targets were PIC
16C54s.
>I only had ~50 chips to program but it worked fine.

Well, i wrote my email just too fast :) I meant that in a project i'm
working i need
to store the serial numbers into flash/eeprom (onchip). You say one could
write a
program that alters the hex file and add's the numbers as reltw's? Hmmm..
could you maybe mail me an example (maybe offlist is appropiate).
I don't have a C compiler. If you could mail me a sample hex file (original)
and
an altered hex file (serialized) and a C snippet i would be very greatfull!

If you don't have a c compiler you may wish to download the free early
version of turbo c.

Or, if you want to avoid the repetitive compilation process, I would
recommend getting a free copy of awk. Awk can be loosely thought of as
"interpreted c". Awk is good for text file manipulation and altering S
records and intel hex records is straight forward. Awk.exe is small. Awk
syntax is similar to c, but has regular expression capability.

>
> You
> say one could
> write a
> program that alters the hex file and add's the numbers as
> reltw's? Hmmm..
> could you maybe mail me an example (maybe offlist is appropiate).
> I don't have a C compiler. If you could mail me a sample hex
> file (original)
> and
> an altered hex file (serialized) and a C snippet i would be
> very greatfull!
>
> Also thanx to all the others that reacted!
>
>
> Regards,
>
> Jilles Oldenbeuving
> jillesspam_OUTrendo.dekooi.nl
>

>If you don't have a c compiler you may wish to download the free early
>version of turbo c.
>
>Or, if you want to avoid the repetitive compilation process, I would
>recommend getting a free copy of awk. Awk can be loosely thought of as
>"interpreted c". Awk is good for text file manipulation and altering S
>records and intel hex records is straight forward. Awk.exe is small. Awk
>syntax is similar to c, but has regular expression capability.
>
>Might be worth your investigation.
>
>-Rob

>> >MPLAB supports serialization via the SQTP feature.
>> >Look under the PROMATE menu.
>
>> but you cannot get at the data from your program!
>>This always seems to be a major omission
>> by Mchip.

>Not true.

>It is the DEVICE ID that is not readable by the program. Using the SQTP
>file, a serial number is stored IN PROGRAM MEMORY, and is hence available to
>the processor at any time.

yeah, alright, having investigated the promate documentation I have found what
your talking about. But why the blazes did they limit such a useful function to
a certain programmer? Why not have it available whatever programmer you use
(I.E. include the picstart plus)!

I still come back to the loop that the ID bits could have been made program
readable. I cannot think of anything to put in there which I would not want to
read by program.

start
open last_generated_file // O_RDONLY
if not error on open then
read line from last_generated_file
last_code = parse line
if error parsing
scream and die
fi
close last_generated_file
else
last_code = FIRST_CODE // hard coded value in program
fi
new_code = hash_somehow last_code // simplest is to increment
open last_generated_file for write // O_CREAT | O_TRUNC | O_WRONLY
if error opening then
scream and die
write new_code into last_generated_file on one line
close last_generated_file
open log_file for append or create // O_CREAT | O_APPEND | O_WRONLY
if error opening then
scream and die
fi
write new_code into log_file on one line
close log_file
write new_code as a single line hex (INHX16) record on stdout using proper
encoding followed by a NEWLINE (in C), at address taken from arg1.
end

Obviously there are no // comments in DOS batch files. It's been a while
since I wrote something in DOS shell language so please check the syntax
carefully. Some error check phases were omitted in the rational english
description above.

I remind that a INHX16 file record has the line (record structure):

:NNAAAACCDDDD...SS

where NN is the number of data (DDDD) WORDS (16 bits) in the line, AAAA
the absolute address where the 1st word is placed, DDDD four hex digits
expressing a 16-bit word, NN of them, and SS a checksum computed using the
sum of all the bytes (not WORDS) in the record, including NN,AAAA,CC and
all DDDD, like this:

SS = (0x100 - (sum(as above) % 0x100)) % 0x100

where % is the modulo operator. Just in case. There should be a 0x13 at
the end of the line. In C one prints '\n' and the compiler and OS
library stubs manufacture the proper output for the OS used. In VB I don't
know.