Skip to content
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

[FR] Synchronisation to buffered expander IOs (GPIO or PWM) #25011

Open
matsala opened this issue Nov 23, 2022 · 0 comments
Open

[FR] Synchronisation to buffered expander IOs (GPIO or PWM) #25011

matsala opened this issue Nov 23, 2022 · 0 comments
Labels
T: Design Concept Technical ideas about ways and methods. T: Feature Request Features requested by users.

Comments

@matsala
Copy link

matsala commented Nov 23, 2022

Is your feature request related to a problem? Please describe.

Feature is related to bug #24096 "[BUG] I2S expander latency causes sync issues with non-expander hardware"
A solution with #24193 : "Adds PWM capability to ESP32 I2S expander pins"

The purpose is synchronising any action/task with I2S_expander (setting IOs, PWM ...)
The implemented #24193 solution works using I2S_expander disponible IO
  - main limitations that could be removed is that it would work with any hardware : not all hardware has any I2S_expander_IO that can be used / connected
  - could use PWM peripheral : for higher base frequency / or more precise
  - would use less CPU : fill out I2S buffers with a PWM must be CPU intensive

We would only needs a Timer (new, or already existing running timer).

Are you looking for hardware support?

Normally any hardware using buffered Expander IO

Describe the feature you want

It is for synchronising any action/task with I2S_expander.

The main idea is to synchronize the stacked data in the I2S steam, to a simple running Timer.
And keep a correspondence between the current "I2S data number being latched", and the current timer value.

I will do some simplifications of the solution, to be as simple as possible.

I suppose :
  - "I2S expanded IOs" are every 4us
  - we make a Timer running at 250 kHz => 4us
  - I2S buffers are filled with data before I2S is started
  - I2S, and Timer Start can be synchronised
  - when started, I2S buffers are never empty (always filled)
  - we count all stacked data in the I2S buffers
  - synchronized just starting both "I2S and Timer peripheral" at the same time

We know the first "stacked data", will correspond to first Time Slot of "I2S Expander IOs", and the Nth "stacked data" to the Nth Timeslot of "I2S Expander IOs".
Timer counts every Timeslots : first Timeslot Timer=1, second Timeslot Timer=2, .... Nth Timeslot Timer=N

So if we read Timer count, we know it corresponds to the "Timeslot Number"/"Data Number" that is on "I2S Expander IOs".
The same way we know, if the last stacked data is N, it will be on IOs when Timer=N.

If we need an IO, PWM, or anything just after the last staked Data, we know it should be set at Timer =  N+1
=> we could program an interrupt on Timer value N+1 to do the task (set IOs, PWM ...)

Additional context

Related to anticipated remarks :

It is interesting only for "low frequency" actions. Certainly not to generate "Step signal", that is up to 250khz per stepper (by design with Marlin)

Interrupt would need to be of higher priority than the RF => the interrupt needs to be very short (setting IO, or PWM should be less than 1us ?)

I do not know what is the max RF interrupted time on EPS32. For the BLE IC I use, it is about 50us. I imagine it should be of the same order (maybe it could be even more for wifi ?).
I do not know ESP32 priority limitations, but It would be very strange to completely forbid a high level of interrupts. About the same as prohibiting any CRITICAL region.

The reference time is the same for all the peripherals. Any peripheral, so any Timer, and the I2S peripheral share the same Clock.
If the peripheral's reference in time is synchronised one time, they keep synchronised after that.

I think the Timer could be any timer that has a continuous running time of at least staked I2S max time (at least 32ms ?). And fast enough regarding the precision needs.

I do not know how Input IO works, especially for Stops.
As it is done, I imagine we can not know when exactly the Stop was detected ? (because of unknown buffer size)
With the same Timer, we would just need to read the Timer count to know when it was exactly relative to staked data, and so be able to know/calculate relative to teps : we have actual Timer time, and stacked data size => so were it happens in the data stream

@matsala matsala added the T: Feature Request Features requested by users. label Nov 23, 2022
@thinkyhead thinkyhead added the T: Design Concept Technical ideas about ways and methods. label Nov 24, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: Design Concept Technical ideas about ways and methods. T: Feature Request Features requested by users.
Projects
None yet
Development

No branches or pull requests

2 participants