Pic-Kit 3 and Linux?

[Joe Pfeiffer-3]

I see code to use Microchip's PICkit 2 under Linux is available from
Microchip.  Meanwhile, they are pushing hard to use their PICKit 3 for
new designs.  Does the PICKit 3 use the same command set as PICKit 2,
or is there otherwise a way to use it with Linux?

Thanks,

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Xiaofan Chen]

On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer <joseph@...> wrote:
> I see code to use Microchip's PICkit 2 under Linux is available from
> Microchip.  Meanwhile, they are pushing hard to use their PICKit 3 for
> new designs.  Does the PICKit 3 use the same command set as PICKit 2,
> or is there otherwise a way to use it with Linux?
>

PICkit 3 does not use the same command set as PICkit 2. Its
firmware structure is also different from PICkit 2 (more like ICD 2).
So as of now it is not working under native Linux.

You can of course use Virtual Machines and Windows to get
it working under Linux.

I am not so sure when this situation will change. As of now,
PICkit 3 is not as good as PICkit 2, even under Windows.
Ref: http://www.microchip.com/forums/tm.aspx?m=450226


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

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Noel Henson]

On Wednesday 07 October 2009, Xiaofan Chen wrote:
> On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer <joseph@...>
wrote:

> > I see code to use Microchip's PICkit 2 under Linux is available from
> > Microchip.  Meanwhile, they are pushing hard to use their PICKit 3 for
> > new designs.  Does the PICKit 3 use the same command set as PICKit 2,
> > or is there otherwise a way to use it with Linux?
>
> PICkit 3 does not use the same command set as PICkit 2. Its
> firmware structure is also different from PICkit 2 (more like ICD 2).
> So as of now it is not working under native Linux.
>
> You can of course use Virtual Machines and Windows to get
> it working under Linux.
>
> I am not so sure when this situation will change. As of now,
> PICkit 3 is not as good as PICkit 2, even under Windows.
> Ref: http://www.microchip.com/forums/tm.aspx?m=450226

Just a question... Do really we need an inexpensive, Linux-capable PIC
programmer?

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Noel Henson]

On Wednesday 07 October 2009, Noel Henson wrote:

> On Wednesday 07 October 2009, Xiaofan Chen wrote:
> > On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer
> > <joseph@...>
>
> wrote:
> > > I see code to use Microchip's PICkit 2 under Linux is available from
> > > Microchip.  Meanwhile, they are pushing hard to use their PICKit 3
> > > for new designs.  Does the PICKit 3 use the same command set as
> > > PICKit 2, or is there otherwise a way to use it with Linux?
> >
> > PICkit 3 does not use the same command set as PICkit 2. Its
> > firmware structure is also different from PICkit 2 (more like ICD 2).
> > So as of now it is not working under native Linux.
> >
> > You can of course use Virtual Machines and Windows to get
> > it working under Linux.
> >
> > I am not so sure when this situation will change. As of now,
> > PICkit 3 is not as good as PICkit 2, even under Windows.
> > Ref: http://www.microchip.com/forums/tm.aspx?m=450226
>
> Just a question... Do really we need an inexpensive, Linux-capable PIC
> programmer?
>
> Noel

Whoa, it must be getting late. That should read, "do we really need an
inexpensive, Linux-capable PIC programmer?"

Noel


--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Joe Pfeiffer-3]

Xiaofan Chen writes:

>On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer <joseph@...> wrote:
>> I see code to use Microchip's PICkit 2 under Linux is available from
>> Microchip.  Meanwhile, they are pushing hard to use their PICKit 3 for
>> new designs.  Does the PICKit 3 use the same command set as PICKit 2,
>> or is there otherwise a way to use it with Linux?
>>
>
>PICkit 3 does not use the same command set as PICkit 2. Its
>firmware structure is also different from PICkit 2 (more like ICD 2).
>So as of now it is not working under native Linux.
>
>You can of course use Virtual Machines and Windows to get
>it working under Linux.

That's what I was afraid of.  I'm currently only using the open source
version of VirtualBox, so this would involve switching....  not a big
effort, but something I'd rather not do.

>I am not so sure when this situation will change. As of now,
>PICkit 3 is not as good as PICkit 2, even under Windows.
>Ref: http://www.microchip.com/forums/tm.aspx?m=450226

That's very interesting to know -- it's actually a bit odd that they
still sell PK2, since they're so emphatic on wanting people to use
PK3.

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Joe Pfeiffer-3]

Noel Henson writes:

>On Wednesday 07 October 2009, Noel Henson wrote:
>> On Wednesday 07 October 2009, Xiaofan Chen wrote:
>> > On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer
>> > <joseph@...>
>>
>> wrote:
>> > > I see code to use Microchip's PICkit 2 under Linux is available from
>> > > Microchip.  Meanwhile, they are pushing hard to use their PICKit 3
>> > > for new designs.  Does the PICKit 3 use the same command set as
>> > > PICKit 2, or is there otherwise a way to use it with Linux?
>> >
>> > PICkit 3 does not use the same command set as PICkit 2. Its
>> > firmware structure is also different from PICkit 2 (more like ICD 2).
>> > So as of now it is not working under native Linux.
>> >
>> > You can of course use Virtual Machines and Windows to get
>> > it working under Linux.
>> >
>> > I am not so sure when this situation will change. As of now,
>> > PICkit 3 is not as good as PICkit 2, even under Windows.
>> > Ref: http://www.microchip.com/forums/tm.aspx?m=450226
>>
>> Just a question... Do really we need an inexpensive, Linux-capable PIC
>> programmer?
>>
>> Noel
>
>Whoa, it must be getting late. That should read, "do we really need an
>inexpensive, Linux-capable PIC programmer?"

"Need" is an awfully strong word.  If you were to dilute your question
to "would we really, really prefer to have an inexpensive PIC
programmer we can use without either rebooting to Windows or starting
a VM", my answer would be "yes".

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[vaclavpe]

>
> Just a question... Do really we need an inexpensive, Linux-capable PIC
> programmer?
>
> Noel
>

Sometimes, I would really need a Linux-capable debugger as well - i use PIC18F family and SDCC. Even debugging in GDB would be sufficient.

Vaclav

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Noel Henson]

On Wednesday 07 October 2009, Joe Pfeiffer wrote:

> Noel Henson writes:
> >On Wednesday 07 October 2009, Noel Henson wrote:
> >> On Wednesday 07 October 2009, Xiaofan Chen wrote:
> >> > On Wed, Oct 7, 2009 at 11:51 PM, Joe Pfeiffer
> >> > <joseph@...>
> >>
> >> wrote:
> >> > > I see code to use Microchip's PICkit 2 under Linux is available
> >> > > from Microchip.  Meanwhile, they are pushing hard to use their
> >> > > PICKit 3 for new designs.  Does the PICKit 3 use the same command
> >> > > set as PICKit 2, or is there otherwise a way to use it with
> >> > > Linux?
> >> >
> >> > PICkit 3 does not use the same command set as PICkit 2. Its
> >> > firmware structure is also different from PICkit 2 (more like ICD
> >> > 2). So as of now it is not working under native Linux.
> >> >
> >> > You can of course use Virtual Machines and Windows to get
> >> > it working under Linux.
> >> >
> >> > I am not so sure when this situation will change. As of now,
> >> > PICkit 3 is not as good as PICkit 2, even under Windows.
> >> > Ref: http://www.microchip.com/forums/tm.aspx?m=450226
> >>
> >> Just a question... Do really we need an inexpensive, Linux-capable
> >> PIC programmer?
> >>
> >> Noel
> >
> >Whoa, it must be getting late. That should read, "do we really need an
> >inexpensive, Linux-capable PIC programmer?"
>
> "Need" is an awfully strong word.  If you were to dilute your question
> to "would we really, really prefer to have an inexpensive PIC
> programmer we can use without either rebooting to Windows or starting
> a VM", my answer would be "yes".
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...

The reason I ask is that I'd have no problem designing a universal PIC
programmer for us all to use. In the past I needed to create one that
worked for a particular line of remote controls for groups. It could
program the Atmel (which is SPI-like) and Microchip (different for each
family + HV Vpp). If the complexity of the programming 'OS' as Microchip
calls it is removed from the programmer, or rather if the programmer only
knew about the physical layer protocol, then the programming algorithm for
each family could reside on the host where it is very easy to change.

If I were to design one, I'd probably take the cheapest PIC part with and
SCI port, add a charge pump for Vpp and throw on a USB-to-serial IC and
call it done. But I'll only put in the effort if there's interest.

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Joe Pfeiffer-3]

Noel Henson writes:

>
>The reason I ask is that I'd have no problem designing a universal PIC
>programmer for us all to use. In the past I needed to create one that
>worked for a particular line of remote controls for groups. It could
>program the Atmel (which is SPI-like) and Microchip (different for each
>family + HV Vpp). If the complexity of the programming 'OS' as Microchip
>calls it is removed from the programmer, or rather if the programmer only
>knew about the physical layer protocol, then the programming algorithm for
>each family could reside on the host where it is very easy to change.
>
>If I were to design one, I'd probably take the cheapest PIC part with and
>SCI port, add a charge pump for Vpp and throw on a USB-to-serial IC and
>call it done. But I'll only put in the effort if there's interest.

I'd be interested in such a thing.  Having the intelligence on the
host would definitely be a Good Thing.

Why a PIC with SCI and a USB-to-serial rather than a PIC with USB?
Also, for ease in assembly, I'd suggest cheapest DIP rather than
cheapest (I've hand soldered surface-mount and regarded it as No Fun).

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Peter Stuge-4]

Joe Pfeiffer wrote:
> >If I were to design one, I'd probably take the cheapest PIC part
> >with and SCI port, add a charge pump for Vpp and throw on a
> >USB-to-serial IC and call it done. But I'll only put in the effort
> >if there's interest.
>
> I'd be interested in such a thing.  Having the intelligence on the
> host would definitely be a Good Thing.

It will also be kinda slow. But it's better than nothing.


> Why a PIC with SCI and a USB-to-serial rather than a PIC with USB?

Please PLEASE do not ever use USB-to-serial as the first choice!
It's a totally dumbed down way of using USB. It would be MUCH better
to use one of the USB PICs.


> Also, for ease in assembly, I'd suggest cheapest DIP rather than
> cheapest (I've hand soldered surface-mount and regarded it as No
> Fun).

I think SMT is fun, but it can be small. Fortunately there are USB
PICs which come in both SO and PDIP packaging so the same design can
easily be reused to create both a very compact design, and one which
is very easy to build.


Note that this design, (USB PCI + sync serial port + charge pump) is
pretty much what is inside the PICkit2.


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Noel Henson]

On Thursday 08 October 2009, Joe Pfeiffer wrote:

