Conversation
| frame = esp_camera_fb_get(); | ||
| // Testing how to get the latest image | ||
| esp_camera_fb_return(frame); | ||
| frame = esp_camera_fb_get(); |
There was a problem hiding this comment.
As far as I can tell, there isn't a clear reason to get and release before getting the frame we'll actually use. If there is, we can incorporate that into the frameLock class
There was a problem hiding this comment.
this may be to clear a buffered frame. test with an actual camera and an image that is changing to confirm ?
| @@ -789,14 +716,13 @@ void loop () { | |||
|
|
|||
There was a problem hiding this comment.
Immediately above is a return statement without a esp_camera_fb_return call. Using the frameLock class should change the behavior there as we now will implicitly call esp_camera_fb_return in the class destructor
|
There's enough code changes here that I'm a little nervous merging. Currently looking into Pio test infrastructure to see how we could better automatically review changes like this |
positavi
left a comment
positavi
left a comment
There was a problem hiding this comment.
LGTM if it tests well and you think its easier to manage/maintain. please double check there is no frame buffer issue removing the extra camera frame. it may also be legacy for one of the other supported camera modules.
2 participants
An attempt to make things more readable by separating concerns into separate files. This involves moving enums and associated functions out of the main deployable example file.
Additionally, this adds a RAII class to help manage getting frames from the camera in the main loop. While this doesn't put a formal lock on the frame, it does guarantee that at the end of each loop the frame is properly released preventing errors from successive calls to esp_camera_fb_get between loops