Searching \ for '[PIC]Using C instead of Assembly language' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: techref.massmind.org/techref/microchip/languages.htm?key=c
Search entire site for: 'Using C instead of Assembly language'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]Using C instead of Assembly language'
2008\08\31@201624 by Jason Hsu

picon face
Thanks for the suggestions on how to program microcontrollers in C
instead of Assembly language.

In the process of trying to get started, I can see why Assembly
language is MUCH more popular among hobbyists than C.  There is
EXCELLENT support for Assembly language.  MPLAB offers FREE and full
functionality for Assembly language programming of microcontrollers.

Most of the available tools for C for microcontrollers are very costly
(hundreds or thousands of dollars).  The free tool PICC-LITE works for
very few microcontrollers.  The open source tools are tricky to set up
and are in alpha state.  I have been able to work with PICC-LITE.
Until I can get GPUTILS to work on my Linux machine (gtkextra
installation problems), I won't be able to use SDCC on it either.

I've summarized my experience at http://www.jasonhsu.com/microcontroller.html .

I'm going to try GPUTILS/SDCC in Windows next.  But before I do, what
are the prerequisites for these programs (in addition to gcc)?

Would I have an easier time with Ktechlab?  Or PiKdev/lab?  Does
dependency hell come into play here as well?  I haven't tried these
yet.

What are my other options?

Given that I would like to turn my experience in microcontrollers into
a career and that C is much more widely used in industry than Assembly
language, I need more experience using C for microcontrollers.  Having
as much experience with C as I already have with Assembly language
would help me in both my job search and in my productivity on the job.

--
Jason Hsu
http://www.jasonhsu.com/swrwatt.html
www.jasonhsu.com/swrwatt-source_code.txt
NOTE: I am seeking employment as an embedded electronics engineer.

2008\08\31@204000 by cdb

flavicon
face


:: I'm going to try GPUTILS/SDCC in Windows next

Instead of downloading new tools, you could try downloading and installing andLinux on your Windows system - it runs a basic version of Linux as a service in Windows.

I am using it for the Linux version of XCSB - which works well. So if you have a Linux tool you've got used to, then this might work also for you.

http://www.andlinux.org

Colin
--
cdb, spam_OUTcolinTakeThisOuTspambtech-online.co.uk on 1/09/2008

Web presence: http://www.btech-online.co.uk  

Hosted by:  http://www.1and1.co.uk/?k_id=7988359







2008\08\31@205833 by Xiaofan Chen

face picon face
On Mon, Sep 1, 2008 at 8:16 AM, Jason Hsu <.....jhsu802701KILLspamspam@spam@gmail.com> wrote:
> Until I can get GPUTILS to work on my Linux machine (gtkextra
> installation problems), I won't be able to use SDCC on it either.

Who told you sdcc needs gtkextra? Only gpsim needs gtkextra.

What is the Linux distribution you are using? Most of the new
main-stream distributions will have gputils/sdcc/gpsim/piklab
available. Sometimes they are a bit outdated compared to
the latest svn version but they should get you started. If you
want to build from source,  gputils/sdcc do not require too
much dependency to be built. After all, both are console version
without GUI. For gtkextra, you can download the source and build
from the source. Then you can build gpsim. piklab requires
KDE development packages.

Xiaofan


'[PIC]Using C instead of Assembly language'
2008\09\01@030834 by David Meiklejohn
face
flavicon
face
Jason Hsu wrote:

> Most of the available tools for C for microcontrollers are very costly
> (hundreds or thousands of dollars).  The free tool PICC-LITE works for
> very few microcontrollers.

HI-TECH C PRO, for all 10/12/16F PICs (12- and 14-bit) is now available,
for free, in "lite" mode.  This has no restrictions, but like Microchip's
C18 student mode for the 18Fs, optimisation is turned off.  I've found in
practice that it generates code about twice as large as PICC-Lite - but on
the other hand, there are no memory restrictions, so code can often afford
to be larger.  And you get to use all data memory, without worrying about
bank directives.

Glowing endorsement?  No, because it does generate bloated code.  But hey,
it's free (as in beer - no license restrictions), supports every 16F PIC,
and integrates well with MPLAB (or use HI-TIDE), supports ICD, etc.

David Meiklejohn
http://www.gooligum.com.au

2008\09\01@044802 by Tomás Ó hÉilidhe

picon face
Jason Hsu wrote:
> In the process of trying to get started, I can see why Assembly
> language is MUCH more popular among hobbyists than C.  There is
> EXCELLENT support for Assembly language.  MPLAB offers FREE and full
> functionality for Assembly language programming of microcontrollers.
>  


Just so you know, I have minimal experience with assembler. I'd need a
table of all the instructions and it'd take me 20 minutes to write
something the rest of you would write in just a minute or two.


> Most of the available tools for C for microcontrollers are very costly
> (hundreds or thousands of dollars).


Might I suggest that you have your honesty dial turned a little too far
to the right?

Tomás

2008\09\01@052452 by Forrest W Christian

flavicon
face
A while ago I played with several of the C compilers, including the free
ones.

The free ones were disappointing - but you might find they work well.

I have C18 from Microchip.  This works well, but only works on the C18
processors.   I have the full edition, but understand the student
edition is basically the same, but simply with a few optimizations
turned off after an initial period.

I also have the full CCS PIC-C PCWH package.   This works quite well.  
If you only want to use it from MPLAB, then you don't need the full
version... you can buy the appropriate command line compiler for
somewhat less...  like $150.   You can also get a linux version of
this.   This is actually my preferred compiler for the PIC16 parts, and
I sometimes use it for the PIC18's as well.

If you're into cheap, hobbyist C, you might want to try the MikroC.   I
use it when I'm just hacking out some proof of concept thing, since the
libs they include are much easier to use.  However, for larger projects,
it doesn't seem to do as good of a job as the CCS... for instance, it
doesn't handle large quantities of string constants well - plus
occasionally I've had it do weird things.     The free version of MikroC
is limited to 2k of code size - but will compile for any pic
processor.   To purchase this, you can either pay the full $249, or
bundle it with a development board for an effective price of $175.   I
really like the EasyPIC development system - I have an EasyPIC4, and am
thinking about buying a easypic5 sometime in the future.

I think if I was just going to be doing hobbyist things, I'd consider
buying a EasyPic5 and MikroC.

Jason Hsu wrote:
{Quote hidden}

2008\09\01@063545 by Wouter van Ooijen

face picon face
> Forrest W Christian wrote:
> A while ago I played with several of the C compilers, including the free
> ones.
>
> The free ones were disappointing - but you might find they work well.

What was your disappointment with C18? (besides that it works for 18F's
only)

Did you try SDCC?

--

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu

2008\09\01@101300 by Timothy J. Weber

face picon face
Forrest W Christian wrote:
> If you're into cheap, hobbyist C, you might want to try the MikroC.

BoostC never seems to get much attention.  IMO it's a higher-quality
compiler than MikroC (much tighter output code) and costs less for a
comparable license.  I haven't done head-to-head comparisons with other
compilers, but I find it completely suitable for professional projects.

Cost is $5-$30-$70-$150, for varying capabilities.  Supports PIC16 and
PIC18.  http://www.sourceboost.com/
--
Timothy J. Weber
http://timothyweber.org

2008\09\01@131845 by John Temples

flavicon
face
Jason Hsu wrote:

> I've summarized my experience at http://www.jasonhsu.com/microcontroller.html .

Your statement that PICC-Lite is not available for Linux is not
correct.  All of Hi-Tech's PIC compilers as well as their IDE are
available under Linux.

--
John W. Temples, III

2008\09\01@205713 by Forrest W Christian

flavicon
face
Wouter van Ooijen wrote:
> What was your disappointment with C18? (besides that it works for 18F's
> only)
>  
I wasn't including C18 in the category of free ones...   I will agree
the student version of C18 works rather well, and is free.
> Did you try SDCC
Yes, although I can't remember the specific reasons why I wasn't that
impressed with it...  Also, it was probably a year and a half ago that I
looked, so things may have changed.

2008\09\01@213044 by Forrest W Christian

flavicon
face
Let me add a bit more to help clarify...

When I was looking at the C compilers, I was looking for something which
could produce production-quality code, but on a budget.  At that point,
I really wanted to target the 16F line since those parts were somewhat
less expensive - but I looked at C18 as well.

Hi-Tech C was out of my price range, and the limitations on the free
compiler didn't suit me so I didn't really look there.

C18 was PIC18 only, and I really wanted the 16F target.   So that was a
strike against there.   I don't recall the C18 student edition being
free - or if it was there was some other limitation which I couldn't
live with.   Right now, I don't think I could live with a non-optimizing
compiler.

I looked a bit at boost c and SDCC and mikro c and some of the others
and didn't really find what I was looking for as far as production
quality code goes.

So I settled on buying a copy of PCWH from CCS.  It seems to produce
robust code, although the newer compiler/ide gave me some fits early on
(it seems fine now).

A while later, I bought a EasyPIC4 board from Mikro-e.   With that I
played with the free version of the Micro-C compiler.   I've got some
hobbyist stuff that I did with the Mikro-C compiler, and at some point I
decided I would take advantage of the discount on the full edition
compiler since I had purchased a board.   The Mikro-C environment makes
hacking some one-off project a fair bit easier than PCWH or C18 -
usually because I've got the EasyPIC4 plugged into the machine and am
using it for testing purposes.

Like I mentioned in my prior email, generally I'll go for MikroC if I'm
just screwing around since the libs are a lot easier to use for those
things you'd want to do as a hobbyist - like they have sound libs and
the like.   If it's going to be production code targeted on the PIC16,
PCWH gets used, and if it's targeted for the PIC18, it's either C18 or
the PCWH - usually C18 for big applications, and PCWH if I'm doing
something which may get scaled down and run on a PIC16.

Forrest W Christian wrote:
{Quote hidden}

2008\09\01@214240 by Bob Blick

face
flavicon
face
Jason Hsu wrote:
> Thanks for the suggestions on how to program microcontrollers in C
> instead of Assembly language.
>
> In the process of trying to get started, I can see why Assembly
> language is MUCH more popular among hobbyists than C.  There is
> EXCELLENT support for Assembly language.  MPLAB offers FREE and full
> functionality for Assembly language programming of microcontrollers.

And nobody has mentioned AVR to you yet? C compilers for the PIC
(especially the base and midrange parts) are hard to write, and good
ones are not cheap. Whereas with the AVR, it is a more conventional
micro and AVR-GCC is good.

Cheerful regards,

Bob

2008\09\02@065743 by Vitaliy

flavicon
face
Jason Hsu wrote:
> In the process of trying to get started, I can see why Assembly
> language is MUCH more popular among hobbyists than C.

I am surprised by the fact people who replied so far, seem to agree with
you. Is it really so, that the majority of hobbyists use assembly in their
projects?

In my opinion, unless your project is a very high-volume, extremely
price-sensitive commercial product, you shouldn't be using the PIC16F, or
programming in Assembly. I know this statement has the potential of starting
a flame war, but please bear with me as we look at the facts.

The 16F is cheaper than the 18F or the 16-bit PICs, but for one-off or
low-volume projects, the difference is negligible (about $1). See for
yourself -- click on the product series, and sort by price in ascending
order (also pay attention to what you get for the money):

PIC16F: http://tinyurl.com/9akkz
PIC18F: http://tinyurl.com/2yg3zw
PIC24H: http://tinyurl.com/2x9k2w

For anything but high-volume projects (many thousands), or projects
requiring very little code, you will spend *more* per unit if you go with
the PIC16F.

Microchip has free Student versions of the C18 and C30 compilers.
Programming in C has many advantages over assembly, but the main one is that
it makes the code much easier to write, understand, and reuse. It lets you
focus more on the design, rather than the implementation details, of your
program. Another big advantage for a beginner, is that there are many more
resources available for C (books, websites, expert programmers), than for
the PIC16F flavor of Assembly.

Some folks argue that writing in C results in bloated code, especially on
Microchip's compilers. However, for most hobbyist projects, performance and
even the amount of available memory is irrelevant. Even if it wasn't, for
less than an extra $1, you get a processor with at least 10 times as much
memory, running at up to 20 times as fast. If that's still not enough (here
we're assuming that a compiler is 20 times worse at producing assembly than
a newbie), drop down to inline assembly for the performance-critical
portions of your program.

I think most of us are familiar with the curve showing the ratio of hardware
vs software cost over time. Hardware is getting ridiculously cheap. People's
time, on the other hand, is becoming increasingly more expensive. Pretty
soon, the 16- and 32-bit PICs will literally cost less than a pack of gum.

The bottom line is, if you are new to PICs, get the Explorer 16 board, or at
least an 18F, download the free C compiler, and remember that you're writing
code for humans first, and for computers second. Err on the side of
readability, even if it comes at the expense of memory locations, or machine
cycles.

Good luck,

Vitaliy

2008\09\02@081125 by John Day

flavicon
face
At 06:58 AM 9/2/2008, Vitaliy wrote:
>Jason Hsu wrote:
> > In the process of trying to get started, I can see why Assembly
> > language is MUCH more popular among hobbyists than C.
>
>I am surprised by the fact people who replied so far, seem to agree with
>you. Is it really so, that the majority of hobbyists use assembly in their
>projects?

Vitaliy,

Remember this is a PIC list! And assembler has been the traditional
way to handle PIC devices. In my office we use PIC processors for
some limited functionality where the client dictates it. Generally we
prefer Atmel and NXP for most work. The lack of a GNU compiler for
the PIC is a serious limitation however we do use the Hi-Tech compiler.

Their is also a lot of literature around on using PICs with assembler
- and not so much about C. It appears to me that many get their first
exposure to PICs using MPLAB and never really progress. However in
the Atmel/AVR world people will start with AVR Studio and the
assembler, but the Win-AVR GCC package is so easily installed and
integrates so well into AVR-Studio that C rather than assembler is the norm.

John


2008\09\02@112147 by Byron Jeff

flavicon
face
On Tue, Sep 02, 2008 at 06:58:25AM -0400, Vitaliy wrote:
> Jason Hsu wrote:
> > In the process of trying to get started, I can see why Assembly
> > language is MUCH more popular among hobbyists than C.
>
> I am surprised by the fact people who replied so far, seem to agree with
> you. Is it really so, that the majority of hobbyists use assembly in their
> projects?

Many do. It's simply exposure. There are tons of resources for building
projects in assembly, along with detailed tutorials of getting everything
installed. Another plus is that all of the tools are completely free.

Once you start talking about C, there is a wide diversity of tools with a
wide range in prices and capabilities. So there's no universality.

> In my opinion, unless your project is a very high-volume, extremely
> price-sensitive commercial product, you shouldn't be using the PIC16F, or
> programming in Assembly. I know this statement has the potential of starting
> a flame war, but please bear with me as we look at the facts.

Let's hear it.

>
> The 16F is cheaper than the 18F or the 16-bit PICs, but for one-off or
> low-volume projects, the difference is negligible (about $1). See for
> yourself -- click on the product series, and sort by price in ascending
> order (also pay attention to what you get for the money):

Agreed. It's one of the reasons that I argue that using a PIC that's fully
packed with peripherals as opposed to parts with limited functionality.

> PIC16F: http://tinyurl.com/9akkz
> PIC18F: http://tinyurl.com/2yg3zw
> PIC24H: http://tinyurl.com/2x9k2w

Absolutely. The problem in the past has been programming tools. Also with
the 24H the packaging is an issue. For a hobbyist, DIP will continue to be
a prime motivator. So actually the dsPIC30F would package better than the
PIC24H.

>
> For anything but high-volume projects (many thousands), or projects
> requiring very little code, you will spend *more* per unit if you go with
> the PIC16F.

I don't think price is the true motivation for most hobbyist. They
generally want to bite off something they can chew.

If you want to see where they gravitate, look for the setup with the most
hands on step by step tutorials.

> Microchip has free Student versions of the C18 and C30 compilers.
> Programming in C has many advantages over assembly, but the main one is that
> it makes the code much easier to write, understand, and reuse. It lets you
> focus more on the design, rather than the implementation details, of your
> program. Another big advantage for a beginner, is that there are many more
> resources available for C (books, websites, expert programmers), than for
> the PIC16F flavor of Assembly.

I agree for C in general, but not necessarily for C for embedded systems
and even more specifically C for Microchip controllers.

For example as a Linux based Pic guy, I'd probably start here:

http://www.micahcarrick.com/04-25-2005/pic-c-programming-linux.html

Note that it meets my specific target.


{Quote hidden}

The only caveat that I would add is that anyone working with PICs still
needs to have a reading level knowlege of assembly. The reason is that
often PIC assembly is the linguq franca of algorithms. Microchip themselves
do this by putting out most of their code in PIC assembly.

BAJ

2008\09\02@150940 by Vitaliy

flavicon
face
Byron, I will mostly address the points I disagree with you on (very few).
:)

>> The 16F is cheaper than the 18F or the 16-bit PICs, but for one-off or
>> low-volume projects, the difference is negligible (about $1). See for
>> yourself -- click on the product series, and sort by price in ascending
>> order (also pay attention to what you get for the money):
>
> Agreed. It's one of the reasons that I argue that using a PIC that's fully
> packed with peripherals as opposed to parts with limited functionality.

I read your article on 16F84 vs 16F628 (?) a while back, and all I'm doing
here is applying your logic across microcontroller families, rather than
within a single family.

>> PIC16F: http://tinyurl.com/9akkz
>> PIC18F: http://tinyurl.com/2yg3zw
>> PIC24H: http://tinyurl.com/2x9k2w
>
> Absolutely. The problem in the past has been programming tools. Also with
> the 24H the packaging is an issue. For a hobbyist, DIP will continue to be
> a prime motivator. So actually the dsPIC30F would package better than the
> PIC24H.

PIC24H PICs are available in DIP packages (see link above).

>> For anything but high-volume projects (many thousands), or projects
>> requiring very little code, you will spend *more* per unit if you go with
>> the PIC16F.
>
> I don't think price is the true motivation for most hobbyist. They
> generally want to bite off something they can chew.

I think people have the incorrect notion that simpler hardware = easier
coding (the opposite is generally true).

> If you want to see where they gravitate, look for the setup with the most
> hands on step by step tutorials.

That's changing, though. "Learning to Fly the PIC24H"
(http://www.flyingthepic24.com) is a pretty good tutorial-style book. Search for
"microchip pic" on Amazon.com to see more similar books. Also, I find more
and more code examples written in C18 and  (check Microchip and SparkFun
forums, for example).

>> Another big advantage for a beginner, is that there are many more
>> resources available for C (books, websites, expert programmers), than for
>> the PIC16F flavor of Assembly.
>
> I agree for C in general, but not necessarily for C for embedded systems
> and even more specifically C for Microchip controllers.

I meant for C in general, but although your statement would have been true a
few years ago, it no longer is. Most of the code in hobby and embedded
magazines is in C.

> For example as a Linux based Pic guy, I'd probably start here:
>
> http://www.micahcarrick.com/04-25-2005/pic-c-programming-linux.html
>
> Note that it meets my specific target.

I'm not sure I follow.

> The only caveat that I would add is that anyone working with PICs still
> needs to have a reading level knowlege of assembly. The reason is that
> often PIC assembly is the linguq franca of algorithms.

I think pseudocode does a much better job of explaining algorithms. If it
weren't so, you wouldn't need to comment assembly so profusely.

> Microchip themselves
> do this by putting out most of their code in PIC assembly.

Was certainly true circa 2000, but is no longer true. In fact, Microchip's
official line (expressed in Lucio's book) is "learn to trust the compiler".
At the MASTERS conference this year, very few exercises were in assembly.
Today, C is the real lingua franca of embedded programming.

Vitaliy

2008\09\02@223423 by Byron Jeff

flavicon
face
On Tue, Sep 02, 2008 at 03:10:25PM -0400, Vitaliy wrote:
> Byron, I will mostly address the points I disagree with you on (very few).
> :)
>
> >> The 16F is cheaper than the 18F or the 16-bit PICs, but for one-off or
> >> low-volume projects, the difference is negligible (about $1). See for
> >> yourself -- click on the product series, and sort by price in ascending
> >> order (also pay attention to what you get for the money):
> >
> > Agreed. It's one of the reasons that I argue that using a PIC that's fully
> > packed with peripherals as opposed to parts with limited functionality.
>
> I read your article on 16F84 vs 16F628 (?) a while back, and all I'm doing
> here is applying your logic across microcontroller families, rather than
> within a single family.

In general I agree. There are two reasons that I haven't personally moved:

1) The 16F family provides all the functionality I need.
2) I have a toolset that works with the 16F family.

Moving requires learning a new toolset. When #1 above finally fails, that's
when for me it's worth investing in a new toolset.

But if you are starting fresh, I agree that starting with the best chip
that's in striking range on price (with the caveat that the info is
available to use it) should be used.

{Quote hidden}

I pulled the data sheet when I read your post the first time. I didn't see
it. Let me take another look... OK. I see now. It doesn't look though that
they have a 40 pin PDIP, only 28 pin ones.

> >> For anything but high-volume projects (many thousands), or projects
> >> requiring very little code, you will spend *more* per unit if you go with
> >> the PIC16F.
> >
> > I don't think price is the true motivation for most hobbyist. They
> > generally want to bite off something they can chew.
>
> I think people have the incorrect notion that simpler hardware = easier
> coding (the opposite is generally true).

As I always put it "It may be easier to go from 0 to 40 by bitbanging, but
that does you little good when you need to go 100."

{Quote hidden}

For both of these I ask "What about online?" Folks are not generally going
to look for books or magazines anymore. They go straight for Google.

And while C is trivial for someone who knows it, trust me as someone who
has taught C programming for more than 15 years, if you haven't been
exposed, there's a huge learning curve.

> > For example as a Linux based Pic guy, I'd probably start here:
> >
> > www.micahcarrick.com/04-25-2005/pic-c-programming-linux.html
> >
> > Note that it meets my specific target.
>
> I'm not sure I follow.

As an example of a tutorial for programming PICs in C on my platform.
That's what people will look for.

> > The only caveat that I would add is that anyone working with PICs still
> > needs to have a reading level knowlege of assembly. The reason is that
> > often PIC assembly is the linguq franca of algorithms.
>
> I think pseudocode does a much better job of explaining algorithms. If it
> weren't so, you wouldn't need to comment assembly so profusely.

It doesn't matter if it's better. The point is that there's a ton of code
out there that's written in assembly. Being able to read it will help in
translating it to the language of your choice.

>
> > Microchip themselves
> > do this by putting out most of their code in PIC assembly.
>
> Was certainly true circa 2000, but is no longer true. In fact, Microchip's
> official line (expressed in Lucio's book) is "learn to trust the compiler".
> At the MASTERS conference this year, very few exercises were in assembly.
> Today, C is the real lingua franca of embedded programming.

Let's test your theory out. I'm going to take a look for the latest 16F and
18F application notes with code. Let's see what they have...

According to microchip's release by date page:

http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2047

this application note:

http://ww1.microchip.com/downloads/en/AppNotes/00734b.pdf

supposedly was released today.

It has code for both the 16F and the 18F. Both are written in assembly.

On the other hand this recent TCP/IP app mote for the 18F:

http://ww1.microchip.com/downloads/en/AppNotes/00833c.pdf

was written in C.

A small sample to be sure. But I don't think that it's cut and dried in
either direction.

BAJ

2008\09\03@010041 by Xiaofan Chen

face picon face
On Tue, Sep 2, 2008 at 9:42 AM, Bob Blick <bobblickspamKILLspamftml.net> wrote:
> And nobody has mentioned AVR to you yet? C compilers for the PIC
> (especially the base and midrange parts) are hard to write, and good
> ones are not cheap. Whereas with the AVR, it is a more conventional
> micro and AVR-GCC is good.

I believe it is much easier to start with PIC18 with MPLAB C18
(student version is free) than messing with AVR-GCC even though
it is supposed to be good.

With MPLAB IDE and C18, you can get the things to work right
away. With WinAVR, you still need to learn how to write a
Makefile or similar to get it working. And if you want to use
assembly, I think the assembly which comes with gcc is
really difficult to use.

Xiaofan

2008\09\03@010355 by Xiaofan Chen

face picon face
On Tue, Sep 2, 2008 at 7:24 PM, Byron Jeff <.....byronjeffKILLspamspam.....clayton.edu> wrote:

> I agree for C in general, but not necessarily for C for embedded systems
> and even more specifically C for Microchip controllers.
>
> For example as a Linux based Pic guy, I'd probably start here:
>
> http://www.micahcarrick.com/04-25-2005/pic-c-programming-linux.html
>
> Note that it meets my specific target.
>

Apparently it did not even meet the target of the author himself and
he is now using AVR. Actually the document is rather outdated and
not a very good introduction for using PIC under Linux.

In general, I think it is much easier to use other MCUs like AVR
and ARM under Linux than to use PIC. Under Windows, using
PIC is just as easy (if not easier) as other MCUs.

Xiaofan

2008\09\03@010738 by Xiaofan Chen

face picon face
On Tue, Sep 2, 2008 at 8:13 PM, John Day <EraseMEjohn.dayspam_OUTspamTakeThisOuTsiliconrailway.com> wrote:
> Remember this is a PIC list! And assembler has been the traditional
> way to handle PIC devices. In my office we use PIC processors for
> some limited functionality where the client dictates it. Generally we
> prefer Atmel and NXP for most work. The lack of a GNU compiler for
> the PIC is a serious limitation however we do use the Hi-Tech compiler.

I understand that this list is mostly for people who are still using
smaller PICs (mostly PIC16 and a bit of PIC18), however Microchip
compilers for PIC24/dsPIC and PIC32 are both based on GCC.

Xiaofan

2008\09\03@011050 by Xiaofan Chen

face picon face
On Mon, Sep 1, 2008 at 6:35 PM, Wouter van Ooijen <wouterspamspam_OUTvoti.nl> wrote:
>  > Forrest W Christian wrote:
>> A while ago I played with several of the C compilers, including the free
>> ones.
>>
>> The free ones were disappointing - but you might find they work well.
>
> What was your disappointment with C18? (besides that it works for 18F's
> only)

Maybe because of the free student version will lose some optimizations
after the evaluation period.

> Did you try SDCC?
>

I do not think SDCC is good enough for PIC16. It is a bit better for PIC18,
but still not that good yet. It is said sdcc for MCS51 is pretty good.

Xiaofan

2008\09\03@040927 by Alan B. Pearce

face picon face
> this application note:
>
> http://ww1.microchip.com/downloads/en/AppNotes/00734b.pdf
>
>supposedly was released today.
>
>It has code for both the 16F and the 18F. Both are written in assembly.

However to be fair AN734 has been around a long time, and the particular
issue you provided the link for is Rev B, so it is an update to include the
18F devices with newer features in the MSSP. It having code in assembly is
therefore understandable.

2008\09\03@075823 by Gerhard Fiedler

picon face
Byron Jeff wrote:

> The only caveat that I would add is that anyone working with PICs still
> needs to have a reading level knowlege of assembly.

I agree with this. I read PIC assembly good enough for my purposes, and I
got pretty much all of my reading (and writing) skills from occasionally
reading compiler output (and of course transferring whatever I knew before
about other micro families). It's good enough to be able to understand app
notes...

Gerhard

2008\09\03@235107 by David Meiklejohn

face
flavicon
face
Vitaliy wrote:
{Quote hidden}

I agree with this - unless you want a PIC with less than 18 pins.  In that
case, your choices are a 14-pin 16F, a 8-pin 12F, or a 6-pin 10F.

Now, you can argue that with modern surface-mount devices, an 18-pin device
can be physically quite small, but remember that this discussion was about
hobbyists, and DIPs are definitely more hobbyist (or even professional
prototyping) friendly.

E.g. check out my Christmas Star project -
http://www.gooligum.com.au/kits/xmasstar/xmasstar.html.  I wanted something
that easy for hobbyists to build (hence a DIP), but I wouldn't have wanted
anything bigger than an 8-pin device in the middle of that star.  No 18F
would do.  And besides, it's much more fun to get an 8-pin device to drive
20 independently-addressable LEDs - where's the challenge in using an 18-pin
device?  :-)


