-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
I2D driver doesn't work (ESP8266-01) (GIT8266O-769) #1192
Comments
Hi, Try #1169. This change enable transmit data via I2S.
Probably is problem with definition of |
Thanks @AMKrol . I've just got DMA working (sending out) and will try and sort out a PR in the next few days with my changes. Whoever decided to mix RX/TX and TX/RX in the same module was foolish; should have been consistent and just had a comment indicating that "write/send uses RX" and "read/incoming uses TX" to avoid lots of confusion! |
@AMKrol, I have a Git branch (based on In case this is the simplest, I have copied the diff below.
|
The inconsistency in the description of the registers can be corrected using the slc_struct.h file. You need to swap struct txlink and struct r xlink. Swap struct int_st, int_ena, int_clr uint32_t tx_done: 1; uint32_t rx_done: 1; Insert the line into the static esp_err_t i2s_param_config(i2s_port_t i2s_num, const i2s_config_t *i2s_config) function |
@MishaSyd Am I correct that you are making the code back like the old versions of the libraries were? My issue arises because the meaning of "TX" and "RX" is switched between the two sides of the DMA code some sometimes RX means "from hardware towards memory via DMA" and sometimes it means "from memory towards hardware via DMA" - at least the old versions of the DMA code were consistent in that "sending" out "from memory towards hardware via DMA" was always RX (and vice versa). |
After these edits, all DMA chains began to work correctly.
вс, 25 дек. 2022 г. в 19:01, papadeltasierra ***@***.***>:
… @MishaSyd <https://github.com/MishaSyd> Am I correct that you are making
the code back like the old versions of the libraries were? My issue arises
because the meaning of "TX" and "RX" is switched between the two sides of
the DMA code some sometimes RX means "from hardware towards memory via DMA"
and sometimes it means "from memory towards hardware via DMA" - at least
the old versions of the DMA code were consistent in that "sending" out
"from memory towards hardware via DMA" was always RX (and vice versa).
—
Reply to this email directly, view it on GitHub
<#1192 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/A46A7QN6VTZ7CUWHENFVT3TWPB4WVANCNFSM552TRRKA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
After editing, the files slc_struct.h and i2s.c were translated in my code
вт, 27 дек. 2022 г. в 09:34, Misha Sidorenko ***@***.***>:
… After these edits, all DMA chains began to work correctly.
вс, 25 дек. 2022 г. в 19:01, papadeltasierra ***@***.***>:
> @MishaSyd <https://github.com/MishaSyd> Am I correct that you are making
> the code back like the old versions of the libraries were? My issue arises
> because the meaning of "TX" and "RX" is switched between the two sides of
> the DMA code some sometimes RX means "from hardware towards memory via DMA"
> and sometimes it means "from memory towards hardware via DMA" - at least
> the old versions of the DMA code were consistent in that "sending" out
> "from memory towards hardware via DMA" was always RX (and vice versa).
>
> —
> Reply to this email directly, view it on GitHub
> <#1192 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/A46A7QN6VTZ7CUWHENFVT3TWPB4WVANCNFSM552TRRKA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
@papadeltasierra did you succeded on making I2S example to work? I applied the changes from your diff but still no luck. |
I am unable to test the samples because I don't have a scope to test output but I do have a heavily hacked example that is using DMA to drive a 433MHz transmitter and this would not work until I applied my changes. It runs 24/7 on my desk and uses DMA to generate a stable OOF keyed signal (using multiple by 32 coding i.e. an output logic "1" is represented by 0xFFFFFFF) to allow for the fact that I can't run the DMA slow enough to represent the required OOF intervals signal as a simple 1:1 mapping. |
Can you see this project? https://github.com/papadeltasierra/display433 There should be no secrets in here (please tell me if there are ;-) ) but the "i2s_ook" code is my heavily hacked code that uses the DMA. |
I tried to use that code with no success either :( (migrating it to the 3.4 sdk). |
Sorry - that's a much as I can help. I tinker a little but no more. One of those nice cheap oscilloscopes is one my "nice to have" list but it's never quote reached the top. I don't know how good your understanding of DMA and the software is but I found these bugs by printing out the code and spending an afternoon reading it carefully. The key thing is that in the code to make the pins go up and down is "receive" and to be able to read data from an external source you "send". |
Ref: #981
The issue above seems to be same issue but has been closed, claiming (if I read it correctly) some fault on the board being used. However I know my board works and yet this example still does not work.
Environment
Problem Description
I have compiled and installed the
examples/peripherals/i2s
example but it does not work. I added a log to trace the number of bytes written by i2s_write() and this is always zero.From reading the code and adding logging in various places, it would appear that the interrupt handler has to signal an underun, or at least some sort of TX event, before the curr_ptr is given a buffer to write to. As far as I can see the interrupt NEVER triggers.
This is NOT a hardware issue as my very old "hand rolled DMA code" from about 5 years ago correctly runs DMAso tehre is some sort of bug in the current SDK.
On thing that does look odd is that when the TX interrupt is enabled, we tweak the rx_link (sic) and when the RX interrupt is en/disabled, we tweak the tx_link! However this is not the cause of the issue as I tried switching these and this had not affect.
Expected Behavior
i2s_write() writes the expected number of bytes and the DMA causes the appropriate lines to switch appropriately.
Actual Behavior
i2s_write() always returns "0 bytes written" and there apears to be no "action" on the SLC lines.
Steps to repropduce
Code to reproduce this issue
just the is2_example_main.c application.```
Debug log goes here.
Please copy the plain text here for us to search the error log. Or attach the complete logs but leave the main part here if the log is too long.
The text was updated successfully, but these errors were encountered: