"Expected an identifier" Error in USBDevice_Types.h on mBuino

Archive
21

setup() is already a separate function, but if I understand your suggestion correctly, updated constructor would look like this?


Accelerometer::Accelerometer() {
 
    ledReady = 1;
    i2c.frequency(100000); //freq de i2c 100KHz
    wait(0.02); // El acelerometro tarda 20ms en arrancar

    pc1.printf("Waiting 10 seconds before setup...\r\n");
    wait(10); 

    pc1.printf("Calling setup()...\r\n");
 
    setup(); // to initialize the accelerometer
    int response = 0;
   response = check(); // To see if I set you have to read the record 16.
    pc1.printf("Response: ");
    pc1.printf("%d \r\n",response);
    //response = 0x05;
    if (response != 0x05) {
        pc1.printf("Setup error...\r\n");
        while (1) {
            ledErr = !ledErr;
            wait(0.1); // If failure remains blinking led
        }
    }
 
    calibrate();
    ledReady = 0; // on status indicator, ready to use
}

Does that seem right?
22

@ Architect - Waiting 10 seconds before calling setup() does not seem to make a difference in function, but reading the command register prior to setup returns 0 instead of 96.

I also tested modifying the pin definitions in the header file, to double-check if I might have those wrong, and I confirmed that if I set the pins wrong I get the bad configuration flashing LED pattern, so I’m pretty confident I have the pins set correctly.

23

@ Architect - Trying to understand how this works. Here’s the code for the check() function:

char Accelerometer::check() {
 
    pc1.printf("Starting check()...\r\n");
    char data, reg;
    reg = 0x16;
    pc1.printf("Writing %x to %x ...\r\n", reg, addr);
    i2c.write(addr, &reg, 1);
    wait(0.01);
    
    pc1.printf("Reading from %x ...\r\n", addr);
    i2c.read(addr, &data, 1);

    pc1.printf("Returning %x from check()...\r\n", data); 
    return data;
}

In the code above, is addr the address of the i2c device (the accelerometer)? If so, then the i2c.write call is just writing the value of reg to the accelerometer?

24

This is what I know about that: in I2C all devices have their own (hardwired) address to allow multiple devices on the same I2C pins. To read a value you first tell the device which value you want to read, by writing the register-address to the device-address. In the subsequent call you read the value of that register using the same device-address. So to read you first need to write!

For reference: similar constructs can be found in the E-Dice code:


void MMA845x::readRegister(uint8_t registerAddress, uint8_t* data, int length)
{
    char convertedRegisterAddress[] = {registerAddress};
    i2cBus.write(i2cAddress, convertedRegisterAddress, 1, true);
    i2cBus.read(i2cAddress, (char*)data, length);
}
25

@ devhammer - @ maxint described it correctly. Trying to find my module.

26

@ devhammer - Got the module. I am going to try it with your code.

27

@ devhammer - Tried the code as is (changed the led pin in accelerometer class) and it worked from the first try. Went back to your posts and I think I have found the issue. It looks like you have reversed SDA and SCL pins in the constructor.

It should be like this:


Accelerometer acer(P0_5,P0_4);

;D

28

Which code? I don’t think I have any code that calls the constructor passing in the pins.

The library code I’m using passes the pins to the I2C constructor, like so:



and the header file defines I2C_SDA and I2C_SCL like so:



