My apology if I have already asked this or posting in wrong forum.
All I want is to send SPI data to BCM2835 and verify it got processed in software.
I am not interested in verifying actual hardware output, not yet.

Here is what I have done so far
Configured RPi 3B (raspi-config) for SPI.
Verified / TOK by system("ls -l /dev/spi*");
That tells me I have TWO SPI devices
/dev/spidev0.0
/dev/spidev0.1
Question
Which spi device is connected to RPI 3B header after I do ALT0 on SPI pins?
The data sheet say " SPI0_xxx".
Question
How do I enable CE0 or CE1 on header ? ( SPI_CE0_N / SPI_CE1_N) Standard SPI SS signal.
Question
Is there a doc anywhere to tell me the CORRECT sequence in setting SPI_FIFO DATA register.?
Clearing TXD / RXD and setting TA SAME ( per datasheet) time generates SPI DONE immediately , without me setting the SPI_FIFO DATA register at all.
I shall try to find such sequence in BCM2835 C library , but "been there, done that" and it is no fun muddling thru the library code.

Please reply only if you know what I am talking about, references to "another GPIO" library are not necessary.

My apology if I have already asked this or posting in wrong forum.
All I want is to send SPI data to BCM2835 and verify it got processed in software.
I am not interested in verifying actual hardware output, not yet.

Here is what I have done so far
Configured RPi 3B (raspi-config) for SPI.
Verified / TOK by system("ls -l /dev/spi*");
That tells me I have TWO SPI devices
/dev/spidev0.0
/dev/spidev0.1
Question
Which spi device is connected to RPI 3B header after I do ALT0 on SPI pins?
The data sheet say " SPI0_xxx".
Question
How do I enable CE0 or CE1 on header ? ( SPI_CE0_N / SPI_CE1_N) Standard SPI SS signal.

spidev0 is SPI0, the number after the dot chooses which CE line is asserted when using that device, so writing to spidev0.0 sends data over SPI0 with CE0 asserted, writing to spidev0.1 sends data over SPI0 with CE1 asserted.

Though if you are using Linux's spidev you shouldn't be messing around with the hardware registers yourself, the device driver expects to be in contol of them.

As to writing to the FIFO, it doesn't look complicated. Once you've set up the HW you go in a loop

If you have data to send and TXD shows it isn't full write one byte to the FIFO (you have to write it as a 32bit value though). Keep doing this until either you have no more bytes to send or TXD shows it is full.

If you are expecting to read and RXD shows there is data then read the FIFO, the lowest byte is the data. Keep doing this until you have either read all the bytes you were expecting or RXD shows that it is empty.

If you still have data to read or write then go back to step 1.

Wait for DONE to signal that the HW has finished transmitting the FIFO.

Raspbian spidev driver, it looks like the driver generally uses IRQ (when not using DMA) to process each run of the loop in bcm2835_spi_interrupt() which reads as much as it can followed by writing as much as it can each time it gets signalled.

This is roughly what I've seen other libraries do (wneh not using IRQ or DMA)) where sit doing the loop for the whole transfer.

To clarify - I am not using ioctl , just modified BCM2835 C library.
Please do not tell me what I can or cannot do "messing around" - this is not Arduino forum!
I have managed to set SPI_FIFO DATA and wait for DONE.
The "problems" encountered so far - some on this is dupe.
Bit 18 TDX never changes - datasheets basically say "ready to accept TX data ... (?) .
When SPI_CS is initially reset ( all zeroes) - bit 18 gets set ( expected ) but it NEVER changes.

"LOOP start " When SPI_CS is CLEAR and TA set same time
Bit 18 stays set (expected ?) , bit 16 (DONE!) get set( done what ?) and bit 7 (TA ) get set
Setting SPI_FIFO DATA to anything , I use 0xffffffff resets bit 16 ( DONE) - as expected.
and sets RXD (duh?)prior to DONE is set again - as expected. .
( I can observe approximate time in few uS until the DONE is set again)
Bit 18 NEVER changes.
"LOOP end "

I can repeat the above "LOOP" and never encounter any failure.

So
why does bit 18 never change?
what is with "RXD" setting at the end of waiting for "TX_FIFO" to be DONE?
Perhaps setting RXD means it is ready to receive?

PS
I am adding "wait for process RXD _FIFO " it should read nothing until I add "local loo[back".

I wasn't telling you what you can and can't do, I was saying that if you use spidev at the same time as manipulating the hardware registers directly then chaos can ensue as you can end up interfering with each other. Especially, for example, with the FIFOs because if spidev reads a value whilst you are trying to read it only one of you will see it. The usual Linux way is that if a driver is controling a particular resource, anything wanting to use that resource should go through that driver to avoid conflicts.

