• State
  • Locked Locked
  • Replies 8 replies
  • Subscribers 32 subscribers
  • Views 1972 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Stellaris Launchpad, lm4f120h5qr. Interfacing with ADXL345 accelerometer/General SPI question.

Luke Dolan
Prodigy 160 points

Other Parts Discussed in Thread: TM4C123GH6PM, EK-TM4C123GXL, ENERGIA

Hi, 

    I've been trying to understand how the SSI works on the lm4f120h5qr, in particular how back-to-back transmissions work. In the ADXL345 datasheet it is said that "all axes of interest should be read in a burst (or multiple-byte) read operation.". As such, there needs to be a succession of reads on the launcpads side, without setting the Fss pin high. From reading the data sheet I believe this is possible, "For continuous back-to-back transmissions, the SSIFss pin remains in its active Low state until the final bit of the last word has been captured and then returns to its idle state as described above." .

So, to my question.

How do I make sure that the lm4f120h5qr keeps the pin low throughout the whole transmission?

In total I want 6 bytes to be read from the ADXL345 (2 bytes for each axis). How does the SSI know to stop?, How does the ADXL345 know to stop?

My understanding is I send a read bit along with a multi-byte bit, followed by the address of the data registers, and from there I am unsure. If anyone could provide any information on this I'd be very greatful!

regards

Luke.

  • 0
    Guru 26105 points

    Hi,

    The answers for your questions are simple: to keep SSIFss low, just fill up the FIFO with dummy bytes - when the last byte is out, then at half period of the SSI clock later, SSIFss rise up ending the transmission and reception at the same time. 

    Petrei

  • 0 in reply to Petrei
    Guru 117855 points

    There are different SPI "modes" (and these impact the SSIFss bit management) - you must "mate" the MCU to the Slave device's requirement.  (did not see that detail w/in your post)  As was past noted here (this forum) there is a means to produce a multi-byte SSI transmission/read (and also a means to produce a wider data packet (16 bits) - although you may have to manually manage the SSIFss bit.

    I'm uncertain if "dummy bytes" (other poster) are an ideal solution (to retain SSIFss level) - as the Slave may be confounded.  Suspect that dummy is fine - but best after the correct data has been "harvested" from the Slave.

    The MCU will "know" to stop as directed by your code.  (you've placed the final byte in your sequence)  And your ADXL345 will stop when the MCU's clock pulses and SSIFss pins terminate/toggle.

    Quite often - tightly focused experimentation (with the actual hardware - each end) provides the best insight.  Suspect that you'll need to get at least one early transmit byte correct - before the Slave will emit valid data...  Once achieved - you should be able to build from that...  (a scope or other data monitor will greatly aid)

  • 0 in reply to cb1_mobile
    Prodigy 160 points

    Hi, I forgot to add that it was in CPOL = 1, CPHA =1 mode. As such the SSIFss bit must remain low throughout the entire exchange in multi-byte reads. I am not sure of the other solution you are offer, that is not sending dummy bytes. Are you suggesting that I Toggle the SSIFss myself? I think I'll give the experimentation a go, I've got a better understanding now of how it works, thank you!

  • 0 in reply to Luke Dolan
    Guru 117855 points

    Indeed you can toggle bit SSIFss yourself.  Do this by not using GPIOPinType() and GPIOPinConfig() to set SSI as this pin's alternate function.  Beware - depending upon the pin you choose - some are special "defaults."  (far easier if you survey the data manual - choose a pin "free" from such restriction) Port A and PF0 are notably restricted - require special effort to "steer" away from default...

    Now if you can employ the "automatic SSI mode" - and the MCU's SSI mode "meets" your Slave's requirement - that is often best/easiest.  If the SSIFss bit is "too active" - that's the indication that you should set it as GPIO Output - and then "bang it" appropriately upon entry to - and exit from - SSI transactions...

    Suspect that your Accel chip is on 2nd board - insure that when interconnected - both boards are always powered together.  (never one, alone...)  And the shorter the connections - the better.

  • 0
    Intellectual 985 points

    Hi Luke,

    I am just starting to learn the H5QR and I also am interested in the ADXL345 Interface. I would be very interested in seeing any example/pseudo code you have regarding them. 

    Respectfully,

  • 0
    Intellectual 315 points
    Did you ever get a good result from this? I am trying to do the same thing on a TM4C123GH6PM microcontroller on the EK-TM4C123GXL Launchpad and cannot get good results from anything I've tried!
  • 0 in reply to Dan Haugen
    Intellectual 985 points

    Dear Dan,

    I was able to get the chip working, what specific questions do you have?

    -Sheldon

  • 0 in reply to Sheldon Blackshire
    Intellectual 315 points
    What is the sequence of SSIDataPut() and SSIDataGet() commands that will allow a seamless data transfer? I've gotten the code working in Energia, but I need to use CCS due to the complexity of the design and peripheral interfaces.