```cpp

 #define I2C_SDA P0_5 
 #define I2C_SCL P0_4

The result should be that the I2C instance is initialized with the correct pins, no?

Per the docs here:

http://developer.mbed.org/handbook/I2C

The initialization in the first code snippet should be correct, based on the pins defined in the second.

29

@ devhammer - Ok, looks like we are using different libraries now.

I have imported this library as a “program”

Then I have changed i2c_accelerometer.cpp to use mBuino led as debug led:


...
//DEBUG
//DigitalOut led(LED1);
DigitalOut ledbg(P0_7);
//extern Serial pc;
...

Then I have changed his test_accel.cpp to this:


/* *************************************
 * Biblioteca para uso del acelerometro MMA7455L
 * Club de Robotica - FIUBA
 */

 #include "mbed.h"
 #include "USBSerial.h"
 #include "i2c_accelerometer.h"

USBSerial serial;
void TestAcc(void);

int main() {
    TestAcc();
}

void TestAcc() 
{
    uint8_t buf[16];
    
    float xyz[3];
        
    serial.scanf("%s", buf);
    serial.printf( "Accellerometer MMA7455L test %s\r\n",buf );
        
    Accelerometer acer(P0_5,P0_4);
    
    while (1) 
    {
        acer.get8BitVector(xyz);
        serial.printf("%4.3f || %4.3f || %4.3f \r",xyz[0],xyz[1],xyz[2]);        
        wait(0.5);
    }
}

You will need to import USBDevice library as well. Also after you connect with putty you need to pres any key and hit enter. TestAcc function waits to read something from the console at the top.

30

@ Architect - LOL.

Yeah, I think I may have been a bit punchy yesterday…was operating on less sleep than I need.

I had pulled down the initial version of

because it appeared to be a little less complex. That version didn’t pass the pin assignments to the constructor.

Very sorry for the confusion.

I created a new program, imported the most recent version of the arielburman mma7455 library, and made the modifications you specify, but still no luck. I get the initial output:

“Accellerometer MMA7455L test” plus the letter(s) I type before hitting Enter, but after that I get LED7 flashing indicating an error, which I’m guessing is the same thing I’ve been seeing, an incorrect value returned from the check() function.

In the meantime, I also tried hooking up the accelerometer to a Cerbuino Bee and created a test Gadgeteer program, just to make sure that the module was operating correctly, and it works fine with Gadgeteer.

Are you using a breakout board to wire the module to the mBuino? If so, can you snap a pic of the pins on the breakout and mBuino? Mine are attached.

31

I took it apart, but your wiring looks good. How are you instantiate the accelerometer object?

32

At this point, I’m using the same code you posted most recently. I imported the current version of:

applied the change of the debug LED, and then just copied the code for test_accel.cpp line for line from your post.

So I’m initializing the accelerometer object the same as you, I think.

33

And still not working? Keep in mind that debug led supposed blink rapidly during calibration procedure for a second or so.

34

I’ll tweak the timing on the debug LED code to distinguish between error and calibration, but I let it go for a while, and it didn’t seem to do anything other than the initial debug message.

35

Very strange. Especially that you got it working with Gadgeteer.

36

I don’t get it either. I don’t think I’m doing anything differently from you, but I am definitely hitting the error in the setup() function, as I modified the wait from 0.25 to 0.5 and that’s the pattern I’m seeing. I never actually get to calibration at all.

As for Gadgeteer, this is a great example of why I love Gadgeteer. With the right drivers, using a device like this is a piece of cake, and requires only a few lines of code.

Had my first microcontroller experience been trying to get this accelerometer working with mBuino, I probably would have given up in frustration.

That’s not a knock on mBuino, which I like very much, but rather it’s a complement to Gadgeteer, which makes a great gateway to micros for those of us not blessed with an existing knowledge of C/C++ and the fiddly bits of I2C, etc. :slight_smile:

I’ll probably take another whack at it this week, but I think for tonight I’m going to go watch the Redskins play (and one assumes, lose to) the 49ers (it’s on DVR, so no spoilers, please!).

Thanks, as always, for your help and advice!

37

Finally found the problem, which I should have tested way earlier, particularly after getting it to work with Gadgeteer.

Turns out that the breakout module I was using (one of @ ransomHall’s MakeBread modules) must not have been passing through all of the pins.

I figured it out because I gave up on the accelerometer, and tried connecting a DisplayN18 module instead, and that didn’t work either, despite double-checking all of the pin connections and the code. Given that the N18 uses SPI, I figured something had to be going on in hardware, which is when I decided to try a different module for breaking out the Gadgeteer pins (switched to a GHI Extender module).

BANG! N18 started working right away, so I switched up the pins, and then tested the accelerometer code again, and now it’s working perfectly.

Whew! Glad it’s finally working.

Thanks again for patiently walking me through all the steps…gotta remember to check the breakout earlier next time. :slight_smile:

38

Glad you have figured it out. As far as the bad breakout module. I think I used that one before without any problems. May be just a bad soldering on one of the pins. You can try to reheat the pin with your iron. It might fix the issue.

39

I tested all the pins, and it looks like it’s the ground that’s the problem, and that’s the pin that runs through the diode. All the solder joints look pretty solid, so I’m thinking maybe it’s a bad diode.

Diode test on my EX210 reads 0.185v. The manual says that the expected value should be between 0.400 and 0.700v, so that might confirm the diode is the issue?

Not a big deal either way, as I have a ton of extender and MakeWire modules I can use as breakouts.

40

You can bypass it completely. Cut it off and solder a wire jumper.