How to run it on Raspberry Pi Pico? about afbr-s50-api HOT 6 CLOSED

Alternatively, could you provide the reference to the SPI protocol you use? Like, what kind of commands are available, and what they look like.
For example, in "argus_hal_test.c" I can see some magic numbers were used to configure the sensor. In the function ConfigureDevice, you send 5 bytes uint8_t d2[] = { 0x16, 0x7F, 0xFF, 0x7F, 0xE9 } but it's not clear what these numbers are.

from afbr-s50-api.

It seems the structure was actually OK. After implementing functions from "platform" folder, I've managed to compile the code.
There are still a couple of problems.

1. For some reason, the first call to SpiConnectionTest always fails.
2. TimerTest fails with

+-------+---------+------------+
| count | samples | elapsed us |
+-------+---------+------------+
|     1 |     100 |         10 |
|     2 |     200 |         10 |
|     3 |     300 |         10 |
|     4 |     400 |         10 |
|     5 |     500 |         10 |
|     6 |     600 |         10 |
|     7 |     700 |          9 |
|     8 |     800 |         10 |
|     9 |     900 |         10 |
|    10 |    1000 |         10 |
+-------+---------+------------+
Linear Regression: y(x) = 0E-7 sec * x + 100E-7 sec
ERROR: Time test failed!
The measured time slope does not match the expected value! (actual: 0E-7, expected: 1024E-7, min: 993E-7, max: 1054E-7)

What does it mean?
3. In S2PI_SetIrqCallback I'm not sure on which edge the irq should be called. Rising or falling, or both?
4. SPI read/write operation is blocking. Is it a problem?

from afbr-s50-api.

Hi YuryMalyshev,

thanks for the detailed information. I just came to the same result about the missing platform implementation. When porting the API to another platform (as the RP2040), one needs to implement the platform layers for the given platform. This is the main part of porting the API, so you already have made a big leap by doing so.

Are you aware of our porting guides?
Here is a reference porting guide to an STM32 platform:
https://docs.broadcom.com/docs/AFBR-S50-SDK-Porting-Guide-to-Cortex-M4-PG
And here is a generic porting guide with some useful hints you may find helpful:
https://broadcom.github.io/AFBR-S50-API/porting_guide.html

Regarding the new questions:

1. Can you post the error message of the failed SPIConnectionTest? You can also have a look here: Device Initialization Yields Device Not Connected (Error Code -101)
2. The timer test depends on the SPI connection as it connects to the device and runs some measurements on the device to obtain a time reference that can be compared to the timer implementation. As long as the SPIConnectionTest fails, the timer test is also bound to fail...
3. S2PI_SetIrqCallback must triggers on the falling edge.
4. The API relies on a asynchronous SPI operation. It will generate a new SPI transfers from SPI, GPIO or timer interrupt callbacks and than immediately return and wait for the next callback to happen. It has never been tested if synchronous SPI operations are OK.

Unfortunately, we can not provide a register map for several reasons. One of them is the complexity that is built into the API to generate reasonable measurement values.

Please let me know if you need further help.

Best regards,
Christoph Berger

from afbr-s50-api.

Thank you for the answer.

Yes, I glanced over the porting guide. The main confusion was due to my mistake with CMake, I didn't link the library properly at first, so functions from api and platform were missing.

1. The error I get is

ERROR: SPI connection test failed!
Verification of read data is invalid!
read_data[1] = 0, but expected was 1

the subsequent call passes.

Other than that, all tests (except PIT, I don't need it right now) passed now.

from afbr-s50-api.

Hello Yury,
is everything working now with your Pico porting? Would you mind to share you code?
Appreciate your efforts.
Thank you!

from afbr-s50-api.

Hello,
There's a bit of a problem with the IRQ line. It fails every now and then, and then everything gets stuck. I think it's a problem with my logic / how I handle the state change. It's probably needed to either use both cores or switch to RTOS to fix it.

I gave up on it for now, it's no longer a priority for us. I'll take another look during/after Christmas holidays.

I'll think about how to share the code because I created a bunch of CMakeLists files all over the place, so I want to clean it up a bit.

from afbr-s50-api.