Searching \ for '[PIC:] Getting started with PIC's' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/begin.htm?key=pic
Search entire site for: 'Getting started with PIC's'.

Exact match. Not showing close matches.
PICList Thread
'[PIC:] Getting started with PIC's'
2004\11\11@144230 by crayola

flavicon
face
I am just starting out programming pic microcontrollers (never did
any embedded programming before) and I need some advice. I looked
over the FAQ's and such but couldn't find what I was looking for.

As I understand it.. I need 3 things to get going..

1. Some sort of development language - I am planning on picking
  up picbasic pro from melabs since it seems to be well supported
  and I dont know ANYTHING about assembly language. I have also
  found several books on programming with pic basic to get me started.

  Or should I use C? http://www.rentron.com/C2C.htm
  Reynolds offers a C2C compiler and getting started course for $60.
  Its supports a lot less PIC chip #'s however.

  I have programmed in C, basic, perl, etc.. on a computer so
  I imagine after I get the basic semantics of working on a
  pic, I should be fine with either language.

       What would you choose?

2. A programmer to program the pic chips - I was thinking about
  using the melabs serial programmer.

       http://www.melabs.com/products/serprog.htm

  It looks like it supports virtually every PIC chip out there
  that I might use. Is this a good choice for a programmer?

3. Some sort of basic development/lab board to get started. I was
  thinking about buying Compubotics RC40 robot controller which
  has a PIC 16f877 in it with a bootloader so code can be
  dumped right from a serial port. Essentially its a mini development
  environment ready to move servos.

       http://compubotics.com
       http://www.compubotics.com/docs/rc40callout.pdf

  Does this seem like a good choice?

What do I plan on doing with the PIC? Controlling relays, servos, etc
based on audio and infared inputs. Basically I want to get into
animatronics in a big way.

What type of basic circuitry is required to support a PIC?
I understand they need a crystal, power supply (of course), a few
resistors.

Can anyone point me to a basic circuit layout that would provide
support for a 16f877 pic?

Thanks for any help you can offer..
Mike

____________________________________________

2004\11\11@154421 by Larry Bradley

flavicon
face
My $.02  worth

At 02:42 PM 11/11/2004 -0500, you wrote:
{Quote hidden}

Take a look at Basic18 http://www.midwest-software.com/Basic18/basic18.htm.
There is a free, but limited version that you can use, and upgrade to a
more powerful compiler if you like. This is a decent structured Basic
language, much better, in my opinion, than the MELABS product (I have both,
and only use Basic18 now).

This compiler only supports the 18F series of Pics, but that is what you
should be playing with anyhow.



>2. A programmer to program the pic chips - I was thinking about
>    using the melabs serial programmer.
>
>         http://www.melabs.com/products/serprog.htm
>
>    It looks like it supports virtually every PIC chip out there
>    that I might use. Is this a good choice for a programmer?


Take a look at http://www.voti.nl/wisp628/index.html. It works very well,
and is quite inexpensive.

{Quote hidden}

I just use a standard breadboard setup, with a homemade power supply.


{Quote hidden}

>_____________________________________________

2004\11\11@154844 by Jan-Erik Soderholm

face picon face
crayola@optonline.net wrote :

> I am just starting out programming pic microcontrollers (never did
> any embedded programming before) and I need some advice. I looked
> over the FAQ's...

It would help if you said *what* FAQ, so we know what you have read.
There isn't a single *The* PIC FAQ, as far as I know.

> and such but couldn't find what I was looking for.
>
> As I understand it.. I need 3 things to get going..
>
> 1. Some sort of development language - I am planning on picking
>    up picbasic pro from melabs since it seems to be well supported
>    and I dont know ANYTHING about assembly language.

And you are absolutly not interesting in learning ??
Then why jump into microcontrollers in the first place ?
You sure have to know *something* if you're going to
use microcontrolers at all.

>    Or should I use C?...
>    What would you choose?

No matter what higher level language you use, you will just make
it harder for yourself if you don't understand assembler and can read
an assembler code listing. Sometimes, when the compiler doesn't
"do" what you expect, it can help to read the assembly listing from
the compiler to find out why. You might be fine anyway, but it doesn't
hurt.

> 2. A programmer to program the pic chips - I was thinking about
>    using the melabs serial programmer.
>
>        http://www.melabs.com/products/serprog.htm
>
>    It looks like it supports virtually every PIC chip out there
>    that I might use. Is this a good choice for a programmer?

Some says yes, some says no... :-)

I know nothing about that one (but it seems a bit pricy, $119.95),
but I have been using the Wisp628 :
http://www.voti.nl/wisp628/index.html with very little problems.

>
> 3. Some sort of basic development/lab board to get started. I was
>    thinking about buying Compubotics RC40 robot controller which
>    has a PIC 16f877 in it with a bootloader so code can be
>    dumped right from a serial port. Essentially its a mini
>    development environment ready to move servos.

Sounds fine, if moving servos is what you will be doing. :-)

Eitherwise, I personaly find the Dwarf boards from the same source
as the Wisp628 as some nice "building blocks" :
http://www.voti.nl/dwarf/index.html

>        http://compubotics.com
>        www.compubotics.com/docs/rc40callout.pdf
>
>    Does this seem like a good choice?

Only you know what you need.
As far as I can see, the stuff from Compubotics doesn't support
any of the PIC18 processors.

> What do I plan on doing with the PIC? Controlling relays, servos, etc
> based on audio and infared inputs. Basically I want to get into
> animatronics in a big way.

You meen like on : http://www.animatronics.org/ ??
Looks nice :-)

>
> What type of basic circuitry is required to support a PIC?
> I understand they need a crystal, power supply (of course), a few
> resistors.

http://www.voti.nl/picfaq/index.html
http://www.voti.nl/swp/index.html

And the data sheet for each PIC typ, of course.

> Can anyone point me to a basic circuit layout that would provide
> support for a 16f877 pic?

There isn't *one* curcuit. It depends a bit on how twe PIC is run.
What type of osc for example. Many newer PICs have internal
osc's and doesn need any external crystal, and so on.

And while the 16F877 sure is a nice chip, and has been very
popular over the years, I'm not sure that it is *the* chip to
jump onto if one is just beginning with PICs. There are many
newer PICs where you get a lot more features. Both in the
PIC16 and the PIC18 lines.

> Thanks for any help you can offer..
> Mike

Just some personal opinions, of course.
After others have added theirs opinion, you might get a
clearer picture.  Or not... :-)

Just a final note...
If you realy are going hard into the robots and animatronics
stuff, maybe the dsPIC shuold be something to look at.
Much faster, and with a lot of special hardware to deal with
sensors, sounds, motors, servos and similar stuff...
Think about it.

Regards,
Jan-Erik.

____________________________________________

2004\11\11@154905 by olin_piclist

face picon face
crayola@optonline.net wrote:
> 1. Some sort of development language - I am planning on picking
>    up picbasic pro from melabs since it seems to be well supported
>    and I dont know ANYTHING about assembly language.

Time to learn.  On small microcontrollers you are never that far from the
hardware.  You need to understand what it is doing, even if eventually using
a high level language.  Otherwise, you won't have much chance of fixing
problems when something doesn't work right.

If you really don't want to get into assembly and don't want to understand
these processors at that level, then stop now.  Microcontrollers aren't for
you.  Stick with MFC apps and Java web pages.

You will also need at least a basic knowledge of electronics.  There is a
reason that most microcontroller engineers are more EE than CS oriented.

>    I have programmed in C, basic, perl, etc.. on a computer so
>    I imagine after I get the basic semantics of working on a
>    pic, I should be fine with either language.

No.  Unlike large general purpose machines with operating systems, you have
to understand the machine when programming microcontrollers, regardless of
the language.

> What would you choose?

Do the first few projects in assembler until you feel comfortable with it.
Then switch to a high level language is you still want to.

> 3. Some sort of basic development/lab board to get started. I was
>    thinking about buying Compubotics RC40 robot controller which
>    has a PIC 16f877 in it with a bootloader so code can be
>    dumped right from a serial port. Essentially its a mini development
>    environment ready to move servos.

That might be an easy way to move a few servos quickly, but the environment
will obscure the inner workings and keep you from learning what you really
need to know if you want to learn about microcontrollers.

The first project or two should be something much simpler.  Start out by
blinking an LED, and maybe talking to HyperTerm via a serial interface.

> What do I plan on doing with the PIC? Controlling relays, servos, etc
> based on audio and infared inputs. Basically I want to get into
> animatronics in a big way.

Then realize there is a lot to be learned and start out by trying to learn
it instead of immediate results.

> What type of basic circuitry is required to support a PIC?
> I understand they need a crystal, power supply (of course), a few
> resistors.

If you have to ask, then there is no simple answer.  Start with the data
sheet, then ask specific questions about what you don't understand.

Remember, microcontrollers aren't for everyone.  If you don't want to deal
with details like the instruction set and processor architecture, and don't
want to learn electronics, they aren't for you.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\11@162113 by crayola
flavicon
face
> Time to learn.  On small microcontrollers you are never that
> far from the hardware.  You need to understand what it is
> doing, even if eventually using a high level language.  
> Otherwise, you won't have much chance of fixing problems when
> something doesn't work right.

I don’t have any problem learning assembly.. I just don’t have any resources to do so.. Using a higher level language will provide some usable results quickly. I do agree with your point however that knowing how everything works under the covers is essential to solving issues. Perhaps you can point out some good books/tutorials on learning assembly that start out from the basics and build up? Something with an embedded slant would be helpful.
> Stick with MFC apps and Java web pages.

Insults are not needed.. I am not some code monkey.
> You will also need at least a basic knowledge of electronics.
>  There is a reason that most microcontroller engineers are
> more EE than CS oriented.

I have a basic understanding of electronics and theory... I am just not familiar with applying it to microcontrollers.
> Do the first few projects in assembler until you feel
> comfortable with it. Then switch to a high level language is
> you still want to.

Books? Tutorials you can recommend?
Thanks, Mike


___________________________________________

2004\11\11@164620 by Josh Koffman

face picon face
Check out the Square 1 books (http://www.sq-1.com). David (and his
wife) are great people, and I really enjoyed the books.

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

On Thu, 11 Nov 2004 16:21:13 -0500, spam_OUTcrayolaTakeThisOuTspamoptonline.net
<.....crayolaKILLspamspam@spam@optonline.net> wrote:
> Books? Tutorials you can recommend?
____________________________________________

2004\11\11@165300 by Jan-Erik Soderholm

face picon face
crayola@optonline.net wrote :

> I don’t have any problem learning assembly.. I just don’t
> have any resources to do so.. Using a higher level
> language will provide some usable results quickly.

Maybe... :-)

> > Do the first few projects in assembler until you feel
> > comfortable with it. Then switch to a high level language is
> > you still want to.
>
> Books? Tutorials you can recommend?

Check :
http://www.voti.nl/picfaq/index.html
http://www.voti.nl/swp/index.html

(and maybe http://www.st-anna-data.se/picdoc.zip, which i
a PDF version of the last link above...)

Then read up on the instruction set (any data sheet would do)

I entered "PIC assembly tutorial" in Google (94200 hits)
and found the following on the *first* page (first 10 hits) :

www.mstracey.btinternet.co.uk/pictutorial/picmain.htm
 (uses the old 16F84, but might be usefull anyway)

http://www.ic.unicamp.br/~celio/mc404/pic/pic_for_programmers.html

www.boondog.com/tutorials/pic16F84/pic16f84.html
 (also using the old 16F84...)

www.ecs.umass.edu/ece/wolf/courses/ECE354/lectures/ECE354-04-02-04-ASM.pdf
 (actualy quite nice. I've saved it as a possibly later use...)

I'll leave it to you to explore the other 11-94200 hits :-) :-)

Regards,
Jan-Erik.
____________________________________________

2004\11\11@170819 by Jinx

face picon face
Nobody mention MPLAB or Piclist yet ?

http://www.microchip.com

www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=1475&
category=devSoftware

http://www.piclist.com

If you're getting into animatronics and robotics IMHO you really
do need to know assembler. One of my current jobs involves very
fast stepper motor calculations and drive, which involves getting
down and dirty with multiple PICs and Scenixes. Managing each
cycle is important, particularly in the area of picking up and multi-
plexing sensor and encoder data

____________________________________________

2004\11\11@170845 by Colombain Nicolas

flavicon
face
Hi Mike,

Here is my point concerning the assembler pb.
You will need, depending on your applications, to write a few things in
assembler. But you can do most of the work without it.
You can start by using a "high level" language like PBP, JAL or C. You will
find a lot of examples and libraries.
Most of them will be sufficient in a first time. If you encounter any
problems, ask to the lists (PicBasic, Jallist or Piclist).
Perhaps you can start with PBP. It will be easy to start but perhaps you
will be quickly limited....
If you want something more "function like" I would take a look at JAL. This
is a Pascal like language dedicated to the Pics.
The most common pics are supported and you will find a nice communitee with
a very active list.
A programmer (very cheap) and several small kits are available on Wouter
(JAL conceptor) web site. The language is free and the tools too.
Lot of developments have been already done by using the 16F877 so...

You know, I can use the MFCs without having to know how the x86 assembler
because my PC is sufficient to perform the tasks I want to execute and the
complexity has been abstracted.
It's the same thing with the pic. If a high language is sufficient, why
spend a lot of time with something which could not be of interest.
If you encounter time/memory pbs, you will need to take a look at the
assembly and if it's the case, we will help you.

Regards,
Nicolas

____________________________________________

2004\11\11@171140 by olin_piclist

face picon face
crayola@optonline.net wrote:
> I don’t have any problem learning assembly.. I just don’t have any
> resources
> to do so.

Sure you do.  Download MPLAB from Microchip for free.  It is a complete
suite of development tools to write PIC firmware in assembler.  As for the
hardware, I think the best alternative for a newbie hobbyist is the
Microchip ICD2 in circuit debugger.  That's about $200.  Other than that all
you need is a 5V power supply, an 18F252, and a few jellybean parts to build
up a PIC circuit.  It doesn't take much to hook up a few LEDs to a PIC and
make them do something.

> I have a basic understanding of electronics and theory... I am just
> not familiar with applying it to microcontrollers.

If you understand the electronics and are just missing the PIC specifics,
all you have to do is read the data sheet.  It's all in there.

> Books? Tutorials you can recommend?

There are probably tutorials out there.  Whenver I need to learn a new
language, I find the best source is the manual for that language.  In this
case, the relevant document is "MPASM User's Guide with MPLINK and MPLIB".


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
___________________________________________

2004\11\11@171837 by Eisermann, Phil [Ridg/CO]

flavicon
face
piclist-bounces@mit.edu wrote:
>> Time to learn.  On small microcontrollers you are never that
>> far from the hardware.  You need to understand what it is
>> doing, even if eventually using a high level language.
>> Otherwise, you won't have much chance of fixing problems when
>> something doesn't work right.
>
> I don’t have any problem learning assembly.. I just don’t have any
> resources
> to do so.. Using a higher level language will provide some usable
> results quickly. I do agree with your point however that knowing how
> everything
> works under the covers is essential to solving issues. Perhaps you
> can point out some good books/tutorials on learning assembly that
> start out from the basics and build up? Something with an embedded
> slant would be helpful.
you know, i learned the PIC assembler without any tutorials. I had
a background in programming various HLLs and University EE; I looked at some examples, read the instruction set, away I went. I guess it is
not an approach I would recommend for everyone. But have you browsed
http://www.piclist.com?

>> Stick with MFC apps and Java web pages.
>
> Insults are not needed.. I am not some code monkey.

I don't think that was meant to be an insult. But you really would
be well served learning at least some assembly first, then going to
a HLL if you still want.

I have worked with several co-ops. We use HiTech PICC here, and trying to get them to understand how a microcontroller worked using 'C' was an unmitigated disaster. After many false starts, they can sometimes produce code that sort-of-works. Some learned quicker than others. Some will never learn. Most were at a point
where they barely had digital logic classes, but all had learned
C or C++ at that time. I am not their teacher, nor do I have time
to instruct them in everything they need to know. so I chose the
'C' route, figuring it would be less painful, and "provide some
useable results quickly" sound familiar? *grin*

All would have been better off had I insisted they learn assembly.
And *I* would have been better off because they would have had a
better understanding of the hardware instead of me having to
explain every little detail.

> I have a basic understanding of electronics and theory... I am just
> not familiar with applying it to microcontrollers.

Everyone has a method of learning that works best for them. Only
you know what works best for you. And it depends on your level of
understanding.

>> Do the first few projects in assembler until you feel
>> comfortable with it. Then switch to a high level language is
>> you still want to.

great advice.

> Books? Tutorials you can recommend?

I wish I could. I never read a book on PICs. I got Myke Predko's
book on Microcontrollers for the co-ops :) I looked at it, but
it didn't provide me with any new info. I personally do not like
the way the info was presented, but it does have a lot of good basic
information. he has a website http://www.myke.com.
The datasheet was always more than adequate for me. But again, that
may not be your style, you may want the information presented in a
different format, you probably have a different background, etc. To
each his own.
But I bet you will get plenty of recommendations in a few hours :)

___________________________________________

2004\11\11@172953 by John J. McDonough

flavicon
face
>    and I dont know ANYTHING about assembly language.

<SHAMELESS_PLUG>
http://www.amqrp.org/elmer160/lessons
</SHAMELESS_PLUG>

--McD


____________________________________________

2004\11\11@183858 by olin_piclist

face picon face
Jinx wrote:
> Nobody mention MPLAB or Piclist yet ?

Good idea.  We'll send a message to the list telling everyone how wonderful
it is how to sign up, what address to post a message to...   D'oh, never
mind.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\11@191328 by Lawrence Lile

flavicon
face

>
> 1. Some sort of development language - I am planning on picking
>    up picbasic pro from melabs since it seems to be well supported
>    and I dont know ANYTHING about assembly language. I have also
>    found several books on programming with pic basic to get me started.
>
>    Or should I use C? http://www.rentron.com/C2C.htm
>    Reynolds offers a C2C compiler and getting started course for $60.
>    Its supports a lot less PIC chip #'s however.
>

PICBasic has started a lot of people going, and is very productive since the learning curve is low and a lot of things are canned for you.  It will not generate tight code compared to C, nor will it allow you to do the full suite of PIC capabilities.  Eventually you will bang up against these limits.  Great if you are a hobbyist, don't want to learn a lot of new languages, or need a quick crutch. Few people make a living programming in PICbasic.

If you already know some C, then you have  a leg up in C for PICs, although there are some major differences.  You generally don't just PRINTF whenever you want something on the screen, usually there IS no screen....  Forget about large arrays, complicated pointers, and so on, you ain't got much memory to work with.  Free C compilers exist, but generally if you want one that supports all the PICs you have to pay.

You'll eventually need to know some assembly, can't hardly get away from it.  Most C languages allow you to drop into assembler for a few lines then relax back into the HLL world.  I haven't used more than three lines of assembly in a row in years, others on this list bang out every project in assembly.  Once you have a big kit of parts in assembler, then you can be very productive in it.  You could be a hobbyist for a long time with either Basic or C HLL and a programmer and be blissfully unaware that assembler even exists.  Eventually, that attitude will result in Gotcha's, though. If it is a hobby project, then the stakes are low.


>
> 2. A programmer to program the pic chips - I was thinking about
>    using the melabs serial programmer.
> 3. Some sort of basic development/lab board to get started. I was
>    thinking about buying Compubotics RC40 robot controller which
>    has a PIC 16f877 in it with a bootloader so code can be
>    dumped right from a serial port. Essentially its a mini development
>    environment ready to move servos.
>
MELABS is a great resource.  Check out their proto boards, they are about $15 and save a lot of time laying out basic circuits.  Nice slot for the crystal, decoupling caps, on-off LED, etc. This is, of course, if you want to solder right away.

Get a programmer that supports ICSP, in-circuit-serial-programming, in circuit debugging.  Olimex makes a clone of MCHIP's model, I think Olin has and ICSP unit as well IIRC.

The pre-made board is a good place to start, also consider Microchip's prototype boards, available from their site or from DIgikey and Mouser.  

Eventually, graduate from pre-made boards and build em yourself.


> What do I plan on doing with the PIC? Controlling relays, servos, etc
> based on audio and infared inputs. Basically I want to get into
> animatronics in a big way.
>

Robots!  

{Quote hidden}

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.762 / Virus Database: 510 - Release Date: 9/13/2004


____________________________________________

2004\11\11@191504 by Lawrence Lile

flavicon
face

>
> Books? Tutorials you can recommend?
>

Log onto amazon.com and search for Easy PIC'n, Serial PIC'n, or Myke Predko.



> Thanks,
> Mike
>
>
> ______________________________________________

