Searching \ for 'Programming SMT parts' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/devprogs.htm?key=programming
Search entire site for: 'Programming SMT parts'.

Truncated match.
PICList Thread
'Programming SMT parts'
1997\05\02@034852 by Campbell Scientific Australia

flavicon
face
I was wondering how do any of you program SMT PIC's?

We are using a 16C84 in a current design, and we don't have enough room to
do in-circuit programming. Is there a common ZIF socket for programming the
18 pin 16C84 SOIC parts with the PICSTART? Or is there another way to
program them easily?

Thanks,

Alex Thomas
spam_OUTcsaTakeThisOuTspamultra.net.au

1997\05\02@072621 by Andy Kunz

flavicon
face
At 04:22 PM 5/2/97 +1000, you wrote:
>I was wondering how do any of you program SMT PIC's?
>
>We are using a 16C84 in a current design, and we don't have enough room to
>do in-circuit programming. Is there a common ZIF socket for programming the
>18 pin 16C84 SOIC parts with the PICSTART? Or is there another way to
>program them easily?

Parallax has an SMT adapter for their board.

A friend has mounted such an adapter so that it plugs into the regular LIF
place on the programmer.

Both work great.

For 12C parts, I'm cheap and had to resort to soldering wires onto the SMT
part, burning it, then soldering it into the board.

Andy

==================================================================
Andy Kunz - Montana Design - 409 S 6th St - Phillipsburg, NJ 08865
         Hardware & Software for Industry & R/C Hobbies
       "Go fast, turn right, and keep the wet side down!"
==================================================================

1997\05\02@081818 by tjaart

flavicon
face
Campbell Scientific Australia wrote:
>
> I was wondering how do any of you program SMT PIC's?

We do quite a bit.

> We are using a 16C84 in a current design, and we don't have enough room to
> do in-circuit programming. Is there a common ZIF socket for programming the
> 18 pin 16C84 SOIC parts with the PICSTART? Or is there another way to
> program them easily?

We left a few small pads to do the programming on a bed of nails. Works
well.
You can also test the other functionality on the board.
Don't do production runs with a PICstart - it's not made for the job.

--
Friendly Regards

Tjaart van der Walt
.....tjaartKILLspamspam@spam@wasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             WASP International  http://wasp.co.za           |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
|_____________________________________________________________|

1997\05\02@100143 by Bill Collins

flavicon
face
Campbell Scientific Australia wrote:
>
> I was wondering how do any of you program SMT PIC's?
>
> We are using a 16C84 in a current design, and we don't have enough room to
> do in-circuit programming. Is there a common ZIF socket for programming the
> 18 pin 16C84 SOIC parts with the PICSTART? Or is there another way to
> program them easily?
>
> Thanks,
>
> Alex Thomas
> csaspamKILLspamultra.net.au

EDI Corp. (702-735-4997, fax 702-735-8339) makes programming adapters
for surface mount parts.  The one I bought for the PIC 16c55 in the SSOP
package (the really small one) works very well.  I have programmed about
40 parts with no problems, which is amazing considering the lead pitch
of this part.  The socket that I ordered connects the pins of the part
to a DIP plug straight through.  I had to make an adapter to correct for
the pinout differences between the 16c55 DIP and SSOP, but that's easy
once you are working with a DIP.

Cost was around $100 (us)

Bill

1997\05\02@123327 by Gerhard Fiedler

picon face
At 14:14 02/05/97 +0200, Tjaart van der Walt wrote:
>We left a few small pads to do the programming on a bed of nails. Works
>well.
>You can also test the other functionality on the board.

I'm thinking about a thing like this and putting some calibration data
(ADC) into OTPROM, like measure it first and then program the chip with a
patched file. Or better, burn the program, do a calibration run (part of
the program), get some reference values (from the PIC), send these back to
the programmer, and then put these reference values in the program memory
at some unused location. Does anybody have experience with a setup like
this? I.e. is it possible to program just some locations after the "main"
program has already been burned?

>Don't do production runs with a PICstart - it's not made for the job.

Would you mind to explain briefly why? (More as to give me some clues what
to look for what I don't have in a PICstart when I have to buy a production
type programmer...)

TIA,

Gerhard

1997\05\02@140146 by mike

flavicon
picon face
In message  <01BC5720.BB7C8080@alex> .....PICLISTKILLspamspam.....MITVMA.MIT.EDU writes:
> I was wondering how do any of you program SMT PIC's?
>
> We are using a 16C84 in a current design, and we don't have enough room to
> do in-circuit programming. Is there a common ZIF socket for programming the
> 18 pin 16C84 SOIC parts with the PICSTART? Or is there another way to
> program them easily?
>
>

