Serial busses

[BillO]

Is there any equivalent out there to the PCF8584 or PCA9564 for SPI? I can't seem to find anything and am wondering why there would be enough demand for I2C that warrants two competing chips, but no demand for a simple parallel to SPI chip. It makes little sense. Or am I missing something? Are CPU's with a parallel bus just not invited to the SPI party?

I know of 65SPI, but I hate PLCC devices, plus I'd have an issue programming it.

[Alarm Siren]

I had a quick look around for such a device, and it does seem you're right, they're just not there (or at least, difficult to find).

I suspect its because SPI is easy enough to bitbang in software so long as you have 4+ GPIO pins spare, whereas I2C is comparatively arcane.

I've also noticed that, as a general rule, almost everything that comes in SPI is also available as I2C, but the opposite is not always true.

P.S. Thanks for those I2C bridge chips' part numbers. I've been looking for something just like them and not been able to find them so *yoink*.

[MichaelM]

I also looked up at least one of the devices for which you were searching for alternates, and I agree with Alarm Siren. If you'd prefer a solution like the PCF8584, I think that you can construct it from a CPLD, which is going to be some type of SMD device. Since that package style is not on your bucket list at the moment, at one time there were a number of PIC processors that provided a parallel slave interface similar to that found on the PCF8584. Perhaps a DIP version of one those PIC processors would provide the functionality that you want. In addition, to providing an SPI port, many also provided an I2C and a UART. Properly programmed to work with a 6502/65C02-based system, such a device would provide all of the basic serial interfaces. I identified these SMD devices, but I am sure that they also have a family of DIP devices: PIC18F6585/8585/6680/8680.

[Alarm Siren]

I had a quick look at the PIC18F[etc] datasheet, and it looks to me like the parallel interface you mention is actually a master, not a slave. So, you wouldn't be able to have the 6502 control the PIC as if it were a slave I/O device using that parallel interface; instead you'd have to have the two sharing a common RAM, similar to the Apple II's GPU and CPU setup. Perfectly possible, but perhaps a smidge more complex than desired. A good spot all the same, I wasn't aware on any MCU with an external parallel bus like it.

[GARTHWILSON]

Alarm Siren wrote:

I had a quick look at the PIC18F[etc] datasheet, and it looks to me like the parallel interface you mention is actually a master, not a slave.  So, you wouldn't be able to have the 6502 control the PIC as if it were a slave I/O device using that parallel interface; instead you'd have to have the two sharing a common RAM, similar to the Apple II's GPU and CPU setup.  Perfectly possible, but perhaps a smidge more complex than desired.  A good spot all the same, I wasn't aware on any MCU with an external parallel bus like it.

I haven't looked that closely at the PIC18's, but many of the PIC16's have a PSP, parallel slave port, and I suspect the PIC18's aren't much different in that regard.  You can put it right on the processor's data bus, but it's slower than something like a 6522 because you have to for example write the data to the PIC, then give it enough time to see it and do something with that info, then come back again and tell it what it's supposed to do with that data, then again give it more time to process it, maybe polling it in between to see when it's ready for the next thing, and so on.  If you want to read data, you'll tell it what you want to read, give it time to get that data ready to output, come back later to read it, etc..  For this reason, it would be better to use the PSP only if the amount of data is rather small compared to the job the PIC will be doing with it.  Edit, 10/19/18:  Microchip's ap. note AN579, about using the PSP, is at http://ww1.microchip.com/downloads/en/A ... 00579b.pdf .

[Waveguide]

How about using the '299 shift register as a base for an SPI interface?

http://www.ti.com/lit/ds/symlink/cd74hct299.pdf

Some extra logic would be required but I think it could be done.

[BillO]

GARTHWILSON wrote:

..., but it's slower than something like a 6522 ...

I had a look at your serial code for the 6522. Excuse my inexperience, but that did not look like any assembler code I cut my teeth on centuries ago. Do you mind my asking what assembler you use?

[MichaelM]

