AnsweredAssumed Answered

ADXL345 C++11 conversion

Question asked by mwpowellhtx on Sep 9, 2013
Latest reply on Sep 20, 2013 by neilzhao

Hello,

 

I am adapting an ADXL345 into our mobile application, and I'd like to get some feedback. I've got an accelerometer_data_t structure that basically maps the X, Y, and Z in terms of a float-based solution: i.e. for easier subsequent transformations, translations, etc.

 

However, there's the matter of lifting the data out from the read-buffer in the first place before that ship leaves port, so to speak. So here goes:

 

Sample Code

/**

* \brief Directs the buffer into the data.

* \param data An accelerometer-data reference.

* \param buffer A buffer reference.

* \returns The data reference.

*/

accelerometer_data_t& operator<<(accelerometer_data_t& data, const buffer_type& buffer) {


    //Set-field lambda-helper-function.

    auto set_field_ = [](accel_value_type& f, const buffer_type& b, buffer_type::size_type p) -> bool {


        //Defensive coding style.

        if (b.empty() || p > b.size()-2) return false;


        //Assumes data is right-justified. Capture into a temporary integer.

        int16_t temp_ = static_cast<int16_t>(b[p]|(b[p+1]<<8));


        //Then into the field.

        f = static_cast<accel_value_type>(temp_);

 

        return true;

    };

 

    //Set the fields with the raw data.

    //pos_datax, y, z defined as 0x0, 0x2, and 0x4, respectively

    set_field_(data.m_x, buffer, pos::pos_datax);

    set_field_(data.m_y, buffer, pos::pos_datay);

    set_field_(data.m_z, buffer, pos::pos_dataz);

 

    //Then return with the data.

    return data;

}

 

Neverminding the lambda-functional-programming style, does this look about right?

 

Reading the data-sheet and application node, is there anything special I need to do to comprehend the dynamic range? That is, whether it is configured for 2, 4, 8, or 16 g resolution?

 

I am assuming a right-justified field with sign extension.

 

Thank ye...

Outcomes