Design of the Virtual 2315 Cartridge system requires some Arduino workarounds

TWO USERS OF THE SPI PROTOCOL ON THE ARDUINO

My design for the Virtual 2315 Cartridge system uses a Xilinx Artix S7 board to control the internal disk drive of the IBM 1130 and an Arduino for the interface to the outside world, these communicating over an SPI link.

The virtual cartridge files are stored on an SD card and the boards and software for accessing these by Arduino make use of an SPI link. 

In the usual case, one can have multiple slave devices connected to one SPI link since the slave select signal causes only one at a time to access the SPI signal lines. There are complications in sharing an SPI, one of which is incompatible modes and formats for the two devices. SPI has different clock polarity and phase settings, resulting in one of four SPI modes, as well as different clock rates. Another complication is that a device may not release the output lines properly when it is not selected, thus blocking other slaves that should be able to communicate. Finally, the software libraries for the slave devices might not release the slave select line or work well when other libraries are alternating use of SPI. 

REASONS I WON'T SHARE THE ONE HARDWARE SPI CHANNEL

I am concerned that the SD card library is one that does not play well with other slave devices. I experienced this with a prior project years ago attempting to share an Arduino SPI channel, plus I find posts by other people having issues sharing channels with the SD cards. 

Also, my code will be cleaner and less error prone if I am not juggling slave select sequences as I move between communications to the SD card and to my FPGA. This is more esthetic but it helped me with this decision. 

ATMEL PROCESSOR PROVIDES UARTS THAT IMPLEMENT SPI FOR SECOND CHANNEL

The ATMEL processor has multiple UARTS and these have the ability to be put into SPI compatibility mode although only as an SPI master not as a slave. In my case, I only need master channels so this makes them of great interest. I can use the regular SPI channel to talk to the SD card since its library assumes the use of the SPI library, while my link to the FPGA is targeted to a UART in SPI mode. 

NO PINS CONNECTED TO THE SCK FOR THE OTHER SPI CHANNELS, NEED BODGE

The designers of the Arduino Mega 2560 chose which of the 100 pins on the ATMEL processor they would route to the limited pins on the board. They did route the other UARTS Transmit and Receive lines to pins but left the Clock pin unconnected.

I will tack a wire onto the processor pad for one of the clocks - I chose UART 2 at pad 14 for ease of access. I then want to repurpose one of the existing pins on the board to wire to this signal. I chose the AREF signal which is used to shift the range of the analog to digital converters for the analog pins. I simply lifted the pad of the processor for the AREF connection and then soldered my added wire to the trace going to the AREF pin on the board.

SPI LIBRARY SET UP FOR PRIMARY CHANNEL, NEED TO CLONE FOR SECONDARY

I will set up my own functions to operate the secondary SPI channel, rather than using any of the standard SPI library. This eliminates any chance of interference in that library. Otherwise I would have had to clone the library under a second name and adjust all the code that accesses specific pins to move them. 

CODING THE ARDUINO IS WELL ALONG

I have written a substantial portion of the logic for the Arduino to communicate with the user through an LCD and keypad interface, to list, read, write and copy virtual cartridge files on the SD card, and to manage the Heads Loaded signal back to the disk drive when we have a virtual cartridge ready for access. 

After I finish the secondary SPI channel routines and merge them into my code, debugging will begin. I have the SD card, Arduino Mega 2560 and LCD Keypad hardware, thus I can put together a testbed to test everything except for the link with the FPGA - since I haven't written the VHDL nor debugged that yet. I do have the FPGA board on hand.