Ho do you specify an SPI address with spi_xfer - SOLVED

[benoitstjean]

PIC: 24HJ128GP306
PCWHD: 4.132

First, I know I should use the #USE SPI directive in order to configure my SPI port. Then, I need to use the spi_xfer function to transmit...

Second, like any protocol, you should somehow somewhere specify the address where you want to write followed by the data you want to write to that address.... In the spi_xfer function, I don't see such parameter to specify the address where to write. I looked at the CCS docs and whatever's in there isn't clearly indicating how to write to a specific address.

I am using a 23LC1024 (1MB SRAM). If I want to write the value 0xAA at address 0x0F4321 on that chip over SPI, how would I implement that using the spi_xfer function?

The CCS docs say <data is the variable or constant to transfer via SPI.>... so, that's fine... but do they mean that 'data' can be either the data AND the address and I must write using multiple calls to spi_xfer?

Should I be doing this:

[bkamen]

Mmm...

No.

SPI can output to a stream depending on how the function is written...

but typically SPI's addressing is in controlling of the CHIPSELECT line that the SPI device has in some form. (some are call SEL or CS or NCS or CSB -- but it's all a line to say "Hey - I'm talking to you!")

If you only have one SPI device on an SPI bus, the chipselect can in some cases even be tied to "true" all the time. (usually Low) -- although in some cases, it's not wise since release of CS resets the protocol state machine inside the SPI device -- a desirable thing.

So... with SPI, typically a statement code setting the devices CS line is separate from the function that stuffs a byte into the transmit buffer so addressing can be utilized as the coder/device needs.

Make sense?

-Ben
_________________
Dazed and confused? I don't think so. Just "plain lost" will do. :D

[PCM programmer]

The documentation means 'data' in a generic sense. It means simply
that 8 bits of digital information are shifted out. The interpretation of
the 'data' is decided by you, or by the protocol required by the SPI slave
device.

[bkamen]

[ckielstra]

Just want to elaborate a bit more on the Chip Select (CS) line:
Each device you want to address is to be activated by a CS line, meaning that if you have 8 devices you need 8 CS lines as well. This is one of the major drawbacks of SPI when compared to the competing I2C bus.
SPI is great when high speed data (over 400kbit/sec) and/or a few devices are to be addressed.
When more than 3 or 4 devices are to be addressed the I2C bus often results in cheaper hardware configurations (but has a speed limit at 400 kbit/sec).

[benoitstjean]

Sorry guys but the chip select thing is totally off topic. I created this post asking how to write data to a specific address on an SRAM chip using the spi_xfer function. The chip select line is at the electrical level and is simply to select the chip, or not, but has nothing to do with writing a certain value at a specific address.

So again, if I want to write value 0xAA at address 0xF4321 on a 23LC1024 (1MB SRAM), would I do the following:

* Write to address 0x0F4321 */
spi_xfer( 0x0f ); // high byte
spi_xfer( 0x43 ); // middle byte
spi_xfer( 0x21 ); // low byte
spi_xfer( 0xAA ); // data

If this is not the case, then how do I do it? From what PCM Programmer said, "The documentation means 'data' in a generic sense. It means simply
that 8 bits of digital information are shifted out" so it seems, to me, that above is what I would do.

But then will I get an SPI TX interrupt after every call to spi_xfer once the data has been shifted-out?

I don't see how else this function can be used other than feeding it the information byte by byte keeping in mind that I must also follow the protocol for my chip...

I will try it but in the meantime, if someone has comments regarding this topic, please post.

Thank you.


************** UPDATE **************

It's a 1Mbit SRAM, not 1MBYTE so I changed my data below and also, after every call to spi_xfer, I *do* get an interrupt. So, I think that I simply need to break-down the commands, address and data into their individual 8-bit values and send them out following the specs for the chip. I'll post some code shortly once it's fully working for a read/write.

************************************

[benoitstjean]

Ok, so there's something weird going-on with the functions...

