Learning to use PICS

[Byron A Jeff]

In article <364fd697.0411290907.7a86f50b@posting.google.com>,
David Harper <dave.harper@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

 

[mike]

David Harper 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 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

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]

In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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.

-
-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

 

[Spehro Pefhany]

On Tue, 30 Nov 2004 15:58:11 GMT, the renowned "Nicholas O. Lindan"
<see@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"
speff@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 <byron@cc.gatech.edu> wrote in message
news:coi37q$4t6@cleon.cc.gatech.edu...

In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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

Regards
Sergio Masci

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

 

[mike]

Byron A Jeff wrote:

In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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
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/

 

[Sergio Masci]

mike <spamme0@netscape.net> wrote in message
news:41AD3A46.7070504@netscape.net...

Byron A Jeff wrote:
In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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.

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.

 

[Wouter van Ooijen (www.vo]

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???

exactly.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics

 

[mike]

Bill Bowden wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<coi37q$4t6@cleon.cc.gatech.edu>...

In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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?
How much more memory is required to do the same task in Basic as
opposed to assembly?

-Bill

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.
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/

 

[Spehro Pefhany]

On 1 Dec 2004 00:09:36 -0800, the renowned wrongaddress@att.net (Bill
Bowden) wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<coi37q$4t6@cleon.cc.gatech.edu>...
In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Bill Bowden]

Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote in message news:<covrq0djc0heperonadagv27mcjp2dvkdp@4ax.com>...

On 1 Dec 2004 00:09:36 -0800, the renowned wrongaddress@att.net (Bill
Bowden) wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<coi37q$4t6@cleon.cc.gatech.edu>...
In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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

 

[Wouter van Ooijen (www.vo]

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?

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.


Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics

 

[Robert Baer]

"Wouter van Ooijen (www.voti.nl)" wrote:

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?

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.

Wouter van Ooijen

-- ------------------------------------
http://www.voti.nl
Webshop for PICs and other electronics
http://www.voti.nl/hvu
Teacher electronics and informatics

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

 

[Spehro Pefhany]

On 2 Dec 2004 23:19:43 -0800, the renowned wrongaddress@att.net (Bill
Bowden) wrote:

Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote in message news:<covrq0djc0heperonadagv27mcjp2dvkdp@4ax.com>...
On 1 Dec 2004 00:09:36 -0800, the renowned wrongaddress@att.net (Bill
Bowden) wrote:

byron@cc.gatech.edu (Byron A Jeff) wrote in message news:<coi37q$4t6@cleon.cc.gatech.edu>...
In article <41AB98C1.8000002@netscape.net>, mike <spamme0@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.


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Sergio Masci]

Bill Bowden <wrongaddress@att.net> wrote in message
news:ad025737.0412022319.194bd35d@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.


Regards
Sergio Masci

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

 

[Spehro Pefhany]

On Fri, 3 Dec 2004 20:22:58 -0000, the renowned "Sergio Masci"
<sergio@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
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Sergio Masci]

Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:frm1r01bff2sjiubgl6lnid2h7rod5igst@4ax.com...

On Fri, 3 Dec 2004 20:22:58 -0000, the renowned "Sergio Masci"
sergio@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.

Regards
Sergio Masci

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

 

[Spehro Pefhany]

On Sat, 4 Dec 2004 00:53:57 -0000, the renowned "Sergio Masci"
<sergio@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


Best regards,
Spehro Pefhany
--
"it's the network..." "The Journey is the reward"
speff@interlog.com Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog Info for designers: http://www.speff.com

 

[Sergio Masci]

Spehro Pefhany <speffSNIP@interlogDOTyou.knowwhat> wrote in message
news:q7i2r0tfniq7smkrvlai7djkad2gc9pia6@4ax.com...

On Sat, 4 Dec 2004 00:53:57 -0000, the renowned "Sergio Masci"
sergio@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


Best regards,
Spehro Pefhany

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]

"Sergio Masci" <sergio@NO.SPAM.xcprod.com> wrote in message news:<41b0ca26$0$1073$db0fefd9@news.zen.co.uk>...

Bill Bowden <wrongaddress@att.net> wrote in message
news:ad025737.0412022319.194bd35d@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