digitalPulse "Timeout on Utility Timer" #6366
Replies: 1 comment
-
Posted at 2020-01-17 by @MaBecker Hi,
Missing pins .... start with how to use software SPI http://www.espruino.com/Reference#software Posted at 2020-01-17 by @MaBecker And than have a look at this forum post http://forum.espruino.com/comments/15065227/ Posted at 2020-01-17 by nistvan.86 Hi MaBe, I'm using the hardware SPI of the ESP8266 (SPI1), and it has only one configuration. The documentation says I don't have to manually specify the MISO/MOSI/SCK pins if I'm okay with the defaults.
But you are right, it won't hurt to try manually specify everything if it doesn't work. However the error is related to the digitalPulse call, not SPI. The line with the "wait for completion" comment fails as you can see with the timer timeout. The documentation of this function says:
I have to wait for the pulses to go out before I can issue the reset command on the SPI bus.
So maybe it's not even necessary, since the digitalPulse will be a blocking call on the ESP8266 if I understood correctly. Anyway, I'm going to dig out my logic analyzer and see what's going on with the pins. I've seen your previous comment sent out in the email related to the firmware version :) Posted at 2020-01-19 by nistvan.86 Based on my logic analyzer's output digitalPulse is stable to around 0.1 ms resolution. Below that it doesn't always produced what I ask it to do. :( Posted at 2020-01-19 by @MaBecker Please have look at this issue espruino/Espruino#1511 (comment) Posted at 2020-01-19 by nistvan.86 Thank you, I've upgraded to the 'cutting edge' firmware (2v04.76). I still experience some issues. The minimal code to reproduce it:
I get only a single low-high transition in this case according to my logic analyzer. Interestingly if I prepend this with two 1ms values, the microsecond transitions are generated correctly.
And this does make the modem reset work, I can query it's version number afterwards. Am I still doing something wrong? Attachments: Posted at 2020-01-19 by nistvan.86 I can't attach the bad logic analyzer output for some reason, you can find it on my Google Drive. Mod: since then I've edited this post and added the image here. Attachments: Posted at 2020-01-20 by Robin Sun 2020.01.19
FYI - Only one image may be uploaded at a time. Did an attempt at a re-edit allow the ability to perform the additional upload? It's okay to re-edit to test Hi @nistvan.86, I'm late to this thread and wont be of much help should this truly be an ESP8266 issue, but I'm not really grasping what isn't working.
Is the concern still with this msg while 2v04 is currently flashed?
Has 'af_output' been tried for pinMode()? 0.03 msec is 30 usec and the pulse shown appears to be documented as 29.8 usec
Incidentally, I've been playing with digitalPulse() and ran into a similar situation. My *(unresolved and unresearched at 'C' code level)* belief is that the array mechanism requires whole numbers, and a decimal seems to muck things up. I was able to create narrow usec pulses at the usec level using the following as a patch: *(edit as necessary)*
yes, I know it uses the analog flavor, . . .
then to create a pulse train, embed within an interval, something like: (use setTimeout() for a single pulse)
Not sure if this is what you are after, but I'm running short on time tonight and wouldn't be able to respond should you reply. Just thought I'd pass along some ideas. . . .
If I've butt'ed in and not assisting here, please forgive. . . . Posted at 2020-01-20 by @MaBecker ok, just created issue digitalPulse() not working as expected #1749. Posted at 2020-01-20 by @MaBecker @nistvan.86 can you build firmware and do further investigation? Posted at 2020-01-20 by @gfwilliams I'll comment on the issue tracker, but I believe this is a known issue because ESP8266 is using a 32kHz RTC as the base for all timings. It won't be to do with using non-integer values (other than you're asking for the pulse length to be shorter than Espruino can accurately manage), and the 1ms pulse length that's sorting things out for you is probably because it's something that can be accurately scheduled with the 32kHz RTC which helps to 'sync' everything up. Posted at 2020-01-20 by nistvan.86 @robin had to retry it a couple times before the image appeared. Did the same thing yesterday, but had no luck back then. Anyway, the image is now attached. @MaBecker I can give it a go on the weekend if you have anything specific in mind to try out. Thank you for the Github issue! @gfwilliams sounds logical. This "hack" solves my problem here, because the longer edges are simply ignored by the modem. But I'm just lucky with my situation, other use cases might not be so forgiving. Posted at 2020-01-21 by Robin Mon 2020.01.20 @nistvan.86 glad that worked, but a bit of a mis-communication. My belief was that multiple upload of images was the issue, and intended to have the subsequent upload in post #7 rather than a replace of your remote account. That said, it appears the issue was with the actual file then? Posted at 2020-01-21 by @gfwilliams
On STM32 I believe they probably are, but that's the limit. It'd be better to discuss the intricacies on the issue that got filed, but it's a 32kHz timer so on non-STM32 you should assume accuracy is 1/32768 sec until the timers get implemented differently. Posted at 2020-01-21 by @MaBecker
Maybe try the hardware timer instead of the RTC. Posted at 2020-03-10 by opichals @MaBecker I too seem to have some issues here on my d1-mini. I am trying to do IR transmit based on the instructions at the bottom of https://www.espruino.com/pronto. I get It seems that the Perhaps a combination of
Posted at 2020-03-10 by maze1980 The neopixel module for ESP8266 does a dry-run/pre-roll without emitting any pulses. That dry run is necessary to load the machine code from flash into RAM. Without this dry run the timing of the pules representing the first byte won't have proper timing. It might be the same issue in this case. Reference files: There is no dry-run for ESP8266 in jswrap_io.c, so I would assume it is the same issue. That code is not capable of producing very short pulses accurately in the first run. Posted at 2020-03-15 by opichals Just to confirm. I confirmed the above mentioned IR sending is working as described without any issue on the Original Espruino board v1.3. Posted at 2020-03-15 by @MaBecker
Hi @maze1980, are you talking about this section? Posted at 2020-03-18 by maze1980 More like Posted at 2020-03-18 by @MaBecker ok, i can see. can you suggested the change for jswrap_io.c? Posted at 2020-03-20 by maze1980 I don't think it is easy to fix, especially without breaking existing code. Maybe it is possible to change
to
and get the desired pulse, just a a little delay. Then there would be no code change required, just a note in the documentation. |
Beta Was this translation helpful? Give feedback.
-
Posted at 2020-01-16 by nistvan.86
I'm trying to port my NodeMCU code which communicates with the Ti CC1101 modem. Using the NodeMCU ESP8266 board (4MB Flash). I'm using the hardware SPI pins (D5-D7), plus the D8 PIN for chip select.
The only thing I'm doing so far is trying to reset the modem with the chip select line "wiggling" described in the modem's manual in the section "manual reset". This requires microsecond toggling then issuing an SPI command.
My code (generated from Typescript):
Uploading with SAVE_ON_SEND using espruino tool, I get this output:
What does this mean? The pulse can't be sent? Or is the pulse sending happening so fast that the hardware timer controlling it already finished when I'm invoking the wait so it starves out?
I should really wait for the pulse to complete, that's when I can send the RST strobe command to the chip.
My NodeMCU LUA code for the same thing which works can be found here. Maybe it helps.
Beta Was this translation helpful? Give feedback.
All reactions