Learning to use PICS

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

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

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

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/

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/

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

memory

every

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

- optimising PIC compiler FREE for personal non-commercial use

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/

memory

every

instructions

than

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

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

exactly.

Wouter van Ooijen

-- ------------------------------------

Webshop for PICs and other electronics Teacher electronics and informatics

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.

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

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

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

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

-- ------------------------------------

Webshop for PICs and other electronics 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.

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

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

- optimising PIC compiler FREE for personal non-commercial use

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

I would be interested to see the generated code and to know which compiler you are using.

Regards Sergio Masci

- optimising PIC compiler FREE for personal non-commercial use