-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Quirc esp-eye example (IEC-51) #240
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @FBEZ, thanks for your PR!
I've left a few comments, please ping me if you have any questions or when I should review again.
|
||
#include "esp_camera.h" | ||
|
||
#define CONFIG_CAMERA_MODULE_ESP_EYE 1 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would recommend bringing board definitions using the board support package. This way to support a new board, work needs to be done only on BSP side, and the example doesn't have to be updated.
(It's okay if that means that fewer boards are supported. After all, it's just an example.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you Ivan for your kind and detailed feedback.
Using the bsp approach would be the best choice for sure. Right now though I don't see the bsp for the esp-eye (meaning the older one). I could setup a very basic bsp for this board starting form the esp32-s3-eye and update this example accordingly.
I will receive and Esp32-s3-eye the next week to test this example on it anyway.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah yes, we don't seem to have a BSP for the original ESP-EYE.
I think at this point it's probably safe to recommend ESP32-S3-EYE for new applications, so I wouldn't mind keeping this example supported on that board only. Later when we add ESP-EYE BSP, we can update the example to support it as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, then it will take a few days to receive the hardware and make the changes.
If it's better, I can close this PR here and reopen when everything it's in place. Otherwise I'll leave it here and update it in a few days.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You can keep this PR, just make the changes and push to the same branch when you are ready. Later once everything is ready you can clean up the commit history.
|
||
static const char *TAG = "APP_CODE_SCANNER"; | ||
|
||
static void decode_task() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FreeRTOS task function definition should look like this:
static void decode_task() | |
static void decode_task(void* arg) |
} | ||
|
||
quirc_destroy(q); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
vTaskDelete(NULL);
missing here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part of the code isn't supposed to be reached. I'm not sure what the best approach would be here.
Do you suggest the vTaskDelete or to remove the quirc_destroy completely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on the error handling strategy — see the other comment about this.
If you decide to handle errors by terminating the task, probably having the cleanup path with quirc_destroy would make sense. You could use an out:
goto label and use macros like ESP_GOTO_ON_ERROR
to handle errors and perform cleanup.
If you decide to handle errors by aborting (which is not an unreasonable strategy for an example project) then quirc_destroy can be removed since it's unreachable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok then since as you say it's an example, I think it's best to keep it the simplest possible. I removed the quirc_destroy.
// Initializing the quirc handle | ||
struct quirc *q = quirc_new(); | ||
if (!q) { | ||
ESP_LOGE(TAG,"Failed to allocate memory\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Newline at the end of format strings is not necessary for ESP_LOG, it's added automatically.
Also, missing space after comma. (Have you installed the pre-commit hooks using pre-commit install
? They should automatically format the source files.)
struct quirc *q = quirc_new(); | ||
if (!q) { | ||
ESP_LOGE(TAG,"Failed to allocate memory\n"); | ||
exit(1); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Error handling is a bit inconsistent. In the check above you are doing vTaskDelete()
, here you are using exit
. And in the check just below you only log the error code and continue.
Let's try to make this more consistent. You can decide the error handling strategy for this function — return or abort — and use the same approach in the whole function.
@@ -0,0 +1,48 @@ | |||
FROM espressif/idf |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No problem with devcontainers in general, but we usually don't add them directly to the example projects. Perhaps we can add one at project level, though. Still, I would prefer if this is done in a separate PR.
Hi there, |
Checklist
url
field definedChange description
It is an example for the quirc component using an esp-eye