David Meiklejohn
http://www.gooligum.com.au


2008\09\04@104042 by Martin

face
flavicon
face
Hi Vitaliy,
I agree with everything you say. The new 18F..J parts seem particularly
nice IMO. The 18F67J10 costs ~US$2.65, has 128k flash and 3904 bytes
RAM. Yeah, it's a 64TQFP but you can get carrier boards really cheap.
I like the specs on the 24H parts as well but getting a C compiler for
them is probably a little more expensive. OTOH if you get the microchip
C compiler you can go between the dsPICs and PIC24s. I especially agree
with the statement that time is increasingly expensive. If you're not
factoring in time you're probably wasting it.

I would be really excited to see a PIC32 in a bit smaller package like a
TQFP 44. I think it needs a better ADC too.. but maybe that's a noise
limitation.


-
Martin


Vitaliy wrote:

{Quote hidden}

2008\09\04@223808 by Vitaliy

flavicon
face
Martin wrote:
> Hi Vitaliy,
> I agree with everything you say.

Oh-oh. :)

> The new 18F..J parts seem particularly
> nice IMO. The 18F67J10 costs ~US$2.65, has 128k flash and 3904 bytes
> RAM. Yeah, it's a 64TQFP but you can get carrier boards really cheap.
> I like the specs on the 24H parts as well but getting a C compiler for
> them is probably a little more expensive.

We've successfully used both the C18 and the C30 compilers at work. The
Student version is free, and one would have to write a lot of code in order
for the optimizations to start to matter.

> I would be really excited to see a PIC32 in a bit smaller package like a
> TQFP 44. I think it needs a better ADC too.. but maybe that's a noise
> limitation.

Honestly, I don't know that much about PIC32. Given the fact that it takes
Microchip an average of 18 months to fix the errata and make new silicon, I
think we'll wait a year or so before getting our feet wet. Hopefully by that
time, there would also be plenty of example code, and we'll be able to
google solutions to the more common problems.

> I especially agree
> with the statement that time is increasingly expensive. If you're not
> factoring in time you're probably wasting it.

Yeah, but it goes both ways -- see Byron's post. If you are already familiar
with the 16F, have the toolset, and don't need more resources (pins, RAM,
ROM) then the cost of switching to a new processor family is likely to be
greater than the benefits.

Vitaliy



----
"We buy other people's mistakes." -- Steve Sanghi, Microchip CEO
----

2008\09\04@233506 by Xiaofan Chen

face picon face
On Thu, Sep 4, 2008 at 10:40 PM, Martin <@spam@martinKILLspamspamnnytech.net> wrote:
> I would be really excited to see a PIC32 in a bit smaller package like a
> TQFP 44. I think it needs a better ADC too.. but maybe that's a noise
> limitation.

Some of the Freescale ColdFire V1 (and a few V2) MCUs start to look
interesting here even though the choices are still very limited. But
they seem to be very competitive against PIC24/PIC32, especially
on the higher end (Ethernet, USB, etc).

>From the product summary brocure:
10k SRP of MCF51QE32/64/128 is US$1.94/3.30/3.80. LQFP64
10k SPR of MCF51JM128 is US$3.65 with 44LQFP option.
10k SRP of MCF52212/213 is US$2.84/3.74. LQFP64.
http://www.freescale.com/coldfire

All have 12bit ADC. Some have USB Device/Host/OTG. Some have
MAC. All have US$99 development board. The special edition
CodeWarrior has code size limited C compiler (64KB for V1
and 128KB for V2).
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CW-SUITE-SPECIAL

Xiaofan

2008\09\05@073551 by Michael Rigby-Jones

picon face


> -----Original Message-----
> From: KILLspampiclist-bouncesKILLspamspammit.edu [RemoveMEpiclist-bouncesTakeThisOuTspammit.edu] On
Behalf
> Of Xiaofan Chen
> Sent: 05 September 2008 04:35
> To: Microcontroller discussion list - Public.
> Subject: Re: [PIC]Using C instead of Assembly language
>
> On Thu, Sep 4, 2008 at 10:40 PM, Martin <spamBeGonemartinspamBeGonespamnnytech.net> wrote:
> > I would be really excited to see a PIC32 in a bit smaller package
like a
> > TQFP 44. I think it needs a better ADC too.. but maybe that's a
noise
{Quote hidden}

www.freescale.com/webapp/sps/site/prod_summary.jsp?code=CW-SUITE-
> SPECIAL
>
> Xiaofan


The only Hitachi/Freescale parts I've ever used have been the HC11 and
H8S, so I'm not really up to speed on them. Do the Coldfire devices have
any significant advantages over ARM based ones?

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2008\09\05@092742 by Xiaofan Chen

face picon face
On Fri, Sep 5, 2008 at 7:35 PM, Michael Rigby-Jones
<TakeThisOuTMichael.Rigby-JonesEraseMEspamspam_OUTbookham.com> wrote:
>
> The only Hitachi/Freescale parts I've ever used have been the HC11 and
> H8S, so I'm not really up to speed on them. Do the Coldfire devices have
> any significant advantages over ARM based ones?
>

Hitachi is now Renesas (Hitachi+Mitsubishi) and they claim to be
the No. 1 MCU maker. H8 and M16C are both still quite popular.

ColdFire is more prominent on the higher end (more like MPU)
especially those with embedded RTOS support like Linux. ARM7s
(also Cortex M3) can not run Linux since they do not have MMU.
You need ARM9/Xscale for that. The choice of ARM9 is not as
great as ARM7/Cortex M3. So ColdFire is still competitive in
some markets. Now it seems that Freescale is really pushing
quite hard on the 8-bit and low-end 32bit with Coldfire V1 core.
I think V1 core will target Cortex M3.

Still I would say ARMs are still the most popular MCU core
today and I have doubts whether PIC32 can compete with
Cortex M3. STM32 really catches a lot of attentions now.
NXP LPC1000 is also out.


Xiaofan

More... (looser matching)
- Last day of these posts
- In 2008 , 2009 only
- Today
- New search...