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 )

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 )

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

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

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

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 )

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...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of
Phil Seakins
Sent: Monday, September 08, 2008 9:04 PM
To: p...@yahoogroups.com
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)?



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

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...@yahoogroups.com [mailto:p...@yahoogroups.com] On Behalf Of
> Phil Seakins
> Sent: Monday, September 08, 2008 9:04 PM
> To: p...@yahoogroups.com
> 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)?

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

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 )

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

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 )

Then learn assembler. It's easy, more efficient and a better fit for
most PICs than C anyway.

Al

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...@yahoogroups.com [mailto:p...@yahoogroups.com] On
> Behalf Of Phil Seakins
> Sent: Monday, September 08, 2008 9:04 PM
> To: p...@yahoogroups.com
> 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)?
>------------------------------------------------------------------------
>
>Internal Virus Database is out-of-date.
>Checked by AVG.
>Version: 7.5.524 / Virus Database: 270.6.15 - Release Date: 2/09/2008 12:00 AM
>



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

On Mon, 8 Sep 2008 16:46:38 -0500, you 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)? 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.
Info on getting started on PIC assembler is available, especially for
the 12 and 16 series. Moving up to the dsPIC isn't an impossible leap.

Take a look at back issues of Nuts and Volts magazine. They've had a
bunch of articles on assembler programming the PIC family (mostly the
12 and 16 series).
href="http://www.nutsvolts.com"

Everyday Practical Electronics has had some good starter articles
too.
href="http://www.epemag3.com/"

There are also several books too.

At the risk of starting a religious war...
Getting max speed out of compiled code is not trivial. If you aren't
reasonably competent in assembler, and REALLY understand how that
particular compiler works, your chances are slim. In many cases code
requiring max speed (interrupts, etc.) is implemented as "inline"
assembler code embedded into higher level languages.

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

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 )