As to RXD being set when you are writing, AFAIA that is expected (unless you are using 3-wire mode). For every bit the master sends out on MOSI it also reads one on MISO, even if the slave isn't actually sending anything meaningful the hardware will still sample it. So if you just want to send data then you read and throw away the junk data. When you just want to read you send the same number of dummy bytes as you want to read (as recieving only takes place whilst sending).

I think if the recieve buffer gets full then transmitting pauses until you do read.

As Ivar said (Google it ) - keep clam.
So what you are saying is that this "bytes" business BCM uses in their datasheet is bogus as I suspected.
I will try to modify my SPI_FIFO DATA to "send" only one bit and see what develops.
So far my attempt to "read" the data has failed. My code problem for sure.
Still not sure why TXD never changes - perhaps same issue as "manipulating bytes".
Thanks for discussing the issue with me.

As far as "changing BCM library " - my goal is to make C++ class and learn more about inheritance.
My app will control several pieces of hardware so it seems logical to me to make it real C++.
Cheers

So what you are saying is that this "bytes" business BCM uses in their datasheet is bogus as I suspected.
I will try to modify my SPI_FIFO DATA to "send" only one bit and see what develops.

No, whilst the SPI bus is only one bit wide, the hardware always transfers data in blocks of 8 sequential bits, so every time you put one value into the TX buffer the hardware will generate 8 consecutive clock pulses transferring one bit of the data per clock. Similarly it reads the 8 bits of data coming in at the same time and puts them in the RX buffer as one byte. So as far as you are concerned you always send and receive data in bytes, the hardware of the master and slave ports have to transfer the data in bits between themselves, but that is by large hidden from you.

I am aware of all of that - after all it is S(erial)PI.
I am just questioning the notion that after physically transmitting one bit the receiver will read what is coming back.
There is no logical reason to do that - responding on single bit transmitted by master and received by slave.
Cheers

I am aware of all of that - after all it is S(erial)PI.
I am just questioning the notion that after physically transmitting one bit the receiver will read what is coming back.
There is no logical reason to do that - responding on single bit transmitted by master and received by slave.
Cheers

When considering HW design, there is almost ALWAYS a logical reason* for doing something.

It's usually just not obvious what it is from a SW point of view.

* Usually making the HW design easier, or using less gates to reduce die footprint, or other such esoteric HW processes to make the life of the SW engineer harder.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

I am not sure to whom I am directing this.
I do not object to academic / what if discussion, but it gets of the subject too fast.
No, I am not interested in sending ONE bit at a time.
I have managed to retrieve data from SPI_FIFO_DATA.
Minor detail - since I have way too much scaffolding in my code I do not have to wait to retrieve the data
from the register. Just one pass thru do {} while does it - that is the software feedback I am interested in.
Do not care if the data received is garbage, for now.
The indicator that I got the data is RXD showing "empty" zero. .

The DONE does not change , neither bit 18.
There is something odd about this - especially the bit 18 lack of change.
.
I sure would like somebody familiar with the BCM to explain that.
Cheers.

I am aware of all of that - after all it is S(erial)PI.
I am just questioning the notion that after physically transmitting one bit the receiver will read what is coming back.
There is no logical reason to do that - responding on single bit transmitted by master and received by slave.
Cheers

The SPI bus doesn't preclude you from having devices that can send and receive at the same time. On every clock pulse both master and slave can simultaneously send and receive one bit, the RPi's hardware fully allows this to happen. By the looks of it it only generates clock pulses when writing data so to read a value back you send the same number of dummy bytes out, the slave should ignore those if it doesn't support simultaneous communication either by throwing away anything read or just not sampling the MOSI line whilst it transmits. Likewise when the RPi sends commands out, if it isn't expecting the slave to be sending anything back at the same time then it can throw away the data the hardware read.

E.g. say you have a battery level monitor slave where the master sends it a byte command asking it to send a byte back relating to how much charge remains. If both devices only talked one at a time (master sends command then slave sends data then master sends next command) this would mean it you could at best get a result every other byte. If both devices allow it the slave could be reading the next command whilst it is sending the result of the previous command. Now your system can get a reading every single byte, you've just doubled the throughput.

I am not sure to whom I am directing this.
I do not object to academic / what if discussion, but it gets of the subject too fast.
No, I am not interested in sending ONE bit at a time.
I have managed to retrieve data from SPI_FIFO_DATA.
Minor detail - since I have way too much scaffolding in my code I do not have to wait to retrieve the data
from the register. Just one pass thru do {} while does it - that is the software feedback I am interested in.
Do not care if the data received is garbage, for now.
The indicator that I got the data is RXD showing "empty" zero. .

The DONE does not change , neither bit 18.
There is something odd about this - especially the bit 18 lack of change.
.
I sure would like somebody familiar with the BCM to explain that.
Cheers.

So far on this thread I have had 4 reports. Mostly asking for you to improve the manner/tone of your posts.

Please bear that in mind.

Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."