See anything wrong with bit bang driver for HTS221??

[steve sagerian]

Posted on April 03, 2018 at 04:41

I am writing a bit banging SPI driver for the HTS221 with no success,

I drive the SDO data just before the falling clk end

and I read the SDI data on the rising clk edge. I have included a screen capture of the Saleae logic analyzer..

which shows (what I believe to be a typical initialization) setting the reading cntrl1 and writing cntrl1 with PD= 1, but I am not seeing the correct response from the who am I request.

[S.Ma]

Posted on April 03, 2018 at 05:20

Do you really need for such a slow sensor to use SPI?

Otherwise, try to just read the WHO_AM_I register first.

I beleive that it is important to update data or read data at the correct clock edge, the one which is not used by the slave to set or sample the level. Also, when CSS is high, if addressing another device, the unselected HTS will be in I2C mode, so the SPI signals must be clean not to look like a Start bit.

[steve sagerian]

Posted on April 03, 2018 at 12:55

When you say slow sensor, do you mean its slow to complete a conversion? I haven't even gotten that far.

Looking thru the data sheet I dont see any mention of conversion times, guess that is why it has a data ready signal.

I really dont want to run the other peripherals at 400Khz so it looks like my only other option is to move the clock line to a unused pin and create a separate SPI bus just for this part. 

Thanks 

KIC8462852 EPIC204278916

[Miroslav BATEK]

Posted on April 05, 2018 at 15:31

First of all you have to respect the SPI protocol and timing specified in the datasheet.

Second it is good to start with reading of WHO_AM_I register, this is the simple step, if it will work you can move forward.

The Salea logic analyzer is able to decode the SPI data, does it decode your SPI signals?

I cannot zoom in you captured signals so I can't check if you send the correct data, but the CLK signal seems to be weird . Why there is no constant frequency and duty cycle?

[steve sagerian]

Posted on April 12, 2018 at 21:00

I think that is funny considering the chip itself has not respected the SPI protocol by requiring the developer to turn the MOSI line into a MISO mid way between transfers (there are other issues but who has time to complain) , but I understand your comment to mean that I need to meet the setup and hold times, and min/max periods. I have checked that and despite how the wave forms look, they are within specifications. The frequency doesn't need to be constant and can vary with in the min/max specs. Its really more about clock edges and when the data is valid. In any event, since I am doing a bit banging implementation I can (have) moved the clock line to an unused pin and created a separate SPI bus for just this part. In trying to validate my implementation I have been trying to read the WHO_AMI_I register first, it would have been helpful to have a portion of the data sheet to say whats can be done(what messages the part will accept) prior to setting the power on bit. 

I haven't seen an actual SPI implementation for this part, except for some hand waving discussion and vague references to using bits and pieces of the SPI HAL driver,and since a normal SPI bus has separate MOSI MISO lines I am not sure its relevant.