2004\11\11@192426 by Bob Axtell

face picon face
When I began programming embedded processors, it was the 8031/8051 or the 6805.
I always had no problem buying (or making) a programmer for each one, and always used
the Assembly language.

I then ran across a client who insisted that I write in 'C' for "maintainability". I forgot who made
the compiler then, but I did some 8051 C programming. But the product performance was
sluggish and tired, needing to be doubled or quadrupled in speed to match the same performance
that assembler offered.

When Motorola burned us badly in the early 1990s (no 68HC05 chips were available to be
bought) I was forced to redesign everything in ASM. Microchip was a fledgling company
then, and I was forced to redesign 15 68HC05 designs to PIC16C54 as quickly as possible.
I dropped 'C' for MPASM and have never looked back.

There is NO good reason to use C if you carefully save and document the routines you prove
over time. I have many tested and verified routines for many tasks, saved in a safe place and
backed up. The good thing about PICs are that, except for banking and RETURN, code
written in 1992 will work just fine 12 years later in the latest PIC16.

I don't use a higher-level language, because I already have routines that perform the functions
needed.

The final advantage of ASM is that it is easy for someone to support it, especially if it is written
in Microchip's mnemonics. Higher-level languages just introduce another layer of confusion.

Go with Microchip's MPASM.

--Bob

Eisermann, Phil [Ridg/CO] wrote:

{Quote hidden}

>____________________________________________

2004\11\11@194106 by Victor Faria

picon face
"PicBasic Pro Compiler now supports ALL Microchip PICmicro MCUs!"
This was copied from one of the Melabs  resellers site
Victor
{Original Message removed}

2004\11\11@194106 by Steve Mercer

