View Full Version : Help with 2010 Accelerometer & I2C
wt200999
14-01-2010, 12:07
I am trying to implement the kit accelerometer, and I started by basing it off of the HiTechncCompass class from last years code. (I can't find the newest version, but I doubt that class has changed). The problem I am having is when I try to initialize the I2C in my robot constructor, the constructor does not finish and the robot stops responding. The console output from the serial port also does not give me any errors either. Here is the class I started, with simple functions just to see what I can get out of it:
I2CAccel.h
#ifndef __I2CACCEL__
#define __I2CACCEL__
#include "SensorBase.h"
class I2C;
class I2CAccel : public SensorBase
{
public:
I2CAccel(UINT32 ModuleSlot);
~I2CAccel();
float Get();
private:
static const kAddress = 0x3A;
static const kReadAddress = 0x3B;
static const kPowerSaving = 0x08;
static const kPowerCtrl = 0x2D;
I2C* m_i2c;
};
#endif
I2CAccel.cpp
#include "I2CAccel.h"
#include "DigitalModule.h"
#include "I2C.h"
I2CAccel::I2CAccel(UINT32 slot)
: m_i2c (NULL)
{
//Somewhere on these 3 lines it fails...
DigitalModule *module = DigitalModule::GetInstance(slot);
m_i2c = module->GetI2C(kAddress);
m_i2c->Write(kPowerSaving,kPowerCtrl);
}
I2CAccel::~I2CAccel()
{
delete m_i2c;
m_i2c = NULL;
}
float I2CAccel::Get()
{
UINT16 value;
m_i2c->Read(kReadAddress, sizeof(value), (UINT8 *)&value);
return (float)value;
}
I was wondering if anyone else has gotten theirs working?
bcieslak
15-01-2010, 12:33
I am working on the same project with my team ::ouch:: and play to modify the compass code to get me started. I am hoping the I2C code is good so I can concentrate on the accelerometer.
At first glance of the data sheet for the adxl345 it appears we will need to add more code that just the read of one register. Data is in 3 different registers at addresses 0x32 to 0x37 in a two's complement format so I would guess that returning a float from the read is the wrong choice. The compass may return a float but not the accelerometer. (this is what if get from the data sheet anyway).
We will probably have to trigger a sampling of some sort before the read.
I am not sure how the chip select is getting set or what the address is on the acclerometer. I'll start by assuming the chip is always selected and the address is zero (0).
As far as your code goes the only address I recognized is the power control register, not sure where you got the other ones. there not on my data sheet.
I'll keep you posted on what I find this weekend. And look forward to what others have to say.
Brian
bcieslak
15-01-2010, 13:21
I had a little more time to dig into the data sheet and can see where you got address 3a and 3b from. It is the result of adding the r/w bit to the 7 bit address. From looking at the I2C code I wonder if it twittles that read write bit for you. I wonder if the address they are really looking for there is 0x1D.
If you want to work this out off line my email address is k9wis@yahoo.com
Brian
bcieslak
15-01-2010, 15:56
One last thing...Don't try to turn on the measurement bit in the constructor.
There may be other objects associated with the I2C stuff that hasn't been constructed yet. Create an init method where you do the write and call it after you are sure all the construcing is done, like the first part of your main loop.
Brian
::ouch::
wt200999
15-01-2010, 20:43
Yeah the address given in the Sensor Guide says 0x3A, and I figure its all in 8bit for the WPI Function, so the 0x1D wouldn't work with that but 0x3A would?? I really don't know I2C or WPI's implementation of it, so I don't really know. I'm going to keep playing with it tonight.
I also just found the register map, didn't see it in the datasheet when I worked on it last, don' know how I missed it.
The biggest issue I am having now is whenever I call the read or write function the robot freezes up, and my console output shows nothing. This is both when I try to perform a read or a write....
slavik262
17-01-2010, 22:53
Any luck so far? It would be awesome if you got this working.
I had a little more time to dig into the data sheet and can see where you got address 3a and 3b from. It is the result of adding the r/w bit to the 7 bit address. From looking at the I2C code I wonder if it twittles that read write bit for you. I wonder if the address they are really looking for there is 0x1D.
The I2C library takes the 8-bit version of the address (i.e. 0x3A). It does automatically set the R/W bit.
The easiest approach would be to port the LabVIEW example called "ADXL345 I2C Accelerometer".
bcieslak
18-01-2010, 09:20
The easiest approach would be to port the LabVIEW example called "ADXL345 I2C Accelerometer".
I am still new to this environment that FIRST has set up for us so please excuse my ingnorance....Where do I find the labview example for I2C. Right now I am set up to write C++ code using the WPI library and the windriver tools..I have no experience with labview..not even sure I have it installed..
Brian
whytheheckme
18-01-2010, 09:50
(I can't find the newest version, but I doubt that class has changed)
If I remember correctly, last year's class was slightly broken. I could be wrong, but you might consider finding the newer one.
Jacob
I am still new to this environment that FIRST has set up for us so please excuse my ingnorance....Where do I find the labview example for I2C. Right now I am set up to write C++ code using the WPI library and the windriver tools..I have no experience with labview..not even sure I have it installed..
Brian
Naturally you need LabVIEW installed. Just run it from the start menu and in the getting started window that pops up on the bottom right there is a short list of examples... click on more examples and look for ADXL345 I2C Accelerometer.
The biggest issue I am having now is whenever I call the read or write function the robot freezes up, and my console output shows nothing. This is both when I try to perform a read or a write....
I did find an issue with the initial release of the I2C for this year. The bug was introduced since last year. See details here: http://firstforge.wpi.edu/sf/go/artf1144
This bug would prevent the accelerometer from working.
bcieslak
22-01-2010, 09:58
Yippeee!! everything is finally working....We re imaged the Crio, made sure 'ALL' the updates were applied to the driver station and the development laptop, compiled then downloaded the BuiltinDefaultCode.out file.
Then we added Joe's accelerometer code and fixed the I2C.cpp file. and all still worked.
We had some problems with the IterativeDemo but I we'll revisit that later. The BuiltinDefaultcode is what we will base our robot code on.
Thanks to all especially Joe Hersh for all the info and his patience..They don't pay you enough...Every one should send Joe a starbucks gift card so he can buy enough coffee to keep him awake when he sending those responses at 3 AM..:ahh:
Brian C
Yippeee!! everything is finally working....We re imaged the Crio, made sure 'ALL' the updates were applied to the driver station and the development laptop, compiled then downloaded the BuiltinDefaultCode.out file.
Then we added Joe's accelerometer code and fixed the I2C.cpp file. and all still worked.
Would you mind posting all the code that got it working for you? Hopefully that should speed it up for everyone.
Thanks
Would you mind posting all the code that got it working for you? Hopefully that should speed it up for everyone.
Here's the discussion where I posted the initial support: http://decibel.ni.com/content/thread/5634
It will be officially included and supported in the next C++ update.
nabioullinr
31-01-2010, 12:33
For some reason I keep receiving 0.0 from GetAcceleration(); am I instantiating the accelerometer correctly?:
ADXL345_I2C(4, ADXL345::kRange_2G)
(assuming the digital sidecar is connected to slot 4)
nabioullinr
31-01-2010, 13:54
We attached an oscilloscope to the bus and noticed that the data returned from the slave accelerometer is 0 for all three transactions (x, y, z); could it be attributed to some sort of a power saving feature which is not disabled?
We attached an oscilloscope to the bus and noticed that the data returned from the slave accelerometer is 0 for all three transactions (x, y, z); could it be attributed to some sort of a power saving feature which is not disabled?
I'm guessing you didn't fix WPILib... http://www.chiefdelphi.com/forums/showpost.php?p=902865&postcount=12
If you fix the I2C library it should start working for you.
nabioullinr
01-02-2010, 15:52
How would I patch wpilib? I could not find anything useful (besides the description of the bug).
How would I patch wpilib? I could not find anything useful (besides the description of the bug).
Download the source code, change the logical OR to a bitwise OR, build the library, run the Scripts/updateBuiltInLibrary.cmd file to install the compiled library, rebuild your project.
-Joe
Shinigami2057
01-02-2010, 16:41
Will this patch be in a team update soon? It's not good that teams already have gone this long with broken support for something in the KoP...
Will this patch be in a team update soon?
I'm not sure... I have no control over release schedules.
It's not good that teams already have gone this long with broken support for something in the KoP...
I know... that's why I've tried to provide timely workarounds, fixes, problem notifications, feature implementation examples, and support the best I can so that teams will not be held up by the release schedules. It's not ideal to need to patch these things manually, but it's also not good to force every team to install and keep track of 10+ updates in various languages that would all be released independently and out of phase with each other. Many teams can't keep up with the one update released at kickoff.
-Joe
Download the source code, change the logical OR to a bitwise OR, build the library, run the Scripts/updateBuiltInLibrary.cmd file to install the compiled library, rebuild your project.
-Joe
I don't get it. I follow those instructions exactly, and it removes the WPILib from Windriver completely when I run the updateBuiltInLibrary.cmd.
I get the "no such file or directory" error.
I don't get it. I follow those instructions exactly, and it removes the WPILib from Windriver completely when I run the updateBuiltInLibrary.cmd.
I get the "no such file or directory" error.
That probably means you didn't build the library successfully. Make sure you build the debug version, since that's what the script copies.
What file or directory exactly does it fail on?
-Joe
ok, I made a new project in Windriver. I copied the entire WPILib and its files (most recent release) into that project, and made the change to the logical OR.
The build target is specified as "Windows-gnu-native-3.x-4.x-debug" (I'm assuming thats what you mean by building the debug version.)
The error is that it can't find "WPILib.h" after I run the updateBuiltInLibrary.cmd
ok, I made a new project in Windriver. I copied the entire WPILib and its files (most recent release) into that project...
The script is expecting the library source to be in "c:\WindRiver\workspace\WPILib" and if it's not there you will get this behavior.
Thank you sir. You have been most helpful!
Shinigami2057
02-02-2010, 00:59
I'm not sure... I have no control over release schedules.
I know... that's why I've tried to provide timely workarounds, fixes, problem notifications, feature implementation examples, and support the best I can so that teams will not be held up by the release schedules. It's not ideal to need to patch these things manually, but it's also not good to force every team to install and keep track of 10+ updates in various languages that would all be released independently and out of phase with each other. Many teams can't keep up with the one update released at kickoff.
-Joe
That's quite understandable. Maybe in future seasons it'd be a good idea to do something along the lines of providing weekly updates that merge in the most critical patches for each language; updates that are helpful but not necessary would be included at longer intervals, perhaps only once per season.
The updates could be optional (e.g., not an 'official mandatory' team update) until the season draws to a close to prevent teams freaking out over things that aren't affecting them until ship draws close.
In any case, thanks a lot for your replies and the hard work you've been doing to make the lives of FIRST teams easier :)
Should the cRIO need to be re-imaged for the patched WPILib to take effect?
I find that I am still unable to write to the device.
Extra details:
I know I'm not writing to the device because after I write to PowerControl and DataFormat regAddress's, I read them, and get back nothing (0). I know I'm reading correctly because I can get the DeviceID just fine. I have patched the WPILib as previous posts have instructed, but I think there might be a missing last step or something obvious that I'm missing.
Should the cRIO need to be re-imaged for the patched WPILib to take effect?
I find that I am still unable to write to the device.
Extra details:
I know I'm not writing to the device because after I write to PowerControl and DataFormat regAddress's, I read them, and get back nothing (0). I know I'm reading correctly because I can get the DeviceID just fine. I have patched the WPILib as previous posts have instructed, but I think there might be a missing last step or something obvious that I'm missing.
The cRIO does not need to be reimaged for the WPILib patch to take effect. WPILib is a static lib that is linked with your program and deployed with your application. If I were you I would double check that you are successfully building the library, running the script to install it, and relinking your application. Do something that would prove all these steps are working such as putting a printf inside one of the I2C methods you are changing. If it prints, you know you have linked against the new version of the library.
-Joe
Make sure you are building the debug build of WPILib.
Bigcheese
04-02-2010, 21:14
FYI: They just released an update to WPILib that fixes all this and adds the ADXL345_I2C class.
It also (finally) adds support for reading 7 bytes instead of just 4. Now I can use the FIFO buffer on the device properly.
nabioullinr
07-02-2010, 13:30
I still receive 0.0 for all three axes, even after updating WPILib and removing the ADXL class I inserted earlier; any ideas?
I still receive 0.0 for all three axes, even after updating WPILib and removing the ADXL class I inserted earlier; any ideas?
When your user program loads, what version of WPILib does it print out?
vBulletin® v3.6.4, Copyright ©2000-2017, Jelsoft Enterprises Ltd.