As Garth indicated, the Parallel Slave Port (PSP) is also a feature of the PIC16 processor family. He's also quite correct in that using that interface from a 6502/65C02 system would entail some careful programming in order to transfer any significant amounts of data. However, if the processors are running tight loops on the interface, or an interrupt driven interface on the 6502/65C02 side, the overall performance may be suitable for your application.

The 40-pin version of the PIC16F87XA processor family supports the PSP like the PIC18F family I found yesterday.

[GARTHWILSON]

BillO wrote:

GARTHWILSON wrote:

..., but it's slower than something like a 6522 ...

I had a look at your serial code for the 6522.  Excuse my inexperience, but that did not look like any assembler code I cut my teeth on centuries ago.  Do you mind my asking what assembler you use?

I'm not sure which serial code you're referring to; maybe http://wilsonminesco.com/6502primer/SPI.ASM ? The comments there include:

Code: Select all

 ; For SEND_BYT and RCV_BYT below, I use program structures discussed in my web page
 ; http://wilsonminesco.com/StructureMacros/ .  The source code for implementing them on the C32 assembler is at
 ; http://wilsonminesco.com/StructureMacros/STRUCMAC.ASM , but you can undoubtedly see what they will assemble
 ; if you want to do it without the macros.  I used them here to make it more clear what is happening.

Cross-32 (C32) is a very nice macro assembler originally from Universal Cross Assemblers in Canada, but now is being sold by Data Sync Engineering.  [Edit, 2023:  It's gone.  I'm trying to find out where else we can get it, or if I could distribute it myself.]  For $99, you get an assembler that's good for at least about 50 different processors, and they give you the information to make up the tables to assemble even for a processor of your own design, so you don't have to write your own assembler for it.  It's an excellent, powerful macro assembler that runs on your PC.  It adheres to the manufacturer's recommended notation for 65xx assembly language.

The structure macros however are my own creation—although as soon as I made them, I found that others have done the same kind of thing.  As with any macro, they hide the confusing or ugly internals, so that once you have them written and debugged, they do the exact same thing you would do by hand, but now you don't have to look at those innards anymore.  Your code becomes more clear and concise; and since you can see what you're doing better, you become more productive and produce fewer bugs.  A simple example is this loop where you want to keep looping until the Z flag is set:

Code: Select all

        BEGIN
           <do stuff>
           <do stuff>
           <do stuff>
        UNTIL_ZERO     ; ("UNTIL_EQ" would do the same thing)

The "UNTIL_ZERO" just assembles a BNE (as you would expect), but you don't need a label, because the assembler remembered where to branch back to because of the "BEGIN."  You can nest these too, for example having another similar loop inside this one, and each branch will go to the right target address.  You can of course still use the normal instructions you're already used to as well, like if you want to use a label and have another routine jump into the middle of this one.

Having the macros never limits you.  They only open up more possibilities.  See the article at http://wilsonminesco.com/StructureMacros/ which starts with the very basics of macros and works its way up to the program structure macros.  It has links to the macro source code and to further explanation in the 6502 stacks treatise for those who want to go further.

OTOH, if you're referring to the I²C code at http://wilsonminesco.com/6502primer/GENRLI2C.ASM, I wrote that before I had the 65c02 structure macros going, and it has several sections, including 65c02 assembly, Forth, and PIC12 assembly.  From the file:

Code: Select all

; This file has five sets of source code:
; A. 65c02 source code for running the I2C interface as shown in the 6502
;    primer's "potpourri" page.  I ran it with the actual circuit just enough
;    to have a degree of confidence the I'm not steering you wrong.
; B. a section on changes to make if you use different bit numbers
; C. my working Forth source code for using the 24256 32Kx8 I2C EEPROM.  Even if
;    you don't know Forth, much of it should be pretty clear as to what order
;    things need to happen in to interface to this 8-pin serial EEPROM.
;    It is profusely commented.
; D. my working Forth code for operating the MAX520 quad D/A converter.
; E. my working PIC code for running a tiny 24c00 EEPROM that was put as a
;    separate die in the PIC12CE673 we used for a product.

I have a list of 65xx assemblers on my links page, at http://wilsonminesco.com/links.html#assem .  Most of them are free, and a couple of them were written by our own forum members.