flavicon
face
Ok, here goes. I am a new PIC user as well and searched long and hard
for a learning development board. The one I found is the EasyPIC2
from MikroElektronika (http://www.mikroelektronika.co.yu). It has everything
you need to get started as well as headers to break out the ports to
breadboard(s). It also has a USB programmer on board.

The folks there are extremely helpful. If a new PIC comes out that is
not currently supported on the board they will update the software
post haste. As an example, I asked for PIC16F88 support and they had
an update out in a day.

As far as a programming language is concerned I tried C/C++ first (As
I know this the best) but found it just did not cross over very well
to the 8 bit microcontroller. I hadn't used Basic in twenty years but
found it easy to pick up again. When I first used basic it was on 8
bit processors and now it works well with a microcontroller.

MikroElektronika has a basic compiler that is relatively cheap and
the demo version allows you to create code up to 2K in size. I still
have not approached that much code yet - you can do a lot in 2K.

The forum is very active and they are open to any suggested feature.
A lot of the current features were instigated by users.

Note that I do not work for MikroElektronika but am a very satisfied user.

Good luck and have fun.


{Quote hidden}

>_____________________________________________

2004\11\11@194540 by Marcel Duchamp

picon face
Something that I don't think has been mentioned yet is that MPLAB comes
with a *built in simulator*.  It has single-step, run-to-breakpoint,
timers, watch windows, etc.

You write code, you run code, you see what code does, you change code, you
run code, etc.

In this way, you can check out the instruction set with tiny, easy to
understand, programs. Plus Microchip ASM examples can be found via Google
and in one evening, you will go from "I don't know assembly" to "Assembly
is cool".  It's as easy to code as it is to say.

When you get a programmer, you will have code already written and ready to
burn. If you can learn C, you can learn assembly.
MD



At 04:24 PM 11/11/04, you wrote:
I don't have any problem learning assembly.. I just don't have any
resources to do so..  

____________________________________________

2004\11\11@210047 by Lee Jones

flavicon
face
>> I don't have any problem learning assembly.. I just don't have
>> any resources to do so.

> Sure you do.  Download MPLAB from Microchip for free.  It is a
> complete suite of development tools to write PIC firmware in
> assembler.

And download the data sheet for the specific PIC device that
you plan on using.  Details on the instruction set, interrupt
structure (if any), and memory model are in the data sheet.
You _need_ this information no matter what language you use.


>> Books? Tutorials you can recommend?

> There are probably tutorials out there.  Whenver I need to learn a
> new language, I find the best source is the manual for that language.
> In this case, the relevant document is "MPASM User's Guide with MPLINK
> and MPLIB".  (33014g.pdf)

I agree with this with one extension.  How the assembler and linker
work is documented inthe MPASM User's Guide.  The instruction set is
only explained and defined in the PIC device data sheet.  You need
_both_ the MPASM User's Guide and the data sheet.

                                               Lee Jones

____________________________________________

2004\11\12@005813 by Byron A Jeff

face picon face
On Thu, Nov 11, 2004 at 02:42:30PM -0500, .....crayolaKILLspamspam.....optonline.net wrote:

I decided to throw a couple of thoughts into this fray...

1. I agree with Olin almost 100 percent. Learn assembly as it's the linqua
franca that most PIC people speak. Also spend some time learning the hardware
infrastructure of the PIC and the associated electronics.

2. One variation is the programming environment. As a pro sometimes Olin
misses the disconnect of purchasing a $200 programmer to program $3 chips.
While to a pro it's pretty much chump change, it's a significant investment
for a hobbyist. Other options include the olimex ICD2 clone at half that
price:

http://www.sparkfun.com/shop/index.php?shop=1&cat=3

Wouter's WISP628

http://www.voti.nl/wisp628

And I have no clue why Olin didn't plug his own EasyProg:

http://www.embedinc.com/EasyProg

My own Trivial programmers are the cheapest of the bunch, but does require
some TLC to get stable:

http://www.finitesite.com/d3jsys

3. Whichever family you choose make sure to get a copy of the Reference
Manual for it. Hundreds of pages of descriptions and code examples on every
aspect of the part. This coupled with the datasheet are foundations for use.

4. When searching out tutorial material, take some care to understand the
difference between using real hardware onchip and simulation. A lot of
tutorials are geared around the 16F84, which as I argue here all the time is
virtually obsolete. Newer parts carry tons of onboard stuff like PWM, ADC,
comparators, USARTS and the like. But since the 16F84 has virtually none of
these, all the tutorials talk about how to simulate these activities in
software. The good thing about hardware is that it's pretty much setup and
forget it. You'll need PWM for your animatronics. But if you read a tutorial
for an older part, you may get the impression that you'd have to manage PWM
by hand. But the current parts all have hardware PWM that you can setup and
forget and it'll just run.

Just some thoughts,

BAJ
____________________________________________

2004\11\12@011007 by Michael Cunningham

flavicon
face
Thanks for all the info everyone.. Since I am doing this
as a hobby and not a career.. I believe I am going to do
the following..

1. Pick up picbasic pro
2. Get mplab's assembler and all the docs..
3. Buy the melabs serial programmer and the rc40 controller as I planned..
4. Buy a few pics and read the data sheets..

This way I can play and get some basic things going.. blinking leds, moving
servos, etc.. without having to learn a whole new language upfront..

Over time I will definitly make it a point to begin to learn assembly as
necessary to get things accomplished. I can definitly see the benefits
and understand how knowing the hardware is essential even with a HHL.
I just put in an order for a couple books from square-1 "Easy Microcontrol'n
"
and "Microcontrol'n Apps". Those combned with the picbasic books and "PIC in
Practice"
book I have should be enough to get me going.

Thanks again,
Mike



____________________________________________

2004\11\12@025613 by Wouter van Ooijen

face picon face
> <SHAMELESS_PLUG>
> http://www.amqrp.org/elmer160/lessons
> </SHAMELESS_PLUG>

Oh no, not the 16F84(A) again :(

I can understand that a dsPIC in a TQPF package is not the best starting
point for a newbie, but you don't learn your child cycling on one of
those old very-large-frontwheel bikes, do you? A 16F630 is about as
simple as a 16F84 (and no Xtal needed), and is *much* cheaper (a newbie
will likely fry a few chips).

Wouter van Ooijen

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


____________________________________________

2004\11\12@025613 by Wouter van Ooijen

face picon face
> 1. I agree with Olin almost 100 percent. Learn assembly

Just to voice the opposition: I think one can do wonderfull things with
PICs and other microcontrollers without knowning the assembly language
at all. One might even use a library-right language like some Basics and
know little about the actual PIC hardware. It is all a matter of
applying the right tools for the right job. So:

1. If the job at hand is getting some results with minimal effort, go
for a basic stamp and forget that it's a PIC.

2. For better results, at the cost of more effort, go for a bare PIC,
learn is hardware, and use a HLL to tame the beast. This is the big
step: use the PIC hardware directly, instead of using some library
abstraction of it. This can take a *lot* of time, depending on the type
of PIC you use. Like Eur (Jallist) says: print the datasheet, read the
datasheet, sleep next to it, *be* the datasheet.

3. Next step is knowing the PIC assembly language, so you can get the
most out of it, while still using HLL.

4. As a last step you might need to rewrite some (often small) parts of
your code to get the very most out of the chip.

5. Doing a full project in assembler is a nice exercise, but IMHO it is
seldom justified when you weight the effort against the result.

Wouter van Ooijen

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


____________________________________________

2004\11\12@045602 by William Chops Westfield

face picon face

On Nov 11, 2004, at 11:54 PM, Wouter van Ooijen wrote:

>> 1. I agree with Olin almost 100 percent. Learn assembly
>
> Just to voice the opposition: I think one can do wonderfull things with
> PICs and other microcontrollers without knowning the assembly language
> at all.

I think you need at least a bit of "read only" knowledge of PICs just
to read the datasheets intelligently, if nothing else.  It's not clear
that you have to be well versed in designing, writing, and debugging
assembly language, and it's certainly possible to hop to a HL Language
without ever attaining "expertise" in assembler.  But you will need
some knowledge of assembler (perhaps not necessarily PIC assembler)
to understand the datasheets.

BillW

____________________________________________

2004\11\12@052428 by Wouter van Ooijen

face picon face
> But you will need
> some knowledge of assembler (perhaps not necessarily PIC assembler)
> to understand the datasheets.

I disagree. I have seen good programs in HLL made by people who read
only the peripheral parts of the datasheets. And I have done so myself
for other chips. For most peripherals it is just reading and writing
certain addresses. That can be done any suitable HLL without asm
knowledge. Don't get me wrong, I don't say asm knowledge hurts, I just
day that it is not required.

Wouter van Ooijen

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


____________________________________________

2004\11\12@053757 by Mcgee, Mark

flavicon
face
I just started with PICs.  And I can heartily agree with this recommendation
for a good place to start leaning PIC and assembler, despite the plug from the
author! This was my first port of call, and I found it very, very useful.  I
haven't really looked at anything else other than datasheets and the mid range
reference manual from Microchip's web site.

I use the Free download MPLAB with the in-build MPASM assembler.  I find the
simulator absolutely invaluable.  You really ought to look at this stuff
first!

> <SHAMELESS_PLUG>
> http://www.amqrp.org/elmer160/lessons
> </SHAMELESS_PLUG>

I am a C++ developer by trade, but decided on assembler for my PIC projects.
It's taken a couple of weeks on the train, one hour per day, and I feel I know
all 35 instructions of the PIC16f628a that I'm using.

Understanding how these things work at a low level may well help with your
high level programming in other areas too.  Can't hurt anyway.

I have to admit, my programming career started when I was at junior school
when I learned Z80, then 6510 assembler, so it may have helped me pick up PIC
stuff....

Cheers,
Mark


==============================================================================
This message is for the sole use of the intended recipient. If you received
this message in error please delete it and notify us. If this message was
misdirected, CSFB does not waive any confidentiality or privilege. CSFB
retains and monitors electronic communications sent through its network.
Instructions transmitted over this system are not binding on CSFB until they
are confirmed by us. Message transmission is not guaranteed to be secure.
==============================================================================

____________________________________________

2004\11\12@054939 by hael Rigby-Jones

picon face


{Quote hidden}

Whilst it's not required to write a non-critical program, IMHO it is
required for:

Minimising execution time
Minimising code space
Low level debugging, including tracking compiler faults.

Knowledge of assembly allows more effective use of a HHL as well, nudging an
optimiser in the right direction or inline asm.

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.
=======================================================================
____________________________________________

2004\11\12@055858 by Jan-Erik Soderholm

face picon face
Lee Jones wrote :

> And download the data sheet for the specific PIC device that
> you plan on using.  Details on the instruction set, interrupt
> structure (if any), and memory model are in the data sheet.
> You _need_ this information no matter what language you use.

Agree. Just a small point...

I've found the intruction set descriptions to be generaly better
in the two "Reference Manuals".

The "Complete Mid-Range Reference Manual" :
http://ww1.microchip.com/downloads/en/DeviceDoc/33023a.pdf

Or only the instruction set chapter (PIC12F/16F) :
http://ww1.microchip.com/downloads/en/DeviceDoc/31029a.pdf

The "Complete PIC18C Reference Manual" :
http://ww1.microchip.com/downloads/en/DeviceDoc/39500a.pdf

Or only the instruction set chapter (PIC18F) :
http://ww1.microchip.com/downloads/en/DeviceDoc/39531.pdf


Regards,
Jan-Erik.
____________________________________________

2004\11\12@062919 by Wouter van Ooijen

face picon face
> Whilst it's not required to write a non-critical program, IMHO it is
> required for:
>
> Minimising code space

Indeed, but how often is this realy justified? For a hobby one-off it
makes little sense to optimise for the very smallest chip that will fit.
For a commercial project, except for very large series, the pressure to
minimise development cost will be even higher.

> Minimising execution time

On this I agree, but this is not often needed. If you need it, you need
it badly, and you will have to learn assembler. And you will probably
have to study it for a few years, maybe Scott can give you some lectures
about sequeezing the last instruction from an algorithm.

But is this realy cost-effective, compared to swithing to an 18F, dsPIC,
or maybe to an ARM?

> Low level debugging, including tracking compiler faults.

This is true to some extent, although I have debugged compiler bugs in
various architectures I was not (initially) familiar with. In most cases
one expert in this field will be sufficient for a department, hobby
group, or mailing list.

Wouter van Ooijen

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


____________________________________________

2004\11\12@071327 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Wouter van Ooijen" <@spam@wouterKILLspamspamvoti.nl>
Subject: RE: [PIC:] Getting started with PIC's


> Oh no, not the 16F84(A) again :(

For someone who has been in this business since Turing,  it's pretty simple
to just read the datasheet and deal with the peripheral.  But for people who
are struggling to get the concept of a register, all that stuff is
intimidating.  Heck, on most of the parts every single pin has three or four
uses.

While we are using the 84 as the foundation, we touch on a number of other
parts, and don't recommend the 84 for a new project.  As we all know, it has
half the features for twice the price.  But you don't have to remember to
turn off the A/D converter (after first explaining what the A/D converter
is, how the pin is shared between a voltage reference, A/D converter,
comparator and digital I/O),  you don't have the GPR values disappearing on
you when you go to initialize a port, and on and on and on.

Plus, for a hobbyist, almost any project he picks up will be for the 84.

Yes, we cover porting those 84 projects to the 628 where feasible (some of
that code on the net is truly horrid and even a simple port isn't simple),
and I plan soon to update it to include the 88, which really is a pretty
cool chip.  We also talk about how in-circuit programming frees you from the
limitation of your programming socket.

So yes, it is the 84(A), and I still think it's the right choice.  But I
don't plan on buying any more of them <g>

--McD


____________________________________________

2004\11\12@073324 by Byron A Jeff

face picon face
On Fri, Nov 12, 2004 at 08:54:10AM +0100, Wouter van Ooijen wrote:
> > 1. I agree with Olin almost 100 percent. Learn assembly
>
> Just to voice the opposition:

All voices are welcome... Including the opposition. ;-)

{Quote hidden}

Wouter,

I do see where you're coming from. Some points to your points.

1. The only three problems with the Basic stamp are the fact that it's
expensive, slow, and you're limited to their abstractions. There are
certainly enough BS enthusiasts and resources to function effectively. But at
a per piece cost that's easily 10 times the cost of a bare PIC, unless you're
really doing a one off, it isn't cost effective.

2. I'd swap your points 2 and 3 above. As I stated in my first post PIC
assembly isn't about the performance aspect, it's about the community and
communications aspect of the large PIC community. Most everyone from Microchip
on down "talks" in PIC assembly. It's the linqua franca of communicating PIC
concepts, just like English is the communications mechanism on this list,
though it's not many list members first language. Consider that the code in
virtually every applications note and every example in the Midrange manual
is written in PIC assembly as are a vast many projects out there. So one needs
to know PIC assembly to tap into that vast knowledge library.

The second aspect of it is that even while you're learning the HLL you need
to be able to translate back and forth. If someone comes on the list and asks
"How do I do...?" the answer (generally a multitude of them) come back in PIC
assembly. But the same question "How do I do... in {PBP,C,JAL,XCSB,...}" will
get a much more muted response because each of those communities are more
fragmented.

A perfect example of this is when Vasilie (sp) translated my DS1620 access
routines that I wrote in PIC assembly into a JAL library. Without exposure
to both, it would have been difficult.

The final point of this is that it isn't that PIC assembly is so terribly
difficult to muster. The limited instruction set and addressing modes makes
it a pretty easy read except for the handful of PIC quirks like test and skip
instructions, jump tables, and banked addressing.

3. Finally I am in agreement that lots can be done with HLLs. The abstractive
layers help much of the time in both generating and maintaining projects.

All I'm saying is that you get so much leverage in being conversant in PIC
assembly, that it's near manditory to have at least a conversational
understanding of it no matter which language one ultimately picks to develop
with.

P.S. JAL is cool beans. But of course you already knew that.

BAJ
____________________________________________

2004\11\12@075743 by Wouter van Ooijen

face picon face
> Yes, we cover porting those 84 projects to the 628 where
> feasible

Why the 628? This chip is also obsoleted (by the 628A, and maybe the
648A), and is indeed more complex than an F84. But the F630 is almost as
simple as an F84 as far as peripherals are concerned, and simpler for
the extrenal hardware (no xtal needed), and *much* cheaper.

Wouter van Ooijen

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


____________________________________________

2004\11\12@083526 by Wouter van Ooijen

face picon face
> 1. The only three problems with the Basic stamp are the fact that it's
> expensive, slow, and you're limited to their abstractions. There are
> certainly enough BS enthusiasts and resources to function
> effectively. But at
> a per piece cost that's easily 10 times the cost of a bare
> PIC, unless you're
> really doing a one off, it isn't cost effective.

That depends a lot of the project at hand, the deadline, the performance
needed, and your hourly rate. I agree that the BS price and performance
sucks comparted to a bare PIC, but the PIC learning curve sucks (even
when using Jal :) compared to a BS.

> assembly isn't about the performance aspect, it's about the
> community and communications aspect of the large PIC community.

I disagree to the extent that you don't need to learn assembly to
communicate, nor to read the manual. It helps, but it is not mandatory.

> The final point of this is that it isn't that PIC assembly
> so terribly
> difficult to muster. The limited instruction set and
> addressing modes makes
> it a pretty easy read except for the handful of PIC quirks
> like test and skip
> instructions, jump tables, and banked addressing.

It's releatively easy to learn, but only when compared to other assembly
languages. It is still dificulty compared to a HLL. And (although this
is mostly beside the point you were making) PIC asm might be easy to
learn (to know what the instrcutions mean), it is still a major PITA to
*use* (even more so than some asm languages that are more difficult to
learn).

Wouter van Ooijen

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


____________________________________________

2004\11\12@083530 by Byron A Jeff

face picon face
I thought at some point we have agreed to disagree on this topic. But since
the can is open, I'd like to talk about it.


On Fri, Nov 12, 2004 at 07:13:11AM -0500, John J. McDonough wrote:
> {Original Message removed}

2004\11\12@084148 by Byron A Jeff

face picon face
On Fri, Nov 12, 2004 at 10:53:55AM -0000, Michael Rigby-Jones wrote:
{Quote hidden}

For the average user, none of these are critical points.

1. Most compilers generate code that's good enough from a execution
perspective. Take a look back at the optimizations that Sergio has done on
XCSB for example.

2. If you overflow code space, simply get a bigger chip.

3. Compilers are never broken! ;-) But even if they are then debugging that
is usually outside of the scope of a novice anyway.

Assembly has few few fundamental technical advantages. If that were inherently
true, then many systems at all levels would be programmed in them.

For the PIC it's a communications and community issue. PIC assmebly is the
language everyone speaks, and everyone reads. So if you going to fully
participate, you need to be able to speak and read it. Simple as that.

Wouter is definitly on point about everything else. It's easier, faster, and
more productive to program in an HLL. But virtually all of us will drop down
to PIC assembly to discuss issues.


>
> Knowledge of assembly allows more effective use of a HHL as well, nudging an
> optimiser in the right direction or inline asm.

Wouter said that in his points.

BAJ
____________________________________________

2004\11\12@085948 by hael Rigby-Jones

picon face


>-----Original Message-----
>From: spamBeGonepiclist-bouncesspamBeGonespammit.edu [TakeThisOuTpiclist-bouncesEraseMEspamspam_OUTmit.edu]
>On Behalf Of Byron A Jeff
>Sent: 12 November 2004 13:42
>To: Microcontroller discussion list - Public.
>Subject: Re: [PIC:] Getting started with PIC's
>
>
>1. Most compilers generate code that's good enough from a execution
>perspective. Take a look back at the optimizations that Sergio
>has done on XCSB for example.
>

I agree, XCSB does seem very good.  However there are things you either
cannot do in a HLL or that are very clumsy, typicaly optimised bit twiddling
operations a la Scott Dattalo.

>2. If you overflow code space, simply get a bigger chip.
>

Not always possible!  Especialy with the small, low pin count devices that
are so popular.

>3. Compilers are never broken! ;-) But even if they are then
>debugging that is usually outside of the scope of a novice anyway.
>

Not if they knew ASM and could read the list files!  In fact that's how I
learnt assembly on the PIC16 originaly, looking through the compiler
listings and essentialy learning from the very experienced people that wrote
the compiler.

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.
=======================================================================
____________________________________________

2004\11\12@094206 by Lawrence Lile

flavicon
face
> It's taken a couple of weeks on the train, one hour per day, and I feel I
> know
> all 35 instructions of the PIC16f628a that I'm using.

That's right, only 35 instructions.  That is really not a lot of info to learn.  Each one does just the simplest task, and what is more, many of them don't get much use.  I hardly ever use NOP, COMF or SWAPF, for instance.  

The learning curve on Assembler seems intimidating, but keep the entire scope in mind, it is a collection of 35 of the most basic and trivial math operations you can possibly have.  They can be broken down into three or four groups of similar functions (BCF, BSF, BTFSC, BTSS for instance all operate on a bit) It is really not as tough as people make out.  

-- Lawrence Lile, P.E.
Electrical and Electronic Solutions
Project Solutions Companies
http://www.projsolco.com


> {Original Message removed}

2004\11\12@101420 by Wouter van Ooijen

face picon face
> That's right, only 35 instructions.  That is really not a lot
> of info to learn.  Each one does just the simplest task, and
> what is more, many of them don't get much use.  I hardly ever
> use NOP, COMF or SWAPF, for instance.

never done an interrupt handler :) ?

> The learning curve on Assembler seems intimidating, but keep
> the entire scope in mind, it is a collection of 35 of the
> most basic and trivial math operations you can possibly have.
>  They can be broken down into three or four groups of similar
> functions (BCF, BSF, BTFSC, BTSS for instance all operate on
> a bit) It is really not as tough as people make out.  

But the real trouble is not understanding the individual instructions,
it is using them to accomplish something usefull!

The alphabet contains only 26 letters (okay, a few more in some weird
languages) yet I can understand, much less speak, most of the languages
that use these letters.

Wouter van Ooijen

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


____________________________________________

2004\11\12@101941 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Byron A Jeff" <RemoveMEbyronspamTakeThisOuTcc.gatech.edu>
Subject: Re: [PIC:] Getting started with PIC's


> And this is where I believe the real problem lay and why we have to be
> really aggressive about dissuading new 84 designs, or even implementing
> existing 84 projects. But there's a documentation vacuum that's real
> difficult to fill. My wrap up is coming...

I tend to agree with you here, but I'm not so sure that the answer is simply
more dox.

> Of course I'd throw in my obligatory bootloader plug, which completely
obviates
> the need for a "programmer" in any sense...

Jawel, the bootloader is another of those things I'm not the biggest fan of.
ICSP is pretty darned simple.

> The 16F84 is fine for the 1-14 chapters that you have, which BTW I really
> appreciate and can point people to.

Thank you. Glad you took the time to take a peek.  Unfortunately, a LOT also
happens on the QRP-L reflector, whose archives aren't all that easy to
search.

> But my concern is chapters 15-30, which are of course unwritten.

Well, almost.  Lesson 15 is in the hands of the web site maintainer, and I
have a draft of 16.

> Onboard periperals are important because they give a set and forget
abstraction
> interface that greatly simplifies any work beyond the novice level. And
frankly
> the 16F84 simply cannot deliver on those issues. It becomes a detailed
> software problem.

I think you are right.  I don't plan to do a lot more lessons in this
particular course.  We will cover using an LCD, using a DDS, maybe a
frequency counter, and probably tie some of these things together with a
keyer project.  Admittedly, talking to a DDS involves a little bit-banging,
but I certainly don't advocate successive approximation A/D with a resistor
network when half the price buys you a 7 channel A/D.

I think the more involved topics cry out for another part.  I'm not so sure
what part that is.  As you point out, there is enormous inertia to stay with
the part you first learned.  Personally, I think being parochial about any
part is not the best plan, especially where you have a wide range of parts
with a common software model and different selections of peripherals.  But
we have gotten a lot of people over the inertia of grokking a little
assembler in the first place.  While I doubt I can be 100% successful in
getting everyone to explore more possibilities, I think we can make
significant headway.

I am seeing evidence that I'm getting through.  Different students have
begun projects with the 628, 818, 88 and 877, so the barrier isn't absolute.
But I bet for every student playing with another chip, there are ten trying
to put too much stuff into an 84.

> So John, when folks like Wouter and I go "Sheesh, not the 16F84 AGAIN!"
we're
> looking at the late beginner/intermediate aspects of using the parts, the
> proverbial chapters 15-30 of your tutorial.

Yes, like I said, I won't be buying any more 84's.  But I viewed the
complexity of even the 628 as too much for the students I have.  My
interaction with them has convinced me I was right.  I have to admit, I am
not confident I can convince them that the huge range of chips offers
features they may want.  The heavy lifting there, though, is for Elmer 161.
Who knows, maybe we can come up with a "son of PIC-EL" with a dsPIC or
something on it.  I think for this particular audience, that offers some
interesting possibilities.  But even a part like the 16F88 has some really
cool stuff.

By the way, the response has been amazing. When we first talked about doing
the kit to go with the course, I was concerned that we wouldn't be able to
move the roughly 100 of the things needed to break even.  After all, this is
a pretty small niche.  I got more concerned as the PIC-EL design got more
complex and pushed the price point up.  Well, we finally cut the kits off
after 700 (this is, after all, a club project and the volunteers are fried),
and there are plenty of folks looking for more, and a fair number of
students just hand wiring the experiments.  There is a lot of hunger for
this information.

--McD


____________________________________________

2004\11\12@104516 by Peter Johansson

flavicon
face
Byron A Jeff writes:

> 4. When searching out tutorial material, take some care to understand the
> difference between using real hardware onchip and simulation. A lot of
> tutorials are geared around the 16F84, which as I argue here all the time is
> virtually obsolete. Newer parts carry tons of onboard stuff like PWM, ADC,
> comparators, USARTS and the like. But since the 16F84 has virtually none of
> these, all the tutorials talk about how to simulate these activities in
> software. The good thing about hardware is that it's pretty much setup and
> forget it. You'll need PWM for your animatronics. But if you read a tutorial
> for an older part, you may get the impression that you'd have to manage PWM
> by hand. But the current parts all have hardware PWM that you can setup and
> forget and it'll just run.

Well said.  I was in the OPs position about two months ago when I
decided to get into microcontrollers.  I did the requisite googling,
and from the amount of information about the 16F84, one would get the
impression that this is the chip to use by default.  This was very
true at one time, but hasn't been the case for several years now.

Obviously, if everyone had infinite amounts of free time, all of these
websites would be updated to include the newer chips.  But my
experience is that EE people tend to be worse than most when it comes
to keeping their web pages updated.  Likely because they are hard at
work doing far more interesting things in their lab.

It is going to take a fair bit of time before the old 16F84 pages
disappear, are updated, or the number of updated 16F and 18F pages
start making it to the top of google searches.  This is unfortunate
because many newbies are going to continue to be confused.  They are
going to go to Jameco or DIgikey and see the 16F84s for $3-$4, and
then find the 628s, 630s, 648s, etc. for less than half the price with
lots more features and then start scratching their heads...

To *this* newbie, it seems that microchip is getting very competitive
in the pricing of it's dsPIC30 chips, which upon initial investigation
seem to be at about the same price point as the closest PIC18 chip in
single unit quantities.  To a new hobbyist, there is not much
difference between a $2 chip (16F) and a $5 chip (dsPIC30) when you
are only going to be buying a few of them.  It would seem to make
sense, then, that any new tutorials be based on the dsPIC30 line.
While the dsPIC30 line is **far** more complex than the venerable old
16F84, I'd be willing to bet that it is only marginally more difficult
to get it to flash an LED.

But going back to the OP directly: you *definitely* want to start with
assembly.  Heck, there are only 35 instructions to learn for the 16F
series!  You'll spend *far* more time learning the IO and all the
crazy banking, paging, and interrupt schemes than you will the 35
opcodes.  And the reality is that *that* is the important stuff you
really need to know about when programming in a higher level language
anyways.


-p.
____________________________________________

2004\11\12@105959 by Herbert Graf

flavicon
face
On Fri, 2004-11-12 at 02:54, Wouter van Ooijen wrote:
> > 1. I agree with Olin almost 100 percent. Learn assembly
>
> Just to voice the opposition: I think one can do wonderfull things with
> PICs and other microcontrollers without knowning the assembly language
> at all.

Very true, if you're VERY lucky. There hasn't been a compiler (be it
PIC, PC, HDL, etc.) that I haven't found a bug in. And without knowing
assembly it simply isn't possible to debug a compiler bug yourself.
Which means your at the mercy of others. Call me unreasonable but I
don't like having to rely on others to solve my problems.

> One might even use a library-right language like some Basics and
> know little about the actual PIC hardware. It is all a matter of
> applying the right tools for the right job. So:
>
> 1. If the job at hand is getting some results with minimal effort, go
> for a basic stamp and forget that it's a PIC.

Absolutely. In fact, if someone isn't interesting in learning PIC
assembly I'd ONLY recommend this route.

{Quote hidden}

I don't think anyone is suggesting one has to do the WHOLE project in
assembly, only that knowing assembly is a requirement for doing ANY
project in my mind.

