Nabble - MicroControllers - GNUPIC

Re: PiKdev 1.2.1 available

2009-10-17T14:01:23Z

Le Saturday 17 October 2009 01:47:45 George M. Gallant, Jr., vous avez écrit :

Hello George

The src package containts a cpik050.pro, which is an input file for qmake
(the Makefile generator from trolltech/nokia which comes with Qt)

qmake -o Makefile cpik050.pro

generates the Makefile, according to the target system

This point is expained in the cpik WEB page, but an INSTALL
or README file should be provided in the package.

I plan to switch to cmake in the future - but I need to become comfortable
with it.

I am not sure it is really a good idea to install to /usr/local because
the executable itself is related to OS version (it depends on
glibc and stdc++ shared libraries)
After a major OS release, cpik will not work anymore if it is not rebuilded.
However, I must admit that such a situation is very rare.

Other files (cpik libraries, run-time library, devices headers) could be
stored in /usr/local/share. I just put them in /usr/share because 98%
of apps do that, but if people are unhappy with that, I can change it.

Alain

> Alain,
>
> I downloaded the src & bin for cpik. Two comments:
>
> 1. The src does not have a Makefile.
>
> 2. The bin install script is hard coded to install in /usr.
> I prefer to install non-distribution related code in /usr/local
> so that it does not get erased with the next OS upgrade.
>
> Thanks,
> George
>
> On 10/08/2009 04:21 PM, Alain Gibaud wrote:
> > Hi,
> >
> > PiKdev is a lightweigth integrated development environment for PIC
> > devices which exists since 2002. Due to various reasons, the development
> > of this IDE has been stopped during a couple of years, but I found enough
> > time to develop it again.
> >
> > PiKdev supports pic10, pic12, pic16 and pic18 devices.
> > Supported programmers are serial (JDM-like), parrallel (Tait-like)
> > or USB (Microchip's pickit2 and clones).
> >
> > Programming languages are ASM (with gputils tools) and C
> > (with the cpik compiler for PIC18 devices).
> >
> > PiKdev is simple but handy. It supports the "project concept",
> > but can also be used for stand-alone asm files.
> >
> > Recent improvements are:
> >
> > - Improved project browser, with direct access to each
> > function/variable/typedef declaration or definition.
> > This feature works also with cpik's source libraries (.slb files)
> > and is very useful when a project become important. A C parser has been
> > developped for C source code analysis.
> >
> > - Interactive CONFIG bits editor. This feature has been developed for
> > PIC18 devices because they contain no less then 14 config registers.
> > Populating these registers is a pain when you begin a project. The editor
> > allows you to choose a configuration and generates (commented) source
> > code for you. Can be used in both ASM or C contexts, and works for all
> > supported devices. Config fuses are now part of the project parameters.
> >
> > Link for pikdev: http://pikdev.free.fr
> >
> > The cpik (PIC18 only) compiler is now perfectly usable and has been used
> > for several projects (V0.5). Feel free to test and report opinions.
> >
> > Link for cpik: http://pikdev.free.fr/download-cpik.php3
> >
> > Alain
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...

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

Re: PiKdev 1.2.1 available

2009-10-16T16:47:45Z

Alain,

I downloaded the src & bin for cpik. Two comments:

1. The src does not have a Makefile.

2. The bin install script is hard coded to install in /usr.
I prefer to install non-distribution related code in /usr/local
so that it does not get erased with the next OS upgrade.

Thanks,
George

On 10/08/2009 04:21 PM, Alain Gibaud wrote:

> Hi,
>
> PiKdev is a lightweigth integrated development environment for PIC devices
> which exists since 2002. Due to various reasons, the development
> of this IDE has been stopped during a couple of years, but I found enough time
> to develop it again.
>
> PiKdev supports pic10, pic12, pic16 and pic18 devices.
> Supported programmers are serial (JDM-like), parrallel (Tait-like)
> or USB (Microchip's pickit2 and clones).
>
> Programming languages are ASM (with gputils tools) and C
> (with the cpik compiler for PIC18 devices).
>
> PiKdev is simple but handy. It supports the "project concept",
> but can also be used for stand-alone asm files.
>
> Recent improvements are:
>
> - Improved project browser, with direct access to each
> function/variable/typedef declaration or definition.
> This feature works also with cpik's source libraries (.slb files)
> and is very useful when a project become important. A C parser has been
> developped for C source code analysis.
>
> - Interactive CONFIG bits editor. This feature has been developed for PIC18
> devices because they contain no less then 14 config registers. Populating
> these registers is a pain when you begin a project. The editor allows you to
> choose a configuration and generates (commented) source code for you.
> Can be used in both ASM or C contexts, and works for all supported devices.
> Config fuses are now part of the project parameters.
>
> Link for pikdev: http://pikdev.free.fr
>
> The cpik (PIC18 only) compiler is now perfectly usable and has been used for
> several projects (V0.5). Feel free to test and report opinions.
>
> Link for cpik: http://pikdev.free.fr/download-cpik.php3
>
> Alain
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>
>

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

Re: PiKdev 1.2.1 available

2009-10-08T13:55:42Z

Alain Gibaud wrote:
> The cpik (PIC18 only) compiler is now perfectly usable and has been
> used for several projects (V0.5). Feel free to test and report
> opinions.

I haven't gotten around to using SDCC and I have to say I really the
looks of cpik! I'll give it a go in a project likely later this year.
I need timers, AD, some math and serial output so I'm all set! :)

//Peter

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

PiKdev 1.2.1 available

2009-10-08T13:21:38Z

Hi,

PiKdev is a lightweigth integrated development environment for PIC devices
which exists since 2002. Due to various reasons, the development
of this IDE has been stopped during a couple of years, but I found enough time
to develop it again.

PiKdev supports pic10, pic12, pic16 and pic18 devices.
Supported programmers are serial (JDM-like), parrallel (Tait-like)
or USB (Microchip's pickit2 and clones).

Programming languages are ASM (with gputils tools) and C
(with the cpik compiler for PIC18 devices).

PiKdev is simple but handy. It supports the "project concept",
but can also be used for stand-alone asm files.

Recent improvements are:

- Improved project browser, with direct access to each
function/variable/typedef declaration or definition.
This feature works also with cpik's source libraries (.slb files)
and is very useful when a project become important. A C parser has been
developped for C source code analysis.

- Interactive CONFIG bits editor. This feature has been developed for PIC18
devices because they contain no less then 14 config registers. Populating
these registers is a pain when you begin a project. The editor allows you to
choose a configuration and generates (commented) source code for you.
Can be used in both ASM or C contexts, and works for all supported devices.
Config fuses are now part of the project parameters.

Link for pikdev: http://pikdev.free.fr

The cpik (PIC18 only) compiler is now perfectly usable and has been used for
several projects (V0.5). Feel free to test and report opinions.

Link for cpik: http://pikdev.free.fr/download-cpik.php3

Alain

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

Re: Pic-Kit 3 and Linux?

2009-10-08T10:23:13Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-08T10:11:05Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:45:17Z

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@...
>

signature.asc (853 bytes) Download Attachment

Re: Pic-Kit 3 and Linux?

2009-10-08T09:44:46Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:37:37Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:29:19Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-08T09:05:27Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-07T23:32:16Z

>
> 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@...

Re: Pic-Kit 3 and Linux?

2009-10-07T21:25:17Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-07T21:22:43Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-07T19:42:18Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-07T19:24:48Z

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@...

Re: Pic-Kit 3 and Linux?

2009-10-07T18:51:55Z

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@...

Pic-Kit 3 and Linux?

2009-10-07T08:51:34Z

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@...

Re: Lightweight distros with GPUTILS in repository

2009-09-16T02:44:54Z

Hi,

Peter Olson wrote:
> Learn about using the 'top' program to find out how much real memory
> is used by various processes (this will take some studying of the
> help, I really can't give a 25 word explanation of what to do).

Alternatively,

ps xauww | sort -k4n

will list all the processes on the machine in order of their %MEM
column, largest last.

Cheers,

Ralph.

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

Re: Lightweight distros with GPUTILS in repository

2009-09-15T08:33:53Z

At 7:38 AM +0800 9/15/09, Jason Hsu wrote:
>I'm trying to program microcontrollers in C on a 10-year-old laptop
>with only 256 MB of RAM and a 500 MHz processor.

...

>Are there any lightweight distros that offer GPUTILS in the
>repository? Is there anything I can do in a distro to substantially
>reduce its RAM requirement?

Most distros start server process that you don't need. If you don't need to
send and receive email directly at the box, then disable sendmail. Don't
run Firefox; it uses tons of memory. Unfortunately, X tends to use a lot
of memory, but you may need it to run design tools. If you don't need graphic
tools, learn to use the command line, and log in at run level 3, where
the X server doesn't get started. Learn about using the 'top' program to find
out how much real memory is used by various processes (this will take some
studying of the help, I really can't give a 25 word explanation of what to do).

peter

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

Re: Lightweight distros with GPUTILS in repository

2009-09-15T06:56:33Z

On Tue, Sep 15, 2009 at 12:38 AM, Jason Hsu <jhsu802701@...> wrote:

> Are there any lightweight distros that offer GPUTILS in the repository? Is
> there anything I can do in a distro to substantially reduce its RAM
> requirement?
>

Usually graphical environment takes the most RAM so you may try not to
install X (and definitely not a big window manager like Gnome or KDE). With
'top' you can see which process takes most of the RAM so you may try to
remove those packages as well. You may also can try to use older kernels
with customized compilation so no unnecessary kernel modules are there.

Also you may can get a ram extention for your notebook from eBay or other
online market/store...

Tamas

>
> --
> Jason Hsu <jhsu802701@...>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

--
http://www.mcuhobby.com

Lightweight distros with GPUTILS in repository

2009-09-14T16:38:08Z

I'm trying to program microcontrollers in C on a 10-year-old laptop with only 256 MB of RAM and a 500 MHz processor.

I tried the version of Debian stable with XFCE as the default but gave up on it because I couldn't figure out how to get it to connect to the wireless Internet.

I tried Xubuntu, but it was slow. Even with no applications running, it used swap space.

As I mentioned before, I never was able to get GPUTILS to work in Puppy Linux or Damn Small Linux. The dependency hell was too overwhelming.

Are there any lightweight distros that offer GPUTILS in the repository? Is there anything I can do in a distro to substantially reduce its RAM requirement?

--
Jason Hsu <jhsu802701@...>

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

Re: How do I specify certain addresses to not be banked?

2009-09-14T05:13:48Z

It is better to use linker scripts and proper variable occupation with 'RES'
directive.

Anyway, it is also a common technique that you use a dedicated bank as a
"register area" or "temp bank" where the bank selection always points to
this area, and then use MOVFF to load the variables to this temporary area
before making any operation on it. For example if you need to do a long
calculation with several variables located in many different banks it is
better to move them to this "register area" and do all the calculations then
store the results back to it's original location. It is pretty much the same
as you were using a register architecture, and you can save CPU time and
program memory by this technique.

One another technique of course is to use the shared area for globals and
function parameters and each one of the program block use one particular
bank for it's locals (which the can be overlapped/overlayed with other
modules). Then at the module prolog you need to do a context saving and a
bank selection, then at the epilogue a context restore.

Which one is to use really depends on the application, and you can save on
banking quite a lot by choosing the right one.

Tamas

On Sun, Sep 13, 2009 at 5:39 PM, Jesse Gordon <jesseg@...> wrote:

> Hi Raphael,
>
> Thank you very much. You were most helpful!
>
> Actually, I was, for some reason, under the impression that the banked bit
> was set by default in the assembler - but I see now that for addresses 0-7f
> it is not set - which is exactly and perfectly what I want!
>
> Then for my non-"globals" I can just define them with EQU 0x1xx and they
> will all use the current bank select.
>
> Thank you very much!
>
> -Jesse
>
> Raphael Neider wrote:
>
>> Hi Jesse,
>>
>> And I wish to use the first half of bank 0 as "global" vars in the same
>>> way that the second half (the SFRs) are "global."
>>>
>>> [>>snip<<]
>>
>>> So, here is the question: How can I make some of my own ram locations
>>> also always be accessed in bank 0 without me having to specify the ",0" on
>>> every file instruction?
>>>
>>> For example, if I do:
>>>
>>> MyGlobalByte EQU 0xF01
>>>
>>> As it is, the assembler just drops the F00 part and a CLRF on
>>> MyGlobalByte will clear byte 1 in the currently selected bank. Why can't the
>>> assembler see that I've specified 0xF01 and automatically clear the
>>> use-bank-selected bit - Just like it does for addresses above 0xF80?
>>>
>>
>> The PICs have an access bank, which is split into general purpose
>> registers (often 0x00 - 0x7F, sometimes 0x00 - 0x5F) and special
>> function registers (0x80 - 0xFF, which are mapped to 0xF80 - 0xFFF,
>> sometimes 0x60 - 0xFF, remapped to 0xF60 - 0xFFF). The split point
>> is defined by Microchip and cannot be changed.
>> You can use
>>
>> MyGlobalByte EQU 0x001
>> ...
>> MyGlobalByte EQU 0x07F
>> SFR0xF80 EQU 0xF80
>> ...
>> SFR0xFFF EQU 0xFFF
>>
>> and gpasm (knowing the memory layout of the target device) will
>> access these via the access bank. All other memory locations
>> (0x80 - 0xF7F) will use banked access - so use proper BANKSEL
>> directives where needed.
>>
>> Hope that helps,
>> Raphael
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: gnupic-unsubscribe@...
>> For additional commands, e-mail: gnupic-help@...
>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

--
http://www.mcuhobby.com

Re: How do I specify certain addresses to not be banked?

2009-09-13T09:39:31Z

Hi Raphael,

Thank you very much. You were most helpful!

Actually, I was, for some reason, under the impression that the banked
bit was set by default in the assembler - but I see now that for
addresses 0-7f it is not set - which is exactly and perfectly what I want!

Then for my non-"globals" I can just define them with EQU 0x1xx and they
will all use the current bank select.

Thank you very much!

-Jesse

Raphael Neider wrote:

> Hi Jesse,
>
>> And I wish to use the first half of bank 0 as "global" vars in the
>> same way that the second half (the SFRs) are "global."
>>
> [>>snip<<]
>> So, here is the question: How can I make some of my own ram locations
>> also always be accessed in bank 0 without me having to specify the
>> ",0" on every file instruction?
>>
>> For example, if I do:
>>
>> MyGlobalByte EQU 0xF01
>>
>> As it is, the assembler just drops the F00 part and a CLRF on
>> MyGlobalByte will clear byte 1 in the currently selected bank. Why
>> can't the assembler see that I've specified 0xF01 and automatically
>> clear the use-bank-selected bit - Just like it does for addresses
>> above 0xF80?
>
> The PICs have an access bank, which is split into general purpose
> registers (often 0x00 - 0x7F, sometimes 0x00 - 0x5F) and special
> function registers (0x80 - 0xFF, which are mapped to 0xF80 - 0xFFF,
> sometimes 0x60 - 0xFF, remapped to 0xF60 - 0xFFF). The split point
> is defined by Microchip and cannot be changed.
> You can use
>
> MyGlobalByte EQU 0x001
> ...
> MyGlobalByte EQU 0x07F
> SFR0xF80 EQU 0xF80
> ...
> SFR0xFFF EQU 0xFFF
>
> and gpasm (knowing the memory layout of the target device) will
> access these via the access bank. All other memory locations
> (0x80 - 0xF7F) will use banked access - so use proper BANKSEL
> directives where needed.
>
> Hope that helps,
> Raphael
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>
>

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

Re: How do I specify certain addresses to not be banked?

2009-09-13T03:44:54Z

Hi Jesse,

> And I wish to use the first half of bank 0 as "global" vars in the same
> way that the second half (the SFRs) are "global."
>
[>>snip<<]

> So, here is the question: How can I make some of my own ram locations
> also always be accessed in bank 0 without me having to specify the ",0"
> on every file instruction?
>
> For example, if I do:
>
> MyGlobalByte EQU 0xF01
>
> As it is, the assembler just drops the F00 part and a CLRF on
> MyGlobalByte will clear byte 1 in the currently selected bank. Why can't
> the assembler see that I've specified 0xF01 and automatically clear the
> use-bank-selected bit - Just like it does for addresses above 0xF80?

The PICs have an access bank, which is split into general purpose
registers (often 0x00 - 0x7F, sometimes 0x00 - 0x5F) and special
function registers (0x80 - 0xFF, which are mapped to 0xF80 - 0xFFF,
sometimes 0x60 - 0xFF, remapped to 0xF60 - 0xFFF). The split point
is defined by Microchip and cannot be changed.
You can use

MyGlobalByte EQU 0x001
...
MyGlobalByte EQU 0x07F
SFR0xF80 EQU 0xF80
...
SFR0xFFF EQU 0xFFF

and gpasm (knowing the memory layout of the target device) will
access these via the access bank. All other memory locations
(0x80 - 0xF7F) will use banked access - so use proper BANKSEL
directives where needed.

Hope that helps,
Raphael

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

How do I specify certain addresses to not be banked?

2009-09-12T21:43:51Z

Greetings. This is my first post - so please be patient as I learn the
ropes. Thanks!

I'm working with an 18f1220.

I wish to use bank 1 for my main code, and bank 2 for my low priority
ISR so they can have each plenty of non-shared ram.

And I wish to use the first half of bank 0 as "global" vars in the same
way that the second half (the SFRs) are "global."

Let me explain:

PORTA, for example, is defined as:
PORTA EQU H'0F80'

Let's say I then do a:
CLRF PORTB
the assembler (gpasm-0.13.4 beta) does (and should) clear the access bit
so the CLRF will always operate on 0x80 in bank zero.

Thus, no matter what bank is currently set in BSR, a CLRF on PORTA will
always hit bank 0...

So, here is the question: How can I make some of my own ram locations
also always be accessed in bank 0 without me having to specify the ",0"
on every file instruction?

For example, if I do:

MyGlobalByte EQU 0xF01

As it is, the assembler just drops the F00 part and a CLRF on
MyGlobalByte will clear byte 1 in the currently selected bank. Why can't
the assembler see that I've specified 0xF01 and automatically clear the
use-bank-selected bit - Just like it does for addresses above 0xF80?

That way, whenever I do an operation on MyGlobalByte, it would always
(without me having to specify ",0") access 0x01 in bank 0.

Surely I can go change some line in some file to make it do that task
for the range of 0xF00-0xFFF since it already does it for 0xF80-0xFFF.

Thank you very much,

-Jesse

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

Re: What distros offer GNUPIC in the package management system?

2009-09-03T07:07:17Z

Jay Dagenais wrote:
> imo,, you are better off sticking with debian or possibly ubuntu.

I think that's a risky statement, because how the distribution works
is very important to me. The original question did not say what the
motivation for the question is, so it's impossible for everyone here
to share their (vast!) experience with gputils.

Me, I really like Gentoo. But Fedora Electronic Lab (FEL) looks very
interesting for EDA tasks:

http://chitlesh.fedorapeople.org/FEL/
http://fedoraproject.org/wiki/Interviews/FEL

//Peter

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

RE: What distros offer GNUPIC in the package management system?

2009-09-02T08:29:33Z

oh,, and I've had it running on suse,, but I think maybe I didn't get it thru yast but rpm'd from a site- this was some years ago so they may well have added it to the official package listing??

imo,, you are better off sticking with debian or possibly ubuntu.

> From: jaydag71@...
> To: gnupic@...
> Date: Wed, 2 Sep 2009 08:11:01 -0700
> Subject: RE: [gnupic] What distros offer GNUPIC in the package management system?
>
>
> I think you can find it for slackware also,,, but I could be wrong,, too many distros!!
>
> > Date: Wed, 2 Sep 2009 09:18:53 +0100
> > From: nospam@...
> > To: gnupic@...
> > Subject: Re: [gnupic] What distros offer GNUPIC in the package management system?
> >
> > Jason Hsu wrote:
> > > I know that Debian and Ubuntu both offer GNUPIC in the official package management system.
> > >
> > > What other distros offer GNUPIC through the official package management system?
> >
> > Is there a package called "GNUPIC"? Debian has:
> > gputils - GNU PIC utilities
> > gputils-common - headers and linker scripts for gputils
> > gputils-doc - documentation for gputils
> > picasm - Assembler for the Microchip PIC-family Microcontrollers
> >
> >
> > gpsim - Simulator for Microchip's PIC microcontrollers
> > gpsim-dev - Libraries needed only for building gpsim components
> > gpsim-doc - Documentation for gpsim
> > gpsim-lcd - LCD module for gpsim
> > gpsim-lcd-graphic - LCD module for gpsim
> > gpsim-led - LED module for gpsim
> > gpsim-logic - logic module for gpsim
> > nitpic - simulator for the Microchip PIC16C84 microcontroller
> > simulpic - simulator for Microchip PIC16F84 microcontroller
> >
> > picp - command line utility to drive a PICSTART programmer
> > picprog - Microchip PIC serial programmer software
> > odyssey - PIC microcontroller programming application
> >
> > sdcc - Small Device C Compiler
> > sdcc-doc - Small Device C Compiler (documentation)
> > sdcc-libraries - Small Device C Compiler (libraries)
> >
> > piklab - IDE for PIC-microcontroller development
> > No pikdev but there is a Debian package available
> > from the pikdev website: http://pikdev.free.fr/
> >
> > There are probably other PIC related packages in
> > Debian.
> >
> >
> >
> >
> >
> > --
> > Linux 2.6.30
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: gnupic-unsubscribe@...
> > For additional commands, e-mail: gnupic-help@...
> >
>
> _________________________________________________________________
> New! Open Messenger faster on the MSN homepage
> http://go.microsoft.com/?linkid=9677405

_________________________________________________________________
New! Open Messenger faster on the MSN homepage
http://go.microsoft.com/?linkid=9677405

RE: What distros offer GNUPIC in the package management system?

2009-09-02T08:11:01Z

I think you can find it for slackware also,,, but I could be wrong,, too many distros!!

> Date: Wed, 2 Sep 2009 09:18:53 +0100
> From: nospam@...
> To: gnupic@...
> Subject: Re: [gnupic] What distros offer GNUPIC in the package management system?
>
> Jason Hsu wrote:
> > I know that Debian and Ubuntu both offer GNUPIC in the official package management system.
> >
> > What other distros offer GNUPIC through the official package management system?
>
> Is there a package called "GNUPIC"? Debian has:
> gputils - GNU PIC utilities
> gputils-common - headers and linker scripts for gputils
> gputils-doc - documentation for gputils
> picasm - Assembler for the Microchip PIC-family Microcontrollers
>
>
> gpsim - Simulator for Microchip's PIC microcontrollers
> gpsim-dev - Libraries needed only for building gpsim components
> gpsim-doc - Documentation for gpsim
> gpsim-lcd - LCD module for gpsim
> gpsim-lcd-graphic - LCD module for gpsim
> gpsim-led - LED module for gpsim
> gpsim-logic - logic module for gpsim
> nitpic - simulator for the Microchip PIC16C84 microcontroller
> simulpic - simulator for Microchip PIC16F84 microcontroller
>
> picp - command line utility to drive a PICSTART programmer
> picprog - Microchip PIC serial programmer software
> odyssey - PIC microcontroller programming application
>
> sdcc - Small Device C Compiler
> sdcc-doc - Small Device C Compiler (documentation)
> sdcc-libraries - Small Device C Compiler (libraries)
>
> piklab - IDE for PIC-microcontroller development
> No pikdev but there is a Debian package available
> from the pikdev website: http://pikdev.free.fr/
>
> There are probably other PIC related packages in
> Debian.
>
>
>
>
>
> --
> Linux 2.6.30
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>

_________________________________________________________________
New! Open Messenger faster on the MSN homepage
http://go.microsoft.com/?linkid=9677405

Re: What distros offer GNUPIC in the package management system?

2009-09-02T01:18:53Z

Jason Hsu wrote:
> I know that Debian and Ubuntu both offer GNUPIC in the official package management system.
>
> What other distros offer GNUPIC through the official package management system?

Is there a package called "GNUPIC"? Debian has:
gputils - GNU PIC utilities
gputils-common - headers and linker scripts for gputils
gputils-doc - documentation for gputils
picasm - Assembler for the Microchip PIC-family Microcontrollers

gpsim - Simulator for Microchip's PIC microcontrollers
gpsim-dev - Libraries needed only for building gpsim components
gpsim-doc - Documentation for gpsim
gpsim-lcd - LCD module for gpsim
gpsim-lcd-graphic - LCD module for gpsim
gpsim-led - LED module for gpsim
gpsim-logic - logic module for gpsim
nitpic - simulator for the Microchip PIC16C84 microcontroller
simulpic - simulator for Microchip PIC16F84 microcontroller

picp - command line utility to drive a PICSTART programmer
picprog - Microchip PIC serial programmer software
odyssey - PIC microcontroller programming application

sdcc - Small Device C Compiler
sdcc-doc - Small Device C Compiler (documentation)
sdcc-libraries - Small Device C Compiler (libraries)

piklab - IDE for PIC-microcontroller development
No pikdev but there is a Debian package available
from the pikdev website: http://pikdev.free.fr/

There are probably other PIC related packages in
Debian.

--
Linux 2.6.30

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

Re: What distros offer GNUPIC in the package management system?

2009-09-01T18:45:36Z

Jason Hsu wrote:
> I know that Debian and Ubuntu both offer GNUPIC in the official package management
> system.
>
> What other distros offer GNUPIC through the official package management system?
>

Gentoo, and I suppose LFS... :-P

hth,

Jason.

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

What distros offer GNUPIC in the package management system?

2009-09-01T05:25:11Z

I know that Debian and Ubuntu both offer GNUPIC in the official package management system.

What other distros offer GNUPIC through the official package management system?

--
Jason Hsu <jhsu802701@...>

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

PIC32 site

2009-08-24T07:20:45Z

Hi people, reading about the PIC32 I found a lost site named
pic32.org which is more an idea than a site.. its very empty
and seems to be not maintained.

Does anyone knows something more about that site? Is it that
the owner has not time or that there are some legal issues
with the name? as I think its a brandnamed one.

I'm seeking for information about pic32 Tools, OSes,
libraries, code snippets, whatever... preferably open source.

I'm considering moving some of my developments to the PIC32
platform and as I know it's going to be a big change for me
and it as it will require lots of effort I would like to do
it on an open source platform.

------------------------------
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@...

Re: What's your distro?

2009-08-13T05:20:20Z

Debian... reconsidering using Ubuntu due to some problems with my video
card... as Xiaofan mentioned I'm becoming a packages expert! :-)

Anselmo Luginbuhl escribió:
> Debian
>

--
Mauricio Giovagnini (Maunix)
Sitio Web: www.maunix.com.ar

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

Re: What's your distro?

2009-07-28T13:22:44Z

On Sunday 26 July 2009, Jason Hsu wrote:
> I want to see what distro every GNUPIC user here uses. You don't need to explain why in this thread - just name the distro you are using.
>
> I just want to see what distros people have successfully used for programming PIC microcontrollers in GNUPIC.
>

Linux From Scratch

--
Holger Oehm <holger.oehm@...>
KeyID: B50E51A9, 1024bit at http://www.holger-oehm.de/public-key.asc
Fingerprint: E92A 5C2C 497A 44ED 23C0 DB66 1DD9 3EF7 B50E 51A9

signature.asc (204 bytes) Download Attachment