First off, what's the difference in the #USE SPI when using SPI1 or SPI2 versus using FORCE_HW? In either case, the CCS documentation says for SPI1/SPI2 "Use the hardware pins for SPI Port x" but for FORCE_HW, it says "Use the pic hardware SPI". What should I use? To me, it's the same thing... the hardware SPI... isn't it?

Second, I tied a logic analyzer to the 4 signal pins on my 23LC1024 SRAM so I could see what is going-on. I tried both spi_write2 and spi_xfer (I am using hardware SPI 2).

The result is that I see data being transferred but as much as I'm sending 5 bytes, each byte has only 4-5 clock cycles when it should be eight and if I base myself on the CCS docs for spi_write2, it says "Sends a byte out the SPI interface. This will cause 8 clocks to be generated."... so I should at least see 8 clock ticks per byte, which I'm not.

I've setup the SPI like this:

#use spi ( MASTER, BITS=8, SPI2 )

Any comment?

[RF_Developer]

No, its all on topic and relevant.

"So, I think that I simply need to break-down the commands, address and data into their individual 8-bit values and send them out following the specs for the chip."

Yes, that is precisely what you have to do. Its always what you have to do: read the datasheet for the relevant devices and implement accordingly. While in concept a bi-directional interrupted bit stream of arbitary but finite length, in practise SPI *generally* transfers 8 bits of data *in both directions* at a time. Other bit lengths are possible but uncommon and rare in hardware based implementations, software can do almost whatever length you like. That means pretty much all SPI transactions have to be broken down into a sequence of bytes with enough or more bits as required.

From the datasheet for the 23LC1024, to write 0xAA to address 0x0F4321 you would need the following:
* Write to address 0x0F4321 */
Select memory chip somehow

[benoitstjean]

Thanks. I am selecting the chip myself through the CS pin but the main idea behind my post was how to write data X at address Y, not how to access the chip. I know that there is a certain protocol to follow to write the data (such as the first byte being sent must contain a certain bit pattern depending on if it is a "read" or a "write" command).

As mentioned in my last post, I have a logic analyzer tied to the 4 signal pins on the SRAM and the functions are called in a sequence but the clock pin isn't even toggled 8 times per byte sent. I tried both the spi_write2 and spi_xfer and the result is the same.

Now, about the #USE SPI directive, what's what? As stated, what's the difference between the flag SPI1/SPI2 versus using FORCE_HW? In either case, the CCS documentation says for SPI1/SPI2 "Use the hardware pins for SPI Port x" but then, for FORCE_HW, it says "Use the pic hardware SPI". So, what's the difference?

And I do get an interrupt everytime the spi_write2 or spi_xfer command is issued since I write a '*' on a display on every #INT_SPI2 interrupt. The problem I'm seeing through the logic analyzer is that either command doesn't seem to issue the proper number of clock cycles for each byte. And I am, in deed, sending 0x02 as the first "command" (write):

[bkamen]

[NEW_GUY]

Probably the following command you might have gone through,

spi_xfer(stream, data, bits);

The sequence of transmission of Data on perticular address would be:
- make sure, your SRAM operating mode is BYTE MODE, other wise, no need to send an address.
- make sure that your CS pin is enable thorught the command and data transfer.
- according to above api,
stream: any_name
data: write command
bits: 8

this command can transfer any no. of bits on spi by generating those many no. of clocks.....

- you shud follow following sequence:
ENABLE CS = 0;
1. send write command : 8 bits
2. send address: 24 bits
3. send data: 8 bits
DISABLE CS = 1;

to read:
Enable CS =0;
1. send read command : 8 bits
2. send address : 24 bits
3. receive data:8 bits
Disable CS =1;


Try it out...

[benoitstjean]

Deleted

[benoitstjean]

UPDATE:

IT WORKS. I can now WRITE and READ properly to the address I want.

CODE (for my PIC24HJ128GP306 tied to a 23LC1024 SRAM):

Add to .h file: