I added a Read Only mode bit to the Status and Control registers which would allow your to set this mode and then just read the SPI Data register to get the previously shifted byte and automatically start a new shift sequence. The outgoing data will be $00 (I need to confirm that). This will allow for a fast read only mode when needed.
I remember reading in a Maxim appnote (I'll have to dig it up, I can't remember where I put it) that when reading data from an MMC card in SPI mode, the recommendation is for the MOSI wire to be at logic '1' (ie "sending" $FF). You may want to look further into it.
It would be impossible to satisfy the needs of every Slave device in the default configuration.
If special conditions exist with an SPI slave, then manual control of the outgoing data would need to be performed, i.e., don't use Fast Receive mode but rather write $FF (or any other required pattern) to the SPI data register to initial a transfer.
Again, as kc5tja pointed out, this device fills the needs of layer 1. Your SPI device drivers can be designed to meet the needs of higher layer protocols.
I am still taking input, including the need for the ENA flag, so please feel free to comment.
I am currently refining the datasheet and contacting suppliers to get the lowest possible price of these chips. I hope to get a few beta devices out soon for others to test and hope to have the final configuration ready by Oct-Dec.
If you have access to several different SPI devices and can prototype my device into your 6502/65816 system, then contact me via PM or email for beta test opportunities.
I remember reading in a Maxim appnote...that when reading data from an MMC card in SPI mode, the recommendation is for the MOSI wire to be at logic '1' (ie "sending" $FF). You may want to look further into it.
Quote:
It would be impossible to satisfy the needs of every Slave device in the default configuration.
I don't see this as being a problem unless the MISO data was replacing the MOSI data in the shifting process, in the same 8-bit register. If the MISO and MOSI data registers are separate, the same MOSI data could keep getting sent over and over until you change it. You could set it once to 00 or FF or anything in between, and then read to your heart's content, and the output value remains intact.
I don't see this as being a problem unless the MISO data was replacing the MOSI data in the shifting process, in the same 8-bit register. If the MISO and MOSI data registers are separate, the same MOSI data could keep getting sent over and over until you change it. You could set it once to 00 or FF or anything in between, and then read to your heart's content, and the output value remains intact.
The MOSI and MISO registers are seperate. However, I currently have the D0 input at the outgoing latch/shift register set to 0. I could map the D7 output back to D0 input and that would maintain the initial value.
One option might be to change ENA to just tristate the SDO pin when no write needed mode is enabled. The reason for this is that many SPI devices allow a "three wire" mode where MOSI and MISO are connected to each other to form a "SDATA", where each device tristates it's output pin when it isn't outputting data.
I was able to loop D7 back to D0. I'm not sure what the consensus would be, but I could map the FRX bit to the output enable of the MOSI pin, to allow for three wire connections during fast receive mode. However, if the consensus says to not tristate the MOSI pin, then there could be a custom part that does for those who want it.
Again, Ive reached the limit of the device and to add more would require removing something else. I have removed the ENA bit and replaced it with the TDX bit, gating the D7 back to D0 when 1 and inserting zero's when low.
This will most likely be the final configuration. I've updated the datasheet with these changes.
I still need to test the maximum External Clock frequency and add that to the datasheet. Everything else seems to be running well.
I'd map the TDX bit instead, high being tristate and low being repeat the buffer. The repeating process is something which can be done by just loading the register with 0x00 or 0xFF, while tristating is something which can not be otherwise done. If a person still wants a pull-[up|down] without loading 0x00 or 0xFF into the register, they can add a 1k resistor on the line anyway.
I've updated the datasheet one last time. I removed the TDR - transmit data repeat flag and replaced it with the TMO - tri-state MOSI pin flag for those wanting three wire interfaces.
The transmit buffer is now a circular shift register so it will always repeat the last byte loaded.
I also added the external clock max frequency in the timing data. The Xilinx compiler's timing report states 45.45MHz. I have not tested this as I am still working with slower clocks at this point.
The design is about complete. I still have a few items to test but feel all is working as described.
The datasheet, along with the source and Intel-Hex object file are on my website. While I'm not going to offer these for sale, I can help program them if anyone is interested.
but since they have RS232 to USB, that would be redundant and trivial.
They also have SPI to USB, so if your microcontroller or home-made computer has SPI, you can get USB with one IC. There are probably more of these and cheaper too, since SPI is a better match speedwise than RS-232 is.
There's also the FTDI chips, they do both serial->USB and paralell->USB, the chips are surface mount but they also do hobbyest friendly modules, in DIP24 0.6" packages, with all the required components, and a USB socket.
I'm using one of the paralell ones at the moment on a breadboarded 6502 based setup, it's really easy to use at the 6502 end all I needed to do was decode the address for the chip select, provide /RD and /WR and just write/read to the decoded address. On the PC end it just appears as a virtual com port.
For a long time, I have wished there were such a part. I've done a lot of SPI and other synchronous-serial work, but always bit-banged it, which, although it gives total control, is limited in speed, and requires total processor attention.
Is it possible to get sources etc., please? I replaced the floppy drive of a Commodore 1541 with an harddisk. I want to find out if it can be done with a SD-card as well.
Many thanks in advance!
For a long time, I have wished there were such a part. I've done a lot of SPI and other synchronous-serial work, but always bit-banged it, which, although it gives total control, is limited in speed, and requires total processor attention.
Is it possible to get sources etc., please? I replaced the floppy drive of a Commodore 1541 with an harddisk. I want to find out if it can be done with a SD-card as well.
Many thanks in advance!
I'm not sure exactly what you're looking for, but I can say the serial parts I've used were all individual ICs-- EEPROM, flash, D/A converters, digital pot.s, relay drivers, even the in-circuit serial programming (ICSP) of PIC microcontrollers, and probably other things I'm forgetting-- and the data sheets always had the timing diagrams and all other information necessary to talk to the part, rather than telling the reader to go somewhere else to learn about the interface standard. If you're interested specifically in SD though, I think you'll be interested in Maxim's ap. note at http://www.maxim-ic.com/appnotes.cfm/an_pk/3969 .
For a long time, I have wished there were such a part. I've done a lot of SPI and other synchronous-serial work, but always bit-banged it, which, although it gives total control, is limited in speed, and requires total processor attention.
Is it possible to get sources etc., please? I replaced the floppy drive of a Commodore 1541 with an harddisk. I want to find out if it can be done with a SD-card as well.
Many thanks in advance!
