GPIOs 2&3 conflict with i2s_dacs detection (ControllerI2s) #12
Comments
|
Thanks for investigating this issue. I have been wondering if this could be a probem. Do you know what determines the plugin start order? |
|
We have a priority system for plugin startup. Core plugins start before non-core, and there is a priority number from 1 to 10 (1 higher, 10 lower) in package.json of every plugin. So first move would be setting priority 10 in gpios. |
|
Thank you very much @volumio : making the 2 suggested changes fixed nearly all the error messages. |
|
@volumio here is the log with remaining i2c errors (I still happen to have many). PS: also, note volspotconnect (which as no boot priority set) starts after gpio-buttons which is set at priority 10 |
|
First solution: try to remove the priority from the gpio-buttons plugin (but we will look into this as it seems a bug). what do you think? |
|
I'm a bit concerned with setting arbitrary delays for fixing non deterministic dependencies, as this may break later: can be a workaround at most; actually the current error messages are fine as they do not prevent GPIO3 action to work. Safer to keep the error until the root cause if debunked I guess. With promises & defer chains, there should be a mean to know for sure when core Volumio startup & init sequences are finished for good I guess, right? |
|
That's what we should expect. But maybe something is not working as it should. |
|
So, from your expectation, and looking at earlier log, at which point should Isn't it intriguing we see |
|
Been trying to trace what's happening in This gets resolved too late in the game, even after @volumio would it be acceptable to keep i2cDetect (and therefore readI2S) in sync, so that all is finished before plugins are started? |
|
That would mean refactoring those functions a lot... And using try catch to handle errors. It would not be a problem per se... |
|
...or, (since I understand i2cdetect -y 1 is taking ages and you may not want to delay startup to that much), instead of trying to detect "anything", can't we try to "bruteforce read" where/what would one expect from the list of DACs that are possible (since Volumio supports a list of known DACs)? |
|
GPIO3 is particularly interesting as it powers-up the pi. EDIT: pi touchscreen does not seem to require use of GPIO3 (SCL) |
|
We just read once, then we match what we read with possible results. I think this is the fastest way ... |
|
When there is no DAC, |
|
Mmm interesting. We can then give a timeout to this command {timeout: 1000} What do you think? |
|
This seems to suggest it may take 1sec per transaction when nothing is connected to GPIO3 (SCL) due to clock stretching. |
|
Timeout will certainly help so that |
|
Closing it here and following-up on Volumio2 project page as it is definitely a Volumio issue in DAC auto-detection when i2S is set to OFF, no i2c devices connected. This does not prevent gpio-buttons from working on pin 2 & 3. |
If one registers actions with GPIO 2 or 3, journalctl will show many errors like:
i2c i2c-1: transfer timed outafter restart.Indeed i2c-1 is on pins 3&5 (GPIOs 2&3) and is used by i2cDetect in here by
ControllerI2s.prototype.onVolumioStartto detect i2s dacs when Volumio2 starts.The issue is that gpio-buttons sets its triggers in
GPIOButtons.prototype.onVolumioStart, so it may happen beforeControllerI2s.prototype.onVolumioStartkicks-in since both are plugins...If gpio-buttons is first in sequence, GPIOs 2 or 3 are blocked by gpio-buttons triggers, and i2s detection fails with
i2c i2c-1: transfer timed out(many of them!).How can we ensure
applyConf(which sets GPIOButtons triggers) happens after Volumio i2s detection is finished?Thanks.
PS: I'm not using any DAC in this case, so all pins are free to use.
The text was updated successfully, but these errors were encountered: