I’m also trying to wire this chip with the spark core, but had no luck
Can somebody post the entire code how you were able to get it work?
I connected it like this:
// Gnd - GND
// 3.3v - VCC
// 3.3v - CS
// Analog 4 - SDA
// Analog 5 - SLC
And used the demo code from https://github.com/jenschr/Arduino-libraries/tree/master/ADXL345 along with kennethlimcp’s modified .h file, but it drops error continuously
Your help would be appreciated, thank you in advance!
Hey @Noten, it seems like it’s I2C based?
The current firmware in the buildfarm has issues with I2C and a fix it on it’s way.
Sorry about that!
Oh, i didn’t know that. So what is the next step? Should i wait for the fix and start compiling it again? Or should i start downloading the firmware from the web-ide and upload to the core manually?
Problem is i’m afraid i don’t even have a working code sample, so i cannot say for sure this is related to i2c or code, etc…
If you have a working and available source-code for this, i could try with that, so at least i could see that this is i2c related for sure.
Thanks for your fast reply kenneth!
I’m afraid using the Web IDE doesn’t resolve the issue as it’s compiling against the broken firmware.
The only short term solution right now is to compile it using the commit which fixes the issue locally.
That might be a little painful to work with for a start…
I think the demo code on the repo i published works fine since it was requested by someone and he probably used it already…
If i compiled it locally with the I2C fix, i’ll drop the binary file here so that you can test it out
One thing missing in terms of hardware might be the pull-up resistors for I2C lines unless the board came with it already.
Thanks for your continuous help I’m not really a technical person, so not really sure how these things should be connected (especially with the pull-up resistor), i just connected the pins and that’s it.
Here is my sensor:
Not sure if i have to use any pull-up resistors and if yes where (and how).
Your test code would be brilliant! If you could that ,that would be awesome!!!
Thanks a bunch Kenneth for all your help again, really appreciate it.
Do you have the link for the product? I’ll look up the datasheet.
Also, the library repo is this: https://github.com/kennethlimcp/spark-lib-adxl345
Currently compiling it against an older firmware and will post the link for the binary file in a moment
Sure. The model number is GY-291, with the ADXL345, you can find more info about it here:
and THANK YOU for compiling the firmware for me!
@Noten you can try this binary file: https://dl.dropboxusercontent.com/u/36134145/adxl345.bin
Seems like the library is broken as i haven’t maintained it in a while but i compiled using a test code that did not require the library for while.
You will need to open up a Serial terminal with 115200 to test out.
Kenneth, you ROCK!
So as the “Yosemite” issue is resolved as well, i was able to install your firmware, it is AWESOME!
So once the i2c is fixed on the webIDE, i will be able to compile the code from your github repo and done?
I think the library is a little broken but from the repo link i pasted above, there’s an example that works like how you just tested without the library!
If i don’t fix it before the I2C issue is resolved, simply use that example as a temporary solution. I’ll ask @peekay123 for some help with the library errors.
Doesn’t look complicated to fix but i’ll probably tackle it few hours later.
Thank you Kenneth! Appreciate it!
@Noten, the library is now available in the Web IDE listed as ADXL345
No clue with i didn’t compile locally with the slightly older firmware but it compiled fine with the latest build farm firmware.
The repo is here: https://github.com/kennethlimcp/spark-adxl345
But for now, only the no-library example works and you can use it with your code to develop stuff until I2C is back up
The repo is super cool! Thanks a bunch! Is there any advantages of using the i2c library when it’s back up?
I guess there might be more features and ease of usage for that matter.
Actually i just need whether the values are changing (somebody is moving the sensor), and i think this is more than enough for this purpose. I’m more than happy with this solution, so thanks again!
Hi @kennethlimcp, I seem to be able to get the no-library example working, however I need to take quicker readings and when I remove the delay at the end of the main loop the photon seems to lock up very quickly. Is this a known problem? Thanks
The recommended output datarate of the chip is 12.5-400Hz.
Although datasheet also shows a current-datareate diagram of up to 3200Hz, without delay I’d guess you might get a bit too fast.
Thanks @ScruffR - is there a way to work out the minimum delay I could use based on that then? Or just trial and error?
If you are cloud-bound and single threaded you’ll have a 1ms delay between each interation of
loop() limiting you to 1kHz already, so adding another
delay(2); should bring you bellow 400Hz, but do you really need to be that quick - try not to go bellow 10ms delay?
I’m not too familiar with this chip, but others do feature an interrupt output to inform the controler when data is ready - this should give you the fastest possible speed, but usually requires more setup work in code and on the chip.