-
Notifications
You must be signed in to change notification settings - Fork 57
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
Example crashes on Doit DevKit unless GPIO6 swapped out #18
Comments
Further update - There are 2 versions of Doit DevKit v1 - one has 30 pins, the other 36. GPIO6 is not brought out on the 30 pin version, so I guess that is why the program crashes. So this may or may not require attention. |
this issue is in the implementation code, not the library. As a note to someone going through these issues that had this same problem: Pick different pins for your encoder that are broken out on your board. |
Kevin,
I am very much a newb and unfamiliar with the protocols involved....
I have borrowed some of your code that is in Encoder32.cpp which is involved in configuring the ESP32 counters to do the quadrature decoding, and the associated data read and write routines. I have wrapped these into software which is used to interface to an app called TouchDRO. There is some interest from other TouchDRO users, and I propose to put this software up on Github. Naturally, I want to include the appropriate attribution. Can you advise what is appropriate?
Roman
… On 26 May 2020, at 11:44 pm, Kevin Harrington ***@***.***> wrote:
this issue is in the implementation code, not the library.
As a note to someone going through these issues that had this same problem: Pick different pins for your encoder that are broken out on your board.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Generally, the procedure would be to make your library dependant on mine. You can subclass ESP32Encoder to incorporate the features, and trust that this library will be distributed through the Arduino library manager. Otherwise, in the Doxygen headers, add
|
Kevin,
I don’t think the library thing would work, as only a small core part of your original .cpp has been kept. And all this subclass and library manager speak is beyond my level, I’m afraid.
I shall include your suggested reference to madhephaestus, though.
Thanks
Roman
… On 19 Jun 2020, at 12:18 pm, Kevin Harrington ***@***.***> wrote:
Generally, the procedure would be to make your library dependant on mine. You can subclass ESP32Encoder to incorporate the features, and trust that this library will be distributed through the Arduino library manager.
Otherwise, in the Doxygen headers, add
@author github:madhephaestus ***@***.***
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
I loaded the example onto a ESP32 DevKit V1 and it crashed. execution stalls at around line 132-133 of ESP32Encoder.cpp (I didn't debug any deeper than this level.)
This is the log:
Rebooting...
ets Jun 8 2016 00:22:57
rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:1
load:0x3fff0018,len:4
load:0x3fff001c,len:1044
load:0x40078000,len:8896
load:0x40080400,len:5816
entry 0x400806ac
Guru Meditation Error: Core 1 panic'ed (LoadProhibited). Exception was unhandled.
Core 1 register dump:
PC : 0x400e7e08 PS : 0x00060f30 A0 : 0x800d0ff5 A1 : 0x3ffb1ee0
A2 : 0x00000006 A3 : 0x00000001 A4 : 0x00000000 A5 : 0x3ffc015c
A6 : 0x0000000c A7 : 0x00000000 A8 : 0xffffffff A9 : 0xfffffffe
A10 : 0x00000000 A11 : 0x00000000 A12 : 0x40080e70 A13 : 0x00000000
A14 : 0x3ffc015c A15 : 0x00000000 SAR : 0x0000001c EXCCAUSE: 0x0000001c
EXCVADDR: 0xffffffff LBEG : 0x00000000 LEND : 0x00000000 LCOUNT : 0x00000000
Backtrace: 0x400e7e08:0x3ffb1ee0 0x400d0ff2:0x3ffb1f10 0x400d10f6:0x3ffb1f40 0x400d0da1:0x3ffb1f60 0x400d1423:0x3ffb1fb0 0x40088279:0x3ffb1fd0
With a bit of debug and tracing, I found that if I used almost any GPIO other than 6 (which is part of encoder 2 in your example), it compiles, loads and appears to run OK. I don't know what's magic about GPIO6, and obviously there's an easy work-around. But it may be a bug with other implications that I haven't seen.
Apologies if I have not followed the correct protocol - I am totally new to this.
The text was updated successfully, but these errors were encountered: