Latest Emlid RPi2 image breaks DF

[mhkabir]

Just updated to the latest Emlid Raspbian image from here : https://docs.emlid.com/navio2/Navio-APM/configuring-raspberry-pi/

782161 overflow
782199 SPI speed set to 1MHz.
783143 SPI speed set to 1MHz.
783239 SPI speed set to 1MHz.
783332 SPI speed set to 8MHz instead of 10MHz.
783389 ERROR: SPI transfer bytes request over limit

Console is spammed with these messages on running the MPU9250 test app. @bo-rc could you have a look please.

[julianoes]

Thanks for reporting. It seems bad news that they don't support bigger buffers. I guess we'll have to do multiple bulk reads for Raspberry Pi but the overhead might make reading of the FIFO buffer quite slow.

[staroselskii]

@julianoes @mhkabir

Hello guys! I launched the df_imu_test yesterday and not surprisingly got the same result.

I'm pretty sure the buffer size is configurable. The spidev.bufsiz hasn't changed anything, though.

I suppose, the problem is somewhere in bcm2835-spi driver that is the default one now (it'd been bcm2708-spibefore).

I'd be glad to help but I'm on vacation right now, so I won't be able to test it until next Thursday.

[bo-rc]

Hi developers, sorry i am having a very difficult time right now. I thought i could dive into the our development but i was wrong; i need another solid month before i can help here.

I am watching the progress though. Sorry i cannot contribute now but i will.

You are the best!

On Wed, May 11, 2016 at 11:17 AM, Georgii Staroselskii < notifications@github.com> wrote:

@julianoes https://github.com/julianoes @mhkabir https://github.com/mhkabir

Hello guys! I launched the df_imu_test yesterday and not surprisingly got the same result.

I'm pretty sure the buffer size is configurable. The spidev.bufsiz hasn't changed anything, though.

I suppose, the problem is somewhere in bcm2835-spi driver that is the default one now (it'd been bcm2708-spibefore).

I'd be glad to help but I'm on vacation right now, so I won't be able to test it until next Thursday.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/PX4/DriverFramework/issues/66#issuecomment-218510395

[mhkabir]

@staroselskii Thanks Georgii, we look forward to your comments. @julianoes Georgii is from Emlid and will be helping us clear up this issue.

[staroselskii]

@mhkabir @bo-rc @julianoes

Hello, guys! I looked into the code today and have a couple of questions.

• Why do we have a limit that equals 21 byte here? Doesn't bulkRead() suppose to handle transactions with bigger buffer sizes? Once I got rid of this condition, the test was reporting totally fine results.
• I don't understand the conditions needed to pass the test in case of MPUs using FIFO, i.e. data.read_counter is updated in a loop. That's why the test fails with m_read_attempts != m_read_counter here with m_read_counter being ~8 times greater. And it does make sense.

I sent a couple of PRs to address some of the issues I stated above. I'd be glad to discuss it more thoroughly as I might've missed something.

[LorenzMeier]

@staroselskii The RPI2 has not seen the level of love and commitment it should have, so please operate under the assumption that if you find issues and you are convinced they are real and you have a fix that that's the way to go forward. Do you get by now proper inertial sensor readings with PX4 and in QGroundControl? This is what I would recommend to work against. If you show me plots (Tools/Widgets -> Analyse) you will see if it works satisfactory.

I'm pretty confident that this is pretty close and can be fixed relatively quickly and it would be fantastic if you could drive it.

[julianoes]

Is this issue fixed in https://github.com/PX4/DriverFramework/pull/82?

[julianoes]

Looks like it's fixed.