Alex,

For the few pre-production parts I've done, I bodged, sorry,
carefully constructed an adaptor from an old PCB that had a
soic chip on it.

It does take a little while to align the PIC correctly and was
often a two handed task. I held the PIC onto the pcb pads and
then hit the program button with my left knee.

It is not recommended for production though.

Some of the suppliers in this country offer a programming
service. You supply a hex file and they will program the
parts for you. There is a set up charge of 10 UK pounds then
25 pence per chip. These charges can be justified if the
quantity and product are right.


Regards,

Mike Watson

1997\05\05@004323 by tjaart

flavicon
face
Gerhard Fiedler wrote:
>
> At 14:14 02/05/97 +0200, Tjaart van der Walt wrote:
> >We left a few small pads to do the programming on a bed of nails. Works
> >well.
> >You can also test the other functionality on the board.
>
> I'm thinking about a thing like this and putting some calibration data
> (ADC) into OTPROM, like measure it first and then program the chip with a
> patched file. Or better, burn the program, do a calibration run (part of
> the program), get some reference values (from the PIC), send these back to
> the programmer, and then put these reference values in the program memory
> at some unused location. Does anybody have experience with a setup like
> this? I.e. is it possible to program just some locations after the "main"
> program has already been burned?

I haven't done it, but I think it would be possible. Program the memory
earmarked for the calibration data with retl FF 's (unused). You could
also
pop the data into external EEPROM if you could do something with the
extra
memory.

>
> >Don't do production runs with a PICstart - it's not made for the job.
>
> Would you mind to explain briefly why? (More as to give me some clues what
> to look for what I don't have in a PICstart when I have to buy a production
> type programmer...)

The PICstart does not verify the PIC at the specified voltage levels.
Most manufacturers will have the correct programmers to do production
runs with, so
you wouldn't have to fork out the really big bucks. The PICstart is
perfect for
fooling around in the Lab.

Friendly Regards

Tjaart van der Walt
EraseMEtjaartspam_OUTspamTakeThisOuTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             WASP International  http://wasp.co.za           |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
|_____________________________________________________________|

1997\05\05@093533 by myke predko

flavicon
face
Gerhard and Tjaart wrote:
>Gerhard Fiedler wrote:
>> I'm thinking about a thing like this and putting some calibration data
>> (ADC) into OTPROM, like measure it first and then program the chip with a
>> patched file. Or better, burn the program, do a calibration run (part of
>> the program), get some reference values (from the PIC), send these back to
>> the programmer, and then put these reference values in the program memory
>> at some unused location. Does anybody have experience with a setup like
>> this? I.e. is it possible to program just some locations after the "main"
>> program has already been burned?
>
>I haven't done it, but I think it would be possible. Program the memory
>earmarked for the calibration data with retl FF 's (unused). You could
>also
>pop the data into external EEPROM if you could do something with the
>extra
>memory.

Just to clarify, you should note that the calibration value would later be
entered into this location.  When I first read this I was confused because
the Calibration location of the 12C50x is the reset vector.

Writing a return instruction (and leaving it) at the reset vector is
definitely *not recommended*.

Going with this, is there some way to put in conditional code in MPASM (or
any language for that matter) that would cause an error if this address was
overwritten?

{Quote hidden}

The PSP is also pretty good for the 12C50x parts - it doesn't update the
Reset Vector location directly from "Simulator" mode (you have to go into
"Editor" Mode) and even then, you are dealing with the "Calibration" value
directly.

myke

"My ancestors didn't spend millions of years clawing their way to the top of
the food chain, just so I could become a vegetarian"

1997\05\05@224645 by Gerhard Fiedler

picon face
At 09:32 05/05/97 EDT, myke predko wrote:
{Quote hidden}

I wanted to put my _own_ data in OTP EPROM locations (no reset vectors, no
chip configurations or whatever) -- but data I only know after having
loaded the PIC with some program to get me this data. That's why I'd have
to do this in a second programming run. Tjaart confirmed that it might work
as intended.

But probably I won't check it really out, because some further
investigation led me to believe that I need more than 8bit ADC resolution,
so I'll use a 16f84 (with a LTC1288 ADC) instead of the intended 16c711 --
and then I have an on-chip EEPROM.

(But still I think this is something useful and that I'll use it sooner or
later; often you have to calibrate an ADC or DAC, but you just do it
_once_, so that the results can very good be stored in OTP memory. And if
you have a little spare room for the routine in your program space, that's
the ideal place to put it...)

Thanks for the thoughts :-)

1997\05\06@005803 by tjaart

