Hello everyone, I need advice. On my latest board, I have an expansion area which includes the SPI pins: CS, CLK, MOSI, and MISO. All of the lines are shared besides CS of course. MISO has a 10K pull-up resistor. Standard stuff.

In my System Monitor program, I want to have a way to interface an SPI device through these expansion pins. Right now I have a 25LC640A EEPROM and an "SPI MicroSD Card Adapter" (here https://duckduckgo.com/?t=ffab&q=spi+mi ... ter&ia=web) connected using SPI protocols, but they share a common base code of enable/disable/read-byte/write-byte.

What should I do through my System Monitor to be able to interface general SPI devices? Some ideas I've tried:

1) Enable/Disable function, Write Byte function, Read Byte function, with the exact byte to be written or location of read byte as an argument. Pros: Basic, easy, probably universal. Cons: Lots of overhead, lots of wasted time. Example from my monitor (note, mine is not exactly like this, but you get the idea):


2) Read and/or Write from list of bytes/addresses, having the values in memory instead of hand-typed by user. Pros: You can get a lot more done quickly. Cons: Sometimes reading and writing switch out every other byte, so this isn't as helpful. Example:


3) Command + Byte structure. This would end up being like a psuedo-code that can be manipulated for advanced instructions. Pros: You can do a lot more when pre-programmed. Cons: Super complicated to the user. Example:


I just don't know of a good way to interface general SPI devices. I haven't used anything really outside of what I have already mentioned. I want this to be general enough that I could make it work with most SPI devices without actually needing special assembly code. I want it to be easy to use but also useful.

Thoughts? I don't care about notation and all that, I want to know what you think the functionality should be like. Write a byte at a time? Write a string of bytes? Write commands + bytes? Or something else, please! Any suggestions and advice is greatly appreciated. Thank you all!

Chad

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

Thank you Garth. That list of commands is incredibly extensive. And that is only for the 25VF'?



That was what I was hoping to avoid. I have my own SPI functions and they work great. My DIP-8 EEPROM and the MicroSD Card Adapter work beautifully, and use most of the same functionality. That's why I was hoping to use that same functionality on a third non-specific device. I know not all devices are going to follow the same patterns, but I was hoping to get something that would *probably* work on the whole.



The way I interface my 25LC' is by reading or writing one single byte at a time. It's 'slow' but because the thing is only 8K in size, it doesn't really matter. How I read the SDcard is by one 'block' at a time, thus 512 bytes in sequence. The problem is that I was hoping for a "different" device. Like, say, a thermometer, or a light sensor, etc. I don't think I'll need a ton of strings for something like that. But a string of commands might be important! I just don't know.

I don't have a specific target device. That's why I'm confused about how approach this problem. I want something that is generally useful and universal. I don't require that it works on EVERY device, just hopefully some or most. And, as a reminder, I'm not looking for specific code or notations here. Just advice and ideas as to what approach might be more handy.

Thank you Garth.

Chad

One thing to remember is that SPI is full duplex and some devices require you to clock out the command and read the data at the same time. ADCs spring to mind, so you end up selecting the device, sending it e.g. 16 clock pulses with the first few bits being data like select channel, select accuracy, then you continue to clock but need to read the input to get the result back - all in the same 'transaction' - which would be bounded by the CS signal for that device.

So having a generic command to handling it might be tricky.

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Thank you Gordon. This post seems to discourage me (not in a bad way!) from doing something 'universal', because there isn't anything universal. Good point. I'll be pondering on this as well. Thank you again.

Chad

I've been doing some work with SPI over the last few days and I've found that just using memory read and write commands was generally enough to do basic stuff. For example I have a serial flash connected to one of the SPI ports and I can test that like this:

:d0800 00 (write $00 to $D0800 - this selects SPI channel 0 which is the serial flash, sets clock frequency to maximum 12.5MHz, slave select deasserted)
:d0800 01 (assert slave select to flash)
:d0400 03 ff fd 00 ff (send READ command, address 0xfffd00, extra FF to clock out first returned byte)
m d0400+100 (read $100 bytes from $d0400 onwards - each read starts another SPI transfer and each SPI controller register maps to a 1K block, so it displays 256 bytes of flash)
:d0800 00 (deassert slave select to end command)

OK, it's more complicated with other devices, but you can do quite a lot with just raw byte send/receive, certainly enough to determine if things are generally working.

I think you can do something general purpose as an aid to developing specific code for a new device - that's what I've done in the past....

The Raspberry Pi does an in-memory exchange as each bit of data is clocked out, the sampled data in is then written in-place, so I used this when I wrote my dumbed-down access for as part of my wiringPi library - if a device needed 2 bytes of data with (say) the first few bits being a command, then I'd build up a 16-bit memory buffer with the command and then get the hardware to exchange 16-bits and pick out the data from the same memory buffer.

So... If you had a command to simultaneously read/write a number of bytes at an address and good commands to edit RAM then this might help. Write the RAM, call the SPI data exchange, read the RAM.

I have a little test program that does this on the Pi (and Arduino which is similar) which I use when developing a 'driver' for a new device or testing some existing or weird device.


So after testing a device "by hand", what I often do is write dedicated handlers for devices I might commonly use, so my wiringPi library has a basic low-level read/write command which takes a data buffer and number of bytes and each device I cater for calls this after setting up it's command/parameter block and picks the result out.

Here is an example of code to read the MCP3002 ADC - this is a 10-bit device with 2 input channels:



The low-level command is the wiringPiSPIDataRW () function call that does the heavy-lifting of the operation to select channel and clock a number of bytes of data out and in.

And note also that sometimes devices take or return data in the order you might not expect... Or it can be changed on the fly... Read section 5 of the MCP3002 data sheet for the gory details of this device... But in essence, the first 4 bits sent to it are: "Wake up" (1), Single/Diff (1=Single), Channel (0 or 1), MSBF first (1 = yes, send most significant bit first) - then you keep on clocking it for another 12 cycles as it returns the data.

Also note that some devices like this use the SPI clock as their internal clock to do stuff like control the gates to the
SAR logic so sometimes the clock must be in a particular range...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

In 2016 I wired up an SPI UART as a subassembly that can plug into other projects. As far as I can tell, there's no need at all for the SPI to run full duplex, because all you're doing is peeking and poking the registers of what is seemingly an industry-standard UART. And certainly the original (parallel) interface couldn't read and write at the same time!


-- Jeff

ps- the chip can speak I2C as well as SPI; there's a mode pin for this.

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

As an aside, I'm currently looking at using a 2MB NOR flash as a source of data to fill a bank of fast RAM chips holding the microcode, such as it is, for a TTL processor (8080, not 6052!) and it's beginning to look as if only a small handful of chips - mostly HC393 counters and an HC165 SIPO - are needed to perform the whole process. Still looking at the timings for the chips, but it looks hopeful that it's only going to take a second or so.

I was considering how one might implement a similar system to load a 6502 with a 64k RAM from a 64k or smaller part (one command byte less initially) to load a monitor program or basic or whatever. In a perfect world, one would play games with fake NOPs and let the 6502 do the address counting, but the odd three bytes at the start of the sequence make it tricky. I think it'll be easier with actual counter chips.

Neil

(microcode vs not microcode: I can't come up with a decent definition, but I suspect that a processor contains microcode only if it executes loops within an instruction. I believe the 6502 uses what is referred to as a PAL, even though it's not programmable, so it's basically a ROM, no?)

(The 6502's instruction decode is just half a PLA really, not even a ROM - there's no address input. It's a structured way to make a lot of many-input NOR gates. The sequencing is nearby and also has inputs to the decode, but again it's an address. Being structured, it's relatively dense and would have been amenable to tweaks or fixes before masks are made, or from one mask revision to another. The so-called 'random logic' can be viewed as the other half of the PLA, the second NOR plane, although it's not nearly as simple as being a second layer of NOR gates.)