Learning to use PICS
David Harper
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
Craig
"David Harper" <dave....@gmail.com> wrote in message
news:364fd697.04112...@posting.google.com...
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
(do a google for others):
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
petrus bitbyter
"David Harper" <dave....@gmail.com> schreef in bericht
news:364fd697.04112...@posting.google.com...
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
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.799 / Virus Database: 543 - Release Date: 19-11-2004
Colubris
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
need to build/buy a programmer.
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 -
sorry, no links for those.
Arch
Joe McElvenney
Have a look at this site -
http://www.oshonsoft.com/
Cheers - Joe
David Harper
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
David Harper
> 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
Robert Monsen
Here is a nice list of references:
http://home.att.net/~wzmicro/pic_link.htm
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.
Craig
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
various programming newsgroups who can help you solve any problems you
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.
Bill Bowden
> I'm interested in learning how to use PICS. I've done lots of
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
Byron A Jeff
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
Colubris
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
your code is.
Arch
David Harper
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
Thanks in advance!
Dave
Byron A Jeff
David Harper <dave....@gmail.com> wrote:
-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
Sergio Masci
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)
*addr = *addr | (1 << id)
endproc
proc inline clear_bit(ubyte *addr, ubyte id)
*addr = *addr & ~(1 << 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
john jardine
"Sergio Masci" <ser...@NO.SPAM.xcprod.com> wrote in message
news:41a89667$0$1067$db0f...@news.zen.co.uk...
>[clip]
>
> The XCSB compiler will convert the following to just 6 machine code
> instructions:
>
> proc inline set_bit(ubyte *addr, ubyte id)
> *addr = *addr | (1 << id)
> endproc
>
> proc inline clear_bit(ubyte *addr, ubyte id)
> *addr = *addr & ~(1 << 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
Sergio Masci
john jardine <jo...@jjdesigns.fsnet.co.uk> wrote in message
news:coac45$hvg$1...@newsg3.svr.pol.co.uk...
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
CBarn24050
>From: "Sergio Masci" ser...@NO.SPAM.xcprod.com
>Date: 28/11/2004 03:06 GMT Standard Time
>Message-id: <41a93fe9$0$1063$db0f...@news.zen.co.uk>
Assembly language programmers do that in 3 instructions.
Sergio Masci
CBarn24050 <cbarn...@aol.com> wrote in message
news:20041128040554...@mb-m18.aol.com...
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.
David Harper
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:
http://ww1.microchip.com/downloads/en/DeviceDoc/30445c.pdf
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
Byron A Jeff
David Harper <dave....@gmail.com> wrote:
>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 part you picked is ultra anchient. Might I suggest a 16F88.
I have a page on rationale here:
http://www.finitesite.com/d3jsys/16F88.html
>
>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).
Correct to a point. Chips like the 16F88 are self programmable, so they can
write their own program memory. This leads to the possibility of a bootloader
where there is no true programmer because the chip programs itself. Note that
you have to use a traditional programmer to get the bootloader onto the chip.
>
>However, with the data memory allocation, I'm having some difficulty
>based on some of the online datasheets:
>http://ww1.microchip.com/downloads/en/DeviceDoc/30445c.pdf
>
>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.
They give you access to periperals such as the timer and I/O ports. Later
chips have a bunch more.
> The next 32 registers are GPR (like RAM?).
RAM. An ultra limited amount too.
>What are the next 88? It's defined as "unimplemented data" according
>to Fig 4-2 in the 16C84 datasheet.
As specified. Nothing there. Unusable.
>
>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?
Right.
>
>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?
Yes.
> If so, are any of the SPR connected in this fashion?
Some. For example the STATUS register is usually mapped into every bank.
>
>Thanks for the patience if you've made it this far, and I really
>appreciate the help!
No problem.
But I beg of you not to get caught with the 16C84 or 16F84. They are older
than dirt. The newer chips bring a lot to the table, and cost less than the
older chips. Take a read of my page for more info.
BAJ
Active8
>>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?
>
> Yes.
>
>> If so, are any of the SPR connected in this fashion?
>
> Some. For example the STATUS register is usually mapped into every bank.
>
>>
>>Thanks for the patience if you've made it this far, and I really
>>appreciate the help!
>
> No problem.
>
> But I beg of you not to get caught with the 16C84 or 16F84. They are older
> than dirt. The newer chips bring a lot to the table, and cost less than the
> older chips. Take a read of my page for more info.
>
Then take the link to the glitchbuster page. It's an easy way to get
everything you need for a PIC project fast.
--
Best Regards,
Mike
mike
If your objective is to understand the architecture of a 16F84, you're
on the right track to understanding an obsolete and arcane part.
There's only one reason to use paged/baanked memory...Price! And that
advantage has long since been nullified by technological advances.
While it's possible to understand the inner workings of a PIC16 part,
the details of actaully making it work in practice will drive you nutz.
All it takes is one mistake in setting the page registers and your
program won't work. And when you edit it, things move around and things
that used to work are now broke.
Now, any programmer who does this all day can manage it. Those of us
who drag out a PIC once a year to do a quick project tend to get
buried by those details. I want to hack out some code and have it work.
I don't want to go searching for errors caused by my forgetting some
processor quirk.
One option is to let someone else manage all those details. A compiler
should be smart enough to keep you out of trouble. I use PicBasic, but
there should be lots of others.
Second option is to use a processor that doesn't page memory. I think
the PIC18 series fixes up most of this mess, but I haven't tried 'em yet.
Think I might go with AVR if I didn't already have investment in tools
for PIC.
All boils down to what you're trying to accomplish. Can't think of any
reason to want to understand an obsolete part. In sample quantities,
all PICs are the same price...free.
mike
--
Return address is VALID.
500MHz Tek DSOscilloscope TDS540 $2200
http://nm7u.tripod.com/homepage/te.html
Wanted, 12.1" LCD for Gateway Solo 5300. Samsung LT121SU-121
Bunch of stuff For Sale and Wanted at the link below.
http://www.geocities.com/SiliconValley/Monitor/4710/
Byron A Jeff
-David Harper wrote:
-> All,
-> [Dave's questions about banking snipped.]
-
-If your objective is to understand the architecture of a 16F84, you're
-on the right track to understanding an obsolete and arcane part.
-There's only one reason to use paged/baanked memory...Price! And that
-advantage has long since been nullified by technological advances.
That's not true. The PIC has a legitimate reason for having a banked memory
architecture. It facilitates a uniform instruction set where virtually every
instruction executes in one instruction cycle.
The non Harvard architecture of the chip was constructed so that instructions
on file registers could hold a 7 bit address. As most parts have more than
128 addresses, banking is required in order to access them.
-
-While it's possible to understand the inner workings of a PIC16 part,
-the details of actaully making it work in practice will drive you nutz.
-All it takes is one mistake in setting the page registers and your
-program won't work. And when you edit it, things move around and things
-that used to work are now broke.
Not true for the data memory, and mostly no longer true for program memory
unless you cross a 2K page boundary.
-
-Now, any programmer who does this all day can manage it. Those of us
-who drag out a PIC once a year to do a quick project tend to get
-buried by those details. I want to hack out some code and have it work.
-I don't want to go searching for errors caused by my forgetting some
-processor quirk.
There's a simple solution to all of these problems, that David planned to
take anyway: use a high level language that hides all of those details.
Languages like JAL, XCSB, and PicBasic nullifies the vast majority of
banking issues.
And using the BANKSEL directive obviates most of the issues in assembly.
Finally if assembly programmers used the available linkers, it would handle
virtually all of the banking issues that arise.
-
-One option is to let someone else manage all those details. A compiler
-should be smart enough to keep you out of trouble. I use PicBasic, but
-there should be lots of others.
Right.
-
-Second option is to use a processor that doesn't page memory. I think
-the PIC18 series fixes up most of this mess, but I haven't tried 'em yet.
-Think I might go with AVR if I didn't already have investment in tools
-for PIC.
Most but not all. The PIC 18 has two directly accessible pages, and a MOVFF
instruction that can access memory from any bank.
-
-All boils down to what you're trying to accomplish. Can't think of any
-reason to want to understand an obsolete part. In sample quantities,
-all PICs are the same price...free.
Definite agreement on that statement.
BAJ
Nicholas O. Lindan
> Can't think of any reason to want to
> understand an obsolete part.
What's obsolete: IBM 360 c. 1963
Intel 8051 c. 1978
Intel 8x86 c. 1978
Motorola 68x c. 1979
PIC 16x5x c. 1990 (?)
It is obsolete only when it is not used anymore, not when
something zoomier comes on the market.
--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer: Electronics; Informatics; Photonics.
Remove spaces etc. to reply: n o lindan at net com dot com
psst.. want to buy an f-stop timer? nolindan.com/da/fstop/
Spehro Pefhany
<s...@sig.com> wrote:
>
>> Can't think of any reason to want to
>> understand an obsolete part.
>
>What's obsolete: IBM 360 c. 1963
> Intel 8051 c. 1978
> Intel 8x86 c. 1978
> Motorola 68x c. 1979
> PIC 16x5x c. 1990 (?)
>
>It is obsolete only when it is not used anymore, not when
>something zoomier comes on the market.
PIC16x54 (original and clones) is still used in huge quantity.. They
even have an untested version for China market consumer stuff.
By contrast, the F84 should not be used in new designs.
Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
sp...@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com
Sergio Masci
Byron A Jeff <by...@cc.gatech.edu> wrote in message
news:coi37q$4...@cleon.cc.gatech.edu...
> In article <41AB98C1...@netscape.net>, mike <spa...@netscape.net>
wrote:
> -David Harper wrote:
> -> All,
> -> [Dave's questions about banking snipped.]
> -
> -If your objective is to understand the architecture of a 16F84, you're
> -on the right track to understanding an obsolete and arcane part.
> -There's only one reason to use paged/baanked memory...Price! And that
> -advantage has long since been nullified by technological advances.
>
> That's not true. The PIC has a legitimate reason for having a banked
memory
> architecture. It facilitates a uniform instruction set where virtually
every
> instruction executes in one instruction cycle.
I agree. It makes the programmers job a little harder but it also frees him
to move the extra time overhead to a less critical part of the code. And if
you use sophisticated tools like the XCASM assembler (it can analyse the
code and insert the banking and paging instructions for you in an optimised
way) your only real problem is large arrays that wont fit in a single bank,
but you will always be able to find a problem with any MCU if you look hard
enough :-)
mike
> In article <41AB98C1...@netscape.net>, mike <spa...@netscape.net> wrote:
> -David Harper wrote:
> -> All,
> -> [Dave's questions about banking snipped.]
> -
> -If your objective is to understand the architecture of a 16F84, you're
> -on the right track to understanding an obsolete and arcane part.
> -There's only one reason to use paged/baanked memory...Price! And that
> -advantage has long since been nullified by technological advances.
>
> That's not true. The PIC has a legitimate reason for having a banked memory
> architecture. It facilitates a uniform instruction set where virtually every
> instruction executes in one instruction cycle.
>
> The non Harvard architecture of the chip was constructed so that instructions
> on file registers could hold a 7 bit address. As most parts have more than
> 128 addresses, banking is required in order to access them.
Ok, I admit to being confused. Are you saying that having a wider word
that lets you access all of the address space directly would compromise
the uniform instruction set? And why wouldn't you just use as many bits
in the word as required to address the machine? Cost/Price maybe???
Please explain what I'm missing.
snipped
Sergio Masci
mike <spa...@netscape.net> wrote in message
news:41AD3A46...@netscape.net...
Locallity.
Things that are related tend to be stored near each other. Consider a
program that is broken down into functions (or subroutines), parameters and
variables local to a function can be stored near each other (in a single
bank of RAM) This improves banking efficiency. Arrays don't need to be
grouped in this way because you need to use a pointer to reference elements
within them. The XCSB compiler uses this property to inprove efficiency.
Yes using wider words with bigger address fields would reduce the need for
banking but is it better to add the complexity to the tools needed to
program the PICs or to the PICs themselves? Use decent tools and banking is
not such an issue.
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use
how wide would you consider reasonable? 4k (12 bits)? 4k banks will seem an
annoyance to someone.
Bill Bowden
> -David Harper wrote:
>
> There's a simple solution to all of these problems, that David planned to
> take anyway: use a high level language that hides all of those details.
> Languages like JAL, XCSB, and PicBasic nullifies the vast majority of
> banking issues.
>
Any idea of the speed and size penality for using a high level language?
How much more memory is required to do the same task in Basic as
opposed to assembly?
-Bill
Wouter van Ooijen (www.voti.nl)
>that lets you access all of the address space directly would compromise
>the uniform instruction set? And why wouldn't you just use as many bits
>in the word as required to address the machine? Cost/Price maybe???
exactly.
Wouter van Ooijen
-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics
mike
Size only matters if it don't fit. Speed only matters if it ain't fast
enough.
If you're trying to save every penny of manufacturing cost and have
volume sufficient to support longer development time, you can probably
justify very low level programming. I do simple hobby stuff. With
BASIC, I can get it done quickly and it usually works the second or
third time. The parts that are too slow get tweeked with inline
assembly. And six months from now, I can figure out what I did.
You get the best of both worlds without all the detail work.
There are reasons not to use a compiler, but they don't apply to all of us.
Spehro Pefhany
Bowden) wrote:
>by...@cc.gatech.edu (Byron A Jeff) wrote in message news:<coi37q$4...@cleon.cc.gatech.edu>...
>> In article <41AB98C1...@netscape.net>, mike <spa...@netscape.net> wrote:
>
>> -David Harper wrote:
>>
>> There's a simple solution to all of these problems, that David planned to
>> take anyway: use a high level language that hides all of those details.
>> Languages like JAL, XCSB, and PicBasic nullifies the vast majority of
>> banking issues.
>
>>
>Any idea of the speed and size penality for using a high level language?
It varies. If you link in printf to do something really simple it
might be 50 times bigger. If the compiler writer is a better
programmer, it might even be smaller. I usually figure 50-100% bigger
(pretty much the next processor size up). Speed isn't as much of a
problem- usually only small parts need to go fast, so it's easy to
tweak them or substitute asm routines for those parts.
>How much more memory is required to do the same task in Basic as
>opposed to assembly?
Reasonably-written C is often more frugal with RAM because the
compiler industriously constructs a call tree and then aggressively
re-uses RAM for automatic variables.
Wouter van Ooijen (www.voti.nl)
>How much more memory is required to do the same task in Basic as
>opposed to assembly?
That depends too much on your programming skills to answer. You can
get 1 : 10 variation between programmers using the same language. You
might get 1 : 2 variation between a very experienced programmer using
a HLL versus assemblty, but using a good C compiler vmight reduce this
to maybe 1 : 1.2.
Spehro Pefhany
Bowden) wrote:
>Spehro Pefhany <spef...@interlogDOTyou.knowwhat> wrote in message news:<covrq0djc0heperon...@4ax.com>...
>> On 1 Dec 2004 00:09:36 -0800, the renowned wronga...@att.net (Bill
>> Bowden) wrote:
>>
>> >by...@cc.gatech.edu (Byron A Jeff) wrote in message news:<coi37q$4...@cleon.cc.gatech.edu>...
>> >> In article <41AB98C1...@netscape.net>, mike <spa...@netscape.net> wrote:
>>
>> >> -David Harper wrote:
>> >>
>> >> There's a simple solution to all of these problems, that David planned to
>> >> take anyway: use a high level language that hides all of those details.
>> >> Languages like JAL, XCSB, and PicBasic nullifies the vast majority of
>> >> banking issues.
>>
>> >>
>> >Any idea of the speed and size penality for using a high level language?
>>
>> It varies. If you link in printf to do something really simple it
>> might be 50 times bigger. If the compiler writer is a better
>> programmer, it might even be smaller. I usually figure 50-100% bigger
>> (pretty much the next processor size up). Speed isn't as much of a
>> problem- usually only small parts need to go fast, so it's easy to
>> tweak them or substitute asm routines for those parts.
>>
>> >How much more memory is required to do the same task in Basic as
>> >opposed to assembly?
>>
>> Reasonably-written C is often more frugal with RAM because the
>> compiler industriously constructs a call tree and then aggressively
>> re-uses RAM for automatic variables.
>>
>>
>> Best regards,
>> Spehro Pefhany
>
>So, how much more ROM memory would you guess this CRC routine
>requires written in BASIC or C, verses assembly?
<snip>
About 65% more in C, with no attempt to optimize it. Some of it the
extra is bank select instructions.
Hopefully Basic wouldn't be that much worse, assuming the variable
types are defined properly, and assuming you have the signed/unsigned
distinction in the version of Basic being used.
A CRC routine that's calculated on-the-fly is a decent example of
something you might want to use an assembly routine (or inline
assembly) for. It's tiny and time-critical, and by using a fast simple
routine you avoid the need for memory-hogging tables.
Robert Baer
..And using BASIC with integers, single loops, case statements, etc
after compiling can give 1:1 correspondence with assembly code.
A double loop is less efficent and can be fixed in assembly after
compiling.
Bill Bowden
> Bowden) wrote:
>
> >by...@cc.gatech.edu (Byron A Jeff) wrote in message news:<coi37q$4...@cleon.cc.gatech.edu>...
> >> In article <41AB98C1...@netscape.net>, mike <spa...@netscape.net> wrote:
>
> >> -David Harper wrote:
> >>
> >> There's a simple solution to all of these problems, that David planned to
> >> take anyway: use a high level language that hides all of those details.
> >> Languages like JAL, XCSB, and PicBasic nullifies the vast majority of
> >> banking issues.
>
> >>
> >Any idea of the speed and size penality for using a high level language?
>
> It varies. If you link in printf to do something really simple it
> might be 50 times bigger. If the compiler writer is a better
> programmer, it might even be smaller. I usually figure 50-100% bigger
> (pretty much the next processor size up). Speed isn't as much of a
> problem- usually only small parts need to go fast, so it's easy to
> tweak them or substitute asm routines for those parts.
>
> >How much more memory is required to do the same task in Basic as
> >opposed to assembly?
>
> Reasonably-written C is often more frugal with RAM because the
> compiler industriously constructs a call tree and then aggressively
> re-uses RAM for automatic variables.
>
>
> Best regards,
> Spehro Pefhany
So, how much more ROM memory would you guess this CRC routine
requires written in BASIC or C, verses assembly?
REM -----------------BASIC version ----------------------------
crc:
c = ch AND 255
FOR i = 0 TO 7
IF ((c AND 128) <> 0) AND ((crc AND 32768) = 0) OR ((c AND 128)
= 0) AND ((crc AND 32768) <> 0) THEN
inp. = 4129
ELSE inp. = 0
END IF
crc = ((crc * 2) XOR inp.) AND 65535
c = (c * 2) AND 255
NEXT i
RETURN
------------------------------------------------------
REM ------------ CRC ASSEMBLY version -----------------
CRC
clrf IN_2
movfw INTEGER
xorwf CRC_HIGH,0
iorwf IN_2,f ; First XOR result is in IN_2 (bit 7)
rlf INTEGER,f
bcf STATUS,0 ; Clear status bit so it doesn't shift 1
rlf CRC_HIGH,f ; Shift CRC_HIGH byte
bcf STATUS,0
rlf CRC_LOW,f
btfsc STATUS,0 ; Test for 1 as MSB of low byte
bsf CRC_HIGH,0 ; Put 1 in bottom of high byte
clrf IN_1
btfsc CRC_HIGH,4 ; Test bit 4
bsf IN_1,7 ; Put bit into MSB of IN_1
movfw IN_2 ; Get result of previous test
xorwf IN_1,f ; Second XOR result is in IN_1 (bit 7)
btfsc IN_1,7
bsf CRC_HIGH,4 ; Put 2nd result into bit 4 if 1
btfss IN_1,7
bcf CRC_HIGH,4 ; Put 2nd result into bit 4 if 0
clrf IN_1 ; Get ready for next test
btfsc CRC_LOW,5 ; Look at bit 5
bsf IN_1,7 ; Put bit 5 into MSB of IN_1
movfw IN_2
xorwf IN_1,f ; Third XOR result is in IN_1 (bit 7)
btfsc IN_1,7 ; Test for 1
bsf CRC_LOW,5 ; If 1, put it into bit 5 of crc low byte
btfss IN_1,7
bcf CRC_LOW,5 ; If 0, put it into bit 5
btfsc IN_2,7 ; Look at first result again
bsf CRC_LOW,0 ; If 1, put it into low bit of crc low byte
decfsz COUNTER,f ; Exit after 8th bit (counter=0)
goto CRC ; Do next bit
return
-Bill
Sergio Masci
Bill Bowden <wronga...@att.net> wrote in message
news:ad025737.04120...@posting.google.com...
>
> So, how much more ROM memory would you guess this CRC routine
> requires written in BASIC or C, verses assembly?
>
> REM -----------------BASIC version ----------------------------
>
> crc:
> c = ch AND 255
> FOR i = 0 TO 7
> IF ((c AND 128) <> 0) AND ((crc AND 32768) = 0) OR ((c AND 128)
> = 0) AND ((crc AND 32768) <> 0) THEN
>
> inp. = 4129
> ELSE inp. = 0
> END IF
> crc = ((crc * 2) XOR inp.) AND 65535
> c = (c * 2) AND 255
> NEXT i
>
> RETURN
> ------------------------------------------------------
>
> REM ------------ CRC ASSEMBLY version -----------------
>
> CRC
<snipped 33 assembler instructions>
> return
>
> -Bill
Hi Bill,
The following CRC function is a standard XCSB library function. It is
written in XCSB (XC Structured BASIC) and compiles to 31 machine code
instructions.
file://---------------------------------------------------------------------
-
file://---------------------------------------------------------------------
-
proc uint CRC_byte(uint acc, ubyte data)
ubyte k
ubyte acc2
for k=8 while k>0 step k-=1 do
acc2 = acc >> 8
acc = acc << 1
if ((data ^ acc2) & 0x80) != 0 then
acc = acc ^ CRC_POLY
endif
data = data << 1
done
return acc
endproc
file://---------------------------------------------------------------------
-
file://---------------------------------------------------------------------
-
004C CRC_byte
004C 30 08 movlw 8&255
004D 00 A8 f:28 movwf k
004E for_loop_0000
004E 08 28 f:28 movf k,w
004F 3C 00 sublw 0&255
0050 1C 03 btfss STATUS,C
0051 28 53 p:0053 goto xif_false_0
0052 28 66 p:0066 goto for_end_0000
0053 xif_false_0
0053 08 26 f:26 movf acc+1,w
0054 00 A9 f:29 movwf acc2
0055 10 03 bcf STATUS,C
0056 0D A5 f:25 rlf acc+0
0057 0D A6 f:26 rlf acc+1
0058 08 27 f:27 movf data,w
0059 06 29 f:29 xorwf acc2,w
005A 39 80 andlw 128 & 255
005B 3A 00 xorlw 0 & 255
005C 19 03 btfsc STATUS,Z
005D 28 62 p:0062 goto x_else_0000
005E 30 21 movlw 4129 & 255
005F 06 A5 f:25 xorwf acc+0
0060 30 10 movlw 4129 >> 8
0061 06 A6 f:26 xorwf acc+1
0062 x_else_0000
0062 10 03 bcf STATUS,C
0063 0D A7 f:27 rlf data
0064 03 A8 f:28 decf k
0065 28 4E p:004E goto for_loop_0000
0066 for_end_0000
0066 08 26 f:26 movf acc+1,w
0067 00 A2 f:22 movwf result+1
0068 08 25 f:25 movf acc,w
0069 00 A1 f:21 movwf result
006A 28 6B p:006B goto
CRC_byte_func_exit_point
006B CRC_byte_func_exit_point
Total code space used for function
0x6B - 0x4C = 0x1F = 31 machine code instructions
plus 0 to 11 instructions for prolog
plus -4 to +4 instructions for epilog
The extra instructions for the prolog and epilog are dependent on the
way the function call is optimised which is dependent on the call
stratergy spcified by the programmer and the code calling the function.
Spehro Pefhany
<ser...@NO.SPAM.xcprod.com> wrote:
> 0x6B - 0x4C = 0x1F = 31 machine code instructions
>
>plus 0 to 11 instructions for prolog
>plus -4 to +4 instructions for epilog
>
>The extra instructions for the prolog and epilog are dependent on the
>way the function call is optimised which is dependent on the call
>stratergy spcified by the programmer and the code calling the function.
>
>
>Regards
>Sergio Masci
In C, I get 19-38 instructions for Sergio's algorithm, depending on
optimization.
Sergio Masci
Spehro Pefhany <spef...@interlogDOTyou.knowwhat> wrote in message
> On Fri, 3 Dec 2004 20:22:58 -0000, the renowned "Sergio Masci"
> <ser...@NO.SPAM.xcprod.com> wrote:
>
>
> > 0x6B - 0x4C = 0x1F = 31 machine code instructions
> >
> >plus 0 to 11 instructions for prolog
> >plus -4 to +4 instructions for epilog
> >
> >The extra instructions for the prolog and epilog are dependent on the
> >way the function call is optimised which is dependent on the call
> >stratergy spcified by the programmer and the code calling the function.
> >
> >
> >Regards
> >Sergio Masci
>
>
> In C, I get 19-38 instructions for Sergio's algorithm, depending on
> optimization.
>
>
>
> Best regards,
> Spehro Pefhany
I would be interested to see the generated code and to know which compiler
you are using.
Spehro Pefhany
<ser...@NO.SPAM.xcprod.com> wrote:
>
>
>I would be interested to see the generated code and to know which compiler
>you are using.
I think I have misspoken on the size- the assy file was hiding some of
the instructions for some reason. Here's the code from the program
memory (some manual transcription, so it may not be 100% correct).
It's HitechC for 16F. 27 program words including two bank select
instructions.
0007E5 MOVLW 0x8
0007E6 BCF 0x3, 0x5
0007E7 BCF 0x3, 0x6
0007E8 MOVWF 0x2E
0007E9 MOVF 0x2b,W
0007EA MOVWF 0x2d
0007EB BCF 0x3, 0
0007EC RLF 0x2a, F
0007ED RLF 0x2b, F
0007EE MOVF 0x2c, W
0007EF XORWF 0x2d, W
0007F0 MOVWF 0x40
0007F1 BTFSS 0x40, 0x7
0007F2 GOTO 0x7f7
0007F3 MOVLW CRC_LOW
0007F4 XORWF 0x2a, F
0007F5 MOVLW CRC_HIGH
0007F6 XORWF 0x2b, F
0007F7 BCF 0x3, 0
0007F8 RLF 0x2c,F
0007F9 DECFSZ 0x2e,F
0007FA GOTO 0x7e9
0007FB MOVF 0x2b, W
0007FC MOVWF 0x41
0007FD MOVF 0x2a, W
0007FE MOVWF 0x40
0007FF RETURN
Sergio Masci
Spehro Pefhany <spef...@interlogDOTyou.knowwhat> wrote in message
Thank you for that.
It seems that the Hitech C compiler has noticed an optimisation in the "for
loop" that the XCSB compiler missed, essentially converting:
;----------
k = 8
loop_start
if k <= 0 then goto loop_end
...
k = k - 1
goto loop_start
loop_end
;----------
into
;----------
k = 8
loop_start
...
if (k = k - 1) != 0 then goto loop_start
;----------
Even so, it is still reassuring to see how close the output of both
compilers is. 26 machine code instructions for the Hitech C compiler and 31
for the XCSB compiler. If you look back at a previous post in this thread
you will see that I mentioned that the function epilog can actually reduce
the length of the overall code by 4 instructions (depending on optimisation)
So the code generated by the XCSB compiler would be only 27 machine code
instructions.
I will have to put this "for loop" optimisation on my todo list :-)
Regards
Sergio Masci
http://www.xcprod.com/titan/XCSB - optimising PIC compiler
FREE for personal non-commercial use.
Bill Bowden
> Bill Bowden <wronga...@att.net> wrote in message
> news:ad025737.04120...@posting.google.com...
>
> >
> > So, how much more ROM memory would you guess this CRC routine
> > requires written in BASIC or C, verses assembly?
> >
> > REM -----------------BASIC version ----------------------------
> >
> > crc:
> > c = ch AND 255
> > FOR i = 0 TO 7
> > IF ((c AND 128) <> 0) AND ((crc AND 32768) = 0) OR ((c AND 128)
> > = 0) AND ((crc AND 32768) <> 0) THEN
> >
> > inp. = 4129
> > ELSE inp. = 0
> > END IF
> > crc = ((crc * 2) XOR inp.) AND 65535
> > c = (c * 2) AND 255
> > NEXT i
> >
> > RETURN
> > ------------------------------------------------------
> >
> > REM ------------ CRC ASSEMBLY version -----------------
> >
> > CRC
> <snipped 33 assembler instructions>
> Hi Bill,
>
> The following CRC function is a standard XCSB library function. It is
> written in XCSB (XC Structured BASIC) and compiles to 31 machine code
> instructions.
>
Yes, that's amazing a compiler can be so efficient to
produce a assembly code of similar size to a manually
written assembly routine. The crc routine I wrote
was developed from a drawing of the bit movements
of the two CRC bytes as they are exored against
sequential bits of the data byte. I don't know why the
various bits were chosen, but probably because they yield
the most unique crc.
The flow is something like this:
Basically, the MSB bit of the data is XORed against bit 15 of
the 16 bit crc. That result is XORed with bit 11 of the crc and
the result is pushed up the stack underneath bit 12 (15 disappears).
The first result is then XORed with bit 4 of the crc and pushed
on the stack under bit 5 (old bit 11 is pushed off). The last
step is to XOR the first result against 0 and the result pushed
on the bottom of the stack (old bit 4 disappears). Here's a crude
diagram:
DATA IN (MSB)---> XOR <------- 15 CRC (MSB)
| 14
| 13
| 12
|----XOR-->
| 11 11
| 10
| 9
| 8
| 7
| 6
| 5
|----XOR-->
| 4 4
| 3
| 2
| 1
| 0
|----XOR-->
0
-Bill