Since the blank PIC doesn't know the type and configuration of its clock
until its programmed with that info, does that mean that a crystal or EXT CR
need not be present during programming?

TIA.

ian field wrote:
Since the blank PIC doesn't know the type and configuration of its clock
until its programmed with that info, does that mean that a crystal or EXT CR
need not be present during programming?

TIA.



Yes, this is true.

If you need specific information, each PIC family has a ICSP progamming
manual.

Such as:

http://ww1.microchip.com/downloads/e...Doc/31028a.pdf

"donald" wrote in message
. ..
ian field wrote:
Since the blank PIC doesn't know the type and configuration of its clock
until its programmed with that info, does that mean that a crystal or EXT
CR
need not be present during programming?

TIA.



Yes, this is true.

If you need specific information, each PIC family has a ICSP progamming
manual.

Such as:

http://ww1.microchip.com/downloads/e...Doc/31028a.pdf



Thanks.

Microchip products are a little too well documented - its usually an awful
long read to find one small item of info!

aifk the type of clock is spec'ed in the 'configuration bits' section of
MPLAB. There is a default clock that is initially used and this depends on
the target device (also specified in MPLAB). Past that, the download is
synchronous so the clock is not initially important just as long as there is
one.

Merry Christmas - Oppie

"ian field" wrote in message
...
Since the blank PIC doesn't know the type and configuration of its clock
until its programmed with that info, does that mean that a crystal or EXT
CR
need not be present during programming?

TIA.

"oppie" wrote in message
...
aifk the type of clock is spec'ed in the 'configuration bits' section of
MPLAB. There is a default clock that is initially used and this depends on
the target device (also specified in MPLAB). Past that, the download is
synchronous so the clock is not initially important just as long as there
is one.

Perhaps a better way of phrasing my question - is the PGC clock supplied by
the ICSP interface sufficient on its own during programming, or does an
external clock have to be provided in the absence of an internal clock
generator?

ian field wrote:
"oppie" wrote in message
...
aifk the type of clock is spec'ed in the 'configuration bits' section of
MPLAB. There is a default clock that is initially used and this depends on
the target device (also specified in MPLAB). Past that, the download is
synchronous so the clock is not initially important just as long as there
is one.

Perhaps a better way of phrasing my question - is the PGC clock supplied by
the ICSP interface sufficient on its own during programming, or does an
external clock have to be provided in the absence of an internal clock
generator?

Typically not (disclaimer: it's been a while since I worked with PICs,
mostly using AVRs for 8-bitters nowadays). The clock line on a
synchronous serial interface is used to tell the processor when to latch
the data line. The processor itself needs a faster clock running in its
core to shift the latched bit and then move the completed byte into
flash in between active edges of the programming clock.

Only the datasheet knows for sure ...

--
Rich Webb Norfolk, VA

"ian field" wrote in message
...

"oppie" wrote in message
...
aifk the type of clock is spec'ed in the 'configuration bits' section of
MPLAB. There is a default clock that is initially used and this depends
on the target device (also specified in MPLAB). Past that, the download
is synchronous so the clock is not initially important just as long as
there is one.

Perhaps a better way of phrasing my question - is the PGC clock supplied
by the ICSP interface sufficient on its own during programming, or does an
external clock have to be provided in the absence of an internal clock
generator?

You need some sort of clock running on the micro in order to do anything -
including ICSP.
Default clocks can be anything from an onboard RC oscillator to the
external crystal osc - varies from device to device and families. Check the
datasheet for the chip in question as to start-up oscillator configurations.
What device are you planning to use?

You might also subscribe to the Microchip user's forum for these sort of
questions.
http://forum.microchip.com/

"oppie" wrote in message
...

"ian field" wrote in message
...

"oppie" wrote in message
...
aifk the type of clock is spec'ed in the 'configuration bits' section of
MPLAB. There is a default clock that is initially used and this depends
on the target device (also specified in MPLAB). Past that, the download
is synchronous so the clock is not initially important just as long as
there is one.

Perhaps a better way of phrasing my question - is the PGC clock supplied
by the ICSP interface sufficient on its own during programming, or does
an external clock have to be provided in the absence of an internal clock
generator?

You need some sort of clock running on the micro in order to do anything -
including ICSP.
Default clocks can be anything from an onboard RC oscillator to the
external crystal osc - varies from device to device and families. Check
the datasheet for the chip in question as to start-up oscillator
configurations.
What device are you planning to use?

Most likely 16f84 since that is what I've found the most tutorials for.

"ian field" wrote in message
...

"oppie" wrote in message
...

"ian field" wrote in message
...

"oppie" wrote in message
...
aifk the type of clock is spec'ed in the 'configuration bits' section
of MPLAB. There is a default clock that is initially used and this
depends on the target device (also specified in MPLAB). Past that, the
download is synchronous so the clock is not initially important just as
long as there is one.

Perhaps a better way of phrasing my question - is the PGC clock supplied
by the ICSP interface sufficient on its own during programming, or does
an external clock have to be provided in the absence of an internal
clock generator?

You need some sort of clock running on the micro in order to do
anything - including ICSP.
Default clocks can be anything from an onboard RC oscillator to the
external crystal osc - varies from device to device and families. Check
the datasheet for the chip in question as to start-up oscillator
configurations.
What device are you planning to use?

Most likely 16f84 since that is what I've found the most tutorials for.

The 16F84 should still be available but it's recommended to use the newer
'A' Version
http://www.microchip.com/stellent/id...ame =en010230

The ICSP spec should give you enough information on the basics:
http://ww1.microchip.com/downloads/e...Doc/30277d.pdf
See page 33 for information specific to the 16F8x parts.

Most of my work has been with the 18F series and we just set the processor
up with a 4 mhz crystal and the ICSP header at miinum. Connect up the ICD2 =
you can program and debug through the MPLAB IDE.
===============
I just checked the ICD2 and it does not support your device. Take a look at
the 18F series instead, They're a newer series and better supported. Should
be about the same cost. The ICD is a neat programing/debug tool to use and I
would try to select a part that is supported by it.

The MPLAB ICD 2 currently supports most PIC and dsPIC
Flash microcontrollers. Flash PICmicro MCU's not
supported are PIC16F72/73/74/76/77/83/84A.

"oppie" wrote in message
...

"ian field" wrote in message
...

"oppie" wrote in message
...

"ian field" wrote in message
...

"oppie" wrote in message
...
aifk the type of clock is spec'ed in the 'configuration bits' section
of MPLAB. There is a default clock that is initially used and this
depends on the target device (also specified in MPLAB). Past that, the
download is synchronous so the clock is not initially important just
as long as there is one.

Perhaps a better way of phrasing my question - is the PGC clock
supplied by the ICSP interface sufficient on its own during
programming, or does an external clock have to be provided in the
absence of an internal clock generator?

You need some sort of clock running on the micro in order to do
anything - including ICSP.
Default clocks can be anything from an onboard RC oscillator to the
external crystal osc - varies from device to device and families. Check
the datasheet for the chip in question as to start-up oscillator
configurations.
What device are you planning to use?

Most likely 16f84 since that is what I've found the most tutorials for.

The 16F84 should still be available but it's recommended to use the newer
'A' Version
http://www.microchip.com/stellent/id...ame =en010230

The ICSP spec should give you enough information on the basics:
http://ww1.microchip.com/downloads/e...Doc/30277d.pdf
See page 33 for information specific to the 16F8x parts.

Most of my work has been with the 18F series and we just set the
processor up with a 4 mhz crystal and the ICSP header at miinum. Connect
up the ICD2 = you can program and debug through the MPLAB IDE.
===============
I just checked the ICD2 and it does not support your device. Take a look
at the 18F series instead, They're a newer series and better supported.
Should be about the same cost. The ICD is a neat programing/debug tool to
use and I would try to select a part that is supported by it.

The MPLAB ICD 2 currently supports most PIC and dsPIC
Flash microcontrollers. Flash PICmicro MCU's not
supported are PIC16F72/73/74/76/77/83/84A.


IIRC the f84 is supported by the PICKit 2 - which is what I have, there
seems to be little mystery about devices like the 12f675, whether they use
their internal clock during programming or the PGC signal, they don't need
the crystal or CR which would use up GPIO pins.

The question is whether I need to make provision for external CLK on the
programming header board for any of the devices I might experiment with. So
far I've downloaded numerous tutorials and each author seems to have their
own favourite clock frequency for the assignments, so I have built a clock
module that provides all the common frequencies so it isn't necessary to
keep changing crystals & loading capacitors on the experimentation board,
from the answers so far, it looks like it might be a good idea to include a
CLK in connector on the programming header board.

For the programming header board I'm copying part of the Velleman K8048, it
has 4 sockets 8 pin, 14 pin, 18 pin & 28 pin, if anyone can mention examples
of 14 pin PICs I can search for the data sheets and verify the pinouts - the
other types are common enough and easy to find.

"ian field" wrote in message
...


IIRC the f84 is supported by the PICKit 2 - which is what I have, there
seems to be little mystery about devices like the 12f675, whether they use
their internal clock during programming or the PGC signal, they don't need
the crystal or CR which would use up GPIO pins.

The question is whether I need to make provision for external CLK on the
programming header board for any of the devices I might experiment with.
So far I've downloaded numerous tutorials and each author seems to have
their own favourite clock frequency for the assignments, so I have built a
clock module that provides all the common frequencies so it isn't
necessary to keep changing crystals & loading capacitors on the
experimentation board, from the answers so far, it looks like it might be
a good idea to include a CLK in connector on the programming header board.

For the programming header board I'm copying part of the Velleman K8048,
it has 4 sockets 8 pin, 14 pin, 18 pin & 28 pin, if anyone can mention
examples of 14 pin PICs I can search for the data sheets and verify the
pinouts - the other types are common enough and easy to find.

Honestly, I have hit the limit of my understanding on this part (without
delving deeper than I have time for at present). Seriously suggest you ask
the experts in the microchip forums: http://forum.microchip.com/
Like I had written, for all the PICs I've used, the crystal osc must be
present to do anything. This does not mean it is so for the entire line of
microchip parts.

"oppie" wrote in message
...

"ian field" wrote in message
...


IIRC the f84 is supported by the PICKit 2 - which is what I have, there
seems to be little mystery about devices like the 12f675, whether they
use their internal clock during programming or the PGC signal, they don't
need the crystal or CR which would use up GPIO pins.

The question is whether I need to make provision for external CLK on the
programming header board for any of the devices I might experiment with.
So far I've downloaded numerous tutorials and each author seems to have
their own favourite clock frequency for the assignments, so I have built
a clock module that provides all the common frequencies so it isn't
necessary to keep changing crystals & loading capacitors on the
experimentation board, from the answers so far, it looks like it might be
a good idea to include a CLK in connector on the programming header
board.

For the programming header board I'm copying part of the Velleman K8048,
it has 4 sockets 8 pin, 14 pin, 18 pin & 28 pin, if anyone can mention
examples of 14 pin PICs I can search for the data sheets and verify the
pinouts - the other types are common enough and easy to find.

Honestly, I have hit the limit of my understanding on this part (without
delving deeper than I have time for at present). Seriously suggest you ask
the experts in the microchip forums: http://forum.microchip.com/
Like I had written, for all the PICs I've used, the crystal osc must be
present to do anything. This does not mean it is so for the entire line of
microchip parts.

I posted the question on microchip forums and checked email notification for
replies - its been a couple of days and nothing so far.

Last night I wired up a 18 pin header for the PICKit 2 and fed it a 16f84A,
it auto detected this device as present and correct without connecting the
CLK board but I didn't try performing any of the available options.

"ian field" schreef in bericht
...

"oppie" wrote in message
...

"ian field" wrote in message
...

"oppie" wrote in message
...

"ian field" wrote in message
...

"oppie" wrote in message
...
aifk the type of clock is spec'ed in the 'configuration bits' section
of MPLAB. There is a default clock that is initially used and this
depends on the target device (also specified in MPLAB). Past that,
the download is synchronous so the clock is not initially important
just as long as there is one.

Perhaps a better way of phrasing my question - is the PGC clock
supplied by the ICSP interface sufficient on its own during
programming, or does an external clock have to be provided in the
absence of an internal clock generator?

You need some sort of clock running on the micro in order to do
anything - including ICSP.
Default clocks can be anything from an onboard RC oscillator to the
external crystal osc - varies from device to device and families. Check
the datasheet for the chip in question as to start-up oscillator
configurations.
What device are you planning to use?

Most likely 16f84 since that is what I've found the most tutorials for.

The 16F84 should still be available but it's recommended to use the newer
'A' Version
http://www.microchip.com/stellent/id...ame =en010230

The ICSP spec should give you enough information on the basics:
http://ww1.microchip.com/downloads/e...Doc/30277d.pdf
See page 33 for information specific to the 16F8x parts.

Most of my work has been with the 18F series and we just set the
processor up with a 4 mhz crystal and the ICSP header at miinum. Connect
up the ICD2 = you can program and debug through the MPLAB IDE.
===============
I just checked the ICD2 and it does not support your device. Take a look
at the 18F series instead, They're a newer series and better supported.
Should be about the same cost. The ICD is a neat programing/debug tool to
use and I would try to select a part that is supported by it.

The MPLAB ICD 2 currently supports most PIC and dsPIC
Flash microcontrollers. Flash PICmicro MCU's not
supported are PIC16F72/73/74/76/77/83/84A.


IIRC the f84 is supported by the PICKit 2 - which is what I have, there
seems to be little mystery about devices like the 12f675, whether they use
their internal clock during programming or the PGC signal, they don't need
the crystal or CR which would use up GPIO pins.

The question is whether I need to make provision for external CLK on the
programming header board for any of the devices I might experiment with.
So far I've downloaded numerous tutorials and each author seems to have
their own favourite clock frequency for the assignments, so I have built a
clock module that provides all the common frequencies so it isn't
necessary to keep changing crystals & loading capacitors on the
experimentation board, from the answers so far, it looks like it might be
a good idea to include a CLK in connector on the programming header board.

For the programming header board I'm copying part of the Velleman K8048,
it has 4 sockets 8 pin, 14 pin, 18 pin & 28 pin, if anyone can mention
examples of 14 pin PICs I can search for the data sheets and verify the
pinouts - the other types are common enough and easy to find.


FAIK PICs that have an internal clock, have that clock active from factory
by default. The smallest ones - 10F2xx - even have no possibility to
connect an external clock or Xtal. They can be programmed using the
appropriaty pins only. A extra pitfall I'm aware of is the low voltage
programming pin. You'd better keep it low during programming. I don't know
what happens if the PIC is configured for an external clock or Xtal. But if
you use in circuit programming you have it connected anyway. I only ever had
an Atmel that could not be reprogrammed without an external clock once it
was configured to use one.

petrus bitbyter

"ian field" wrote in message
...

I posted the question on microchip forums and checked email notification
for replies - its been a couple of days and nothing so far.

Last night I wired up a 18 pin header for the PICKit 2 and fed it a
16f84A, it auto detected this device as present and correct without
connecting the CLK board but I didn't try performing any of the available
options.

Sometimes just experimenting is the best way.
Actually, you did get three messages in reply to your thread (as of 10 pm
EST 12/29):
http://forum.microchip.com/tm.aspx?m=304713


Which brings me to:

Cheers and best wishes to all for 2008
Bob 'Oppie' Oppenheimer
New York, USA