If you need a driver for the SPI module, use Processor Expert.
It's worth you time to learn PE.
Making use of the SPI peripheral hardware as an SPI master is the easy part. The more difficult part is to understand the exact communications requirements of the SPI slave device, in this case the TLE8104E. I will assume that you will use a relatively fast SPI clock rate, so there is usually little justification in using interrupts for master communications usage.
You will firstly need to initialise the SPI module as a master. In addition to choosing a clock rate that is compatible with the slave, you will also need to select the CPHA and CPOL settings that the slave requires (see the attached file SPI.c, which would be modified to suit).
The attached file SPI.c provides a very simple polling function that provides for simultaneously sending and receiving of a single byte. This is the only communications "driver" that is necessary. You will then need to write additional functions that fulfil the communications details for the specific device, as described in its datasheet, and these would call the SPI_trans() function as required.
For further simplification, you might setup the following macros:
#define DUMMY 0x00
#define SPI_send(x) (void)SPI_trans(x)
#define SPI_recv() SPI_trans(DUMMY) // Received value is returned
I like the simplicity of your code.
But to me it looks like your SPI function exits before the module is done finishing the last clock. If the chip select to another device is asserted right after the SPI function exits, that device might see an extra edge. This is especially true if you have
devices that need different CPOL settings on the same bus- nvrams and adc's seem to want different clock edges.
Shouldn't you also pole the the CLK output pin and make sure it has returned to its default state before you exit your SPI function?
I might be wrong, or the SPI module SPRF bit timing may have changed over the years... but let me know what you think.
The SPRF flag will become set some time after the last "active" clock edge, and the received data is available. If there is a further clock transition to occur after the flag is set, it would normally be of no consequence since it would be an "inactive" edge. I do not know whether this situation actually occurs. It is certainly OK to raise the SS line as soon as the flag is set.
When swapping between two different SPI devices that have separate setup requirements, I think that it would be wise to firstly disable the SPI module, and to then re-initialise with the alternative setup, prior to the SS line being set to active low.
I would suspect that polling the clock pin may not work because, when the SPI module is enabled, the module will control the pin. Although I have never actually tried reading the pin status as GPIO
I notice that many SPI devices that require a 0:0 setting for CPOL:CPHA are also compatible with a 1:1 setting. This would normally be stated in their datasheet.
That is a good solution...disabling the SPI module and restarting it with new settings.
I believe you can poll the clock. The HCS08 Peripheral Module quick reference HCS08QRUG.PDF shows SPI code where
they wait for the clock to go to its default (at rest, initial, nominal,inactive) logic level by polling the pin with SCLK. (although sitting and waiting for the clock to become inactive in the middle of an ISR is not a good thing)
Peripheral Quick Reference
Retrieving data ...