> Noel Henson writes:
> >The reason I ask is that I'd have no problem designing a universal PIC
> >programmer for us all to use. In the past I needed to create one that
> >worked for a particular line of remote controls for groups. It could
> >program the Atmel (which is SPI-like) and Microchip (different for each
> >family + HV Vpp). If the complexity of the programming 'OS' as
> > Microchip calls it is removed from the programmer, or rather if the
> > programmer only knew about the physical layer protocol, then the
> > programming algorithm for each family could reside on the host where
> > it is very easy to change.
> >
> >If I were to design one, I'd probably take the cheapest PIC part with
> > and SCI port, add a charge pump for Vpp and throw on a USB-to-serial
> > IC and call it done. But I'll only put in the effort if there's
> > interest.
>
> I'd be interested in such a thing.  Having the intelligence on the
> host would definitely be a Good Thing.
>
> Why a PIC with SCI and a USB-to-serial rather than a PIC with USB?
> Also, for ease in assembly, I'd suggest cheapest DIP rather than
> cheapest (I've hand soldered surface-mount and regarded it as No Fun).
>

Ah, the reason for the PIC with the USB IC are the issues with
cross-platform USB drivers. I've been down this road many times. It's much
easier for small volume products to put all of the USB issues to rest by
using a USB-to-serial IC. No firmware issues. No extra engineering issues.  
No wasted host driver development time. That kind of thing. And the
manufacturer of the USB-to-serial IC takes care of and keeps up-to-date the
host-side drivers.

I do prefer the SMT devices, though. If one can solder a DIP, then one can
solder a 50mil pitch SMT device. But, if we get that far with this, I'll
keep that in mind. Besides, if I were to do such a thing, I'd try to have
them assembled professionally in panels.

Noel

--

------------------------------------------------------------------
  Noel Henson
  www.noels-lab.com Chips, firmware and embedded systems
  www.vimoutliner.org Work fast. Think well.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Anselmo Luginbuhl]

On Thu, Oct 08, 2009 at 09:05:27AM -0700, Noel Henson wrote:

>
> The reason I ask is that I'd have no problem designing a universal PIC
> programmer for us all to use. In the past I needed to create one that
> worked for a particular line of remote controls for groups. It could
> program the Atmel (which is SPI-like) and Microchip (different for each
> family + HV Vpp). If the complexity of the programming 'OS' as Microchip
> calls it is removed from the programmer, or rather if the programmer only
> knew about the physical layer protocol, then the programming algorithm for
> each family could reside on the host where it is very easy to change.
>
> If I were to design one, I'd probably take the cheapest PIC part with and
> SCI port, add a charge pump for Vpp and throw on a USB-to-serial IC and
> call it done. But I'll only put in the effort if there's interest.
>
> Noel

Hi,

have you seen the Open Programmer?

http://openprog.altervista.org/

Anselmo

>
> --
>
> ------------------------------------------------------------------
>   Noel Henson
>   www.noels-lab.com Chips, firmware and embedded systems
>   www.vimoutliner.org Work fast. Think well.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>

[Peter Stuge-4]

Noel Henson wrote:
> Ah, the reason for the PIC with the USB IC are the issues with
> cross-platform USB drivers.

Strongly disagree. It's not that tricky. libusb and WinUSB cover a
lot of ground.

Good descriptors (no, I don't mean HID. Axelson's advice is great if
Windows is the only thing in one's world) and only very little host
code is needed.


> It's much easier for small volume products to put all of the USB
> issues to rest by using a USB-to-serial IC. No firmware issues. No
> extra engineering issues. No wasted host driver development time.

Your choice. I think USB devices deserve more careful thought. It is
almost always possible to make use of USB features in a way that
benefits the application, which is just impossible with a dumb
USB-to-serial chip. And, a discrete chip adds to BOM, size and cost,
only if just very little.

Finally, when USB-to-serial is an absolute must, I suggest Silicon
Labs CP2102 or CP2103, or possibly Prolific PL2303, rather than FTDI
chips. (No, I don't work for them. I've just had too much annoying
trouble with FTDI parts.)

https://www.silabs.com/products/interface/usbtouart/
https://www.silabs.com/Marcom%20Documents/Resources/CP210x_Comparison.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2102.pdf
https://www.silabs.com/Support%20Documents/TechnicalDocs/cp2103.pdf


//Peter

---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Ralph Corderoy]

Hi Noel,

> The reason I ask is that I'd have no problem designing a universal PIC
> programmer for us all to use.

Are you familiar with USBprog?  There was an article on it in Elektor a
while back.

    http://www.embedded-projects.net/index.php?page_id=165

Open source hardware and software.  Different firmwares for programming
different families of devices along with other non-programming tasks.

    http://www.embedded-projects.net/index.php?page_id=168

Having that support PIC properly would be good.

Cheers,


Ralph.


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...

[Mauricio Giovagnini]

Noel Henson wrote:

>> For additional commands, e-mail: gnupic-help@...
>
> The reason I ask is that I'd have no problem designing a universal PIC
> programmer for us all to use. In the past I needed to create one that
> worked for a particular line of remote controls for groups. It could
> program the Atmel (which is SPI-like) and Microchip (different for each
> family + HV Vpp). If the complexity of the programming 'OS' as Microchip
> calls it is removed from the programmer, or rather if the programmer only
> knew about the physical layer protocol, then the programming algorithm for
> each family could reside on the host where it is very easy to change.
>
> If I were to design one, I'd probably take the cheapest PIC part with and
> SCI port, add a charge pump for Vpp and throw on a USB-to-serial IC and
> call it done. But I'll only put in the effort if there's interest.
>
> Noel

Noel although your proposal is really nice I've seen such
efforts many times on Windows Platform.  Anytime a problem
arises there's was one man hero that solved the problem but
then the issue was... what about then? support for new
devices, bug corrections, etc.
After years passed it's common to loose interest in such a
thing and that's where open source is vital, chances are
that a new developer will be there to help and continue the
project.

Making a programmer is not a trivial thing, I've seen much
programmers that do work but only under certain
circumstances, if you use a Capacitor in the vpp pin then
the programmer could fail on some situations.. and such
annoying things.  Then there is one post regarding that he
can't make it work with the picxxxx and then you will have a
problem: helping him? not helping him? is he installing
correctly the software ? did he assembled the programmer
hardware ok? and many many things that will be time
demanding... so a community doing this will be better than
just one man.

I don't have enough time to help in such a thing although I
am much interested as I am an electronic engineer with
background in Embedded software for microcontrollers and PCs
and I could help on any of those areas but If I can't help
with the necessary amount of time I'd prefer not to disturb
the developing process.

If I were you I would invest my time on an already working
project for many reasons, right now this come to my mind

1. Perhaps many problems already solved (like how to make
the interface protocol with the PC)
2. Current users that will help in testing the product on
several devices
3. Many things already tested (don't need to reinvent the wheel)


There are several such devices around

a) The pickit 2 itself, I remember some months ago that a
Microchip member wrote that the problem with the pickit2 was
that the embedded coders where not expert in PC software
programming and vice versa so having opened its architecture
didn't give the expected benefits.
Anyway I think the pickit project was born due to dozens of
bad quality pic programmers that were more than a headache
to Microchip Support personnel (those bad quality
programmers tend to burn the programming circuits of the pic
so after 2 or 3 device programming access to it was denied,
I know that because I had bought many of such programmers hehe)

b) The Open OCD programmer [0].  Although I think is more
meant to JTAG devices it could be a nice start knowing that
they have solved the communication interface with the PC

c) The Open Pic Programmer [1] , I haven't used it but I
think again that will be a good start rather than developing
something from scratch.

d) The USBPRog [2], its based on an Atmel microcontroller
but again may be there are somethings that can be
extrapolated to a pic and the PC interface it could be reused


May be there are others around but this could be a good start.


Regards


[0] http://openocd.berlios.de/web/
[1] http://openprog.altervista.org/OP_eng.html
[2] http://www.embedded-projects.net/index.php?page_id=165





------------------------------
Mauricio Giovagnini (Maunix)
www.maunix.com.ar
Cordoba, Arg.
LinkedIn Profile: http://www.linkedin.com/in/mgiovagnini


---------------------------------------------------------------------
To unsubscribe, e-mail: gnupic-unsubscribe@...
For additional commands, e-mail: gnupic-help@...