gnupic: Thread: Re: picp

Hi all, I just subscribed.

I've been working on some modifications to picp, mainly to support 
pic18fxx2, as pointed out by Antonio TodoBom, which is sponsoring this 
effort.

I'm close to declaring some of these changes as stable, Antonio is 
already testing most of the work already implemented.

As soon as it shows some results, I'll be posting patches against the 
original picp.

To the concerns of forking the project, I don't plan to, since I planned 
into making these changes as to add more resources to the original picp, 
and both Antonio and I would be glad of the changes would appear on the 
original program.

Speaking in terms of programming, I would like to perform several 
changes to picp, in order to make it more easy to maintain, and to 
ressemble more closely to the traditional command line behaviour and the 
source code indentation of most gnu tools, which eventually could be 
easier to do by rewriting it almost from scratch, indeed, but currently 
I lack the time to do it (and even if I supposedly did not, I don't 
think it would necessarily be a fork, since I would prefer to coordinate 
with picp authors. They did a great job on reverse engineering the 
protocol, and deserve all credit for that).

But back to the subject, here is what is working so far (on pic18f252):

reading program memory, eeprom, id locations, configuration bits;
writing to program memory.

Soon I'll finish preliminary support for writing to configuration bits, 
id locations and eeprom (both from the command line and from the hex 
files, where applicable). That should take a few days yet. As long as 
testing seems ok, the patch will be posted

Thank you all,

Alexandre (AKA Alex).

On Thu, 11 Sep 2003 4:51 am, Alexandre Pereira Nunes wrote:
> Hi all, I just subscribed.
> 
> I've been working on some modifications to picp, mainly to support 
> pic18fxx2, as pointed out by Antonio TodoBom, which is sponsoring this 
> effort.
> 
> I'm close to declaring some of these changes as stable, Antonio is 
> already testing most of the work already implemented.
> 
> As soon as it shows some results, I'll be posting patches against the 
> original picp.
> 
> To the concerns of forking the project, I don't plan to, since I planned 
> into making these changes as to add more resources to the original picp, 
> and both Antonio and I would be glad of the changes would appear on the 
> original program.
> 
> Speaking in terms of programming, I would like to perform several 
> changes to picp, in order to make it more easy to maintain, and to 
> ressemble more closely to the traditional command line behaviour and the 
> source code indentation of most gnu tools, which eventually could be 
> easier to do by rewriting it almost from scratch, indeed, but currently 
> I lack the time to do it (and even if I supposedly did not, I don't 
> think it would necessarily be a fork, since I would prefer to coordinate 
> with picp authors. They did a great job on reverse engineering the 
> protocol, and deserve all credit for that).
> 
> But back to the subject, here is what is working so far (on pic18f252):
> 
> reading program memory, eeprom, id locations, configuration bits;
> writing to program memory.
> 
> Soon I'll finish preliminary support for writing to configuration bits, 
> id locations and eeprom (both from the command line and from the hex 
> files, where applicable). That should take a few days yet. As long as 
> testing seems ok, the patch will be posted
> 
> Thank you all,
> 
> Alexandre (AKA Alex).
> 
> 

that is awesome.. this means I can start developing for the PIC18 again..

I had started but having to transfer code on to the PC with the Promate 
attached was a pain... I downloaded the latest firmware for my PS+ but 
haven't been able to use it yet..  I'm stuck on 16f877 with ICD1. :/

Matt

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


|that is awesome.. this means I can start developing for the PIC18 again..
|
|I had started but having to transfer code on to the PC with the Promate
|attached was a pain... I downloaded the latest firmware for my PS+ but
|haven't been able to use it yet..  I'm stuck on 16f877 with ICD1. :/
|
|Matt
|
If it's any help, I've just released a program on freshmeat, called
Zaphire, that can program 18XX2/8 chips using a David Tait style
programmer (IE a bunch of latches and nothing else).  I haven't heard
any feedback as to whether it works for other people, but I'm using it
at Uni to program 18F458s and it works fine.

Sorry about the shameless plug.  I also might have sent this twice, in
which case I'm REALLY sorry.

Widget
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/YFzRy89ZHgoCjScRAlWdAKCRWEEAvHhd/avSqVFUeq5OQ0Jl1wCeMB9I
YNZqLRSz1OyU2qDOwVq2wGs=
=s54f
-----END PGP SIGNATURE-----

I freely admit to being derelict in my picp duties.  I does everything 
*I* need it to do, so additional features and updates have lagged 
somewhat (very selfish, I know).

I'm happy to integrate any improvements anyone has to offer.  If 
someone feels very strongly about it and wants to take on the 
responsibility of maintaining the whole thing, I'd be happy to turn 
over the reins.  The truth is that I don't use PICs much anymore 
(nothing more sophisticated than the 12C508), so I'm probably not the 
best person to be maintaining it at this point, given the size of the 
user base.

I'll even look the other way if that person decides to destroy all my 
beautiful, legible source code formatting and replaces it with that 
horrible K&R format :).

   -Andrew



On Wednesday, September 10, 2003, at 01:51 PM, Alexandre Pereira Nunes 
wrote:

> Hi all, I just subscribed.
>
> I've been working on some modifications to picp, mainly to support 
> pic18fxx2, as pointed out by Antonio TodoBom, which is sponsoring this 
> effort.
>
> I'm close to declaring some of these changes as stable, Antonio is 
> already testing most of the work already implemented.
>
> As soon as it shows some results, I'll be posting patches against the 
> original picp.
>
> To the concerns of forking the project, I don't plan to, since I 
> planned into making these changes as to add more resources to the 
> original picp, and both Antonio and I would be glad of the changes 
> would appear on the original program.
>
> Speaking in terms of programming, I would like to perform several 
> changes to picp, in order to make it more easy to maintain, and to 
> ressemble more closely to the traditional command line behaviour and 
> the source code indentation of most gnu tools, which eventually could 
> be easier to do by rewriting it almost from scratch, indeed, but 
> currently I lack the time to do it (and even if I supposedly did not, 
> I don't think it would necessarily be a fork, since I would prefer to 
> coordinate with picp authors. They did a great job on reverse 
> engineering the protocol, and deserve all credit for that).
>
> But back to the subject, here is what is working so far (on pic18f252):
>
> reading program memory, eeprom, id locations, configuration bits;
> writing to program memory.
>
> Soon I'll finish preliminary support for writing to configuration 
> bits, id locations and eeprom (both from the command line and from the 
> hex files, where applicable). That should take a few days yet. As long 
> as testing seems ok, the patch will be posted
>
> Thank you all,
>
> Alexandre (AKA Alex).
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####

Andrew Pines wrote:

> I freely admit to being derelict in my picp duties.  I does everything 
> *I* need it to do, so additional features and updates have lagged 
> somewhat (very selfish, I know).
>
> I'm happy to integrate any improvements anyone has to offer.  If 
> someone feels very strongly about it and wants to take on the 
> responsibility of maintaining the whole thing, I'd be happy to turn 
> over the reins.  The truth is that I don't use PICs much anymore 
> (nothing more sophisticated than the 12C508), so I'm probably not the 
> best person to be maintaining it at this point, given the size of the 
> user base.
>
> I'll even look the other way if that person decides to destroy all my 
> beautiful, legible source code formatting and replaces it with that 
> horrible K&R format :).
>
>   -Andrew
>

K&R wasn't on my mind, either! :-)

I'm very happy to contribute to it, and even though there's room for 
improvements on adjacent areas, I'll be satisfied to reach the goal of 
writing to 18fx52, as we go (currently, I only have 18f252 & 18f452 for 
testing. Since some of the required data (apparently) wasn't available 
on the headers sent to the picstart, I had to add those by hand to the 
device structure).

As for maintaining, I'm not a pic programmer myself, and I currently 
lack free time, so I don't believe I'm the man for the task, at least 
not nowadays. Nevertheless, I'll be glad to help anyone whiling to the 
task, as long as I can...

Alexandre

> I'm very happy to contribute to it, and even though there's room for
> improvements on adjacent areas, I'll be satisfied to reach the goal of
> writing to 18fx52, as we go (currently, I only have 18f252 & 18f452 for
> testing. Since some of the required data (apparently) wasn't available
> on the headers sent to the picstart, I had to add those by hand to the
> device structure).

Is programming the 18Fxx20 parts the same? Or is that yet another part that
needs to be coded? I'm currently working on a board with an 18F6520 (I think
that's the part num).

-- 
Rick

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rick Mann wrote:

>>I'm very happy to contribute to it, and even though there's room for
>>improvements on adjacent areas, I'll be satisfied to reach the goal of
>>writing to 18fx52, as we go (currently, I only have 18f252 & 18f452 for
>>testing. Since some of the required data (apparently) wasn't available
>>on the headers sent to the picstart, I had to add those by hand to the
>>device structure).
>>    
>>
>
>Is programming the 18Fxx20 parts the same? Or is that yet another part that
>needs to be coded? I'm currently working on a board with an 18F6520 (I think
>that's the part num).
>
>  
>

Currently, with the changes I've made, supporting  any part not already 
supported requires some coding (filling some variables, actually). I'm 
trying to overcome these limitations as possible but have not yet 
suceeded on that.

I guess it's trivial to set the xx20 parts up,  but that's yet to be 
confirmed. Currently I still have to finish some things up, but right 
after that I'll take a look at that. I'll let you know, then.

- - Alexandre

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/YTLzc/q4llewz9oRApJAAKCxrm7LoYDOchCetXlXVIZDqEKrbgCg3Xa2
m2meobZwbRslHLlyFpbwfUA=
=g2zO
-----END PGP SIGNATURE-----

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Rick Mann wrote:

>>I guess it's trivial to set the xx20 parts up,  but that's yet to be
>>confirmed. Currently I still have to finish some things up, but right
>>after that I'll take a look at that. I'll let you know, then.
>>    
>>
>
>Wow...thank you very much.
>
>  
>

I checked in mplab, it seems that the picstart plus programmer do not 
support the 18F6520 part (at least not with the firmware revision I have 
here, it's not the latest).

That sucks. Until (read: if) that changes, we cannot do much about it.

Antonio also mentioned that there are some parts which, according to 
microchip, will not be supported at all, 'cause of hardware restrictions.

Does someone have something to add about this point?

- - Alexandre


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/ZI1Jc/q4llewz9oRAqnIAKC2shQ4efDYVpNgyaY8BlUAv1SIcwCfT40j
MN+IddSWipY3BAIkOzfjhg4=
=bTCk
-----END PGP SIGNATURE-----

There's a pretty thorough document on the Microchip website about using ICSP
to program the 18Fxx20 parts. Does this not provide sufficient information
on programming the part?

-- 
Rick

Sorry, forgot the link:

http://www.microchip.com/1010/pline/picmicro/category/embctrl/32kbytes/devic
es/18f6520/9831/index.htm

-- 
Rick