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

Archive
1

Trying to put together a quick demo of an accelerometer with mBuino, and when I try to compile the example with USBSerial for debugging, I get the following exception:

“Error: Expected an identifier in “USBDevice/USBDevice/USBDevice_Types.h”, Line: 75, Col: 43”

which is weird, because I’ve used the USBDevice library for serial debugging in other projects with no problem at all, and I verified that the code for USBDevice_Types.h is identical from the program where it works to the one I’m testing now.

The main difference between the 2 programs is that the one I’m using now also includes a library for using the MMA7745L accelerometer via I2C.

Is it possible that the accelerometer library is clobbering something in the USBDevice library and causing this error? I’m not sure where to begin troubleshooting this.

2

Quick follow-up…I tested and if I comment out the accelerometer header reference and code, the rest compiles fine. So it appears there is a conflict between the two somehow.

If anyone has suggestions on the best means of locating the conflict (not sure what tools the online mBed environment offers for search, etc. in code), I would be grateful.

3

OK, I’m not sure why this worked, but I managed to get rid of the compiler error by moving the USBDevice.h include directive before the accelerometer library include directive.

Don’t have the accelerometer library working yet, but at least I’m one step closer, and I can debug a bit more effectively. :slight_smile:

4

@ devhammer - BTW e-dice project has class for accelerometer and working code.

5

Unfortunately, I’m not sure that’ll work. The code for e-dice is for the MMA845x, while I’m using the Seeed Gadgeteer accelerometer module, which uses the MMA7745L:

https://www.ghielectronics.com/catalog/product/320
http://www.seeedstudio.com/depot/Accelerometer-Module-NET-Gadgeteer-Compatible-p-968.html (comments tab has the module info)

I’ve gotten past a couple of hurdles, but I’m definitely in over my head. I can’t even manage to get a simple int value to print out to the serial debug…for example, I’ve got a simple loop in main() to wait while I get the terminal connected to the virtual serial port:


    int timeToWait;
    for (timeToWait = 10; timeToWait > 0; timeToWait--)
    {
        pc.printf("Waiting... %f seconds remaining...\r\n", timeToWait);
        wait(1); 
    }

and here’s what I get on every iteration of the loop:

“Waiting… 0.000000 seconds remaining…”

The loop works, so I know that the timeToWait variable is being decremented, but I don’t get the right value out. Makes debugging a little harder when I can’t write out the values of variables reliably. :frowning:

6

try %d instead and increase the wait

7

%d got the output working…didn’t need to increase the wait, as I wasn’t having any issues getting the serial port connection from the PC.

Beginning to wonder, though, whether I’d be better off just getting a different accelerometer, one that’s a little newer.

Something like this:

https://www.sparkfun.com/products/12756

might even already be compatible with the e-dice code.

Trouble is, I think I have everything wired up properly (GND from the breakout to ground on mBuino, Pin9 from the breakout to P0_4 on mBuino, Pin8 from the breakout to P0_5 on mBuino, and 3v3 on the breakout to 3v3 on mBuino), but when I initialize the accelerometer, the value that comes back is wrong (code is expecting 0x05, and what’s coming back is 0x16).

Given that I don’t have the data sheet, and even if I did, I’m probably way out of my depth in the bowels of i2c, perhaps moving to something that might be compatible with the e-dice library would be wise.

8

Can you show your code please?

9

@ Architect -

Constructor is as follows:

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

    pc1.printf("Calling setup()...\r\n");
 
    setup(); // to initialize the accelerometer
    int response = 0;
    pc1.printf("Response: ");
    pc1.printf("%d \r\n",response);
    // this is where the function is called to check if the accelerometer is properly initialized
    response = check(); // To see if I set you have to read the record 16.
    pc1.printf("Response: ");
    pc1.printf("%d \r\n",response);
    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
}

Here’s the check() function:

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

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

If I modify the call to check() to just return 0x05, the remaining code, including calibration, seems to run, but I don’t know that I get correct values from the accelerometer.

Now that I think about it, though, I may not have updated the printf statements for that part of the code, so I’ll take a look at that and see if I’m getting actual values back if I hard code the response value.

10

What the addr variable is set to?

11

@ Architect - addr is set in the i2c_accelerometer.h file:



Just ran the code with the response hard-coded to 0x05, and confirmed that I do not get valid values back.
12

@ devhammer - Try this code:

13

I’d found that earlier, but hadn’t tried it yet.

For this line:



Do I need to update the params to use the pin values for the mBuino (i.e. P0_4, P0_5)?
14

Absolutely! that is the pins you have connected accelerometer to, correct?

15

Correct. Just wanted to make sure I wasn’t misunderstanding how the I2C was initialized, or the correct representation of the pins.

16

@ Architect - The code compiles and runs, but it’s showing zeros for pretty much all of the data values. Here’s the output from PuTTY:

Read some registers:

WHOAMI register: (v[0],v[1],v[2],v[3]) = (0, 0, 0, 255)

I2C ADDRESS: (v[0],v[1],v[2],v[3]) = (0, 0, 0, 255)

MODE CONTROL register: (v[0],v[1],v[2],v[3]) = (0, 0, 0, 255)

Write to MODE CONTROL register 0x16

MODE CONTROL register updated: (v[0],v[1],v[2],v[3]) = (0, 0, 0, 255)

Interrupt latch register: (v[0],v[1],v[2],v[3]) = (0, 0, 0, 255)

Status: (v[0],v[1],v[2],v[3]) = (0, 0, 0, 255)

Clear offset registers

data = 0
(H, L) = (0, 0 )

data = 0
(H, L) = (0, 0 )

data = 0
(H, L) = (0, 0 )

Autocalibration: lay device down horizontal and do not move

x:
(msb, lsb): (0, 0)

a = 0

y:
(msb, lsb): (0, 0)

a = 0

z:
(msb, lsb): (0, 0)

a = 0

x:
(msb, lsb): (0, 0)

a = 0

y:
(msb, lsb): (0, 0)

a = 0

z:
(msb, lsb): (0, 0)

a = 0

x:
(msb, lsb): (0, 0)

a = 0

y:
(msb, lsb): (0, 0)

a = 0

z:
(msb, lsb): (0, 0)

a = 0

x:
(msb, lsb): (0, 0)

a = 0

y:
(msb, lsb): (0, 0)

a = 0

z:
(msb, lsb): (0, 0)

a = 0

Autocalibration complete!

Write offset registers

data = 0
(H, L) = (0, 0 )

data = 0
(H, L) = (0, 0 )

data = 128
(H, L) = (0, 128 )

Waiting…

Read x, y, z with offset correction

x corrected:
(msb, lsb): (0, 0)

a = 0

y corrected:
(msb, lsb): (0, 0)

a = 0

z corrected:
(msb, lsb): (0, 0)

a = 0

Start pulse detection

17

Must be an old code. Hasn’t been updated since 2011. I have to check if I have that module and try it.

Is there a Gadgeteer driver for it, by the way?

18

Never mind. I found the source code.

What does it return when you just read the command register (0x16) at the very beginning (without writing anything to it)?

19

The following code, when run in the constructor for the Accelerometer library, returns 96 (0x96):


    pc1.printf("Reading command register...\r\n");
    char data;
    i2c.read(0x16, &data, 1);
    pc1.printf("Command register value = %x ...\r\n", data);

if I use %d instead of %x, it returns 150.

20

I have an idea. Try waiting for 10 seconds and the do the setup sequence. Don’t do it in the constructor.