PK2 resources for beginners who would like to achieve something

[Darwin Pintado-2]

Hi,

I purchased a pk2 programmer 3-years ago and I thought I will be able to
learn it fast but I wrong. Until now, I haven't programmed it nor did any
projects. I want to create projects but I can't start I don't know where to
start if I want to make mechanical based projects.
I know there were alot of reference by googling but most are complicated for
a starter like me. Can someone point me to the right resources?

Many thanks,
d


>

[Darwin Pintado-2]

What I meant was mechanical project for bike innovation

On Thu, Jun 11, 2009 at 4:28 AM, Darwin Pintado <dwhitekiss@...>wrote:

> Hi,
>
> I purchased a pk2 programmer 3-years ago and I thought I will be able to
> learn it fast but I wrong. Until now, I haven't programmed it nor did any
> projects. I want to create projects but I can't start I don't know where to
> start if I want to make mechanical based projects.
> I know there were alot of reference by googling but most are complicated
> for a starter like me. Can someone point me to the right resources?
>
> Many thanks,
> d
>
>
>>
>

[Tamas Rudnai]

On Thu, Jun 11, 2009 at 5:28 AM, Darwin Pintado <dwhitekiss@...>wrote:

> Hi,
>
> I purchased a pk2 programmer 3-years ago and I thought I will be able to
> learn it fast but I wrong. Until now, I haven't programmed it nor did any
> projects. I want to create projects but I can't start I don't know where to
> start if I want to make mechanical based projects.
> I know there were alot of reference by googling but most are complicated
> for
> a starter like me. Can someone point me to the right resources?


You can start somewhere like reading some books and do some very basics like
flashing LED, read a button, write something on LCD etc...
Mikroelectronika's books are quite good for that and is free of charge to
read online:

http://www.mikroe.com/en/books/

After that you will be on the right track to design your own project like a
computer for your bike (if I understood you well you would like to do
something like that?) Of course you can also find an existing project on the
net for this, however, you will not be able to understand what's going on
until you know the foundation.


Tamas
PS: Don't put your programmer for another 3 years onto the shelf you cannot
reach :-)



>
>
> Many thanks,
> d
>
>
> >
>



--
http://www.mcuhobby.com

[Peter Restall]

On Thu, 11 Jun 2009 04:28:13 +0000, Darwin Pintado wrote:

> Hi,
>
> I purchased a pk2 programmer 3-years ago and I thought I will be able to
> learn it fast but I wrong. Until now, I haven't programmed it nor did any
> projects. I want to create projects but I can't start I don't know where to
> start if I want to make mechanical based projects.
> I know there were alot of reference by googling but most are complicated for
> a starter like me. Can someone point me to the right resources?
>
> Many thanks,
> d

Good morning,

You're probably going to have to be more specific to get any replies; just for
starters you would probably need to tell us things like:

        - Have you written any code for one of these devices ?
        - Have you written any code for any other architecture ?
        - Are you using any particular IDE ?
        - Are you just struggling to get the PK2 working with GNU/Linux ?
        - Are you struggling to get the PK2 programming your chip ?

And so on.  That should help somebody to direct you to an appropriate
resource based on what your existing experience is.

If you're finding it difficult to get into PICs (rather than getting your PIC
environment working with a flavour of GNU/Linux) then I'd probably suggest
you look at the (more general) piclist mailing list:

        http://www.piclist.com/techref/piclist/index.htm

You may have better luck posting there, but be a bit more specific / provide
more details.

If you're just trying to get your PK2 working with your GNU/Linux distro (at
least I'm presuming you're running a GNU/Linux-based system because you posted
here), a good starting point is Xiaofan's step-by-step blog post:

        http://mcuee.blogspot.com/search/label/PICKit

Scroll down to the bottom for a link to his step-by-step guide (PICkit 2 under
Linux Mini-Howto).

And speaking of Xiaofan - I posted a comment on your Howto page with some
differences I encountered when running through your instructions on my system
(presumably due to it being built more recently than your blog item).  But
they don't look to have appeared - have you censored them ? :)

Regards,