Most of my work these days is done in C on the PIC, but I certainly
would NOT recommend someone start with C, it hides WAY too much (even if
you don't use the libraries) and God help you if you hit a compiler bug.

As a BARE minimum I would suggest start with MPLAB and assembly, get a
LED to blink, and get the UART to work (with interrupts). At THAT point
move to an HLL, because getting a LED to blink and getting the UART to
work with interrupts will expose you to most of what you will need on
the "knowing assembly" front. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

____________________________________________

2004\11\12@111454 by Herbert Graf

flavicon
face
On Fri, 2004-11-12 at 08:41, Byron A Jeff wrote:
> 3. Compilers are never broken! ;-) But even if they are then debugging that
> is usually outside of the scope of a novice anyway.

Depends on your definition of "novice". Many of the recent "novices" on
the piclist have been novices only to the PIC, but had substantial
experience in other domains. Anyone who's been using HLLs for a while is
VERY familiar with debugging compiler faults, so to handicap them on the
PIC side is unreasonable IMHO.

> For the PIC it's a communications and community issue. PIC assmebly is the
> language everyone speaks, and everyone reads. So if you going to fully
> participate, you need to be able to speak and read it. Simple as that.

Very true. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

____________________________________________

2004\11\12@111748 by Wouter van Ooijen

face picon face
> Yes, like I said, I won't be buying any more 84's.  But I viewed the
> complexity of even the 628 as too much for the students I have.

Check the 16F630.

BTW I just did a class for Informatics students (little or no HW
background, no asm background, but some Java and C programming
experience). In 7 lessons of 3 hours each they learned MPLAB, PIC
(14-bit) assembly, some 16F688 peripherals, display multiplexing, etc.
For hardware I used a clone of the PICkit, with more peripherals. If you
can read Dutch you could check http://www.voti.nl/hvu/2TPRJ5/index.html.
Some end tasks:
- play music, compressed format for notes
- test all aspects of the board, including modulated IR send/receive
- use the 10-pin connector to connect to a character LCD

Wouter van Ooijen

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



____________________________________________

2004\11\12@112553 by William Chops Westfield

face picon face
On Nov 12, 2004, at 6:37 AM, Lawrence Lile wrote:

>> It's taken a couple of weeks on the train, one hour per day, and I
>> feel I
>> know all 35 instructions of the PIC16f628a that I'm using.
>>
It's not obvious to me that if you've never learned an assembly language
before, you can pick up enough PIC assembler just from reading the data
sheets.  There's an "assembler hump" that you have to get over to
understand
the basic concepts of machine language/assembler, and any one
architecture's
data sheets probably can't give it to you...

OTOH, if you already took and passed some schools class in assembler,
and
have learned at least one additional assembly language from a datasheet,
you probably don't need to study the PIC assembler much at all...

BillW

____________________________________________

2004\11\12@135414 by Eisermann, Phil [Ridg/CO]

flavicon
face
piclist-bounces@mit.edu wrote:
> There is NO good reason to use C if you carefully save and document
> the routines you prove
> over time.

I have to disagree with this. Bear in mind, I'm not advocating 'C'
over ASM at all. I was in fact pointing out that IMO it is
preferable for someone getting into micros to learn assembly
first.

These sorts of discussions always turn into a mini (semi
religious) war. Fortunately the list members are intelligent
and civilized to each other. As the discussion on this topic
already showed, there is considerable disagreement, but I believe
most or all discussions agreed that learning assembly is at
least a good thing, and most (myself included) consider it
essential. Others argue that assembly is the only way, and
any HLL should be scrapped.

IMHO, the use of HLL's has made me more productive. I can
code what I call 'non-critical' projects much faster in 'C'
than in assembly. By non-critical I mean there's no need to
squeeze out every cycle or ROM, not speed critical, etc.

I've done commercial projects in assembly and 'C' I tend
to use whichever happens to be more suitable for the task.
My last couple of projects were all done in 'C', worked
as designed and intended, and were completed much faster
than *I* could have been done in assembler. Other people
such as yourself have a large collection of software
routines that maybe they can do it just as fast in assembler.
One current project I'm writing in assembler because I need
the speed, and I don't feel like fighting the compiler to get
it.

I know that I won't change your mind, and that wasn't the
intent. The person who started this thread was asking about
HLL's, and I feel there are times they can be appropriate.
They are a tool like any other.

____________________________________________

2004\11\12@135811 by Gaston Gagnon

face
flavicon
face
Hi Michael,

Michael Cunningham wrote:
{Quote hidden}

As your interested in Animatronix and you may be impatient to get these
servos going, try this application, once you have your programmer, of
course :) Twelve  servos in parallel controlled from a serial port of
your PC. And it works great.

http://www.havingasoftware.nl/robots/servo/servo.htm

With modifications the program could be converted for other PIC models
but as you are not up to speed yet with PIC programming I suggest that
you use a PIC16F84 as the application calls for.

This application is also great on the pedagogical aspect for assembly
and state machine.
Think of it, driving 12 servos simultaneously while receiving commands
at 38400 baud with a software UART! What an achievement. Amazing.

Have fun.
Gaston

____________________________________________

2004\11\12@135853 by Wouter van Ooijen

face picon face
> Call me unreasonable but I
> don't like having to rely on others to solve my problems.

But you are at the mercy of Microchip! And of the guy who wrote the code
for your programmer. And we are all at the mercy of Big Bill.

Wouter van Ooijen

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


____________________________________________

2004\11\12@140741 by Bob Axtell

face picon face
I'm not locked in concrete. MPASM has worked well for me.
Sounds like you have it worked out.

I'll tell you a secret, though... I solve VERY complex algorithms
by first doing them in Free Pascal (Win32) or Turbo Pascal 5.5 (DOS)
then converting them into MPASM... <nod><nod><wink wink>

--Bob


Eisermann, Phil [Ridg/CO] wrote:

{Quote hidden}

>_____________________________________________

2004\11\12@143559 by Eisermann, Phil [Ridg/CO]

flavicon
face
piclist-bounces@mit.edu wrote:
> I'll tell you a secret, though... I solve VERY complex algorithms
> by first doing them in Free Pascal (Win32) or Turbo Pascal 5.5 (DOS)
> then converting them into MPASM... <nod><nod><wink wink>

hehe, I've done the same, though using gcc & M$ Visual C. Then
I persuaded the boss to buy a compiler for the PIC; and I
found that in almost all cases what the compiler produced was
pretty good. why do the work twice if you don't have to? But I
still consider assembly an essential tool/skill of the trade.
____________________________________________

2004\11\12@143939 by Herbert Graf

flavicon
face
On Fri, 2004-11-12 at 13:56, Wouter van Ooijen wrote:
> > Call me unreasonable but I
> > don't like having to rely on others to solve my problems.
>
> But you are at the mercy of Microchip!

Yes, but I don't really have a choice in that one.

> And of the guy who wrote the code
> for your programmer.

True, but that's easy to get around since I can try a different
programmer.

> And we are all at the mercy of Big Bill.

Not really, more and more of my stuff is with Linux these days, I mostly
use my windows machine as xterms to my other machines, and as VPN to
work. TTYL

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

____________________________________________

2004\11\12@144613 by Wouter van Ooijen

face picon face
> > There is NO good reason to use C if you carefully save and document
> > the routines you prove over time.

One good reason: It is very difficult (I would say inpossible) in asm
libraries to use the few RAM locations in a PIC efficiently. Most asm
porograms simply assign a unique location to what is in effect a local
variable. A good HLL compiler will use a static-stack approach which
re-uses the RAM locations. Been there, tried that, wrote a compiler
instead.

Wouter van Ooijen

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


____________________________________________

2004\11\12@150229 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> One good reason: It is very difficult (I would say inpossible) in asm
> libraries to use the few RAM locations in a PIC efficiently. Most asm
> porograms simply assign a unique location to what is in effect a local
> variable. A good HLL compiler will use a static-stack approach which
> re-uses the RAM locations. Been there, tried that, wrote a compiler
> instead.

I get around this in a different way that in my opinion works very well.
The vast majority of time, the only variables defined in the code are for
persistant state.  I define a set of "general registers" in global (non
banked) RAM when avaialable.  By default, subroutine are expected to
preserve these except when they are explicitly returning values in them.  On
subroutine entry, the general registers that the subroutine will trash are
pushed onto a software stack, and then restored right before returning.
These general registers are then used as local scratch inside the
subroutine, which is useful since they are fast and usually bank-independent
to access.

All this is made very easy by the the GLBSUB (GLoBal SUBroutine) and
LEAVEREST (LEAVE and RESTore) macros in STD.INS.ASPIC at
http://www.embedinc.com/pic.  The registers to save are listed once on the
GLBSUB line, and the same set is automatically restored by LEAVEREST.  I
have used this scheme over many PIC projects, and found it to be very handy
and efficient of RAM.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\12@154702 by Byron A Jeff

face picon face
On Fri, Nov 12, 2004 at 02:04:01PM -0000, Michael Rigby-Jones wrote:
>
>
> >-----Original Message-----
> >From: EraseMEpiclist-bouncesspammit.edu [RemoveMEpiclist-bouncesEraseMEspamEraseMEmit.edu]
> >On Behalf Of Byron A Jeff
> >Sent: 12 November 2004 13:42
> >To: Microcontroller discussion list - Public.
> >Subject: Re: [PIC:] Getting started with PIC's
> >
> >
> >1. Most compilers generate code that's good enough from a execution
> >perspective. Take a look back at the optimizations that Sergio
> >has done on XCSB for example.
> >
>
> I agree, XCSB does seem very good.  However there are things you either
> cannot do in a HLL or that are very clumsy, typicaly optimised bit twiddling
> operations a la Scott Dattalo.

My thought is that a good embedded HLL will have both optimized bit twiddling
and a way to have inline or included assembly if necessary.

>
> >2. If you overflow code space, simply get a bigger chip.
> >
>
> Not always possible!  Especialy with the small, low pin count devices that
> are so popular.

You can't have it all. Remember that I almost always look at it from a
hobby perspective. If you need to save a nickel because you're purchasing
100,000 units, then it isn't subject for discussion. For a hobbyist building
a one off, what difference is there if you pick one sightly larger chip over
another. It's rare that a hobby project requires a 10F part when a 8, 14, 18
or even 28 pin DIP will do just as well.

>
> >3. Compilers are never broken! ;-) But even if they are then
> >debugging that is usually outside of the scope of a novice anyway.
> >
>
> Not if they knew ASM and could read the list files!

Even if they knew ASM and could read the list files. The whole point of a
compiler is to present an abstraction. Debugging the abstraction is the job
of the compiler writer, not the users.

>  In fact that's how I
> learnt assembly on the PIC16 originaly, looking through the compiler
> listings and essentialy learning from the very experienced people that wrote
> the compiler.

You are in a separate group from many novices, who simply want to apply the
chip as a tool to get a job done.

I'm in the same boat as you. I spend most of my limited PIC time building
development tools that operate to my liking. But the average user simply wants
their project to work. Which in the end is why Wouter is correct that in the
end the average novice should program in an HLL. We only disagree on the degree
that such novices should be conversant with PIC assembly. Wouter thinks that
you can get away with little or none at all, while I'm of the belief that
the user should have at least a speaking and reading relationship with it.

BAJ
____________________________________________

2004\11\12@154819 by Wouter van Ooijen

face picon face
> On
> subroutine entry, the general registers that the subroutine
> will trash are
> pushed onto a software stack, and then restored right before
> returning.
> These general registers are then used as local scratch inside the
> subroutine, which is useful since they are fast and usually
> bank-independent
> to access.

So with some difficulty, and at some cost in code space and run time,
you achieve in asm roughly the same RAM-space-efficiency as I
automatically get in a HLL. Asm is creat for saving code space and run
time, isn't it ;)

BTW how do you (automatically) determine how much software stack space
you need?

Wouter van Ooijen

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


____________________________________________

2004\11\12@155924 by Byron A Jeff

face picon face
On Fri, Nov 12, 2004 at 10:19:35AM -0500, John J. McDonough wrote:
> ----- Original Message -----
> From: "Byron A Jeff" <RemoveMEbyronspam_OUTspamKILLspamcc.gatech.edu>
> Subject: Re: [PIC:] Getting started with PIC's
>
>
> > And this is where I believe the real problem lay and why we have to be
> > really aggressive about dissuading new 84 designs, or even implementing
> > existing 84 projects. But there's a documentation vacuum that's real
> > difficult to fill. My wrap up is coming...
>
> I tend to agree with you here, but I'm not so sure that the answer is simply
> more dox.

Not just more docs, more meaningful docs. Something along the lines of
Fr. McGahee's PICUART tutorial for each of the major PIC peripherals plus
a couple on systems integration (i.e. the digital clock that reads external
temps and has a serial interface to a PC), and interrupt handling.

>
> > Of course I'd throw in my obligatory bootloader plug, which completely
> obviates
> > the need for a "programmer" in any sense...
>
> Jawel, the bootloader is another of those things I'm not the biggest fan of.
> ICSP is pretty darned simple.

I won't go into it again as I've beat that horse to a pulp. I'll just leave
it with the fact that all higher level systems are essentially bootloaded, so
it must have some merit.

{Quote hidden}

Topics?

{Quote hidden}

Or simply use onboard ADC. That's an example of the types of applications I'm
talking about.

{Quote hidden}

Agreed. But by starting at the top of the food chain with a part and working
your way into it will give a novice a comfort level. Let's talk about a
really small byte (pun intended) on the 16F88: the nanowatt module. As soon
as you get started you get a win because you don't have to wire up a crystal
or a resonator. I find it's easier to start with everything there and explain
it one section at a time, then to plateau and have to move to a different part.

Again I'm strictly talking from a hobby or extremely low volume persepctive.
In high volume commercial applications, you have to go in the opposite
direction and start with the smallest part that may fit, then squeeze as
tight as possible.

>
> I am seeing evidence that I'm getting through.  Different students have
> begun projects with the 628, 818, 88 and 877, so the barrier isn't absolute.
> But I bet for every student playing with another chip, there are ten trying
> to put too much stuff into an 84.

Right. And the problem is that there isn't a really good F88, 18F, or 16F87X
based tutorial to point to and say "Work from here."

{Quote hidden}

Really cool stuff. That's why I wrote a comparison page on it here:

http://www.finitesite.com/d3jsys/16F88.html

{Quote hidden}

Cool. I hope this gives you some thoughts for the v2 version.

BAJ
____________________________________________

2004\11\12@160611 by Jan-Erik Soderholm

face picon face
Wouter van Ooijen wrote :

> Olin wrote :
> >
> > On subroutine entry, the general registers that the
> > subroutine will trash are pushed onto a software stack,
> > and then restored right before returning.
> > These general registers are then used as local scratch
> > inside the subroutine, which is useful since they are fast
> > and usually bank-independent to access.
>
> So with some difficulty, and at some cost in code space and run time,
> you achieve in asm roughly the same RAM-space-efficiency as I
> automatically get in a HLL. Asm is creat for saving code space and run
> time, isn't it ;)

Hi.
Since I'm not an expert in compilers and such, I'd like to know how a
compiler "automatically" provides the same thing without (more
or less) the same cost in (machine) code space and run time ?

Regards,
Jan-Erik.
____________________________________________

2004\11\12@160714 by Byron A Jeff

face picon face
On Fri, Nov 12, 2004 at 07:56:51PM +0100, Wouter van Ooijen wrote:
> > Call me unreasonable but I
> > don't like having to rely on others to solve my problems.
>
> But you are at the mercy of Microchip! And of the guy who wrote the code
> for your programmer. And we are all at the mercy of Big Bill.

Of course absolutely none of above is true. The last time I did PIC development
on a microsoft OS was well over 10 years ago. Everything I use is open source
so at a fundamental level I'm at no one's mercy. Even the great Wouter finally
freed JAL for me to use as I see fit. ;-) I even threw in a patch or three
to my copy of JAL.

MPLAB/ICD2/XP are all packages of convenience, not of necessity.

BAJ
____________________________________________

2004\11\12@164711 by olin_piclist

face picon face
Wouter van Ooijen wrote:
> So with some difficulty,

Not really, all I have to do is list the registers to save on the GLBSUB
line.

> and at some cost in code space and run time,
> you achieve in asm roughly the same RAM-space-efficiency as I
> automatically get in a HLL.

I don't know, it depends on how the HLL handles temporary variables.  There
are a lot of worse ways to do this.

> Asm is creat for saving code space and run
> time, isn't it ;)

That's a rather negative way to present it.  Even if this mechanism is
similar to what some HLL uses, I'm not forced to use it when it gets in the
way.  By default my subroutines preserve the general registers that aren't
used to return values, but it doesn't have to be that way.  I just have to
carefully document any interface that is not the normally expected one.

More frequently than letting a subroutine trash the general registers, I
chose something other than REG0 for the return value.  I have the freedom to
write a subroutine with the most convenient interface to what is calling it.
Compilers usually just allocate call arguments from the beginning, or use an
external buffer.

Thinking about it more, the whole issue of call arguments and subroutine
return values is an area where assembler allows you a lot more flexibility
that is easy to access without getting into trouble.

> BTW how do you (automatically) determine how much software stack space
> you need?

I don't.  But I do usually have a pretty good idea of where the deepest call
is, and it's easy to calculate stack space for any such nesting.  Many
routines don't don't use the stack at all.  My default setup reserves a
rather large area for the stack, which I shrink only when running out of
RAM.  In those cases I look at the max call depth more carefully.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\12@170703 by piclist

flavicon
face
On Fri, 12 Nov 2004, Jan-Erik Soderholm wrote:

> Wouter van Ooijen wrote :
>
> > Olin wrote :
> > >
> > > On subroutine entry, the general registers that the
> > > subroutine will trash are pushed onto a software stack,
> > > and then restored right before returning.
> > > These general registers are then used as local scratch
> > > inside the subroutine, which is useful since they are fast
> > > and usually bank-independent to access.
> >
> > So with some difficulty, and at some cost in code space and run time,
> > you achieve in asm roughly the same RAM-space-efficiency as I
> > automatically get in a HLL. Asm is creat for saving code space and run
> > time, isn't it ;)
>
> Since I'm not an expert in compilers and such, I'd like to know how a
> compiler "automatically" provides the same thing without (more
> or less) the same cost in (machine) code space and run time ?

A C compiler using a compiled stack looks at the size of the local
variables a function uses, allocates the appropriate amount of RAM
from a global buffer, and uses this RAM for the local variables.  This
doesn't have the code space overhead of pushing and popping described
above.  Nor does it have the (I presume) debugging nightmare of
declaring the wrong number of local variable bytes to the assembler,
or forgetting to push and/or pop.

The C compiler will also analyze the function call tree so that
functions which call other functions can share space in the local
variable pool without corruption.  For example, if func1 calls func2,
and each uses two bytes of local variables, the compiler will assign
bytes 0 and 1 to func1 and bytes 2 and 3 to func2.  But if func1 and
func2 are mutually exclusive, both will use bytes 0 and 1.  Thus the
compiler will only allocate the necessary number of bytes for local
variables, not requiring the (I presume) fixed-size buffer required in
the approach described above.

--
John W. Temples, III
____________________________________________

2004\11\12@170827 by Peter L. Peres

picon face

On Thu, 11 Nov 2004, Lee Jones wrote:

>>> I don't have any problem learning assembly.. I just don't have
>>> any resources to do so.
>
>> Sure you do.  Download MPLAB from Microchip for free.  It is a
>> complete suite of development tools to write PIC firmware in
>> assembler.
>
> And download the data sheet for the specific PIC device that
> you plan on using.  Details on the instruction set, interrupt
> structure (if any), and memory model are in the data sheet.
> You _need_ this information no matter what language you use.

But the errata information is not in it, so after you get the datasheet,
hunt in the website to find all errata sheets and then determine the stack
of sheets you need to read.

Peter
____________________________________________

2004\11\12@171052 by Martin Klingensmith

face
flavicon
face
It seems like you are asking a "what the hell would you do" question,
and I'll tell you (even though it looks like 50 other people have)

1. I would not move directly to a high level language. Assembly can look
very very confusing but IMO it is *fundamental* to knowing how things
work. If you don't know how things work and you have some problem with
your high-level code, where do you go? [I would use C after learning at
least how a few assembly programs work]

2. Do not get the melabs programmer. They are overpriced for what they
are and will keep charging you for software. They did it to me when I
was getting into PICs, they'll do it to you. Everyone has their favorite
programmer, mine happens to be Wouter's Wisp628. Olin sells a programmer
too, I've never used it.

3. A development/carrier board can be good. I, personally, use a
breadboard to prototype circuits. You need a crystal [or not, depending
on if you want a fast clock or 4MHz internal clock for the 16f877], a
resistor, and hopefully a regulated power supply.

To endorse Wouter once again, he has an online shop at:
<http://www.voti.nl/winkel/index.html>

