# Learning to use PICS

D

#### David Harper

Jan 1, 1970
0
I'm interested in learning how to use PICS. I've done lots of
advanced stuff with the Basic Stamps, but am starting to feel some
speed, capacity, and temperature (low) limitations. I'm wondering if
there are PICS out there that are more rugged, have more memory, and
are considerably faster than BS modules. Not to mention, the prices
I've seen are alot lower.

Dave

C

#### Craig

Jan 1, 1970
0
David Harper said:
I'm interested in learning how to use PICS. I've done lots of
advanced stuff with the Basic Stamps, but am starting to feel some
speed, capacity, and temperature (low) limitations. I'm wondering if
there are PICS out there that are more rugged, have more memory, and
are considerably faster than BS modules. Not to mention, the prices
I've seen are alot lower.

Dave

Hi Dave,

You should take a look at the Atmel AVR microcontrollers. The C compiler is
free (GNU GCC) and they don't need any special programmers. You just
connect them to the parallel port of your PC and then you can program them.
You can program them in different ways if you need to and they're supported
by different programming languages. You can see a simple AVR project I did
here:

http://www.craigsarea.com/ultrasonic.html

I've used PIC microcontrollers quite a lot and I think the AVR's are better
(and cheaper). But if you're determined to use a PIC then something like
the PIC16F874 is a good place to start. It has a lot of the features
offered by other microcontrollers (USART, PWM, ADC, Timers, etc etc).
You'll need a programmer of somesort, the PICSTART Plus is a common one but
it's probally cheaper to make your own. This site has a homemade programmer

http://www.jdm.homepage.dk/newpic.htm

A free assembler and IDE can be downloaded from the Microchip website. It's
called MPLAB. They also offer a restricted C compiler for free. You have
to pay for the complete C compiler.

PIC's are good, but I would recommend the Atmel AVR's.

Hope that helps,

Craig

P

#### petrus bitbyter

Jan 1, 1970
0
David Harper said:
I'm interested in learning how to use PICS. I've done lots of
advanced stuff with the Basic Stamps, but am starting to feel some
speed, capacity, and temperature (low) limitations. I'm wondering if
there are PICS out there that are more rugged, have more memory, and
are considerably faster than BS modules. Not to mention, the prices
I've seen are alot lower.

Dave

Dave,

Look at www.voti.nl A lot about PICs, PIC programming and PIC program
developement. Plus links to other interesting PIC sites.

petrus bitbyter

C

#### Colubris

Jan 1, 1970
0
I'm interested in learning how to use PICS. I've done lots of
advanced stuff with the Basic Stamps, but am starting to feel some
speed, capacity, and temperature (low) limitations. I'm wondering if
there are PICS out there that are more rugged, have more memory, and
are considerably faster than BS modules. Not to mention, the prices
I've seen are alot lower.

Dave

Hi Dave,
Since you're experienced with the BASIC Stamps, you might consider
PicBASIC (www.melabs.com) or one of the other BASIC compilers.
The commands are more-or-less the same, but you can buy your PIC
processors for a few dollars in the temp range that you need. You'll
I made a "picall" programmer, and use the free software for it:
www.picallw.com

Not quite as fast or code-space efficient as assembly - but much
better than the Stamps.

You can try out PicBASIC free at www.compilespot.com

There are also a few BASIC compilers available free for the AVR's -

Arch

J

Jan 1, 1970
0
D

#### David Harper

Jan 1, 1970
0
Hi Dave,
Since you're experienced with the BASIC Stamps, you might consider
PicBASIC (www.melabs.com) or one of the other BASIC compilers.
The commands are more-or-less the same, but you can buy your PIC
processors for a few dollars in the temp range that you need. You'll
I made a "picall" programmer, and use the free software for it:
www.picallw.com

Not quite as fast or code-space efficient as assembly - but much
better than the Stamps.

You can try out PicBASIC free at www.compilespot.com

There are also a few BASIC compilers available free for the AVR's -

Arch

So those compilers allow standard PICS (from Microchip Technologies)
to be programed in BASIC? How much slower is a PIC program in BASIC
than assembly?

Thanks!
Dave

D

#### David Harper

Jan 1, 1970
0
Craig said:
You should take a look at the Atmel AVR microcontrollers. The C compiler is
free (GNU GCC) and they don't need any special programmers.

Is C the only language they're programmable with? The reason I ask is
that I'm a mechanical engineer by job and major, so I have not (yet)
learned C.

Thanks!
Dave

R

#### Robert Monsen

Jan 1, 1970
0
David said:
Is C the only language they're programmable with? The reason I ask is
that I'm a mechanical engineer by job and major, so I have not (yet)
learned C.

Thanks!
Dave

Here is a nice list of references:

If you are looking for basic, I'd stick with the stamp. However, I find
it cheaper and easier to program in assembler.

A nice reference site is www.piclist.com

--
Regards,
Robert Monsen

"Your Highness, I have no need of this hypothesis."
- Pierre Laplace (1749-1827), to Napoleon,
on why his works on celestial mechanics make no mention of God.

C

#### Craig

Jan 1, 1970
0
David Harper said:
Is C the only language they're programmable with? The reason I ask is
that I'm a mechanical engineer by job and major, so I have not (yet)
learned C.

Thanks!
Dave

The AVR's do support other languages. The 2 most common (for any
microcontroller) are assembler and C. Because the AVR C compiler is free,
most AVR examples are programmed in C. A lot of PIC examples are programmed
in assembler just because the assembler is free. PIC assembler is very very
easy to learn whereas AVR assembler can be a bit more involved.

If you want to get the most out of your microcontroller then you should
consider either assembler or C. Assembler is lower level than C and so
offers you more control. But well programmed C can be just as good as
assembler and has the advantage of being more readable (and portable if that
matters). Also, trying to program complex problems in C is much easier (and
therefore less prone to error) than assembler. If you already have
experience of programming in BASIC and you understand the idea of registers,
then moving over to C isn't so daunting. You also have the advantage of
encounter.

My advice is take the plunge and learn C using an AVR microcontroller. The
whole setup will cost no more than £10. And once you've got some experience
with C you'll be able to program whatever you want.

B

#### Bill Bowden

Jan 1, 1970
0
I'm interested in learning how to use PICS. I've done lots of
advanced stuff with the Basic Stamps, but am starting to feel some
speed, capacity, and temperature (low) limitations. I'm wondering if
there are PICS out there that are more rugged, have more memory, and
are considerably faster than BS modules. Not to mention, the prices
I've seen are alot lower.

Dave

There is a good PIC tutorial (13 pages) that covers
PIC assembly programming. There are only 35 instructions
to learn.

http://www.mstracey.btinternet.co.uk/pictutorial/picmain.htm

And for good hardware prices, look at Randy Jones site at
http://www.glitchbuster.com/

Most of his pics are less than $3. -Bill B #### Byron A Jeff Jan 1, 1970 0 I'm interested in learning how to use PICS. I've done lots of advanced stuff with the Basic Stamps, but am starting to feel some speed, capacity, and temperature (low) limitations. I'm wondering if there are PICS out there that are more rugged, have more memory, and are considerably faster than BS modules. Not to mention, the prices I've seen are alot lower. Thanks in advance for any suggestions, insight, or comments! Dave Dave, You're going to get 10,000 suggestions. But given your situation I would suggest taking a look at the XC Structured Basic Compiler (XCSB) by Sergio Masci. It's a highly optimized Basic along the lines of the Stamp. So migration is easy. Since it is compiled, you should get much better performance than the Stamp. Also you can load it into the 16F chip of your choice. I would suggest the 16F877A if you have the space. While you stated in another post that you didn't want limited software I would strongly suggest that you try before you buy. XCSB has a limited Lite version that will let you test our some ideas. Then if everything works you can purchase the standard or pro edition of the software. If you're willing to spend some time learning another language, and BTW no matter what you do you'll be learning another language to some degree, consider JAL. This Open Source, Pascal like, compiled HLL primarily targeted to the PIC has a large following and lots of libraries for doing different things. Also it's completely free and without restriction. Finally you can always go back to the source and write PIC assembly. As you step into the wider PIC world you'll find that lots of code and examples are written in PIC assembly. So having at least a reading knowledge of it can be helpful. One last interesting place to look is Myke Predko's Basic87X interpreter. Like the microcomputer BASICs of old (C64, TRS-80, Apple II) the interpreter , program code, and parser are all embedded on chip: http://www.myke.com/mbaspg1.htm There are lots of resource links. Hope these help: JAL and XCSB can be found on my PIC langages page: http://www.finitesite.com/d3jsys/languages.html Jal's Open Source page is here: http://jal.sf.net Lots of resources on the PICLIST website: http://www.piclist.com hope this helps, BAJ C #### Colubris Jan 1, 1970 0 So those compilers allow standard PICS (from Microchip Technologies) to be programed in BASIC? How much slower is a PIC program in BASIC than assembly? Thanks! Dave Hi Dave, You can write your BASIC code, and then compile it into a standard ..HEX file - with which you can program any PIC of your choice (TONS to choose from for just a few$\$ each!).

There are a bunch of different BASIC compilers for both PICs and AVRs.
Some are more efficient - but all will run much faster than the
Stamps.
I don't have much experience with 'pure' assembly, so can't compare
speed of the BASIC compilers to ASM - but from things I've heard the
BASIC compilers run maybe 25 - 50% slower depending upon how complex

Arch

D

#### David Harper

Jan 1, 1970
0
Everyone,
Thanks for the help so far. I have a question in regards to speed.
I'm trying to figure out how to equate clock speed (for SPI/3-wire
interface) to oscillator speed. From what I've read, it's
adjustable...? I'm basically wondering how much faster the clocks
are for various PICs. The Basic Stamp clock speed is about 16.6kHz,
and I'm wondering how PICs (or Amtel's chips) compare?

I've also eyed the SX chip from Ubicom, distributed by Parallax.
Anyone have any experience with those?

http://www.parallax.com/sx/data_sheets.asp

Dave

B

#### Byron A Jeff

Jan 1, 1970
0
-Everyone,
-Thanks for the help so far. I have a question in regards to speed.
-I'm trying to figure out how to equate clock speed (for SPI/3-wire
-interface) to oscillator speed. From what I've read, it's
-adjustable...? I'm basically wondering how much faster the clocks
-are for various PICs. The Basic Stamp clock speed is about 16.6kHz,
-and I'm wondering how PICs (or Amtel's chips) compare?

The BS clock speed is actually 4 Mhz. The 16.6Khz speed is probably
the speed of interpretation.

As for SPI if you use the hardware SSP module you can clock it up
to the instruction rate of the chip. For a 20 Mhz part this is
5 Mhz. It's fast.

-
-I've also eyed the SX chip from Ubicom, distributed by Parallax.
-Anyone have any experience with those?

None personally. It's a 75 Mhz low end PIC clone. Doesn't have
flash, so you'd have to have to go the programmer/eraser route.

JAL, which I mentioned before has Ubicom support. May give you
an avenue for HLL development for a really really fast chip.

But you may be overstating the speed issue. Some 18F PICS can be
clocked at 40 Mhz giving a 10 MIPS instruction rate.

Fast chips + fast hardware can lead to unbelievably performance.
Working with the Stamp is like driving an earth mover in terms of
speed. Raw PICs will feel like a high performance sports car in
comparison, while the SX will feel like a rocket.

BAJ

S

#### Sergio Masci

Jan 1, 1970
0
David Harper said:
[email protected] (Colubris) wrote in message

So those compilers allow standard PICS (from Microchip Technologies)
to be programed in BASIC? How much slower is a PIC program in BASIC
than assembly?

Thanks!
Dave

This depends on three things (1) the person doing the programming in
assembler,
(2) the BASIC compiler and (3) the complexity of the problem.

A good BASIC compiler WILL produce code that is within 10-20% of that
produced
by an experienced assembler programmer. If the assembler programmer is not
very
experienced then a good BASIC compiler WILL produce code that is MUCH more
efficient.

As the complexity of a problem increases so too does the ability of a good
compiler to outperform the assembler programmer. The compiler is a tool that
enables the computer to automatically perform hundreds of thousands of tests
on
your code. A good compiler will search for optimisations that an experienced
assembler programmer would find laborious and a non-experienced assembler
programmer would not even know about. Most importantly, the compiler can do
all
this work each and every time you make a change to your program. An
assembler
programmer would typically only look at a small part of the program when he
changes it.

