Subject:
Re: [gnupic] PIC under Linux developpement Howto newbie
From:
Byron A Jeff ####@####.####
Date:
5 Jul 2005 23:32:04 +0100
Message-Id: <20050705223200.GB7194@cleon.cc.gatech.edu>
On Tue, Jul 05, 2005 at 12:31:29PM +0200, MvH wrote:
> Hello people on this list;
>
> I am a linux user and I am starting to learn pics. I would like a
> tutorial so I don't have to bother other people
> with simple/stupid questions. Like 'what programmer', 'what is a
> programmer', and 'how to make a serial connection'
Excellent points.
>
> Nobody in my close (learning) environment has told me to use assembler,
> some on the net do, some don't, this is al hard to make up my mind
> about. If you would like to know what a newbie who's new to the subject
> and wants to use linux in the whole process, needs and tries to achieve,
> here are my suggestions:
>
> A tutorial covering the fist steps, like what programmer, what
> programming software, assembler basics, do's and don'ts, blink a led,
> connect a max232, reading in serial output from the pic on a linux
> machine ( minicom -l I found ) would be very helpful for beginners. I am
> currently unraveling this information step by step.
> If this tutorial would be applicable to a wider range of pics, more
> people could learn from this:
>
> Sometimes you just 'get' a pic from someone, sometimes you're forced to
> use one by a university that gives you software to use in school but not
> at home. I mean, sometimes you don't even know what to get, only that
> you have to finish it in 5 weeks time, and the electronics shops aren't
> very helpful or don't have it onstock.
I think Wouter can be helpful in this respect. He ships stuff from his
webshop (http://www.voti.nl) all over the world.
> A second part about sensing the outside world, controlling dc motors,
> doing ir communication, midi, could be pic specific.
Definitely.
>
> The beginner can search the wiki to find out what pic to start with by
> looking at examples. the first steps are pic independent so that's
> already covered.
>
> splitting up this information has following advantages:
>
> Like I was told, different projects have different (pic) needs. Covering
> multiple pics in the first part gives you a starting point to write
> other documentation on, for specific types of pic's.
The problem is that it's confusing to new users not to have a specific
example.
> It would be like reading a book: first, you learn what applies to all of
> them, and how to get 'going', then you learn what your specific needs
> are. If you start reading in the back of the book, you could order the
> hardware, and flip in the beginning to get things working lateron
> without problems.
I always approach this by starting with a single chip that has all of the
facilities on it, then introduce those facilities one at a time. For example
in the 16F 18 pin family, that part is the 16F88. It has everything. Since it's
a superset of all the other 16F 18 pin family PICS, simply by using it you
get all of the others under its umbrella.
> only one last thing: I learned that a pic16f84 is 'old' ( by looking at
> the creation dates of the html pages) 90% of the documentation is
> written for this, but I can't get it anymore in any local shops, this is
> confusing.
It's frustrating. That's why I wrote my 16F84 is obsolete pages.
> I am an art/mediatechnology student. I have limited programming
> skills(perl) and I wouldn't mind learning assembler. I'm now doing
> things in jal, but it's just as new as assembler would be.
jal, C, pyastra, (eventually NPCI), and other high level languages all have
their advantages. The problem I see is that so much of PIC culture is based
around assembly that everything else seems fractured in comparison.
> Hope I didn't open my big mouth just to cause annoyance,
I'm glad you opened your big mouth. No annoyance at all.
BAJ
