[SOLVED] Selecting an ultrasonic sensor and interface

[dbrgn]

I just ordered a LTC1754ES6-5. Let's see how that works out

What are you going to power with that thing?

As written in the post above it, a HC-SR04 ultrasonic sensor. It is very cheap and first tests have shown that it's quite accurate.

[alex]

As written in the post above it, a HC-SR04 ultrasonic sensor. It is very cheap and first tests have shown that it's quite accurate.

The specs really are promising. The sensor's shape is much better than my MB1242 for mounting it under the CF. I should have had an eye on that before I bought it.


@Tobias or everyone else who can help

I updated my fork with your I2C2 fix and finally get an I2C signal on the expansion port. Nonetheless I can only see a start condition with my DSO (SDA above, SCL below):

NewFile0.png (3.74 KiB) Viewed 1302495 times

The I2C calls fail completely (see log group mb1242_debug). Don't have a clue about what still could be wrong.

Would you be so kind to post a code example of your freeIMU board including the I2C2 initialization call and read/write calls?

mb1242.c

Code: Select all

#include "i2cdev.h"
#include "log.h"
#include "mb1242.h"

//static uint8_t devAddr;
static I2C_TypeDef *I2Cx;
static uint8_t sonarBuffer[2];
static bool isInit;

static bool I2cReadSuccess;
static bool I2cWriteSuccess;

void mb1242Init(I2C_TypeDef *i2cPort)
{
  if (isInit)
    return;

  I2Cx = i2cPort;
  //devAddr = MB1242_I2C_ADDRESS;

  isInit = TRUE;
}

void mb1242RequestRangeReading()
{
	// Write command 0x51 to request a range reading.
	I2cWriteSuccess = i2cdevWriteByte(I2Cx, MB1242_WRITE_ADDRESS, I2CDEV_NO_MEM_ADDR, MB1242_TAKE_RANGE_READING_CMD);
}

uint16_t mb1242GetRangeReading()
{
	// Read high byte of range reading.
	I2cReadSuccess = i2cdevReadByte(I2Cx, MB1242_READ_ADDRESS, I2CDEV_NO_MEM_ADDR, &sonarBuffer[0]);

	// Read low byte of range reading.
	I2cReadSuccess &= i2cdevReadByte(I2Cx, MB1242_READ_ADDRESS, I2CDEV_NO_MEM_ADDR, &sonarBuffer[1]);

	return (((uint16_t)sonarBuffer[0]) << 8) | sonarBuffer[1];
}

LOG_GROUP_START(mb1242_debug)
LOG_ADD(LOG_UINT8, I2cRead, &I2cReadSuccess)
LOG_ADD(LOG_UINT8, I2cWrite, &I2cWriteSuccess)
LOG_GROUP_STOP(mb1242_debug)

stabilizer.c - (sonar communication calls in main loop)

Code: Select all

// 10 Hz
      if (++sonarCounter >= SONAR_UPDATE_RATE_DIVIDER)
      {
    	  if (requestedRangeReading == true)
    	  {
    		  sonarDist = mb1242GetRangeReading();
    		  requestedRangeReading = false;
    	  }

    	  if (requestedRangeReading == false)
    	  {
			  mb1242RequestRangeReading();
			  requestedRangeReading = true;
    	  }

    	  sonarCounter = 0;
      }

Thanks again.

[tobias]

I'll try to look in to it. When I tested it I just changed the I2C1 in imu.c to I2C2 so the whole imu was run from the external sensor board instead. I also checked the signals with a I2C analyzer so that everything was OK.

Have you called i2cdevInit(I2C2) anywhere?

I think we have a ultrasonic sensor here somewhere, I'll see if I'm able to get that working.

[alex]

Have you called i2cdevInit(I2C2) anywhere?

Yes, in stabilizerInit:

Code: Select all

void stabilizerInit(void)
{
  if(isInit)
    return;

  motorsInit();
  imu6Init();
  sensfusion6Init();
  controllerInit();

  i2cdevInit(I2C2);
  mb1242Init(I2C2);

  rollRateDesired = 0;
  pitchRateDesired = 0;
  yawRateDesired = 0;

  xTaskCreate(stabilizerTask, (const signed char * const)"STABILIZER",
              2*configMINIMAL_STACK_SIZE, NULL, /*Piority*/2, NULL);

  isInit = TRUE;
}

[tobias]

I've found our ultrasonic sensor but it is one of those that you send a pulse and measure the time, so no I2C.

The start-stop condition you see is from the init code which does that to unlock possible locked slaves during init. To test that you get any communication try to change the imu.c to read from the I2C2 port instead by changing from I2C1 to I2C2 in the init functions e.g:

Code: Select all

i2cdevInit(I2C2);
mpu6050Init(I2C2);
...

And watch the communication with your scope.

Also make sure the UART isn't activated (ENABLE_UART) as it uses the same pins.

[alex]

Also make sure the UART isn't activated (ENABLE_UART) as it uses the same pins.

Neither did I alter this setting nor do I know where to look for it.

I've found our ultrasonic sensor but it is one of those that you send a pulse and measure the time, so no I2C.

The start-stop condition you see is from the init code which does that to unlock possible locked slaves during init. To test that you get any communication try to change the imu.c to read from the I2C2 port instead by changing from I2C1 to I2C2 in the init functions e.g:

Code: Select all

i2cdevInit(I2C2);
mpu6050Init(I2C2);
...

And watch the communication with your scope.

Changed those two lines to I2C2 and disabled my own MB1242 init calls in stabilizer.c, but no signal at all on the I2C2 bus. The console tab states:

IMU: MPU6050 I2C connection [FAIL].
IMU: HMC5883L I2C connection [FAIL].

Isn't that exactly what we would expect since the MPU6050 isn't physically wired to the I2C2 bus? What was your intention?


Moved my i2cdevInit(I2C2) and mb1242Init(I2C2) from stabilizerInit to imu6Init, directly below the existing i2cdevInit(I2C1) (see latest commit). No effect either, but it's in the correct place now, I guess.

[tobias]

Isn't that exactly what we would expect since the MPU6050 isn't physically wired to the I2C2 bus? What was your intention?

I would expect to see some failed communication showing up on the scope.

I was trying to get hold of a mb1242 but they seem to be sold out everywhere. Would have made it a lot easier to help you. I will try to find more time tomorrow to test the I2C2 bus.

[alex]

Isn't that exactly what we would expect since the MPU6050 isn't physically wired to the I2C2 bus? What was your intention?

I would expect to see some failed communication showing up on the scope.

No, nothing.

I was trying to get hold of a mb1242 but they seem to be sold out everywhere. Would have made it a lot easier to help you. I will try to find more time tomorrow to test the I2C2 bus.

I wouldn't mind to send you mine if it helps.

[tobias]

I've done some testing on the I2C bus and for me it works as expected. If I do the same thing as you did, move the imu communication to I2C2, I get a bunch of transactions with no ACK since there aren't anything there to answer. Next thing will be to try using your code.

[tobias]

I've tested with your code an I think there has been some merge problems. The files i2croutines.c, i2croutines.h and nvic.c where not as they should. I have attached a patch so you can update them. Then the I2C2 bus should work again.

Code: Select all

git apply i2cfix.patch