Open pggh opened 4 months ago
chipweinberger
commented
4 months ago out of curiosity, what multiple independent software packages are you using that all scan?
do they scan without your knowledge? if so, why?
or can you control when they scan?
instead of breaking api, a mechanism to lock & unlock scanning capabilities seems sufficient.
filzek
commented
4 months ago It's impractical to implement it as originally suggested, since managing the function calls effectively is crucial. If the same function is called twice, the subsequent call will abort the ongoing one, preventing simultaneous operations. Instead, you should utilize a globally populated list along with a semaphore to manage access to function calls. Allow the thread to remain active, and queue incoming calls in a non-blocking manner. This way, you can notify that the routine is currently in use and will be resumed later. Once resumed, you can process the task queue and execute the desired functions accordingly. Thus, the semaphore should operate in a non-blocking manner, facilitating smooth task execution
Is your feature request related to a problem?
The esp_wifi_scan_start is difficult to use when multiple independent software parts/packages is using it. There is only one radio and only one scan (or connect) can be running at any given time. The existing API does not offer to coordinate this.
Describe the solution you'd like.
The first and very easy improvement would be for esp_wifi_scan_start to return the scan_id that is part of WIFI_EVENT_SCAN_DONE/wifi_event_sta_scan_done_t. This would allow to check whether the received WIFI_EVENT_SCAN_DONE is from the own started scan or from other software components that probably scans for something else. (freeing the memory once and in the correct component is an issue too).
Describe alternatives you've considered.
An overhaul of the API could be considered; probably something with scan-jobs that could be submitted and queued.
Additional context.
No response