STM32F4 19 bit SPI Data Read

[Rogers.Gary]

Posted on February 03, 2016 at 06:51

Hi,

I am using an LTC2433 current sense device that has 3-wire SPI that can operate in several modes. It has a maximum throughput of about 6 reads/second, but since I will be reading it less than 1/second, speed is not an issue. Because it uses so little power, I could run it in Mode 4, which is continuous conversion. LT describes it as ''Internal SCK, 2-Wire I/O, Continuous Conversion''. For reference, I've attached a screen cap of the timing diagram from the data sheet. The length of the data packet is 19 bits (in all modes). In this mode CS is tied low to enable continuous conversion. To transfer, the SDO line from the LT2433 goes from 1 to 0 to indicate the start of the 19 bit data. Also, SCK is toggling as an output in this mode at the internal rate. Question: I'm a bit lost on what the most effective way to capture this would be in this mode. Or...not: just stick to regular SPI. However, with 19 bit data, how does one set up and read with the SPI interface? Would it be set up as 8 or 16 bit? Thanks for your help!

[mark239955_stm1]

Posted on February 03, 2016 at 11:51

Depending on how the current sensor behaves if you issue more than 19 clocks to it, you can probably get away with running it in a triggered slave mode, i.e. your MCU must generate clock and CS, and doing 3x8-bit SPI transfers.  You would probably then need to massage the resulting 24-bit value to align it properly.

[John F.]

Posted on February 03, 2016 at 16:24

The Data Sheet for the LTC2433 makes it plain that you can assert CS# low and check SDO for End Of Conversion. You could do this using the uC SDO pin as a GPIO. Following EOC# you must clock out at least nineteen bits. Since you are limited to groups of at least eight you will clock out 24 (or 32 if you want). Again, the Data Sheet makes it clear that additional bits will be 'Ones'. After all SPI transfers, de-assert CS#.

It's then your job to combine the data to recover the salient bits. You can also use CS# to read EOC# and optionally force a new conversion. The result is then available after the conversion time and is flagged by the LTC2433 EOC# monitored by your uC pin. It doesn't look difficult - just follow the Data Sheet.

[Rogers.Gary]

Posted on February 03, 2016 at 18:09

Hi,

Thanks for the help. I need to be clear on just how the SPI is to be set up for this, if it is at all. You said: ''you can assert CS# low and check SDO for End Of Conversion. You could do this using the uC SDO pin as a GPIO.'' I was going to map AF1 (PB13=CLK, PB14=MISO,PB15=MOSI) So rather than set up PB14 as MOSI, should it be a GPIO and monitor (in an ISR) for it to go to 0? And then use SPI CLK from the STM32F4? Or, alternately, if using the internal LT2433 CLK the STM32F4 would need to do some kind of synchronization between the incoming CLK and the SDO pin (configured as GPIO) - is this correct? Which would make most sense from the least complexity and coding? Thanks again!  

[John F.]

Posted on February 04, 2016 at 09:12

I would not use the LT2433 internal clock. It's simpler to ''manually'' handle the CS# and (SPI) clocking in your program. Since ''speed'' was not an issue for you, I would not even bother with interrupts.

You could dynamically switch PB14 between GPIO (input) and MOSI - the reconfiguration really doesn't take very long! The conversion is under your control because you have programatic control of CS# so you can either start a conversion and come back for the results well after it will have completed or if you don't mind the wait, start a conversion and poll the EOC# signal then configure SPI and clock out the data. The Data Sheet says, ''When using its internal oscillator, the LTC2433-1 can produce up to 6.8 readings per second. The actual output data rate will depend upon the length of the sleep and data output phases which are controlled by the user and which can be made insignificantly short.'' so you could just start a conversion and come back for the result every 200ms or so - it's up to you. If you get it working in this simple way first, you can always ''improve'' it to suit your needs later.