BrainPad Accelerometer Problem

First some background.

VS 2013 Pro
I am using a MFConsole application for my BrainPad.
BrainPad.cs is used in the VS Solution.

The BrainPad responds and returns information from serial commands sent by a Windows Form.
I can use BrainPad COM1 or COM2 with success.

I am able to use/control all the devices on the brain pad without issues except for the Accelerometer.

What is strange is the accelerometer returns the same values every access. On very rare occasions the Z Axis shows a different value. X and Y are always the same value.

X always returns 0.0586
Y always returns 0.3066
Z is almost always 0.8633 but sometimes this will change (But never changes unless power is removed from the board)

The code I use for the accelerometer portion of my application.
Am I missing something?

//The MMA8453Q's standard slave address is a choice between the two sequential addresses 0011100 and 0011101.
//Slave address SA0~
//High: 0011101 Hex 1D (29) Slave Address (SA0 = 1)
//Low:  0011100 Hex 1C (28) Slave Address (SA0 = 0)

//I2C device, device = new I2C(0x1C);
//device.WriteRegister(0x2A, 0x01);

//SCL   PB6/PWM11/I2C1.SCL E13 - Clock - Pin 4 MMA8453Q
//SDA   PB7/PWM12/I2C1.SDA E14 - Serial data - Pin 6 MMA8453Q

//Begin on UP Button pressed or Command from Windows Form
static void DoAccelerometer()
    byte[] buffer;
    double dX = 0.0E;
    double dY = 0.0E;
    double dZ = 0.0E;

    //Exit loop if the RIGHT button is pressed or bool stopAccel is true
        dX = BrainPad.Accelerometer.ReadX();    //ReadX() ReadAxis(0x01)
        dY = BrainPad.Accelerometer.ReadY();    //ReadY() ReadAxis(0x03)
        dZ = BrainPad.Accelerometer.ReadZ();    //ReadZ() ReadAxis(0x05)

        BrainPad.Display.DrawString(1, 50, "Accel X: " + dX.ToString("F4"), BrainPad.Color.Green);
        BrainPad.Display.DrawString(1, 60, "Accel Y: " + dY.ToString("F4"), BrainPad.Color.Green);
        BrainPad.Display.DrawString(1, 70, "Accel Z: " + dZ.ToString("F4"), BrainPad.Color.Green);
        //Send data to Windows Form
        string x = "\r\nAccel X: " + dX.ToString("F4");
        buffer = Encoding.UTF8.GetBytes(x);
        UART1.Write(buffer, 0, buffer.Length);

        string y = "\r\nAccel Y: " + dY.ToString("F4");
        buffer = Encoding.UTF8.GetBytes(y);
        UART1.Write(buffer, 0, buffer.Length);

        string z = "\r\nAccel Z: " + dZ.ToString("F4") + "\r\n";
        buffer = Encoding.UTF8.GetBytes(z);
        UART1.Write(buffer, 0, buffer.Length);

        if (stopAccel)

//Command from Windows Form
static bool stopAccel = false;
static void StopAccel() 
    stopAccel = true;

The code shows usage of the Display and the Serial port returning the accelerometer data. Removing this code does not matter.
If I use Debug.Print(values) I get the same numbers.

Thanks in advance for any advice.

Why not create a complete and simple program that only reads the accelerometer.

@ willgeorge - There is actually a bug in the BrainPad driver. Change the [0] on line 1640 to [1] and that’ll fix it.

@ John -

I thought it was my fault.

EDIT: Applied your fix and it is now working…

I think the bug shows up on line 1785 in the latest source on BrainPad support page. Can you confirm John? For me, line 1640 is a comment.

The Scratch firmware uses an older version of the driver file that did not have this typo.

@ mcalsyn - 1640 is the correct line for me. There are only 1670 lines in the file. I2C.WriteRegister(byte, byte); is the function that needs to be fixed.


Sure looks like line 1785 to me - see image

@ mcalsyn - Looks like your file was autoformatted. Our file has the braces on the same line while you have them on the next.

Doooooh - you’re right - thank you Visual Studio. :wall:

What kind of cretin puts braces on the same line still? That’s so 1980’s :slight_smile:

Actually, more like 1960’s (K&R and 1TBS style). There’s more nesting styles than you can shake a curly bracket at : Indentation style - Wikipedia

There are large swaths of a certain productivity suite at a certain large software firm that still uses Whitesmith style, which (to me) is the worst of all worlds. But that’s just me. I’m an Allman fella myself.

COBOL doesn’t need no stinky braces! It has real paragraphs like Grace Hooper intended.

1 Like

Allman all-the-way here too… Gnu and Horstmann are “OK” (I guess.)

The other “condense stuff just to condense stuff” styles were okay for 24 line monochrome monitors of the pre-cambrian period… but today… don’t they seem antiquated?

If you don’t line up your braces, you are making your code less readable. Whitesmiths though… that’s just horrible, lol

…Back to your regularly scheduled thread…

+1 :dance:

1 Like