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
ESP32: DigitalPulse does not work properly #1175
Comments
I tested again with 1.92.77 and the issue is still here. |
Still seeing the issue in 1.92.89 |
A bad workaround that may help in the meantime as long as accuracy is no concern.
|
This is a critical issue as many modules (ie, the OLED displays such as SSD1306, ...) use a digitalPulse when the reset pin is defined, in order to... well... reset :) That leads to very weird results when defining the reset pin for instance, which is quite unexpected. |
@jumjum123
and in espruino seems to be millseconds: https://github.com/espruino/Espruino/blob/master/targets/esp32/jshardwarePulse.c#L97 if you change: it might work for you. |
@ wilberforce, take a look to line 385 in jshardware.c |
@jumjum123 Any ideas why this is not working? |
@wilberforce I see milliseconds everywhere. |
Looks like duration greater than 32767 are treated as int16 instead of Unit32. |
@jumjum123 interesting. I am usually testing with values around 100~1000 though. |
Following the docu in Neil Kolbans book, in theory the maximum possible time for pulses is around 104ms. |
@jumjum123 isn´t 100 < 104 ??? |
Please read my comment, there is an explanation about the divider actually used. |
@jumjum123 I did read your comment the doc several times. Please read the issue I reported carefully. Sending is pulse of 100ms is a valid test. When DigitalPulse (pin, 1, 100) sets the output to a high level forever (forever > 100ms ....), this is obviously an issue and no one need a logic analyzer to see it. You are right however, with this method, I don´t know if the pulse is really 100ms and not 105 or 95ms... but this is not the problem here. That issue does NOT show up on ESP8266. @jumjum123 are you telling me that you tested on a ESP32 and you can successfully see 100ms pulses (you can use your logic analyzer :)) |
@chevdor, let me try to explain with other words.
To compare 2 ports of Espruino, for ESP8266 and ESP32, is not helpful. Both are not official supported by Gordon. Both are the result of some "crazy" peoples work. These guys spent a lot of time porting Gordons beautiful work to other hardware. |
I think for anyone who cares enough there's probably enough info here to fix this. Rather than changing the divider in https://github.com/espruino/Espruino/blob/master/targets/esp32/jshardwarePulse.c#L97 someone could probably just add |
@gordon,
thanks for your hint. I was thinking into similiar direction.
Thats an valid option.
On the other hand it would open a door to keep processor waiting for long
time.
From my point of view, for long pulse I would recommend using setTimeout.
One more on the other hand, it would work similiar to Espruino Board (and
others)
Could it be an option to open setPulse for pulses up to 100ms and log a
warning if more is expected ?
Whats your opinion ?
2017-07-19 12:24 GMT+02:00 Gordon Williams <notifications@github.com>:
… Reopened #1175 <#1175>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1175 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AB-GniGj6SF-lRq1ZSWrUrCViaWb3yInks5sPdlWgaJpZM4Nrjz8>
.
|
Well, on other (non-ESP8266) platforms, 'util timer' is implemented - it uses one hardware timer to schedule an interrupt to be called at a certain time. The ESP8266 implementation was a massive hack because nobody could figure out how to get a timer & interrupt working. If you could implement that properly on ESP32 it'd be by far the best solution - then you get Waveform, soft PWM, proper digitalPulse, and any other stuff that comes along later on as well... For instance micro:bit uses it to scan out a matrix LED display. Once util timer is done, just copy/paste the STM/NRF52 code: https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L718 Then you can schedule a digitalPulse as long as you want :) |
Sometimes I believe, the more I learn about Espruino, the less I know at the end. |
Wow, great news! Using the util timer will be a huge amount better, and will mean it works much more like the other Espruino boards! I guess we could close this then? Could you come up with a PR for it? |
Once, everything is uploaded, we can close. |
Yes, no problem. |
@jumjum123 are there other timers that could use the util timers too? |
@jumjum123 https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L734 ? |
@wilberforce |
I tried the code you sent me with the esp-idf 2.0 with a led and I'm move the timer so it's not depending on RTOS and clean up the make file and the files we don't need any more - probably on the weekend.. |
Lines 88 to 98 in 8663d1c
As we need the timers, wondering if we need the |
Just checking - does this work even if the interpreter is busy?
If it's using the RTOS then I guess it's possible it might not run in an IRQ? |
yes - this works - after a 1/2 sec the led goes off while stuck in the loop - so it it working off IRQ
|
Great! That's really good news - so presumably (Not that you need to try it, but proper IRQ-based timers are one of the things that the ESP8266 port has always struggled with) |
@gfwilliams
The LED does change intensity, however if we can make this use the espruino libs it would be better |
Is there any reason @jumjum123 's ESP32 code for this can't be ported to the ESP8266 so that Utiltimer works for that? (probably a different issue required here) |
Ahh - to be honest I think that's as easy as copy/pasting the initial
If the APIs are exposed then that'd be great! I got the impression that ESP8266 didn't provide proper hardware timers, but I could be wrong... I did see some code for software PWM that seemed to use them, but nobody seemed too bothered about porting it - there may even be an open bug about it. |
For ESP8266 there is a replacement for the SDK PWM code, maybe this is helpful too. |
Yeah, so what you'd want to do for ESP8266 is look in https://github.com/StefanBruens/ESP8266_new_pwm/blob/master/pwm.c, pull out all the stuff to do with pwm_intr_handler and the timer registers, and shoehorn that same code into the util_timer stubs in jshardware.c... Then ESP8266 PWM/waveform/etc would be loads better |
Sorry not me, way above my head ..... maybe not for @wilberforce or @jumjum123 :) |
Do you mean This looks like it uses specific hardware timers depending on the implementation? |
Yes - it does - but if it's called with the 'software' flags then it defers to jstimer.c: https://github.com/espruino/Espruino/blob/master/targets/nrf5x/jshardware.c#L643 |
Tried to use jstPinPWM and ran into tons of questions.
May be implementation of util timer is strange, therefore next couple of questions came up to me. |
Hi,
Hopefully every pin should support soft PWM (since there's no hardware involved at all)
Usually
Sounds like the IRQs for the utility timer might not be doing what you're expecting... Getting it working with a single soft PWM is good though, because you know that it should be firing at specific time intervals. I guess first steps might be to just try and write the code to set up an IRQ to flash an LED at maybe 1000Hz, in pure C - then when that's working, head towards getting .t working with util timer,
Yes, the jstimer.c file handles all the scheduling - it's why I do it that way.
Espruino/targets/stm32/jshardware.c Line 860 in bc50397
Yes :) Usually digitalPulse should use it, but also Waveform uses it for input and output, and it's also used to wake the CPU up after a certain time period if it was asleep on most platforms.
It should do, if you've implemented the check fro |
Wow, a lot of answers only 20 minutes later 👍 |
@jumjum - looks like you have a lot of homework :-) |
@wilberforce Yes, a lot of homework, and a lot of (new)open questions ;-) |
That's odd - how are you calling it? I just tried on nRF52 and I get:
|
Hmm, the more I dig into jstimer.c, the more I believe that period should always be negative for first call of jshUtilTimerStart. |
Yes, you're right - it was only working on nRF52 because it uses a 32k oscillator so can go all the way through without the system time changing! Sorry about that. It looks like if time is <=0 you just have to make sure the timer calls the IRQ as soon as possible (it's probably safer doing that than trying to call it outside the IRQ) |
I will add a if(period < 10) period = 10 |
Did you changes here: Address this issue - it appears to be working for me.... If so - we can close this. |
@wilberforce
all changes around util timer are changed by me and uploaded to ESP32 branch
They are tested with logic analyzer and worked fine.
Same for some changes in make to get it running for V2.1
Hope, this answers your question.
From my point of view, you can close this issue.
regards from Krefeld, 24 degrees Celsius and cloudy
2017-08-15 8:44 GMT+02:00 wilberforce <notifications@github.com>:
… @jumjum123 <https://github.com/jumjum123>
Did you changes here:
#1214 <#1214>
Address this issue - it appears to be working for me....
If so - we can close this.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1175 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AB-GngpshX5YZMsfUgkbREfuY38R0SjNks5sYT5XgaJpZM4Nrjz8>
.
|
Happy to confirm that I tested a new build and I can now see it working properly (I am also now using proper tools to measure @jumjum123 :) no LED was harmed in this test). |
I am using the firmware 1.92.73 in the ESP32.
I tested the following code on ESP32:
digitalPulse(27, 1, 100)
and on ESP8266:
digitalPulse(15, 1, 100)
On the ESP8266, as expected, I get a pulse of 100ms.
On the ESP32, the GPIO is set to HIGH forever.
Moreover, while digitalWrite seems to work,
digitalPulse(PIN, S, 100)
sets the GPIO to HIGH forever, whatever S is (1 or 0).The text was updated successfully, but these errors were encountered: