pkp timing issue with 16F627/K8048

[hogend]

With pickit 1.1.0-2 on Debian Sid amd64 (Phenom II 720) and using the
Velleman 8048, the 16F627 was not recognized
( <no device present> after pressing "detect now").
A 18F2550 is detected as expected and can be programmed as well.
Similarly, the standalone pkp does not detect the 16F627 device.
However, when running with strace (i.e. "strace pkp" or "strace
pickit"), the 16F627 is detected and can be programmed normally.
Note also that, under windows-XP and using the Velleman programmer,
the 16F627 can be programmed without any problems.

It seems that there is a timing issue (some timing is too short) that
is resolved by the intermediate output of strace.
Any thoughts about this?

BTW. I would love to try 1.2.0, if the source code were available (I
can probably hack around any remaining autoconf issues).
Another thing I noticed is that it is required to run "perl admin/
am_edit" after unpacking the tarball; otherwise the moc/icon rules
are not present in the Makefile. This might be worth mentioning in the
INSTALL file.

[Xiaofan Chen]

On Mon, Aug 10, 2009 at 3:23 PM, hogend<rene.ho...@gmail.com> wrote:
>
> With pickit 1.1.0-2 on Debian Sid amd64 (Phenom II 720) and using the
> Velleman 8048, the 16F627 was not recognized
> ( <no device present> after pressing "detect now").
> A 18F2550 is detected as expected and can be programmed as well.

It seems to me you are using some kind of IDE (pikdev?).
Did you try the standalone pk2cmd 1.20 which can be
downloaded from Microchip's website?
http://www.microchip.com/pickit2

Then you can see if it is a pk2cmd problem or your IDE problem.

--
Xiaofan http://mcuee.blogspot.com

[Alain Gibaud]

Le Monday 10 August 2009 09:23:12 hogend, vous avez écrit :

Hi,

I have often programmed a 16F628, (which is the same processor that 16F627)
whithout any problem.
Anyway, some devices are more sensitive to timing delays than others, and this
is perhaps why the programmer works with 18F and not with 16F627.

My first advice is to decouple CLK and DATA pins (to ground) with 47pF or
33pF. I have observed a very clear improvement of my parallel programmers
with this solution. See my site about this point

Anyway, your observation about running the program under strace is a strong
indication of a delay problem. The solution is simple :

edit the .pkprc file (in your home directory) and change the
delay=0
to
delay=<your value>

<your value> is a delay (in micro-second) which is added to each clock pulse,
when data are serialized to pic.

Good luck, please send a feedback about success/failure on this problem


Alain

PS. Tanks to your advice, the autotool issue is now fixed, so the source code
of pikdev 1.2.0 will be available soon.

[hogend]

Thanks everybody for the replies.

I changed the delay parameter for the programmer in pikdev to 1 and it
is properly detected now.
Programming the device also works. I suggest to change the default
parameters for the
Velleman k8048 to have a non-zero delay.

With the commandline pkp, I still have no success, even when the delay
parameter is changed.
Through strace, I can see that the delay is indeed non-zero, but the
device is still not detected
(pkp --probe gives "probed device: [] [31]").
The most notable difference between using pikdev and pkp is that, in
the latter case, the Vpp
remains 13V after the pkp command exits, whereas, with pikdev, Vpp
returns to 0V.
Regards,

Rene

[Xiaofan Chen]

On Wed, Aug 12, 2009 at 5:19 AM, hogend<rene.ho...@gmail.com> wrote:
>
> Thanks everybody for the replies.
>
> I changed the delay parameter for the programmer in pikdev to 1 and it
> is properly detected now.
> Programming the device also works. I suggest to change the default
> parameters for the
> Velleman k8048 to have a non-zero delay.
>
> With the commandline pkp, I still have no success, even when the delay
> parameter is changed.
> Through strace, I can see that the delay is indeed non-zero, but the
> device is still not detected
> (pkp --probe gives "probed device: [] [31]").
> The most notable difference between using pikdev and pkp is that, in
> the latter case, the Vpp
> remains 13V after the pkp command exits, whereas, with pikdev, Vpp
> returns to 0V.
> Regards,
>

Velleman k8048 may have its time. But why not move to a
better programmer like PICkit 2?

Anyway, this has nothing to do with PICkit 2 and thus pickit-devel
mailing list. Maybe you should use gnupic mailing list for future
problems with K8048 and pikdev. Thanks.
http://www.gnupic.org/

--
Xiaofan http://mcuee.blogspot.com

[hogend]

I already ordered one ;)

On 12 aug, 06:52, Xiaofan Chen <xiaof...@gmail.com> wrote:

[Xiaofan Chen]

On Wed, Aug 12, 2009 at 1:46 PM, hogend<rene.ho...@gmail.com> wrote:
>> Velleman k8048 may have its time. But why not move to a
>> better programmer like PICkit 2?
>

> I already ordered one ;)

Good idea. ;-) Please come back and tell us your experiences
once you get the PICkit 2.

--
Xiaofan http://mcuee.blogspot.com