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:
Darwin Pintado ####@####.####
Date:
30 Jun 2009 03:56:39 -0000
Message-Id: <fc35c2340906292056p7076d2bdyd01f5c4c8d07aad8@mail.gmail.com>
Thanks for all the response. For the past days, I've been doing a research
on the the device I have -> PIC16F690 to have a big picture understanding
and the device I have as of the moment. I am still in the process of
understanding each modules and I was wondering in the I/O ports, lets say
PORTC, I am curiuos why there are unimplemented bits and unknown bits.
d
On Thu, Jun 25, 2009 at 3:30 PM, Peter Keller ####@####.#### wrote:
> 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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>
>
