Bitcraze Forums

Hello everybody.
I'm working on integrating the Arducam with Crazyflie 2.0.

After connecting and porting the code from Arduino to STM32 SPI API, I've noticed a really strange behavior when I try to read the TEST register: I read something different from what I wrote.

Comes without saying that, on Arduino, everything is working flawlessly, while on the STM32 the camera is replying with a wrong signal ().

The high-level code used for Arduino is:
`delay(5000);
myCAM.write_reg(ARDUCHIP_TEST1, 0x40);
temp = myCAM.read_reg(ARDUCHIP_TEST1);
Serial.print("Test: ");Serial.println(temp, HEX);`

The high-level code used for STM32 is:
`vTaskDelay(M2T(5000));
write_reg(ARDUCHIP_TEST1, 0x40);
temp = read_reg(ARDUCHIP_TEST1);
DEBUG_PRINT("Read SPI temp: %d %x\n", temp,temp);
temp = read_reg(ARDUCHIP_REV);
DEBUG_PRINT("REV: %d %x\n", temp,temp);`

The rest is just exactly the same as in the original firmware available at ArduCAM github: https://github.com/ArduCAM

I've tried all the following:
1) Change the ArduCAM
2) Use the same ArduCAM
3) Checked several time the hardware connections
4) Since the drone is powering the ArduCAM with 3.3V, I've tried to power up the camera with external 5V
5) Tried different combination of SPI settings (CPOL, CPHA, MSB, LSB etc)
6) Other small things.

Please let me know if you have any idea.

Best regards,
Jassy

PS: In the pictures, the top oscilloscope screenshot is for from the Arduino while the bottom one is from the Crazyflie.

I think I've solved the issue.
The problem seems to be in the SPI timing. I've tried now to be as fast as possible and it seems to work.

However it's working 10 times worse than expected. I expect a 10 fps framerate while I achieve only 1 fps.
I've tried to play with the DMA setting, but I was not successful. I've also tried to give more priority to my task but it was not successful.

Do you guys had similar speed problems with the SPI interface?

Reading from this page: https://www.bitcraze.io/2016/10/micro-sd-card-support/ it looks like that, maybe, the SPI API are somehow slow themselves. (?)

Please let me know.
Best regards,
Jassy

Hi Jassy,

Since this post the the SPI has been modified to use DMA and so it should be quite fast doing burst transfer (ie. transferring a big buffer all at once). The SPI port on the expansion port is able to go up to 42MHz, what speed are you running it and what speed would you need?

/Arnaud

Hi Arnaud,

Since this post the the SPI has been modified to use DMA

You mean that it has been modified from the 13/01/2017 to today? I'm using the firmware from the 28/11/2016 sha=(39831c3b844577c080c0b576b40bdbc5308348da) which looks like already using the DMA.

Additionally, I've also tried to use the burst mode (my camera is enabled to do that), but no much change. I still need to invest more time because the data read are not perfect.

My device support up to 8MHz and my current setting are 5.2MHz. Finally, is there a way to put the clock rate exactly 8Mhz? Using the BaudRatePrescaler looks like I can just select 5.2MHz or 10.4MHz.
I feel like that the SPI setting is not the problem, though...

Thank you for you time btw.
Cheers,
Jassy

Hum, maybe no change in dma since this exact post, I did not think about the same post (the sdcard has been dormant for a while so I was thinking about long time ago). Sorry for the confusion.

Since you have an oscilloscope, a good way to analyse would be to zoom out, acquire one image per 1 or 2 second (to get a lot of time between acquisition) and to look at how the burst looks, how long it takes and where is the time lost. If you have images of 80x80 assuming 3 bytes per pixel the full image transfer should take about (80*80*3*8*2)/5.2e6 = 59ms which is about 16Hz (I added a times 2 to be conservative). So if you get only 1Hz there is a problem somewhere.

Tweeking the exact SPI frequency is not easy. The SPI clock is the bus clock (APB2, 84MHz max) divided by a power of two. The bus clock is the core (cortex-m4 cpu) clock divided by an integer. To get an SPI clock of 8MHz you will need to clock the core at 128MHz instead of 168. May be worth it for some specific use case but since you will be limited by the radio on the other side it might not help you much anyway.

Best regards,
Arnaud

Thank you again for you help Arnaud.

I've figured out that the main problem is a bug in the spi_deck.
Comparing the SPI-deck code at:
https://github.com/bitcraze/crazyflie-f ... #L255-L262
with an example available at:
http://blog.mark-stevens.co.uk/2014/03/spi-stm32/
looks like that it is wrong enabling and disabling the SPI with that command. In my case slowed a lot my system and it was necessary to perform a "bit rotation from read-back".

Therefore I've placed the once at the initialization.

This help me a lot since it solved all my problems with the camera!

Hope it will be useful for other people.
Best regards,
Jassy

Awesome! Can you maybe make a pull-request with these modification so that we can integrate it in the master branch?

Hi,
how I do that? Looks like I don't have permission to write directly to Crazyflie repository.

Let me know what to do and I will do that.
Best regards,
Jassy

Hi Jassy,

The way to do pull request is to have the commit in a branch in your github account and then start a pull request from it: https://help.github.com/articles/about-pull-requests/

If you do not have a githubg account (and are not interested about having one) you can format a patch with "git format-patch <hash of the commit>". This will create a patch file that you can send me and I can apply and push it in the repos.

Thanks,
/Arnaud

Hi Arnaud,
Oh now I see that I was doing wrong! I was always cloning the repository and not forking it.

The pull request now should be done.

Cheers,
Jassy