Some compilers convert BASIC source code into a special internal form that
requires an interpreter to run. This internal code is downloaded into the
PIC
and then processed by an interpreter that is running on the PIC. Each
instruction in the BASIC program is effectively executed by the interpreter.
If
the instruction is executed 10 times in the BASIC source then it will be
executed 10 times by the interpreter.

Some compilers convert BASIC source code into machine code which is the same
stuff that assemblers produce. A mediocre compiler will generate several
machine
code instructions for each BASIC instruction. A good compiler will combine
multiple BASIC instructions and generate fewer machine code instructions.

Programs executed by an interpreter WILL run much (several hundred times)
slower
than an optimised machine code executable produced by a good compiler that
produces machine code.

The XCSB compiler will convert the following to just 6 machine code
instructions:

proc inline set_bit(ubyte *addr, ubyte id)
endproc

proc inline clear_bit(ubyte *addr, ubyte id)
endproc

proc inline ubyte test_bit(ubyte *addr, ubyte id)
return (*addr & (1 << id) != 0)
endproc

proc main()

ubyte a, b

if (test_bit(&a, 1) then
set_bit(&b, 2)
else
clear_bit(&b, 2)
endif
endproc

A 20MHz 16F876 can execute (aprox) 5,000,000 machine code instructions per
second.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

J

#### john jardine

Jan 1, 1970
0
[clip]

The XCSB compiler will convert the following to just 6 machine code
instructions:

proc inline set_bit(ubyte *addr, ubyte id)
endproc

proc inline clear_bit(ubyte *addr, ubyte id)
endproc

proc inline ubyte test_bit(ubyte *addr, ubyte id)
return (*addr & (1 << id) != 0)
endproc

proc main()

ubyte a, b

if (test_bit(&a, 1) then
set_bit(&b, 2)
else
clear_bit(&b, 2)
endif
endproc

Looks like "C" to me.
I know this must be so, as I can't understand it .
Yet I can easily read the 'Proton','CH-flash', 'iL_Bas16' etc Basics.
regards
john

S

#### Sergio Masci

Jan 1, 1970
0
john jardine said:
[clip]

The XCSB compiler will convert the following to just 6 machine code
instructions:

proc inline set_bit(ubyte *addr, ubyte id)
endproc

proc inline clear_bit(ubyte *addr, ubyte id)
endproc

proc inline ubyte test_bit(ubyte *addr, ubyte id)
return (*addr & (1 << id) != 0)
endproc

proc main()

ubyte a, b

if (test_bit(&a, 1) then
set_bit(&b, 2)
else
clear_bit(&b, 2)
endif
endproc

Looks like "C" to me.
I know this must be so, as I can't understand it .
Yet I can easily read the 'Proton','CH-flash', 'iL_Bas16' etc Basics.
regards
john

It supports pointers like "C" but unlike many C compilers for the PIC it
doesn't generate a ton of code to build and pass the pointers and then
dereference them if it can determine the address at compile time. PEEK and
POKE would be more in keeping with other BASIC dialects but pointers allow
the programmer to give the compiler more information which in turn helps the
compiler trap silly errors and generate better code.

The reason I chose the above example is because it shows how the compiler
converts some very complex functionality into very tight code

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

C

#### CBarn24050

Jan 1, 1970
0
Subject: Re: Learning to use PICS
From: "Sergio Masci" [email protected]
Date: 28/11/2004 03:06 GMT Standard Time
Message-id: <[email protected]>

john jardine said:
[clip]
The XCSB compiler will convert the following to just 6 machine code
instructions:

proc inline set_bit(ubyte *addr, ubyte id)
endproc

proc inline clear_bit(ubyte *addr, ubyte id)
endproc

proc inline ubyte test_bit(ubyte *addr, ubyte id)
return (*addr & (1 << id) != 0)
endproc

proc main()

ubyte a, b

if (test_bit(&a, 1) then
set_bit(&b, 2)
else
clear_bit(&b, 2)
endif
endproc

Looks like "C" to me.
I know this must be so, as I can't understand it .
Yet I can easily read the 'Proton','CH-flash', 'iL_Bas16' etc Basics.
regards
john
It supports pointers like "C" but unlike many C compilers for the PIC it
doesn't generate a ton of code to build and pass the pointers and then
dereference them if it can determine the address at compile time. PEEK and
POKE would be more in keeping with other BASIC dialects but pointers allow
the programmer to give the compiler more information which in turn helps the
compiler trap silly errors and generate better code.

The reason I chose the above example is because it shows how the compiler
converts some very complex functionality into very tight code

Assembly language programmers do that in 3 instructions.

S

#### Sergio Masci

Jan 1, 1970
0
CBarn24050 said:
Subject: Re: Learning to use PICS
From: "Sergio Masci" [email protected]
Date: 28/11/2004 03:06 GMT Standard Time
Message-id: <[email protected]>

john jardine said:
[clip]
The XCSB compiler will convert the following to just 6 machine code
instructions:

proc inline set_bit(ubyte *addr, ubyte id)
endproc

proc inline clear_bit(ubyte *addr, ubyte id)
endproc

proc inline ubyte test_bit(ubyte *addr, ubyte id)
return (*addr & (1 << id) != 0)
endproc

proc main()

ubyte a, b

if (test_bit(&a, 1) then
set_bit(&b, 2)
else
clear_bit(&b, 2)
endif
endproc

Looks like "C" to me.
I know this must be so, as I can't understand it .
Yet I can easily read the 'Proton','CH-flash', 'iL_Bas16' etc Basics.
regards
john
It supports pointers like "C" but unlike many C compilers for the PIC it
doesn't generate a ton of code to build and pass the pointers and then
dereference them if it can determine the address at compile time. PEEK and
POKE would be more in keeping with other BASIC dialects but pointers allow
the programmer to give the compiler more information which in turn helps the
compiler trap silly errors and generate better code.

The reason I chose the above example is because it shows how the compiler
converts some very complex functionality into very tight code

Assembly language programmers do that in 3 instructions.

No they could not.

They could rearrange the code to give the equivalent of:

clear_bit(&b, 2)

if test_bit(&a, 1) then
set_bit(&b, 2)
endif

Then yes the assembler programmer could reduce it to 3 machine code
instructions but in this case the XCSB compiler would then generate 4
machine code instructions (still infinately better than many other PIC
compilers).

BUT THIS IS NOT THE SAME AS THE ORIGINAL CODE

In the original, bit 2 of "b" follows bit 1 of "a" exactly, in the
rearranged code bit 2 of "b" will glitch (temporarily change from 1 to 0
and back to 1) when bit 1 of "a" is 1. If "b" is used to send messages
to an interrupt service routine this may cause you problems, also if
"b" is an alias of an I/O ports this WILL cause you problems.

The XCSB compiler will not perform this kind of optimisation behind your
back because there are MANY ways that it could cause problems.

Regards
Sergio Masci

http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use

D

#### David Harper

Jan 1, 1970
0
All,
I appreciate everyone's suggestions and help so far. Right now I've
started diving into understanding the architecture and memory of a
typical PIC (16C84), which I figure is the best place to start. After
that, I figure the programming will be a lot easier to understand.

The program memory I understand, no problem (like the BS2, only it
seems only instructions can be written at these locations for PICS,
and only during programming).

However, with the data memory allocation, I'm having some difficulty
based on some of the online datasheets:

and beginner guides (from piclist.com):
http://www.piclist.com/techref/microchip/intro/pic.htm

From what I've read, there are 2 banks each divided into 128
registers. The first 12 registers are SPR, which more or less define
the chip's current state. The next 32 registers are GPR (like RAM?).
What are the next 88? It's defined as "unimplemented data" according
to Fig 4-2 in the 16C84 datasheet.

Secondly, figure 4-7 (pg 18) shows 4 banks, not just two... just how
many banks are there for this chip? Can it be more than 2 banks for
different PICS, which is why they're showing it as 'off limits', so to
speak?

Lastly, back in figure 4-2, it states the 36 GPR in bank 1 are mapped
to bank 0. Does this mean they're connected, and if a GPR in bank X
changes, then the same GPR in the other bank will change also? If so,
are any of the SPR connected in this fashion?

Thanks for the patience if you've made it this far, and I really
appreciate the help!

Dave

Secondly

Replies
6
Views
1K
Replies
3
Views
940
Replies
1
Views
1K
Replies
38
Views
3K
Replies
5
Views
689