Component and Capsule for the BMI270 Inertial Sensor #3719
Conversation
capsules/extra/src/bmi270.rs
Outdated
| buffer[1] = ConfigFile[0]; | ||
| buffer[2] = ConfigFile[1]; | ||
| buffer[3] = ConfigFile[2]; | ||
| buffer[4] = ConfigFile[3]; |
There was a problem hiding this comment.
Can't you fix this with a for loop that copies from one buffer to the other?
There was a problem hiding this comment.
Yes, that works. With the changes, I was able to compile it and upload it to the board. But I can't get a reading because it takes a long time to upload it to the sensor.
There was a problem hiding this comment.
This seems like a new problem, then, right? How long is "a long time?" The i2c on the nrf52840 runs at 250kbps by default, which means it should take approximately 256ms to transfer 8KB.
It might be useful to "write out" the algorithm/procedure you are expecting is the right one to configure the sensor get a reading based on the datasheet, relate the code you're writing to that algorithm, and then relate the unexpected behavior to both.
Also, if it helps, it might be useful to reference existing implementations that use this sensor. For example, this is the Arduino library for this sensor (that's used on the same board): https://github.com/arduino-libraries/Arduino_BMI270_BMM150/
|
The relevant piece from the datasheet: |
These changes include transferring the config_file into the component and creating it there. This is done because it is way to computationally intensive to transfer all entries from the config_file into the buffer. Also added more control flow into the capsule and ran make fmt.
|
In the current implementation, I was able to compile it and upload it to the board. I was also successful with uploading the config file to the sensor. But, I can't get a reading for some reason (returns 0's) and I'm unsure of the cause. What do you guys think may be the problem? |
|
Can you get any known response from the sensor? Something like a status or chip id? |
|
I tried reading the chip_id, and it returns 0x24, which is what it supposed to do. |
The alarm was added because according to the datasheet, the driver requires waiting for some time before continuing execution.
Hmm, in that case, it seems like some setup/configuration step might not be quite right? I think I would look at another implementation of the driver and see if there is some command that is different or missing. |
|
This one sat around for a bit, so I think it's time to check in on it. I believe the final status was that this code seems mostly plausible (from a timing/size perspective), but still has a bug resulting in invalid sensor readings. @TheButterMineCutter Are you still working on this? And if so, is that status correct? It also looks like maybe @bradjc is pushing on #3717 which has a board with this sensor installed. |
No I'm not working on it. The status you mentioned is correct. If you want to give it a try and fix the bug resulting in invalid readings, go ahead. I tried my best but wasn't able to fix it. |
|
@TheButterMineCutter it's awesome that you've cleaned things up and addressed comments. Is this actually maybe kind of working now? Or this are you just helping get into an otherwise good state (modulo the bug we haven't identified yet)? One tricky bit is that I don't know if anyone currently has a board with a BMI270 to take over getting the functionality right (though, of course, the nanoble isn't a very expensive board) |
I tested it and it fails in the InitDone state after replacing the config_file. I'm not sure why, what do you guys think may be the problem? |
|
@TheButterMineCutter can you clarify what "fail" means? Is something crashing? Is |
I think it crashes. I put a debug statement just after replacing the config_file and it successfully outputs it into the console (tockloader listen). But, the debug statement I put just after taking the buffer doesn't go off and there is no more response from the driver. |
| let delay = self.alarm.ticks_from_us(us); | ||
| self.alarm.set_alarm(self.alarm.now(), delay); | ||
| } | ||
| State::InitWriteConfig => { |
There was a problem hiding this comment.
I believe the problem is that here, you don't replace the buffer into self.buffer so that when you finally reach the InitDone state, self.buffer is empty and you never enter the closer, so don't send any further I2C commands and the driver is just stuck.
There was a problem hiding this comment.
Replacing the buffer seemed to fix that bug, although I'm still getting 0's when I read the sensor (both for accelerometer and gyroscope).
There was a problem hiding this comment.
OK, so it's "working" now, but the readings are totally wrong (they are zero). That's progress!
Pull Request Overview
This pull request adds the Component and Capsule for the BMI270 Inertial Sensor. It implements the
NineDoftraitread_accelerometer()andread_gyroscope()methods.Testing Strategy
N/A
TODO or Help Wanted
Currently, the capsule is way too large (500kb) to upload to any board. The sensor requires that a config file be uploaded to one of its registers. This config file is an array that contains 8192 entries, each 1 byte long. The capsule tries uploading it via i2c, sending 1 byte at a time. This requires a buffer length of 8193, buffer[0] is the register address, and the rest is the corresponding bytes of the config file. Putting the bytes into the buffer is what takes up most of the file size. An alternative approach must be implemented as the current size of 500kb is unacceptable.
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.