BCM2835 and SPI Transfers

You hint at that you're using a library called BCM2835 in "a language". BCM2835 is hte name of a chip, the CPU on the raspberry pi one.

Now, IF BCM2835 is the name of a library for SPI on BCM2835 and similar chips, then I expect that you can transmit a number of bytes (any number) by passing an array of bytes. For 32 bits, you'd need an array with 4 bytes.

In theory, sending 4 bytes that you have as a 32 bit integer rewquires no conversion: The hardware doesn't know the difference between 4 bytes and a 32bit integer. On the other hand "your language" may.

Apologies, yes BCM2835 is an eponymously named library to control the low level peripherals of the chip.

I think I've seen it mentioned here and assumed (I really should know better) which is why I wasn't more explicit.

It's from https://www.airspayce.com/mikem/bcm2835/index.html

You can pass it an array of bytes to send, there's an example of exactly that on the website which works but only 8 bits at a time before it deasserts CE, another of its functions allows 16 bit shorts to be sent but it still (correctly) deasserts CE after 16 bits.

The ADF4351 needs to see all 32 bits of data before CE is deasserted as it latches them into the relevant registers on deassertion so sending it a short and deasserting CE produces 'odd' results.

Using one of the other functions in the library allows me to send 16 bits at a time before CE deasserts so my code, at the moment, is shifting and masking 32 bit values from a 6 member 'int' array into a 12 member 'short' array, sending those 12 shorts and controlling CE instead of letting the library control it.

I'm sure there's a more elegant way to do the bit manipulation but for now my main concern is that there may be a simpler, more obvious way to get 32bits out of the Pi without having to do the bit shuffling and 'manual' control of CE .

To answer Michael, SPI0 but the functions appear to be the same for 'AUX' SPI (which I assume is SPI1, see above about knowing better)

The SPI protocol allows for sending a number of bits before de-asserting CE. Commonly that number is a multiple of 8, but it doesn't have to be that way.

For example, SD cards (in the simplest form) use an SPI protocol where you need to transfer 512 bytes at a time. That is 4096 bits. (There is probably a command prefixed to that, so there will be a few more than that.)

Anyway, If your library de-asserts CE after each byte, then that is an unwanted restriction of the library you are using. That might be "correctly" because it is documetned that way, but it is not "correct" in that it allows you to talk to "normal" SPI devices. You have the following options:

* Read the manual of your library to figure out how you can prevent this unusual and often unwanted behaviour.

* Dive into the library and fix it to prevent this unusual behaviour.

* Use a different library.

* Wire your device to a different CS pin than the one that the library uses. Now program that pin low to enable your chip, send four bytes (which causes another output on the chip to go up and down 4 times.... So what?) and then program the pin high again.

As far as I can see you need tow be able to write 24 bits without deasserting the CS line to make an MCP23S17 work. So I you might want to investigate how that's done.

The SPI protocol allows for sending a number of bits before de-asserting CE. Commonly that number is a multiple of 8, but it doesn't have to be that way.

For example, SD cards (in the simplest form) use an SPI protocol where you need to transfer 512 bytes at a time. That is 4096 bits. (There is probably a command prefixed to that, so there will be a few more than that.)

Anyway, If your library de-asserts CE after each byte, then that is an unwanted restriction of the library you are using. That might be "correctly" because it is documetned that way, but it is not "correct" in that it allows you to talk to "normal" SPI devices. You have the following options:

* Read the manual of your library to figure out how you can prevent this unusual and often unwanted behaviour.

* Dive into the library and fix it to prevent this unusual behaviour.

* Use a different library.

* Wire your device to a different CS pin than the one that the library uses. Now program that pin low to enable your chip, send four bytes (which causes another output on the chip to go up and down 4 times.... So what?) and then program the pin high again.

As far as I can see you need tow be able to write 24 bits without deasserting the CS line to make an MCP23S17 work. So I you might want to investigate how that's done.

Never mind, I'll work it out for myself as we now seem to be bickering about how to control some other chip.

As far as I know you write three bytes to set a register in the 23S17 to a value, the opcode/addres, the register address and the data. If you deassert the CS each time, how would a non-addressed 23S17 be able to see the difference between the data for the other 23X17 and its address? (Assuming the data you  want in that register happens to be the address of another 23S17?)