gnupic: Re: [gnupic] PK2 resources for beginners who would like to achieve something
Subject:
Re: [gnupic] PK2 resources for beginners who would like to achieve something
From:
Peter Keller ####@####.####
Date:
25 Jun 2009 15:30:28 -0000
Message-Id: <20090625153025.GA17059@cs.wisc.edu>
On Thu, Jun 25, 2009 at 09:42:06AM +0100, Tamas Rudnai wrote:
> If you speak generally "embedded" systems including microcontrollers and
> embedded computers like PDAs and mobile phones than go for C definitely.
> However, if you want to do serious development you should know to "read"
> assembly code at least -- even better if you can write and optimize code by
> your hand.
This is pretty true. "embedded" systems are a spectrum from the lowliest
8 bit processor with 6 pins and sub-K (I mean like 32 bytes) memory all
the way up to things like iPhone which uses Objective-C and the Android,
which uses Java (from a developer point of view). Obviously, this means
a spectrum of tools as well some more approriate than others.
I generally wouldn't use much assembly if I were writing to a 32-bit PIC
with lots of ram, instead writing in some compiler's dialect of C, but for
something like the pic16f, I would definitely use assembly. For the pic18f
series, I'd either use assembly or C (SDCC's dialect since it is free
for linux) depending on my mood and the complexity of what I'm writing.
It doesn't hurt to learn a good subset of the assembly first in the
case of PICs at any rate. I'd start with a PIC16F690 and learn to use
that initially. It is a surprisingly flexible chip with lots of features
you can learn to use independently of each other and the data sheet is
pretty readable.
A lot of embedded design (from the point of view of a hobbiest) seems
to be ensuring you initially pick the right tools, uP, and various parts
for the project at hand to minimize the wasting of your time while
building it. If you're designing for money or for mass production, then
the cost of the thing you make should be minimized, which can increase
development time. But if it is a one off or several for some friends, then
use whatever is easiest for you.
But generally, above all, document what you did for anything significant
into a theory of operations document. All the schematics, the math, the
why it works, the code, how to build it, bill of materials, everything.
You'll be happy you did later.
Later,
-pete
