On Sat, Jan 18, 2003 at 07:52:25PM -0500, Olin Lathrop wrote:
> > Talk to me not about the part, but about the toolchain. Tell us about
> the
> > development tools and programmers you'd suggest a new user use to get
> started.
> >
> > Then I'll ask you about my curveballs, neither of which you are
> interested in
> > (my impression from past conversations with you on the subject):
> >
> > 1) A usable toolchain for non Windows environments.
> > 2) A low cost and easy to obtain toolchain.
> >
> > And of course in the put up or shut up category, here's my list for the
> > curveballs:
> >
> >     Platform: Slackware Linux 8.1
> >         Part: 16F877
> >   Programmer: TLVP used to install WLoader bootloader
> > Dev Software: JAL 04-50 or gpasm 0.10.4
> >    Simulator: gpsim 0.20.12
> >
> > Total cost is under $25 USD.
> >
> > The point I'm making is that it's isn't a cut and dried choice.
>
> OK Byron, I agree Mike was being harsh and I don't even agree with what he
> said, but I don't think this is the best way to start with PICs either.

Nor did I. I just threw it out there so that someone wouldn't say that I
proposed a paradox without giving a solution.

> The **standard** development environment for PICs is Microchip's MPLAB,
> which is free on their web site.  This is what most examples out there are
> written for, and what you'll get the most support for, including this
> list.  Yes, it runs on Windows, like most everything else does.  Most
> people already have a Windows machine for other reasons, so MPLAB is
> completely free.

No problem there. I do wish that there was a similar tool for high level
languages. Can anyone talk about the exact status of the Mchip 18C compiler?

>
> I would also advise to get a real programmer as I've seen too many newbies
> here with TLVP programmer problems.

Actually in my recollection it was a couple of people with lots of TLVP
problems. It in fact has a quite high success rate.

>  In addition, if someone first wants
> to really *learn* PICs (as apposed to quickly getting a complicated
> project working), then assembler is the way to start.

The further along I get into this process, the less I believe this theory.
Assembly usually isn't the most efficient way from the development standpoint
though it generally has the ability to produce the most efficient system
in the end.

Most of the advocacy here has been "Learn assembler 1st, then switch to an HLL"
But it seems to me that it's a path to frustration. I think it would be better
to attack from the top down and teach the 90/10 rule, profiling, and selective
recoding.

>Even if someone
> ends up using a higher level language once they get going, the insight
> gained from doing a few assembler projects will be valuable.

Why doesn't this same theory apply to Macs, Solaris, Windows, or Linux boxes?
What is it about small systems that turns this on its head?

It's almost like the linker argument that gets trotted out every 3 months or
so. The linker is clearly better, yet takes a bit of time to understand. Yet
all the code is written in absolute.

BAJ

--
http://www.piclist.com hint: The list server can filter out subtopics
(like ads or off topics) for you. See http://www.piclist.com/#topics