|
Post by lintball on Jan 17, 2014 8:40:20 GMT -5
I'll search around a little to see if anyone else has seen this. And your right I did a reboot and everything is magically working again...glad that was it, since I was about to take things apart again. Now I can finish up the DAC messaging.
|
|
|
Post by lintball on Jan 24, 2014 9:37:23 GMT -5
I finally got the DACs working last night with the test mode. I was having problems sending the correct command to get them to change to voltage. The issue started when I added the accel. to the I2C bus. I'm not sure why exactly, looking at the read data, it was coming back with the wrong values. So I unplugged the power to Accel but kept it on the I2C bus. Even after that the data was coming back corrupt. So finally I unplugged the Accel all together and then my data was coming back fine and the DACs were following my I2C commands to them. I have it setup so that I2C is coming into a terminal where both DACs and Accel are on one side and the connection to the Pi are on another so its like a Y. Maybe wiring it this way is causing issues. Did you have any problems when you added the accel to the bus?
|
|
|
Post by Frisbone on Jan 24, 2014 19:05:20 GMT -5
I think I had it setup like you did when I was testing - didn't have problems. Right now it's setup like an actual bus but I can't think of a good reason why that should matter.
Perhaps try disabling the AM in the software to see if perhaps its only happening because its trying to communicate with it? Might be a logical or timing conflict between data acquisition and Output. If this is just in the test mode - maybe just avoid initializing the AM.
|
|
|
Post by lintball on Jan 28, 2014 12:18:44 GMT -5
Yep so more testing done with it. I reconnected everything making sure its secure. This time around the DACs tested fine. Now the new fun problem is that the accel is not initializing. Its returning 0x00 for the whoami register. I checked to see if its on the bus (i2cdetect) and I do see it at address 0x1d as it should. And I tried using the command line tool i2cget to read the register manually and it returns 0x00 too. In fact I tried a few registers and they all returned 00. I tried the same command with the DAC and I got an expected response at least from them. Going to double check the docs see I missed something.
|
|
|
Post by Frisbone on Jan 28, 2014 19:27:47 GMT -5
This rings a bell. Sounds like my original repeated start problem where I needed to modify the bcm library to add the custom change for that chip to put a repeated start in. Makes me wonder if you are building with the proper library. Did you happen to rebuild it at any point? Or have you been using the library file that was on the machine from the beginning (which should have it in it)?
Do you want me to send you my library?
Using the command-line tool will only work if it was built with the repeated start. I do have some test code that I wrote that uses the repeated start in the i2c directory, run the following:
sudo ./i2c_rs read 0x0d
It should return 0x2a if its working properly (the who am I register). If that doesn't work, its possible that there is a conflict with the DAC somehow - perhaps disconnect the DAC and try again.
The lib is called bcm2835 and it is in the i2c/hipi/HiPi-0.25/BCM2835/buildlib/src directory.
My build date was July 16 2013, 42482 bytes (libbcm2835.a). If your file is different, that could explain it. If perhaps your build was modified to point to a different file (check ITC.pro file) - could also explain it. I'll email you my file.
|
|
|
Post by lintball on Jan 28, 2014 22:11:19 GMT -5
Well my library matches yours and I did try that test app. That app gave me back the proper response. Looking at the pro file, I see the path listed to that library as it should. maybe there is another older copy somewhere that its using first.
|
|
|
Post by Frisbone on Jan 29, 2014 6:17:29 GMT -5
Well, that explains for sure just the command line issue you saw on the whoami register. I believe that I have test code you can enable (turning a DEBUG output statement from DEBUG to INFO) that outputs the answer to whoami. If that answer is wrong - then you probably have a library issue. If the answer comes back correct, then perhaps the issue you are having is something different than you think. I did have a bug in the code I checked in related to my implementation of the software ISR - but I have since checked in a fix for it - that could have returned zeros for the AM data. You might try to refresh from what is checked in.
At least I'm fairly sure I checked in the fix. I'll confirm tonight. Could simply be that you forgot to refresh from git remote and are seeing that bug - and got side tracked thinking it was something else.
One thing I can tell you is that most times that I set registers for an I2C device the default is an automatic read-back and validation - to ensure that the register I thought I wrote to, accepted the change. Its hard to get through AM initialization without proper communication - there should be an error displayed in there if I2C for it isn't working due to the readback. But to be clear, the readback is disabled on some registers that have write-only bits.
|
|
|
Post by lintball on Jan 29, 2014 9:07:20 GMT -5
Yea I have the high logger values set and I do see the whoami fail with 0xff, if I remember correctly. I did a find on the OS and that library was only in that buildlib/src directory. I also cleaned and rebuild and still the same issue. I also rebuilt your test app to make sure that it is indeed the correct library and that worked as well. I'll try to update the code next and see if that makes any difference.
|
|
|
Post by Frisbone on Jan 29, 2014 18:48:20 GMT -5
I realized I hadn't committed the files yet - they are now. You should get data back now - I do. You also have the option of checking out an earlier snapshot before I separated out the ISR - like October 25th. But this should be working. I'll caveot that with the fact that I've been focusing on the AM for so long now that I haven't been paying much attention to button/trigger handling so its always possible I've broken other things and not have realized it yet. So buyer beware.
|
|
|
Post by lintball on Jan 30, 2014 22:34:57 GMT -5
Thanks that seemed to have worked. I committed the changes I made to the DAC...also noticed I did a merge...not sure if I undid something you committed. Sorry still getting used to GIT and its terminology.
|
|
|
Post by Frisbone on Jan 31, 2014 8:43:33 GMT -5
Yeah, I'm still getting used to git as well. Would think though that the merge simply spliced my latest updates with yours - guess we'll find out. But it looks ok, the changes I did are in master and it looks like it just put my updates in your code-base before it did the commit.
|
|