I tracked this down to versionChecker.js in the EspruinoTools code. This checks for firmware version but also that env.CONSOLE is one of USB, Bluetooth or Telnet.
In my case env.CONSOLE is equal to Serial1. If I hack this in as an option I get fast writes -- whoop!
Just wondering if this is deliberate or a bug/missing feature of EspruinoTools. I saw a comment somewhere that comms over serial has no flow control, but this is virtual serial over USB to the ESP32 and not sure if same applies.
I'm going to leave my hack in for a while and see if there are any issues. It makes a big difference to speed of dev cycle when using espruino --watch.
Hmm well so far not so good...
New interpreter error: FIFO_FULL
>Guru Meditation Error of type LoadProhibited occurred on core 0. Exception was unhandled.
Get this error on second transfer -- every time. Interestingly this doesn't happen with all code. If I create a simple hello world app I can change it multiple times no problem and the transfer is ok.
Could be something to do with code size or maybe something about my app itself (it has a heavy interval timer).
EDIT: I assume ESP32 serial over USB is less capable flow-control wise than the Espruino Pico and this is simply a buffer overflow issue. I played around with the slow serial block size in the code and found 128 bytes to be a happy medium between speed of transfer and stability. Default (slow send) is 19.
Yeah, it's because:
There could be an option for it: You can force the 'slow write' on using the Throttle Send option - I guess that could be a drop-down allowing the option to only throttle various amounts.
But honestly, it may work fine for you, but running in Chrome, on a different platform or with a different ESP32 with a different interface chip it'll probably break - which is why it's done that way. Having something slightly slower than it could be is worth it in order to have it 'just work' for as many people as possible.
Thanks. I actually added an option on my local CLI, -s --serial-block-size. I can send you a pull request if useful. I found that on the ESP32 128 works well enough. I didn't look at adding this in the Web IDE because I don't tend to use it except for testing tiny things (partly due to my Typescript pipeline...)
Thanks, but I think anything I merged would have to include a proper option in the Web IDE as well.
There's already Throttle Send so I'd prefer to just change that rather than adding another option.
Happy to modify and have a go at the Web IDE if you can suggest right approach...
For the ESP32 env.CONSOLE is coming through as Serial1, so setSlowWrite(true) is called in versionChecker.js. In this case SERIAL_THROTTLE_SEND has no effect. I think the options are either to provide an explicit block size for slow sends only, which is what I've done or provide an explicit block size for all sends slow or not.
@Wilberforce, Gordon says that flow control "can be enabled". Do you think this is a possible option for ESP32? In which case we wouldn't need hacky options.
Not sure about the serial console, @JumJum wrote this code. I don't know if all boards have flow control enabled.
Your other option is to use the telnet port 23 to send code up to the esp32, bypassing serial. In the web ide you can cannot via ip - not sure if the command line tools are set up for this.
Sending over TCP is quick from the Web IDE, but wifi doesn't seem to be completely stable (then again my ESP32 doesn't seem completely stable in general!).
There is an issue open for enabling TCP in the CLI... https://github.com/espruino/EspruinoTools/issues/32.
This is from the readme...
espruino --board PUCKJS --minify mycode.js -o output.js
Then you could use nc or similar to send output.js to the telnet port...
You gave me an idea. At the moment I'm running webpack --watch in one terminal and espruino --watch in another. I could write a simple webpack plugin to run espruino CLI (or integrate with the lib) after each build and push the result to the device.
@jugglingcats it would be very cool if you could implement the CLI TCP issue. It should be reasonably straightforward.
In terms of throttling, I guess you'd make the option a drop-down with something like:
For flow control, you just need to add jshSetFlowControlEnabled to jshUSARTSetup. It's done in software so should work on all platforms (it's just that ESP32/8266 don't expose it). Ideally you'd modify built_platform_config.py to check for a default_console_cts option that then made a DEFAULT_CONSOLE_CTS_PIN definition that the ESP32 initialisation then checked, so it could be tweaked based on the board.
But... it also depends whether the IDE requests hardware flow control or not - it may not.
Hi @Gordon I tried adding the call and it didn't cause any issues but didn't seem to help either - still seeing New interpreter error: FIFO_FULL. This is from the command line. Is there a way I can check if hardware flow control is being attempted?
New interpreter error: FIFO_FULL
You'd have to dig around in the code I'm afraid - serial_nodeserial.js for the CLI afaik. Honestly though I have to focus my time on the tools for folks that actually buy Espruino hardware.
From my point of view, I make nothing out of ESP32. Making uploads 50% faster doesn't change anything for me at all - but if 1 in 100 uploads fails with the new code then people come to the forum, email, twitter - and that ends up costing loads of time in support - so this is all super far down my priority list.
100% understand -- read your Makezine article... will try and stay out of your hair.
Hopefully things are working for you financially with the range of hardware you have and that having the other ports in the ecosystem at least adds some value.
Thanks - yes, it's doing ok. I'd be earning more in a 'proper' job, but obviously I have a lot more freedom over what I do this way. There are all kinds of pros and cons of the ESPxxx devices, but it's impossible to say either way if there's a net benefit - I wish it was a bit more clear-cut!
Anyway, it's great to see people using Espruino and pushing it as far as they can - I just won't always be able to reply when I'm mentioned in a non-official board thread :)
Things that can be done that make Espruino faster/better as a whole (like your TCP/IP CLI mods) are fantastic - it's just more of a grey area if it's not actually doing anything for official boards, and it's turning much darker grey if it's also making code harder to maintain or impacting negatively on other devices :)
flow control for ESP32 is set to UART_HW_FLOWCTRL_DISABLE
Just checked all options for flow control
All with RTS don't work.
All others have same speed.
Don't worry about formatting, just type in the text and we'll take care of making sense of it. We will auto-convert links, and if you put asterisks around words we will make them bold.
For a full reference visit the Markdown syntax.
© Espruino, powered by microcosm.
Report a problem