Interfacing a Sensor Hub with TWI drivers?

[polimarte]

Hi,

I am trying to adapt the read register function that use the TwoWire lib of Arduino in order to read a Sensor Hub Response Byte of a defined Host Command :

uint8_t readByte(uint8_t _familyByte, uint8_t _indexByte,\
                                           uint8_t _writeByte)
{

    uint8_t returnByte;
    uint8_t statusByte;

    _i2cPort->beginTransmission(_address);
    _i2cPort->write(_familyByte);
    _i2cPort->write(_indexByte);
    _i2cPort->write(_writeByte);
    _i2cPort->endTransmission();
    delay(CMD_DELAY);

    _i2cPort->requestFrom(_address, sizeof(returnByte) + sizeof(statusByte));
    statusByte = _i2cPort->read();
    if (statusByte)// SUCCESS (0x00)
        return statusByte; // Return the error, see: READ_STATUS_BYTE_VALUE 

    returnByte = _i2cPort->read();
    return returnByte; // If good then return the actual byte. 

}

to have a function that uses the nrf_dr_twi, like this: 

uint32_t nrf_drv_read_registers(uint8_t reg, uint8_t* p_data, uint32_t length)
{
    uint32_t err_code;
    uint32_t timeout = OXI_TWI_TIMEOUT;

    err_code = nrf_drv_twi_tx(&m_twi_instance, OXI_ADDRESS, &reg, 1, false);
    if (err_code != NRF_SUCCESS) return err_code;

    while ((!twi_tx_done) && --timeout) ;
    if (!timeout) return NRF_ERROR_TIMEOUT;
    twi_tx_done = false;

    err_code = nrf_drv_twi_rx(&m_twi_instance, OXI_ADDRESS, p_data, length);
    if (err_code != NRF_SUCCESS) return err_code;

    timeout = OXI_TWI_TIMEOUT;
    while ((!twi_rx_done) && --timeout) ;
    if (!timeout) return NRF_ERROR_TIMEOUT;
    twi_rx_done = false;

    return err_code;
}

Have you some ideas on how i can use the family and index byte of the Sensor Hub in order to retrieve the correct byte? 

Thank you very much in advance,

Kind regards

[Karl Ylvisaker]

Hello Polimarte,

Have you some ideas on how i can use the family and index byte of the Sensor Hub in order to retrieve the correct byte? 

It is as @awneil says - we do not support Arduino, unfortunately.
However, as awneil mentions, I would recommend reading the Sensor Hubs documentation, to figure out how to implement the interface.
It will be easier for you to see what the Sensor Hub is expecting to receive from its datasheet, rather than reading it and translating it directly from an Arduino implementation.

Best regards,
Karl

[awneil]

Karl Ylvisaker said:

I would recommend reading the Sensor Hubs documentation, to figure out how to implement the interface.

Absolutely!

That is always the basic first step in interfacing to any device!

How To Interface Anything To Anything Else

And don't forget to look at the Product Page on the manufacturer's websites:  that is where the manufacturers will present all their supporting collateral - including datasheets, application notes, example code, etc: 

https://www.avrfreaks.net/commen...

 

https://www.avrfreaks.net/commen...

 

Again, this is a key first step in working with any new part.

[Karl Ylvisaker]

If I could have upvoted your answers twice, or otherwise highlighted your answers here I definitely would have, @awneil !


Best regards,
Karl

[awneil]

[polimarte]

Hi i'am sorry to have given a very vague question. I have understood a bit more, now i can describe well my problem, maybe.

The read and write action on my sensor hub are described as:

and i want to use the nrf_drv_tx and rx in order to implement these actions.

If i have the function 

ret_code_t nrf_drv_twi_tx	(	nrf_drv_twi_t const * 	p_instance,
        uint8_t 	address,
        uint8_t const * 	p_data,
        uint8_t 	length,
        bool 	no_stop 
)

where

[in]	p_instance	Pointer to the driver instance structure.
[in]	address	Address of a specific slave device (only 7 LSB).
[in]	p_data	Pointer to a transmit buffer.
[in]	length	Number of bytes to send.
[in]	no_stop	If set, the stop condition is not generated on the bus after the transfer has completed successfully (allowing for a repeated start in the next transfer).

If i need to transmit a series if byte as for example only the Family and Index Byte in order to write,  would i need a buffer (p_data) as an array of dimension 2, able to store these two bytes? 

and so for the reception if i want to retrieve the Status and the Response byte would i need another buffer with same dimension?

Hope to hear you again and thanks for help me!

polimarte

[Karl Ylvisaker]

Hello Polimarte,

Sorry for my late reply.

polimarte said:

i'am sorry to have given a very vague question.

Do not worry, asking the right questions is an art in and of itself. :) 

polimarte said:

I have understood a bit more, now i can describe well my problem, maybe.

Great! Let us see if we can't get to the bottom of this issue then.

polimarte said:

If i need to transmit a series if byte as for example only the Family and Index Byte in order to write,  would i need a buffer (p_data) as an array of dimension 2, able to store these two bytes? 

With the information you have provided above, it seems to me that your device requires the start of a typical write to contain ADDR - FAMILY - INDEX - content.
Based on this  I would recommend that you implement this as an array of commands in an array, which you then queue for transfer. You can do this by providing the NRFX_TWIM_XFER_DESC_TX macro with this array of commands, and then passing this this to the nrfx_twim_xfer function.

Alternatively, if if you do not intend to use the nrfx_twim driver, you could take a look at how some other TWI master drivers for specific components have been implemented. You could see some examples of this in the SDK/components/driver_ext folder of the SDK.
For example, you could see the external driver for the lis2dh12, located in SDK/components/drivers_ext/lis2dh12
Especially, note how all the registers are defined in the internal file - this makes writing the driver a lot easier - and how there are functions for specific tasks. Implementing these config and control functions makes using your driver much easier.
Even if you are planning to use the nrfx_twim driver, you could use the same general structure / approach from this driver, in your driver. 

Lastly, I also recommend that you do a search on github for the specific component you are working with, if the internal registers file is not provided by the component manufacturer - chances are that someone already have transcribed all the register addresses for your particular component, which greatly reduce the time you have to sit and 'transcribe' these addressees from the datasheet directly.

Best regards,
Karl