Comments (12)
My opinion is that installing system-wide services should be done in application code, not in libraries. This applies also to things such as NVS, esp_event, esp_netif.
It would probably be a breaking change to remove the call to an GPIO service installation function, but we could at least add config argument specifying whether esp32_camera should install the GPIO service or not.
(We could also change the GPIO service API to have something like a reference counter, allowing it to be installed and uninstalled any number of times. But this would only be available in new versions of IDF, so we need another solution for esp32_camera anyway.)
from esp32-camera.
I asked the same (similar) question in espressif/esp-idf#12882 (comment) , but didn't get further response.
from esp32-camera.
My opinion is that installing system-wide services should be done in application code, not in libraries. This applies also to things such as NVS, esp_event, esp_netif.
Then I'm wondering if the application developer really understand what intr_alloc_flags should be set.
What happens if wrong intr_alloc_flags is used for gpio_install_isr_service?
e.g. currently, only the first call to gpio_install_isr_service() takes effect.
So the intr_alloc_flags called by ll_cam.c does not take effect if other component already calls gpio_install_isr_service().
from esp32-camera.
Yeah, unfortunately that's the complexity the application developer currently needs to bear.
If we were to change gpio_isr_handler_add to also take the flags, we could at least error out on calls to gpio_isr_handler_add with incompatible flags (i.e. higher interrupt level than requested in gpio_install_isr_service, or IRAM flag, when gpio_install_isr_service hasn't requested it.)
The reference counting approach I mentioned above wouldn't solve this particular issue, I think, because we can't re-register the ISR with different flags without potentially missing some interrupts — on Xtensa, at least.
from esp32-camera.
From version 2.0.4 throughout version 2.0.8 (latest stable) esp32-camera calls uninstall_gpio_isr_service from within esp_camera_deinit which can "break" other components that relied on the isr_service presence.
This was introduced in this MR #516
@me-no-dev
Any update for this issue?
from esp32-camera.
@AxelLin will revert this and check for "already started" on init. I see no other options to help the situation
from esp32-camera.
@AxelLin will revert this and check for "already started" on init. I see no other options to help the situation
my main concern is not about "already started" on init, but about the uninstall_gpio_isr_service from within esp_camera_deinit which can "break" other components.
from esp32-camera.
both things need to happen in order for the driver to be restarted and ISR service to not be re-initialized. The PR you linked above was attempting to fix failed re-init, because "service is already started"
from esp32-camera.
Change is reverted: 2829692
from esp32-camera.
@AxelLin can we close this?
from esp32-camera.
@AxelLin can we close this?
It's ok for me, but I'm not the reporter.
BTW, the fix is not yet released, so I actually cannot get this fix with idf component manger.
from esp32-camera.
@AxelLin @greenaddress this is now released: https://components.espressif.com/components/espressif/esp32-camera/versions/2.0.10
from esp32-camera.
Related Issues (20)
- uint is not defined in ESP-IDF V5.2 HOT 1
- ESP-32 CAM webserver error: E (483) camera: Camera probe failed with error 0x105(ESP_ERR_NOT_FOUND) Camera init failed with error 0x105 HOT 1
- cam_hal: insufficient queue_size in corner case. HOT 3
- Enable psram mode on ESP32S3 causes NO-SOI and then panic HOT 3
- Reset button is hard to reach HOT 1
- The example code cannot run properly (LoadProhibited) HOT 13
- PowerFeather - pin configuration?
- Enable camera has big impact on networking HOT 22
- Hardcoded buffer size for JPEG is too small for low resolution settings (e.g., QQVGA) HOT 2
- Support for Higher Resolutions on gc2145 - $300 Reward HOT 1
- ESP32S3-EYE I accidentally set pin 13 (PCLK) & 14 to INPUT_PULLUP once, now my camera is not recognized anymore (0x105)
- Captured images are stale HOT 1
- cant verify HOT 1
- Incorrect frame width and height returned by esp_camera_fb_get() when using sensor->set_res_raw() HOT 1
- ESP32 camera module get very hot - high temperature HOT 7
- OV2640 standby support HOT 1
- Add sleep/standby function to the driver API
- ESP32-S3-MINI-N4R2 HOT 2
- set_aec2 seems inversed in ov2460 HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from esp32-camera.