12F675 | 16F628 | 16F84 | 16f877 | 16F877A | 16F88 | 18F458 | ADC | AVR | Bootloader | CAN | CCS | CRC | EAGLE | EEPROM | ICD | ICSP | IDE | JDM | LED | Macros | Microchip | MPLAB | PCB-CAD | PIC10F | Pic12f675 | PIC16F84 | PIC16F84A | PIC16F877 | PIC18 | PIC18F452 | PicBasic | PICC | PICSTART | PWM | RS-485 | RS232 | SMT | SPI | UART | USART | USB | Wireless | Wisp628 | Xilinx

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



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

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

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

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...@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: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of
jvoytovich
Sent: Monday, September 08, 2008 1:16 PM
To: p...@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.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?
------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

Thanks! Great info.

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

-----Original Message-----
From: p...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of
John J. McDonough, WB8RCR
Sent: Tuesday, September 09, 2008 6:33 AM
To: p...@yahoogroups.com
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?



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )

--- In p...@yahoogroups.com, "ray xu" wrote:
>
> Thanks! Great info.

Assembly code may very well operate faster than compiled C code
because you can be quite clever in the way you place code in pages and
variables in banks. But YOU have to create the cleverness.

In the case of cc5x, the demo version of the compiler doesn't remove
redundant bank and page selection although the commercial version
does. The code is larger and necessarily slower.

But the thing about uC's is that you are, more often than not, dealing
with hardware registers and small objects in memory. The C code
doesn't look a lot different than the assembly code. Perhaps each
line of C is generating one or two assembly statements - load a
constant value, stuff it in a register; that kind of thing. You don't
tend to do a lot of complex mathematical operations with a 16Fxxx.
You're just twiddling bits and C just makes the code a little more
obvious. You need exactly the same knowledge whether you twiddle in
assembly language or C.

C provides structure and flow control that is more apparent than
assembly language but clean assembly code can be just as good.
Particularly when application specific macros are created. In fact,
it is common to create flow control macros that mirror C quite nicely.
That's why macro assemblers exist.

I have been using the demo version of cc5x for quite a long time and
it works well enough.

One way to learn assembly language is to look at the output of the
compiler as it translates C to assembly before it calls the final
assembler stage. This is possible with most compilers.

Finally, C isn't necessarily available for every chip within a
manufacturer's offerings. For the very small AVRs, the gcc compiler
and avrlib won't work. You need to check for compiler support for the
chip you actually intend to use.

Some manufacturers have a device selection filter on the web site that
will allow you to select the exact features you need. However, having
additional features doesn't always imply additional cost. It seems
silly to have hundreds of variants and the low volume of some variants
may lead to higher costs. There is no reason in the world that the
16F84 costs what it does except that it is obsolete and Microchip
doesn't want it used for new designs. Unfortunately, many hobby
projects use the '84 because it was one of the first flash devices.

PIC vs AVR discussions are pointless. Within each product line there
are similar devices with similar features at varying costs. One
advantage to the AVRs is that they don't have the page/bank issues of
the PICs. They also have specific interrupt vectors for each hardware
device which simplifies writing interrupt drivers. You don't have to
test for all possible sources within a single interrupt handler. All
very nice features but clearly not necessary.

Richard

------------------------------------

to unsubscribe, go to http://www.yahoogroups.com and follow the instructions



(You need to be a member of piclist -- send a blank email to piclist-subscribe@yahoogroups.com )