esp_camera_available_frames implementation

[pablogs9]

Description

This PR adds a functionality for checking if there is an available frame to be read immediately, allowing the possibility of calling esp_camera_fb_get ensuring that there would be no block.

Related

Testing

---

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[cnadler86]

This would be a great addition, IMHO. Is this under the Radar?? The code looks for me very straight forward.

[cnadler86]

Did you tested it with fb_count 1 and 2, as well as grab mode latest and when_empty?

[pablogs9]

@cnadler86 not really, but as far as I see this operation is complementary to the operation performed in cam_take():

esp32-camera/driver/cam_hal.c

Line 481 in 4467667

xQueueReceive(cam_obj->frame_buffer_queue, (void *)&dma_buffer, timeout);

So, we are checking with this new esp_camera_available_frames that this last xQueueReceive will return immediately.

Do you see any additional consideration when fb_count is greater than one, grab mode is the latest or cam_obj->frame_buffer_queue is empty? If so, please tell me and we can iterate through them.

[cnadler86]

I don't think there will be a impact on any current functionality. I can only imagine that the function might return always true or always false in one of the possible configuration cases. I have not taken a deep look at the code and in come cases testing is better than analyzing. That's why I am asking.

[cnadler86]

I tested the PR at application level and it behaves as expected. The FPS will be a little less, since you need to assess at application level weather to "take a picture" or perform some other activities, but with this non-blocking code is possible. Great PR!

@me-no-dev : could you please take a look and in case it is OK, merge this?

[github-actions]

This pull request appears to be stale. Please close it if its no longer valid.

[cnadler86]

What appears to be stale is the hole repository 🧐