Joined: Fri Aug 30, 2002 1:09 am
Posts: 8543
Location: Southern California
|
kc5tja wrote: In fact, the 6502 and 65816 architectures are finding themselves in an increasing number of embedded environments, often times displacing the ARM processor!
Last year, I wrote to Bill Mensch asking for good reasons to use the 65-family processors, for an article. One of the things he said was,
The 65xx architecture is sold in hundreds of millions of chips per year, and the volume is growing. We now find engineers porting applications that might have first been market-tested on PCs or ARM processors and finding the 65xx economy (both business and silicon) attractive and well worth the effort to change to the 65xx.
(emphasis added.)
The 65c02 is indeed going into new designs, but in microcontrollers, not separate microprocessors. These go into all kinds of consumer items like camcorders, and into automotive applications, as well as even life-support equipment. Most of WDC's business seems to be in licensing the IP, not selling parts. They do have a couple of off-the-shelf microcontrollers, the 65134 and 65265, but these off-the-shelf ones don't come in a lot of versions like the PICs do. Unfortunately they're also not programmable on the workbench like the PICs are, but it sounds like that may be changing. The microcontrollers being made today with 65c02 cores in them and being sold at the rate of hundreds of millions per year are mostly custom ICs.
Like Icy, I have designed Microchip PICs into several products too, and not because I like them—actually I hate the decrepit RISC processor at their heart—but because they're available in so many versions, from lots of stocking distributors, they're easy to program on the workbench, some even have complete onboard fixed-frequency clock oscillators, etc.. A 20MHz 65c02 can do a job a lot faster than a 20MHz PIC16 though, if the PIC can do it at all. PICs are good for tiny jobs, but otherwise have severe limitations.
I have a lot of code comparisons between 65c02 and PIC16 written down, but in looking at them again I can see why I haven't just taken 15 minutes to compile them clearly for this website. There's too much there. I will give a few examples here, and just say that there's more where that came from.
Take the example of a single-byte table look-up, where table might be anywhere in ROM:
Code: 6502: 4-5 clocks LDA address,X
Code: PIC: 48 clocks, to do what the 6502 does in 4 or 5 clocks! (This code is
from slide 234 of the seminar, and the same as what's in AN556 Example 5.)
ORG 0x10 ; Page 0
MOVLW LOW (Table) ; Low byte of address 4
ADDWF offset,F ; added to offset. 4
MOVLW HIGH (Table) ; High 5 bits of address 4
BTFSC STATUS, C ; Page crossed? 4
ADDLW 1 ; Yes...Inc high address 4
MOVWF PCLATH ; Load high address 4
MOVF offset,W 4
CALL Table 8
ORG H'800' ; page 1
Table:
ADDWF PCL,F ; Calc table offset 4
RETLW 'A' 8
RETLW 'B'
RETLW 'C'
RETLW 'D'
etc.
Edit, 1/7/13: I just learned of another PIC stinker: If an interrupt hits immediately before the PCL-modifying instruction above, it will misbehave after the return from interrupt, and you'll get the RETLW 'A' even if you wanted a different one; so you have to disable interrupts for the table look-up further lengthening the code and slowing things down and causing a longer interrupt latency. This is from AN556, bottom of page 3.
The PIC has to use different code if the table is in RAM. It can't use the same code for ROM and RAM like the 6502 can. Furthermore, if you index past the end of the table in ROM, you won't just get bad data—you'll crash.
Or consider the disabling of interrupts. The PIC's problem here is that if an interrupt hits during the instruction to clear the Global Interrupt Enable (GIE) bit, the interrupt will be taken, and if the ISR saves the status, the old status will be restored at the end, along with the GIE bit set. So, after clearing that bit, you have to check to see if it's really clear, and go back to try again if it's not.
Code: 6502: SEI ; 2 clocks to disable interrupts reliably.
Code: PIC: ; This loop is from the caveat on
loop: BCF INTCON,GIE ; P.2-767 of '95-'96 data book.
BTFSC INTCON,GIE ; 12 clocks minimum, 28 clocks if you
GOTO loop ; have to loop back even once.
On the 6502, no jump or branch, conditional or otherwise (excluding indirects and subroutine calls), ever takes more than 4 clocks, and they usually take 3. On the PIC however, GOTOs take 8 clocks, but another 8 clocks are required for MOVLW xx and MOVWF PCLATH for longer jumps. If W must be saved with MOVWF and MOVF xx,W during the latter process, yet another 8 clocks are wasted. This makes for a total of 24 clocks to do what the 6502 does in 3.
The PIC can't shift, so if you want to shift something, so you have to rotate and then AND-out the bits that should have ended up as 0s. PIC also can't rotate in W (which is like the 6502's accumulator), so you might have to put the number in a variable. For the following example, shift right 2 bit positions W (PIC) or A (6502):
Code: PIC: 16 clocks 6502: 4 clocks
MOVWF TEMP_W 4
RRF TEMP_W,F 4 LSR A 2
RRF TEMP_W,W 4 LSR A 2
ANDLW B'00011111' 4
Edit, 2/4/12: For a PIC16F project, I just got the code from Microchip's Embedded Control Handbook Update for dividing a 32-bit unsigned number by a 16-bit one, to get a 16-bit quotient and remainder. It's 237 instructions (obviously I won't list it here), to do what the 6502 does in just 35!!!
The 6502's interrupt sequence is only 7 clocks, including pushing the status register. Pushing the accumulator (like PIC's W) takes another 3. The PIC's interrupt sequence is 8 clocks minimum, but if you want to save the status and W, you need about 28 clocks to do what the 6502 does in 11—and then the PIC's is not re-entrant.
PIC16F's 8-level return stack is not enough. With good programming practices, I overflowed it, and the processor crashed when it unwound its way out. The 6502's stack is 16 times as deep (128 2-byte addresses), which has proven to be many times what you need for most applications.
When I first started working with PICs, as I went through programming examples in the Microchip books, I wrote 65c02 code next to the PIC code to help myself understand it better. I soon began to realize that the 65c02 code was consistently shorter and took about half as many clocks to execute as the PIC's code.
PIC's lack of stack access and its shallow stack depth are very limiting.
PIC's page- and bank-switching requirements waste memory and execution time, and make the code more unreadable.
PIC's instruction set is very limited.
PIC's Harvard architecture, separating program from data, makes it harder to work with.
PIC cannot do an indirect or indirect indexed GOTO or CALL.
PIC has no address modes at all with indexing.
PIC's backward subtraction (F-W, instead of W-F) usually lengthens the code, and is quite confusing.
Since, as Icy said, the PIC's logic is backwards and confusing, I start my PIC source code with macro definitions named after 6502 mnemonics to make things more clear, like BEQ.
Edit 12/7/13: Admittedly PIC16F1's and PIC18's have come in to fix a few of the PIC16 problems above, now many years later. It took Microchip many years to do this, and what they have is still rather mickey-mouse compared to the 6502.
The 65c02 lends itself to more intuitive programming. Howard Speegle, the president of Diva Automation, Inc., says he finds it easier to envision a solution with the 65c02 than with the others of the dozen processors he has used, and he can develop the application faster and with less bugs with the 65c02.
I understand one of WDC's licensees is running a 65c02 microprocessor inside a custom IC (ASIC) at 200MHz. Certainly if the PIC can be so successful today with its comparatively lousy processor core, there is no reason to think the 65c02 has no future or even a present._________________ http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?
Last edited by GARTHWILSON on Sat Feb 04, 2012 8:14 pm, edited 3 times in total.
|
|
Login
Register
FAQ
Search