Pete Restall

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

[Xiaofan Chen]

On Thu, Jun 11, 2009 at 3:38 PM, Peter Restall<pete@...> wrote:
> Scroll down to the bottom for a link to his step-by-step guide (PICkit 2 under
> Linux Mini-Howto).
>
> And speaking of Xiaofan - I posted a comment on your Howto page with some
> differences I encountered when running through your instructions on my system
> (presumably due to it being built more recently than your blog item).  But
> they don't look to have appeared - have you censored them ? :)
>

Hmm, I think the comments are still there.
http://mcuee.blogspot.com/2008/04/pk2cmd-linux-port-under-ubuntu.html

Do you have other comments I missed? I just checked the
Blogger Dashboard again and I do not see any other
comments not reviewed yet. I do review the comments
to prevent spams but I do not not censor any comments
which is relevant even if I have no ideas of where the
comments came from.

Example:
http://mcuee.blogspot.com/2009/04/ubuntu-804-homedmrc-file-is-being.html

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

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

[Peter Restall]

On Thu, 11 Jun 2009 16:18:06 +0800, Xiaofan Chen wrote:

> Hmm, I think the comments are still there.
> http://mcuee.blogspot.com/2008/04/pk2cmd-linux-port-under-ubuntu.html

Oops...my mistake...I was thinking the post I commented on was:

http://mcuee.blogspot.com/2007/06/pickit-2-under-linux-mini-howto.html

I was wondering why there looked to be fewer comments than I remembered !
I remember reading through them both when I was running through my own setup
actually, but didn't realise there were quite so many similar ones dotted
around your site.  It's also a good job my comments were saved though; I
certainly couldn't remember what the differences were that I spotted :)


> Example:
> http://mcuee.blogspot.com/2009/04/ubuntu-804-homedmrc-file-is-being.html

Yes, those sort of one-liner obnoxious comments don't help anybody :(  By
going through the effort of posting he could have just as easily explained
why he thought there was an issue.

Regards,

Pete Restall

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

[Darwin Pintado-2]

Thank you Tamas.

The good news as of this writing is that I am already playing with my pk2
LPC Demo Board lessons and it was really fun!

My questions not only to you but to everyone is about using a programming
language. In your experience, which is better C or assemply when it comes to
developing embedded systems?

Where can I go for a start for that language?

d

On Thu, Jun 11, 2009 at 3:23 PM, Tamas Rudnai <tamas.rudnai@...>wrote:

> On Thu, Jun 11, 2009 at 5:28 AM, Darwin Pintado <dwhitekiss@...
> >wrote:
>
> > Hi,
> >
> > I purchased a pk2 programmer 3-years ago and I thought I will be able to
> > learn it fast but I wrong. Until now, I haven't programmed it nor did any
> > projects. I want to create projects but I can't start I don't know where
> to
> > start if I want to make mechanical based projects.
> > I know there were alot of reference by googling but most are complicated
> > for
> > a starter like me. Can someone point me to the right resources?
>
>
> You can start somewhere like reading some books and do some very basics
> like
> flashing LED, read a button, write something on LCD etc...
> Mikroelectronika's books are quite good for that and is free of charge to
> read online:
>
> http://www.mikroe.com/en/books/
>
> After that you will be on the right track to design your own project like a
> computer for your bike (if I understood you well you would like to do
> something like that?) Of course you can also find an existing project on
> the
> net for this, however, you will not be able to understand what's going on
> until you know the foundation.
>
>
> Tamas
> PS: Don't put your programmer for another 3 years onto the shelf you cannot
> reach :-)
>
>
>
> >
> >
> > Many thanks,
> > d
> >
> >
> > >
> >
>
>
>
> --
> http://www.mcuhobby.com
>

[Peter Keller]

On Thu, Jun 25, 2009 at 11:47:54AM +0800, Darwin Pintado wrote:
> My questions not only to you but to everyone is about using a programming
> language. In your experience, which is better C or assemply when it comes to
> developing embedded systems?

I personally like writing the things I need (for the PIC16/18 family)
in raw assembly. I'm probably in the minority though... I just find that
I pick the language most suited to the task at hand, and for my tasks,
it usually means flipping pins on and off, and that is a primitive in
assembly--so I use it.

> Where can I go for a start for that language?

I use linux, so it is gputils for me. I write other codes in other
languages a lot, so I just use vim, make, gputils, and pk2cmd to write
and burn all of my stuff. If you want a gui then pikdev might work well
on linux.

This book is very tasty:

http://www.amazon.com/Quintessential-Microcontroller-Computer-Communications-Networks/dp/185233942X/ref=sr_1_1?ie=UTF8&s=books&qid=1245903875&sr=1-1

I learned a *lot* about PICs with it. Also, you'll have to read the datasheet
for the processors, and yes, they are like 700 pages, but they can be broken
up into small manageable pieces.

Later,
-pete

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

[Tamas Rudnai]

On Thu, Jun 25, 2009 at 4:47 AM, Darwin Pintado <dwhitekiss@...>wrote:

> My questions not only to you but to everyone is about using a programming
> language. In your experience, which is better C or assemply when it comes
> to
> developing embedded systems?


If you speak generally "embedded" systems including microcontrollers and
embedded computers like PDAs and mobile phones than go for C definitely.
However, if you want to do serious development you should know to "read"
assembly code at least -- even better if you can write and optimize code by
your hand.

With C you can start up with virtually any ANSI C book and then learn the
difference between embedded systems and computers later on. You can even
find books teaching C for microcontroller development, however, all of these
I have seen are specialised on one particular compiler.

You might can start off with SDCC (http://sdcc.sourceforge.net) or C18 (
http://www.microchip.com/C18) or PICC (www.htsoft.com), or CCSC (
http://www.ccsinfo.com/content.php?page=compilers) -- I think these are the
most popular ones and all of them have free edition with some limitations
(SDCC is GNU so it has no limit!)

Tamas

[Kerry Miller]

I read with great interest your ideas for PIC development I too am being
interested in how to get started.  I run Linux-x86_64 Fedora 11 with the
GNOME desktop I looked into pk2cmd and it said KDE Desktop to me.  I
know that a lot of programs will run on either Desktop but this one
specifies KDE like it uses KDE libraries.  Clarification please?

On 06/24/2009 10:30 PM, Peter Keller wrote:

> On Thu, Jun 25, 2009 at 11:47:54AM +0800, Darwin Pintado wrote:
>    
>> My questions not only to you but to everyone is about using a programming
>> language. In your experience, which is better C or assemply when it comes to
>> developing embedded systems?
>>      
>
> I personally like writing the things I need (for the PIC16/18 family)
> in raw assembly. I'm probably in the minority though... I just find that
> I pick the language most suited to the task at hand, and for my tasks,
> it usually means flipping pins on and off, and that is a primitive in
> assembly--so I use it.
>
>    
>> Where can I go for a start for that language?
>>      
>
> I use linux, so it is gputils for me. I write other codes in other
> languages a lot, so I just use vim, make, gputils, and pk2cmd to write
> and burn all of my stuff. If you want a gui then pikdev might work well
> on linux.
>
> This book is very tasty:
>
> http://www.amazon.com/Quintessential-Microcontroller-Computer-Communications-Networks/dp/185233942X/ref=sr_1_1?ie=UTF8&s=books&qid=1245903875&sr=1-1
>
> I learned a *lot* about PICs with it. Also, you'll have to read the datasheet
> for the processors, and yes, they are like 700 pages, but they can be broken
> up into small manageable pieces.
>
> Later,
> -pete
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>
>    

--
Kerry N0WIQ
My web site URL is:
http://mywebpages.comcast.net/n0wiq

[Peter Restall]

On Thu, 25 Jun 2009 04:39:53 -0600, Kerry Miller wrote:

> I read with great interest your ideas for PIC development I too am being
> interested in how to get started.  I run Linux-x86_64 Fedora 11 with the
> GNOME desktop I looked into pk2cmd and it said KDE Desktop to me.  I
> know that a lot of programs will run on either Desktop but this one
> specifies KDE like it uses KDE libraries.  Clarification please?

Good Morning Kerry.

I use pk2cmd and I'm running Ubuntu (which is a Gnome-based desktop).  The
utility itself is a command-line based tool, so it should run under both.

And even if you do try installing a KDE-based application, your package
manager should install the KDE library dependencies (if you don't already have
them installed - chances are you have most of them from some other apps that
use them anyway).

The only thing you generally notice when running KDE apps on a Gnome system
is the user interface doesn't seem to match - ie. buttons different sizes to
other applications, that sort of thing; but this happens all the time anyway
due to all the different WMs the X Window System supports.  There are most
likely exceptions to this rule that will not run between environments due to
some dependency on some service or what not, but I'm struggling to think of
one - no doubt somebody else can.

Oh, and 64-bit systems don't work terribly reliably with the C30 compiler
from Microchip (and possibly their other compilers) - they've been written for
32-bit systems and have datatype size assumptions.  I found this out to my
cost :(  Unless you're using PIC24 or dsPICs you probably don't care about
this anyway - I use gpasm for the smaller devices and have had no problems
with that.

Regards,

Pete Restall

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

[Samuel Tardieu]

* Peter Keller <psilord@...> [2009-06-24 23:30:16 -0500]

| On Thu, Jun 25, 2009 at 11:47:54AM +0800, Darwin Pintado wrote:
| > My questions not only to you but to everyone is about using a programming
| > language. In your experience, which is better C or assemply when it comes to
| > developing embedded systems?
|
| I personally like writing the things I need (for the PIC16/18 family)
| in raw assembly. I'm probably in the minority though... I just find that
| I pick the language most suited to the task at hand, and for my tasks,
| it usually means flipping pins on and off, and that is a primitive in
| assembly--so I use it.

As far as I am concerned, I prefer to use Forth (through my rforth1 compiler
for PIC18f) as it lets me define more high-level words. I always reread
the assembly output to check for optimization opportunities, and most of
the time it looks like what I would have written in assembly.

Check for example:

  http://www.rfc1149.net/blog/2006/10/24/rforth1-optimizations/

 Sam


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

[Peter Keller]

On Thu, Jun 25, 2009 at 09:42:06AM +0100, Tamas Rudnai wrote:
> If you speak generally "embedded" systems including microcontrollers and
> embedded computers like PDAs and mobile phones than go for C definitely.
> However, if you want to do serious development you should know to "read"
> assembly code at least -- even better if you can write and optimize code by
> your hand.

This is pretty true. "embedded" systems are a spectrum from the lowliest
8 bit processor with 6 pins and sub-K (I mean like 32 bytes) memory all
the way up to things like iPhone which uses Objective-C and the Android,
which uses Java (from a developer point of view). Obviously, this means
a spectrum of tools as well some more approriate than others.

I generally wouldn't use much assembly if I were writing to a 32-bit PIC
with lots of ram, instead writing in some compiler's dialect of C, but for
something like the pic16f, I would definitely use assembly.  For the pic18f
series, I'd either use assembly or C (SDCC's dialect since it is free
for linux) depending on my mood and the complexity of what I'm writing.

It doesn't hurt to learn a good subset of the assembly first in the
case of PICs at any rate. I'd start with a PIC16F690 and learn to use
that initially. It is a surprisingly flexible chip with lots of features
you can learn to use independently of each other and the data sheet is
pretty readable.

A lot of embedded design (from the point of view of a hobbiest) seems
to be ensuring you initially pick the right tools, uP, and various parts
for the project at hand to minimize the wasting of your time while
building it. If you're designing for money or for mass production, then
the cost of the thing you make should be minimized, which can increase
development time. But if it is a one off or several for some friends, then
use whatever is easiest for you.

But generally, above all, document what you did for anything significant
into a theory of operations document. All the schematics, the math, the
why it works, the code, how to build it, bill of materials, everything.
You'll be happy you did later.

Later,
-pete

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

[Darwin Pintado-2]

Thanks for all the response. For the past days, I've been doing a research
on the the device I have -> PIC16F690 to have a big picture understanding
and the device I have as of the moment. I am still in the process of
understanding each modules and I was wondering in the I/O ports, lets say
PORTC, I am curiuos why there are unimplemented bits and unknown bits.

d

On Thu, Jun 25, 2009 at 3:30 PM, Peter Keller <psilord@...> wrote:

> On Thu, Jun 25, 2009 at 09:42:06AM +0100, Tamas Rudnai wrote:
> > If you speak generally "embedded" systems including microcontrollers and
> > embedded computers like PDAs and mobile phones than go for C definitely.
> > However, if you want to do serious development you should know to "read"
> > assembly code at least -- even better if you can write and optimize code
> by
> > your hand.
>
> This is pretty true. "embedded" systems are a spectrum from the lowliest
> 8 bit processor with 6 pins and sub-K (I mean like 32 bytes) memory all
> the way up to things like iPhone which uses Objective-C and the Android,
> which uses Java (from a developer point of view). Obviously, this means
> a spectrum of tools as well some more approriate than others.
>
> I generally wouldn't use much assembly if I were writing to a 32-bit PIC
> with lots of ram, instead writing in some compiler's dialect of C, but for
> something like the pic16f, I would definitely use assembly.  For the pic18f
> series, I'd either use assembly or C (SDCC's dialect since it is free
> for linux) depending on my mood and the complexity of what I'm writing.
>
> It doesn't hurt to learn a good subset of the assembly first in the
> case of PICs at any rate. I'd start with a PIC16F690 and learn to use
> that initially. It is a surprisingly flexible chip with lots of features
> you can learn to use independently of each other and the data sheet is
> pretty readable.
>
> A lot of embedded design (from the point of view of a hobbiest) seems
> to be ensuring you initially pick the right tools, uP, and various parts
> for the project at hand to minimize the wasting of your time while
> building it. If you're designing for money or for mass production, then
> the cost of the thing you make should be minimized, which can increase
> development time. But if it is a one off or several for some friends, then
> use whatever is easiest for you.
>
> But generally, above all, document what you did for anything significant
> into a theory of operations document. All the schematics, the math, the
> why it works, the code, how to build it, bill of materials, everything.
> You'll be happy you did later.
>
> Later,
> -pete
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: gnupic-unsubscribe@...
> For additional commands, e-mail: gnupic-help@...
>
>

[Peter Keller]

Hello,

On Tue, Jun 30, 2009 at 03:56:36AM +0000, Darwin Pintado wrote:
> Thanks for all the response. For the past days, I've been doing a research
> on the the device I have -> PIC16F690 to have a big picture understanding
> and the device I have as of the moment. I am still in the process of
> understanding each modules and I was wondering in the I/O ports, lets say
> PORTC, I am curiuos why there are unimplemented bits and unknown bits.

If I understand your concern correctly, you can see an example of this
on page 76 in the 2008 pic16f690 datasheet[0]. 'x' means unknown and
this is in regards to when the chip is powered on. When the chip is
powered on, those bits, and consequently the ports themselves, are
in an unknown state.  If you notice, PORTC defaults to 'read' status
(via the TRISC port), which means it isn't also emitting random logic
high/low onto the lines connected to the port.  This is important because
it prevents the chip from putting the associated logic connected to it
into an unknown state upon power up.

The '-' you see in the data sheet, suppose page 80, means that writes will
be ignored on those bits, and reads will return 0. Unimplemented means
that those bits simply aren't used, for anything. Even though that is the
case, I recommend only writing 0 to them when loading those registers since
there could be silicon bugs or whatnot you might tickle if you write 1 to
unimplemented bits on a write.

The 'u', also on page 80, means unchanged. If you inspect the PORTC
line on page 80, you'll see that on POR (Power On Reset), or BOR (Brown
Out Reset), the values in PORTC will be unknown, but on all other
resets--suppose the watch dog timer resets the device, the bits will
be unchanged in PORTC. All of the registers have a behavior like this,
and for the specific features you are using in a project, you must ensure
that each register (associated with those feature) behaves how you expect
and you understand why.

The PIC16F690 has a fair number of modules that often share pins.
This is why you have to turn of the analog channels ANSEL and ANSELH
for the corresponding PORTC pins in order to get digital I/O on the
pin when initializing PORTC (as described on page 76, example 4-4). In
fact, on one pin, you cannot do analog i/o and digital i/o _at the
same time_. You can switch between them, though.  Page 80 shows the
initialization state for the ANSEL/ANSELH bits and the portion of the
data sheet that describes those two registers tell you that 1 means
analog input and 0 means digital I/O.

For your intial project, get a single LED blinking using bit 0 of PORTA
(and a hardcoded delay loop to waste time, instead of an interrupt driven
solution--no need to complicate what you need to learn). The PORTA
portion of the data sheet shows example initialization of the port.
Once you get that going, then hook up all of the pins of PORTA and
make a "knight rider" display of an led going back and forth across the
registers. When you get that done, make a display using all the pins on
ports A, B, C (in a straight line on your breadboard), and have an LED
go from one end to the other end. If you get that done, you'll have a
good understanding for how to initialize and use the ports in a digital
I/O output context.  For digital input, if it is from another logic chip,
it is generally pretty easy, but if it is from a switch, you are required
to worry about to properly debounce a switch. There are decent papers
on this on the internet.

Some modules like the SSP module are pretty complex--don't expect to just
"pick those up" with a single, or even multiple, readings. The I2C and SPI
communication models are complex (I2C is more complex than SPI). I'd leave
those for last in learning how to use this uP after you're grounded in
the other modules. I personally have used every feature of the PIC16F690
except I2C and the PWM module for various hobby projects. (I know how
to do PWM, but I just did it in assembly instead of using the module
since I needed many more pins with PWM on it than the module allowed me.)

The electrical things you initially need to worry about are these:

1. Crosstalk
        a. magnetic
        b. capacitive
2. clock line noise
3. Don't exceed current ratings for pins or other hardware.

1 is what happens if you have physically parallel data lines with a lot of
current in them, suppose 20ma each. When you write patterns like 11101111 and
00010000 over and over again, you'll probably get glitches on the lines from
the magnetic fields interacting with each other. To reduce this, put less
current through the data line, like 2ma or so. With enough research, you
can find decent papers on the net about cross talk. There isa similar analogue
for when the coupling is capacitive, and some research on the net will explain
it better.

2 happens because clock lines often have high current in order to have
enough oomph to make it across the board and to feed multiple chips. These
should be placed far away from other lines, or pass over them at right angles
to the data lines.

3 means have a good understanding of the current you actually need
for something and ensure you use resistors of the right wattage at the
appropriate times.

Since I don't have an oscilloscope, I learned the hard and long way about
cross talk, how to recognize it, and avoid it. I'm fastidious about it now
in my designs because it is so hard to debug electrical signals if they
glitch. With some care, I haven't had any more problems.

Also, one more thing. Understand all of your configuration bits, and set them
ALL to known values. Don't rely on default values for them. Simply understand
them and set them correctly. While messing about with the PIC initially, use
a 4MHz clock. This frequency is relatively safe on breadboards.

Thank you.

-pete

[0] http://ww1.microchip.com/downloads/en/DeviceDoc/41262E.pdf

P.S. Since I'm just a hobbiest, I am probably wrong on things, so make
sure you understand things as you do them and don't assume anything
about the chip, the surrounding hardware, or some idiot like me on a
list somewhere. :)




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

[Peter Stuge-4]

Peter Keller wrote:
> For your intial project, get a single LED blinking using bit 0 of
> PORTA (and a hardcoded delay loop to waste time, instead of an
> interrupt driven solution--no need to complicate what you need to
> learn).

This is good advice.

Whenever I target a new PIC device I create a hello_16fxxx directory
with a minimal hello.asm which does nothing but blink all IO pins.

I can then use that as a template for new programs, and sometimes it
is great to load that old hex file into the PIC to check if all IOs
still work.

(I have done some really cruel things to the PIC IOs but have so far
not been able to destroy a single one. :)


//Peter

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