The prices are good and it is mainly a lot of stuff for the MCU crowd.
Shipping to the US is quite reasonable too.

--
--
Martin Klingensmith
http://infoarchive.net/
http://nnytech.net/
____________________________________________

2004\11\12@174603 by John J. McDonough

flavicon
face
----- Original Message -----
From: "Byron A Jeff" <RemoveMEbyronTakeThisOuTspamspamcc.gatech.edu>
Subject: Re: [PIC:] Getting started with PIC's


> Topics?

Lesson 15 is on reading encoders.  In 16 we introduce relocatable code,
something that is entirely missing in any hobbyist code I have seen.  Once
we can build libraries, we will talk about controlling an LCD.  I've been
adjusting the order of topics somewhat depending on what I hear people are
working on, but I expect 17 will be the LCD and maybe 18 the DDS.

--McD


____________________________________________

2004\11\12@174930 by olin_piclist

face picon face
piclist@xargs.com wrote:
> A C compiler using a compiled stack looks at the size of the local
> variables a function uses, allocates the appropriate amount of RAM
> from a global buffer, and uses this RAM for the local variables.

That means the local variables are unlikely to be in unbanked memory where
accesses to them are really simple.

> This
> doesn't have the code space overhead of pushing and popping described
> above.

But it does have the additional code space overhead of bank switching before
local variable accesses.

> Nor does it have the (I presume) debugging nightmare of
> declaring the wrong number of local variable bytes to the assembler,
> or forgetting to push and/or pop.

That sort of bug happens very rarely.

> The C compiler will also analyze the function call tree so that
> functions which call other functions can share space in the local
> variable pool without corruption.  For example, if func1 calls func2,
> and each uses two bytes of local variables, the compiler will assign
> bytes 0 and 1 to func1 and bytes 2 and 3 to func2.  But if func1 and
> func2 are mutually exclusive, both will use bytes 0 and 1.  Thus the
> compiler will only allocate the necessary number of bytes for local
> variables, not requiring the (I presume) fixed-size buffer required in
> the approach described above.

But the compiler is forced to make pessimistic assumptions about the call
depth and what local variables can be overlapped.  A stack does this
automatically at run time.  The only issue becomes how much stack space to
allocate.

Each method has its pros and cons.  I don't think you can say up front that
one is inherently better for an arbitrary application.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\12@181512 by Bob Ammerman

picon face
>> A C compiler using a compiled stack looks at the size of the local
>> variables a function uses, allocates the appropriate amount of RAM
>> from a global buffer, and uses this RAM for the local variables.
>
> That means the local variables are unlikely to be in unbanked memory where
> accesses to them are really simple.

But the compiler can optimize variable location pretty well, and most
compilers allow you to explicitly allocate globals in specific banks if you
want to.

>> This
>> doesn't have the code space overhead of pushing and popping described
>> above.

> But it does have the additional code space overhead of bank switching
> before
> local variable accesses.

Again, I don't think this is very heavy.

>> Nor does it have the (I presume) debugging nightmare of
>> declaring the wrong number of local variable bytes to the assembler,
>> or forgetting to push and/or pop.

> That sort of bug happens very rarely.

With your macro set I believe that implicitly.

{Quote hidden}

Actually, the compiler can be _very_ smart about this. It knows the call
tree and can set up memory location usage to minimize 'stack' depth
(although dynamic issues generally are not resolved (ie: functions A and B
both call function C and C calls D, but only when called by A, but not B).

> Each method has its pros and cons.  I don't think you can say up front
> that
> one is inherently better for an arbitrary application.

As usual, the compiler makes life simpler for you. Sometimes that is _not_
what you want.

Bob Ammerman
RAm Systems

____________________________________________

2004\11\12@185001 by piclist

flavicon
face
On Fri, 12 Nov 2004, Olin Lathrop wrote:

> EraseMEpiclistspamspamspamBeGonexargs.com wrote:
> > A C compiler using a compiled stack looks at the size of the local
> > variables a function uses, allocates the appropriate amount of RAM
> > from a global buffer, and uses this RAM for the local variables.
>
> That means the local variables are unlikely to be in unbanked memory where
> accesses to them are really simple.

True, if there are enough of them to need RAM.  In many cases on the
PIC18 they're typically in unused SFRs, which not only doesn't require
banking, it doesn't require RAM.

> > This
> > doesn't have the code space overhead of pushing and popping described
> > above.
>
> But it does have the additional code space overhead of bank switching before
> local variable accesses.

I can't imagine a push and pop taking less code space than a
(possible) bank switch.

> > Nor does it have the (I presume) debugging nightmare of
> > declaring the wrong number of local variable bytes to the assembler,
> > or forgetting to push and/or pop.
>
> That sort of bug happens very rarely.

What about maintenance?  Everytime you touch the code, do you have go
back and study your call tree to see if the local variable or function
you added will fit in your statically allocated buffer?

> > The C compiler will also analyze the function call tree so that
> > functions which call other functions can share space in the local
> > variable pool without corruption.
>
> But the compiler is forced to make pessimistic assumptions about the call
> depth and what local variables can be overlapped.

I don't follow you here.  The compiler knows exactly what calls what.

> Each method has its pros and cons.  I don't think you can say up front that
> one is inherently better for an arbitrary application.

Agreed.  But do you even have an option for both with MPASM?

--
John W. Temples, III
____________________________________________

2004\11\12@194527 by olin_piclist

face picon face
piclist@xargs.com wrote:
> I can't imagine a push and pop taking less code space than a
> (possible) bank switch.

On the PIC 18, a push/pop pair takes two instructions and a bank setting one
instruction.  Therefore, two bank switches per variable the the break even
point.  Note however that these variables not in global memory may cause
additional bank switches to get back to the "other context".

> What about maintenance?  Everytime you touch the code, do you have go
> back and study your call tree to see if the local variable or function
> you added will fit in your statically allocated buffer?

As I said before, most of the time it's easy to make the stack big enough
witout a lot of thinking.  I guess you are referring to the pre-allotted
stack space as the "statically allocated buffer".

A data stack is a useful construct in itself.

>> But the compiler is forced to make pessimistic assumptions about the
>> call depth and what local variables can be overlapped.
>
> I don't follow you here.  The compiler knows exactly what calls what.

No, it can't.  It can only know what *could* call what, but doesn't follow
run time flow to see what actually does get called.  Think of recursion as
the worst case.  The compiler can't know that recursion isn't infinite,
which is why recursion is usually disallowed on small systems like this.

The compiler also doesn't know which variables truly need to be overlapped,
only which ones might be in scope at the same time.

>> Each method has its pros and cons.  I don't think you can say up
>> front that one is inherently better for an arbitrary application.
>
> Agreed.  But do you even have an option for both with MPASM?  MPASM has no
option of automatic call tree analisys.  However compilers can't do some of
the things I was talking about either.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com
____________________________________________

2004\11\12@212625 by Daniel Chia

flavicon
face
Hmm as a hobbyist let me inject some of my views..

Well generally what is said about using bigger chips is true, space
normally is not a consideration when tinkering around, so my first PIC
was a 16F877, plenty of peripherals, i/o pins and of Flash and ram. Made
things very easy.

I started out with a bit of asm then moved on to JAL, which was definite
bliss. I think for simple apps a HLL will definitely be more than
enough, until you start pushing boundaries.

I indeed got into a weird bug with JAL but that was quickly resolved
with help from friendly jal-users.

My 2 cents


------------------------------------------------------------------------
Daniel Chia

"Genius is one percent inspiration and ninety-nine percent
perspiration."

    - Thomas Edison

E-mail: RemoveMEdanielcjhKILLspamspamyahoo.com.sg
MSN: danstryder01STOPspamspamspam_OUTyahoo.com.sg
ICQ: 37878331
------------------------------------------------------------------------


> {Original Message removed}

2004\11\13@030143 by Wouter van Ooijen

face picon face
> Since I'm not an expert in compilers and such, I'd like to know how a
> compiler "automatically" provides the same thing without (more
> or less) the same cost in (machine) code space and run time ?

You can analyse the call tree, and share local variables accordingly.
This is a piece of cake for a compiler, but very tedious (and error
prone) work for a human. Hence assembler programs tend to use either
unique locations for local variables, or (Olin) a save/restore approach.
The compiler method achieves the same, but without the overhead of the
save restore code and runtime, and with an automatic check on the size
of the needed data area.

Wouter van Ooijen

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


____________________________________________

2004\11\13@074912 by John Ferrell

face picon face
Check out http://picbook.com/  High end chip, college course from Georgia
Tech.

Don't overlook http://www.mikroelektronika.co.yu/
They have Demo versions of Basic & Pascal Compilers that will generate up to
2K of hex code for free! The hardware looks good as well.

I chose the PicStart Plus from Microchip as my programmer because it stays
fully supported by the chip maker. As I recall, about $200.

For a low cost yet very effective combination of products check out
http://www.voti.nl
The JAL compiler works and it is free!

There are a lot of folks on this list that will sell small quantities of
parts with no minimums and charge only actual mailing costs. It is much more
cost effective than buying a tube of chips and only finding use for 5!

I also like the Square One books.

There are a lot of different opinions on how to get going with PICs. This
list is the best resource.

John Ferrell
My Competition is not my enemy!
http://DixieNC.US

>
> Books? Tutorials you can recommend?
>
> Thanks,
> Mike
>
>
> ______________________________________________

2004\11\14@094414 by John Ferrell

face picon face
I did a 'Re-Think' on this topic.
Where you start depends a lot on what size Pic you elect to use. If you a
working in a "smallish" size (16Fxxx or smaller) Assembler makes more sense.
In the 18Fxxx a high level language can save a lot of labor.

It also depends on your background. If you are already experienced in c,
basic or Pascal you might use that to your advantage.

When you do your first "blink a led" program, it will be easier and better
for you to do it in assembler.

If you are a hardware guy, you are going to need to learn a little
programming. If you are a software guy, you are going to have to learn to a
little hardware.

I don't find the PIC an easy place to learn programming. If you are going to
write in assembler it should come as no surprise that your code will be
better if you get an assembler book and try a little on the PC. The same
with all of the languages.

Unless you are really on a tight budget or just want to build, the
development boards that are available are a bargain.

If you have any doubts about products, a search of the archives or Google
groups will reveal any complaints.

How you prototype projects is a whole new topic...

John Ferrell
My Competition is not my enemy!
http://DixieNC.US

{Original Message removed}

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