PIC vs. other MCU

Started by ray xu September 8, 2008
Hi, I've been lying low in this group since I joined (1 or 2 months ago).
I'm having trouble deciding between using a PIC, AVR, or other low-cost MCU
in my project that requires timing precision. What I need is a MCU with at
least 1 16-bit timer/counter, low cost (including programmer and compiler),
and an easy programming syntax (such as C/C++). The AVRs from Atmel are
very popular and low-cost of the programmer, but I'm not sure if they have
as many counters/timers in the chip. For the PIC, I do have MPLAB installed
I my computer, but I'm not sure if the compiler supports C/C++ syntax. If
not, is there anywhere I can get it? I'm somewhat familiar with the PIC; I
have read the datasheets of some of them, I have used the OOPic before, but
I have no direct experience. If I were to use the PIC, I'm planning to use
the MPLAB ICD 2 programmer.

What I'm trying to do is to use the PIC as a programmable delay chip. Any
suggestions? Thanks.

___________________
Ray Xu
r...@tx.rr.com
DPRG member
OOPic group member
Seattle Robotics
group member
My Blog
> Hi, Ive been lying low in this group since I joined (1 or 2 months
> ago). Im having trouble deciding between using a PIC, AVR, or other
> low-cost MCU in my project that requires timing precision.

What you want can be done with almost any low-end uC, PIC, AVR, 8051,
etc. Choose whichever chip you can get help for, preferrably local to you.

--

Wouter van Ooijen

-- -------
Van Ooijen Technische Informatica: www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: www.voti.nl/hvu
One area that I look at when evaluating micros is the software tools
available. Microchip seems to excel in this area - devoting a large
area on their web site, and offering most of the tools for free
download. You can't program if you can't find the tools!! Some of the
other vendors rely on open source code, and while it may be fairly
reliable and free, you get less support from the vendor on software
issues.

>>...but I'm not sure if the compiler supports C/C++ syntax.<<

Hmm...the topic of using C++ has come up quite a bit with me in the
past. Seems that most people hear a lot about C++ and assume that it's
just the next logical step up from C. The one problem here is code
size - C++ has larger libraries to support functions such as object
memory allocation (for a more complete discussion, see
http://www.linuxdevices.com/eljonline/issue07/4870s1.html).

C++ would have a less deterministic runtime due to its inherent
features, which would NOT be very funny when running a prototype and
getting the "now it works, now it doesn't" result.

C has been referred to as a high-level assembly language. It's a good
compromise between assembly for speed and size, and the abstraction of
high-level language. If you have the CPU speed and memory size, C++
would probably work,

So...no C++ for the PICs!!

>> What I'm trying to do is to use the PIC as a programmable delay
chip. Any suggestions? <<

How are you "programming" it? Will this be hard-coded into the chip
when it is burned, or will the time be fed into it via switches or
some external communication?

So, if C/C++ is not the best choice, then does that mean I have to use
Assembly language (I have now knowledge about it)? The programmable delay
part will be set through an 8-bit bus, much like a DIP switch. The
important thing is that the language/PIC needs to have very low latency
(that's why I'm using a dsPIC30), high speed, small program, and fast
execution (I heard somewhere ASM executes faster than high-level languages,
is that true?). I have most of the tools right now (buying the mini-ICD2
from sparkfun later), but I'm missing the knowledge of Assembly language,
and past experience with PICs. I cannot find any very helpful information
on programming in Assembly for the PIC on the web; are there some good sites
out there? Thanks.

___________________
Ray Xu
r...@tx.rr.com
DPRG member
OOPic group member
Seattle Robotics
group member
My Blog

-----Original Message-----
From: p... [mailto:p...] On Behalf Of
jvoytovich
Sent: Monday, September 08, 2008 1:16 PM
To: p...
Subject: [piclist] Re: Pic vs. other MCU

One area that I look at when evaluating micros is the software tools
available. Microchip seems to excel in this area - devoting a large
area on their web site, and offering most of the tools for free
download. You can't program if you can't find the tools!! Some of the
other vendors rely on open source code, and while it may be fairly
reliable and free, you get less support from the vendor on software
issues.

>>...but I'm not sure if the compiler supports C/C++ syntax.<<

Hmm...the topic of using C++ has come up quite a bit with me in the
past. Seems that most people hear a lot about C++ and assume that it's
just the next logical step up from C. The one problem here is code
size - C++ has larger libraries to support functions such as object
memory allocation (for a more complete discussion, see
http://www.linuxdev

ices.com/eljonline/issue07/4870s1.html).

C++ would have a less deterministic runtime due to its inherent
features, which would NOT be very funny when running a prototype and
getting the "now it works, now it doesn't" result.

C has been referred to as a high-level assembly language. It's a good
compromise between assembly for speed and size, and the abstraction of
high-level language. If you have the CPU speed and memory size, C++
would probably work,

So...no C++ for the PICs!!

>> What I'm trying to do is to use the PIC as a programmable delay
chip. Any suggestions? <<

How are you "programming" it? Will this be hard-coded into the chip
when it is burned, or will the time be fed into it via switches or
some external communication?
Ray Xu said that C++ was not a good choice, he further went on to say
that C is a good choice. Read his response again.

On Tue, Sep 9, 2008 at 7:46 AM, ray xu wrote:
> So, if C/C++ is not the best choice, then does that mean I have to use
> Assembly language (I have now knowledge about it)?

That's my problem. I can't decide which language to use. Most likely, I
won't be using C/C++ (my favorite), because of the compiler costs.

___________________
Ray Xu
r...@tx.rr.com
DPRG member
OOPic group member
Seattle Robotics
group member
My Blog

-----Original Message-----
From: p... [mailto:p...] On Behalf Of
Phil Seakins
Sent: Monday, September 08, 2008 9:04 PM
To: p...
Subject: Re: [piclist] Re: Pic vs. other MCU

Ray Xu said that C++ was not a good choice, he further went on to say
that C is a good choice. Read his response again.

On Tue, Sep 9, 2008 at 7:46 AM, ray xu com> wrote:
> So, if C/C++ is not the best choice, then does that mean I have to use
> Assembly language (I have now knowledge about it)?
Sorry, I quoted the wrong person. I was actually quoting "jvoytovich".
Ray, I was trying to point out that you are lumping "C" and "C++"
together in one category as "C/C++" when in fact they are somewhat
different. Regarding costs, there are several "C" compilers available
for free. While some have limitations, your project seems somewhat
trivial and it's likely it could be handled by one of the free ones.

On Tue, Sep 9, 2008 at 1:17 PM, ray xu wrote:
> That's my problem. I can't decide which language to use. Most likely, I
> won't be using C/C++ (my favorite), because of the compiler costs.
>
> ___________________
> Ray Xu
> r...@tx.rr.com
> DPRG member
> OOPic group member
> Seattle Robotics group member
> My Blog
>
> -----Original Message-----
> From: p... [mailto:p...] On Behalf Of
> Phil Seakins
> Sent: Monday, September 08, 2008 9:04 PM
> To: p...
> Subject: Re: [piclist] Re: Pic vs. other MCU
>
> Ray Xu said that C++ was not a good choice, he further went on to say
> that C is a good choice. Read his response again.
>
> On Tue, Sep 9, 2008 at 7:46 AM, ray xu wrote:
>> So, if C/C++ is not the best choice, then does that mean I have to use
>> Assembly language (I have now knowledge about it)?

> So, if C/C++ is not the best choice, then does that mean I have to use
> Assembly language (I have now knowledge about it)?

I agree with the others: Ray shouldn't lump C and C++ together like that. Whilst
C++ is derived from C, they are technologically two very different languages. The
compiler complexity and run-time overheads are MUCH greater with C++.

In my opinion, C++ is entirely unsuitable for programming small microcontrollers
like PICs. C, on the other hand, is absolutely ideal.

In fact, I think C is by far the best language for PIC programming, and there is a
good choice of free or low cost C compilers which will integrate nicely into MPLAB.
I recommend Ray tries HiTech PICC and CCS C as a minimum: they use very
different paradigms (HicTech treats ports and registers like variables; CCS C hides
them behind library function calls) and he will be able to decide which he prefers.

The bank-switching in most PICs is, frankly, a huge kludge which must be worked
around with care and can be a source of difficult bugs. Using a C compiler means
you can, by and large, forget about it - the compiler usually looks after it for you.

I only use assembler if I really have to: my productivity is much higher when using C.

Ray: get programming your PICs in C - you won't look back.

Staiger
If you are using the dsPIC, then the path of least resistance is C. The C30
Student Edition is free, and as far as i can tell, the advantages of the
paid version are pretty small.

There is no such thing as "very low latency", it depends on your
application. You might talk a little more about what you are doing but from
your descriptions it sounds as if even the slowest of the PICs will be
adequate, but maybe not.

The problem with "Assembly language (I have now knowledge about it)" is that
for ANY embedded application you need to get pretty intimate with the
hardware, and assembler makes that easier than C. Indeed, knowing C up
front might be something of a disadvantage, because much of what an
experienced C programmer would do as second nature is very bad in an
embedded application. If your application is simple enough, the 8 bit parts
are very simple, and the assembly language is simple enough that anyone can
learn it easily. Personally (and many will disagree with me), I think it is
a mistake to try to mess with C on the 8 bit PICs unless you are very
experienced.

That being said, the 16 bit PICs are complex enough, and the C
implementation good enough, that I would suggest C as the way to get started
on the dsPIC. You can shoot yourself in the foot, but it isn't the
minefield it is on the 8 bit parts.

Perhaps as a level set, it is quite simple to get a very good sample of an
audio waveform on the dsPIC using C and without resorting to the automatic
sampling provided by the (very fancy) dsPIC A/D. I have an application
using the PIC24 and Microchip's QVGA display where I can update the screen
dozens of times a second. The 16 bit PICs are quite capable, even with C,
and when the "trial period" expires on the C compiler you only loose some
optimizations which don't seem to be a big deal for a lot of applications
anyway.

By the way, the PIC24's have a number of advantages over the dsPICs. But if
you need very good A/D or the DSP engine then obviously the dsPIC is the way
to go. Also, the dsPIC30's are 5 volts which could be an advantage in your
design. But some of the peripherals on the PIC24s are quite a bit more
capable than the dsPICs, and the ability to reassign I/O pins can mean you
end up with a smaller pin count part (cheaper). Generally you can manage
power consumption a little better with the PIC24s. The instruction set,
aside from the DSP instructions, is identical.

--McD

----- Original Message -----
From: ray xu
To: p...
Sent: Monday, September 08, 2008 5:46 PM
Subject: RE: [piclist] Re: Pic vs. other MCU
So, if C/C++ is not the best choice, then does that mean I have to use
Assembly language (I have now knowledge about it)? The programmable delay
part will be set through an 8-bit bus, much like a DIP switch. The
important thing is that the language/PIC needs to have very low latency
(that's why I'm using a dsPIC30), high speed, small program, and fast
execution (I heard somewhere ASM executes faster than high-level languages,
is that true?). I have most of the tools right now (buying the mini-ICD2
from sparkfun later), but I'm missing the knowledge of Assembly language,
and past experience with PICs. I cannot find any very helpful information
on programming in Assembly for the PIC on the web; are there some good sites
out there? Thanks.

___________________
Ray Xu
r...@tx.rr.com
DPRG member
OOPic group member
Seattle Robotics group member
My Blog
-----Original Message-----
From: p... [mailto:p...] On Behalf Of
jvoytovich
Sent: Monday, September 08, 2008 1:16 PM
To: p...
Subject: [piclist] Re: Pic vs. other MCU

One area that I look at when evaluating micros is the software tools
available. Microchip seems to excel in this area - devoting a large
area on their web site, and offering most of the tools for free
download. You can't program if you can't find the tools!! Some of the
other vendors rely on open source code, and while it may be fairly
reliable and free, you get less support from the vendor on software
issues.

>>...but I'm not sure if the compiler supports C/C++ syntax.<<

Hmm...the topic of using C++ has come up quite a bit with me in the
past. Seems that most people hear a lot about C++ and assume that it's
just the next logical step up from C. The one problem here is code
size - C++ has larger libraries to support functions such as object
memory allocation (for a more complete discussion, see
http://www.linuxdevices.com/eljonline/issue07/4870s1.html).

C++ would have a less deterministic runtime due to its inherent
features, which would NOT be very funny when running a prototype and
getting the "now it works, now it doesn't" result.

C has been referred to as a high-level assembly language. It's a good
compromise between assembly for speed and size, and the abstraction of
high-level language. If you have the CPU speed and memory size, C++
would probably work,

So...no C++ for the PICs!!

>> What I'm trying to do is to use the PIC as a programmable delay
chip. Any suggestions? <<

How are you "programming" it? Will this be hard-coded into the chip
when it is burned, or will the time be fed into it via switches or
some external communication?
Thanks! Great info.

___________________
Ray Xu
r...@tx.rr.com
DPRG member
OOPic group member
Seattle Robotics
group member
My Blog

-----Original Message-----
From: p... [mailto:p...] On Behalf Of
John J. McDonough, WB8RCR
Sent: Tuesday, September 09, 2008 6:33 AM
To: p...
Subject: Re: [piclist] Re: Pic vs. other MCU

If you are using the dsPIC, then the path of least resistance is C. The C30
Student Edition is free, and as far as i can tell, the advantages of the
paid version are pretty small.

There is no such thing as "very low latency", it depends on your
application. You might talk a little more about what you are doing but from
your descriptions it sounds as if even the slowest of the PICs will be
adequate, but maybe not.

The problem with "Assembly language (I have now knowledge about it)" is that

for ANY embedded application you need to get pretty intimate with the
hardware, and assembler makes that easier than C. Indeed, knowing C up
front might be something of a disadvantage, because much of what an
experienced C programmer would do as second nature is very bad in an
embedded application. If your application is simple enough, the 8 bit parts
are very simple, and the assembly language is simple enough that anyone can
learn it easily. Personally (and many will disagree with me), I think it is
a mistake to try to mess with C on the 8 bit PICs unless you are very
experienced.

That being said, the 16 bit PICs are complex enough, and the C
implementation good enough, that I would suggest C as the way to get started

on the dsPIC. You can shoot yourself in the foot, but it isn't the
minefield it is on the 8 bit parts.

Perhaps as a level set, it is quite simple to get a very good sample of an
audio waveform on the dsPIC using C and without resorting to the automatic
sampling provided by the (very fancy) dsPIC A/D. I have an application
using the PIC24 and Microchip's QVGA display where I can update the screen
dozens of times a second. The 16 bit PICs are quite capable, even with C,
and when the "trial period" expires on the C compiler you only loose some
optimizations which don't seem to be a big deal for a lot of applications
anyway.

By the way, the PIC24's have a number of advantages over the dsPICs. But if
you need very good A/D or the DSP engine then obviously the dsPIC is the way

to go. Also, the dsPIC30's are 5 volts which could be an advantage in your
design. But some of the peripherals on the PIC24s are quite a bit more
capable than the dsPICs, and the ability to reassign I/O pins can mean you
end up with a smaller pin count part (cheaper). Generally you can manage
power consumption a little better with the PIC24s. The instruction set,
aside from the DSP instructions, is identical.

--McD

----- Original Message -----
From: ray xu
To: piclist@yahoogroups .com
Sent: Monday, September 08, 2008 5:46 PM
Subject: RE: [piclist] Re: Pic vs. other MCU

So, if C/C++ is not the best choice, then does that mean I have to use
Assembly language (I have now knowledge about it)? The programmable delay
part will be set through an 8-bit bus, much like a DIP switch. The
important thing is that the language/PIC needs to have very low latency
(that's why I'm using a dsPIC30), high speed, small program, and fast
execution (I heard somewhere ASM executes faster than high-level languages,
is that true?). I have most of the tools right now (buying the mini-ICD2
from sparkfun later), but I'm missing the knowledge of Assembly language,
and past experience with PICs. I cannot find any very helpful information
on programming in Assembly for the PIC on the web; are there some good sites

out there? Thanks.

___________________
Ray Xu
r...@tx.rr. com
DPRG member
OOPic group member
Seattle Robotics group member
My Blog
-----Original Message-----
From: piclist@yahoogroups .com
[mailto:piclist@yahoogroups .com] On
Behalf Of
jvoytovich
Sent: Monday, September 08, 2008 1:16 PM
To: piclist@yahoogroups .com
Subject: [piclist] Re: Pic vs. other MCU

One area that I look at when evaluating micros is the software tools
available. Microchip seems to excel in this area - devoting a large
area on their web site, and offering most of the tools for free
download. You can't program if you can't find the tools!! Some of the
other vendors rely on open source code, and while it may be fairly
reliable and free, you get less support from the vendor on software
issues.

>>...but I'm not sure if the compiler supports C/C++ syntax.<<

Hmm...the topic of using C++ has come up quite a bit with me in the
past. Seems that most people hear a lot about C++ and assume that it's
just the next logical step up from C. The one problem here is code
size - C++ has larger libraries to support functions such as object
memory allocation (for a more complete discussion, see
http://www.linuxdev

ices.com/eljonline/issue07/4870s1.html).

C++ would have a less deterministic runtime due to its inherent
features, which would NOT be very funny when running a prototype and
getting the "now it works, now it doesn't" result.

C has been referred to as a high-level assembly language. It's a good
compromise between assembly for speed and size, and the abstraction of
high-level language. If you have the CPU speed and memory size, C++
would probably work,

So...no C++ for the PICs!!

>> What I'm trying to do is to use the PIC as a programmable delay
chip. Any suggestions? <<

How are you "programming" it? Will this be hard-coded into the chip
when it is burned, or will the time be fed into it via switches or
some external communication?