flavicon
face
Gerhard Fiedler wrote:
>
> I wanted to put my _own_ data in OTP EPROM locations (no reset vectors, no
> chip configurations or whatever) -- but data I only know after having
> loaded the PIC with some program to get me this data. That's why I'd have
> to do this in a second programming run. Tjaart confirmed that it might work
> as intended.
>
> But probably I won't check it really out, because some further
> investigation led me to believe that I need more than 8bit ADC resolution,
> so I'll use a 16f84 (with a LTC1288 ADC) instead of the intended 16c711 --
> and then I have an on-chip EEPROM.
>
> (But still I think this is something useful and that I'll use it sooner or
> later; often you have to calibrate an ADC or DAC, but you just do it
> _once_, so that the results can very good be stored in OTP memory. And if
> you have a little spare room for the routine in your program space, that's
> the ideal place to put it...)
>
> Thanks for the thoughts :-)

Here's another one :) We are going to write serial numbers in all the
PICs we
program. Because Mchip won't let us read the chip ID from within the PIC
software, we decided to do it in the ROM. In the software, there is a
lookup
table filled with retlw FFs (unprogrammed) During the manufacturing
process, the
serial number is written in this space as a set number of retlw
instructions. The
PIC can read this and we can identify each individual chip made by us.

--
Friendly Regards

Tjaart van der Walt
tjaartspamspam_OUTwasp.co.za
_____________________________________________________________
| Another sun-deprived R&D Engineer slaving away in a dungeon |
|             WASP International  http://wasp.co.za           |
|             GSM and GPS value-added applications            |
|  Voice : +27-(0)11-622-8686   |   Fax : +27-(0)11-622-8973  |
|_____________________________________________________________|

1997\05\06@012752 by Peter Homann

picon face
Tjaart van der Walt wrote:
{Quote hidden}

I need to do a similar thing. Although I want my serial bumber to be a
16 bit random number. As I'm using 16C84s, I going to put it in EEPROM.

I plan to use another 84 that will work as a random number generator,
using its own EEPROM to store that last value to use as the seed for
the next value. This PIC will "talk" to the target 84 via the 2 lines
that are used for dip switches in the final product. one for the
clock, and one for the data.

It works like this. the 84 is programmed with the application, in
circuit. Then, the circuit is connected to my serial number programmer.

The randon serial number is then passed accross and stored in as EEPROM
data.

This way I don't need to program every board with a different program.




--
_______________________________________________________________________
Peter Homann   email: @spam@peterhKILLspamspamadacel.com.au       Work : +61 3 9596-2991
Adacel Pty Ltd                                   Fax  : +61 3 9596-2960
250 Bay St, Brighton 3186, VIC, AUSTRALIA      Mobile :     014 025-925

1997\05\06@062139 by Jim Robertson

flavicon
face
At 01:32 PM 5/2/96 +0000, you wrote:

>
>I'm thinking about a thing like this and putting some calibration data
>(ADC) into OTPROM, like measure it first and then program the chip with a
>patched file. Or better, burn the program, do a calibration run (part of
>the program), get some reference values (from the PIC), send these back to
>the programmer, and then put these reference values in the program memory
>at some unused location. Does anybody have experience with a setup like
>this? I.e. is it possible to program just some locations after the "main"
>program has already been burned?
>
>
>Gerhard
>
Gerhard,

The above can be done on some devices  even after code protection. In fact
that is the idea way to do it if you are using a part that will allow
reprogramming of protected areas. These parts are: 16C5x, 16C61, 16C71

Other (more) useful parts are the  16C710, 16C711, 12c50x as these allow
reprogramming of locations 0 to 40h without scrambling.

If you are still interested, and I see you are going cold on the idea from
other postings, you may want to look at my programmer software as it will
allow you to put variables into a .SER file and burn them into a code
protected part. Really useful I thought but no one seems to need to do that
sort of thing. :~(

If need be I can modify the software a little to your needs.

Be in touch if I can help further.


Jim

1997\05\06@120338 by Gerhard Fiedler

picon face
At 20:21 06/05/97 -0500, Jim Robertson wrote:
>Other (more) useful parts are the  16C710, 16C711, 12c50x as these allow
>reprogramming of locations 0 to 40h without scrambling.
>
>If you are still interested, and I see you are going cold on the idea from
>other postings, you may want to look at my programmer software as it will
>allow you to put variables into a .SER file and burn them into a code
>protected part. Really useful I thought but no one seems to need to do that
>sort of thing. :~(

Sounds good, maybe I'll gonna use it later... I'm just getting into PICs,
but this will be only the start for a whole series of PIC projects
(probably), so possibly I'll get back to you for your solution.

More... (looser matching)
- Last day of these posts
- In 1997 , 1998 only
- Today
- New search...