Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LIDARLite_v3HP_read uses Repeated Start but datasheet says its not supported #17

Open
kais0r opened this issue Apr 27, 2020 · 0 comments

Comments

@kais0r
Copy link

kais0r commented Apr 27, 2020

Hi.
I just realized that the Library for the v3HP uses the Repeated Start Condition in LIDARLite_v3HP_read Function in /src/LIDARLite_v3HP.cpp on Line 398:
nackCatcher = Wire.endTransmission(false); // false means perform repeated start

Compleete function:

void LIDARLite_v3HP::read(uint8_t regAddr, uint8_t * dataBytes,
                          uint16_t numBytes, uint8_t lidarliteAddress)
{
    uint16_t i = 0;
    int nackCatcher = 0;

    // Set the internal register address pointer in the Lidar Lite
    Wire.beginTransmission((int) lidarliteAddress);
    Wire.write((int) regAddr); // Set the register to be read

    // A nack means the device is not responding, report the error over serial
    nackCatcher = Wire.endTransmission(false); // false means perform repeated start
    if (nackCatcher != 0)
    {
        Serial.println("> nack");
    }

    // Perform read, save in dataBytes array
    Wire.requestFrom((int)lidarliteAddress, (int) numBytes);
    if ((int) numBytes <= Wire.available())
    {
        while (i < numBytes)
        {
            dataBytes[i] = (uint8_t) Wire.read();
            i++;
        }
    }

} /* LIDARLite_v3HP::read */

In the Datasheet on Page 6 it says:

Notes:
• This device does not work with repeated START conditions. It must first receive a STOP condition before a new START condition.
• The ACK and NACK items are responses from the master device to the slave device.
• The last NACK in the read is technically optional, but the formal I2C protocol states that the master shall not acknowledge the last byte.

It seems to work. But i implemented it into an other microcontroller and we ran into some I2C stucks when having higher EMI Problems. By digging into the code we found this issue...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant