Search results for:

I've coded some new graphics commands,

• graphics.fillEllipse
  
• graphics.drawEllipse
  @Gordon, since you are running out of memory on several boards, would this be of interest ?
  

Sorry, no bell is ringing on that.
Could be in there from beginning by nkolban ?

Last not least, flickering is gone.
Surrounded jsvIterateCallback with rtos commands to switch taskhandling off

vTaskSuspendAll();
  jsvIterateCallback(data, allFast ? jswrap_io_shiftOutCallbackFast : jswrap_io_shiftOutCallback, &d);
xTaskResumeAll();

Actual status, compared to direct_io branch is:

• switched fast io off (return false in jshGetPinAddress)
  
• switched task handling off during jsvIterateCallback
  
• moved en.set() and en.reset() from js(g.scan) to be set in arr
  
  

Latest next week, I'll send a request with all changes to direct_io branch.
Open questions:

• how do we call task relevant RTOS function ? We could use #ifdef ESP32 or #ifdef RTOS. I would prefer the 2nd one.
  
• do we need jshIsPinValid(d->pins[n]) in jswrap_io_shiftOutCallback ? Isn't this already done in jswrap_io_shiftOut ?
  

Success, but once again I've only an idea of an idea why, but it works.
Removed en.reset() and en.set() from g.scan
Pushed {callback:en.reset.bind(en)} as first entry into arr,
Pushed {callback:en.set.bind(en)} as last entry into arr
Due to this, lines 15 and 31 have same brightness as all others.

arr.push({callback:en.set.bind(en)});
fixes in the wrong direction, we get dark line 15/31
Timing is a very special for the P3 board

I use the direct_io branch, and love the changes.
In my local copy, I changed the fast function to use jsh_PinSetValue instead of using GPIO-Register.
Flickering could be because of task management in RTOS
Agree to slowness of a JS-Solution, and will take a closer look to g.flip

Believe me, the world is absolutely crazy.
First of all, its much faster, I've been down close to 10 ms.
Bad news, upper 16 rows are always green and lower 16 rows are white.
Whatever I tried, there was no way to get this running. Even hardcode the colour did not help.

After a lot of frustration, I went back to setting pins with jshPinSetValue, and surprise surprise, now it works.
Looks to me like having a timing problem.
Good news is, time for scan is 13 ms now, which is still really fast.
What we don't have is brightness. Line 16 and 32 are much brighter than others.
And brightness is flickering.
This also looks like a timing problem.

Anyway, my next step will be to create a graphics driver, using Graphics.createCallback to get rid of prep step.

I tested with latest direct_io branch, see my code
First checked speed, which is really fast, came down to 18msec/scan :-)
Up to this everything was fine

var led;
connect2 = function(R1,R2,B1,B2,G1,G2,A,B,C,D,Latch,Clock,Enable) {
  var sfnc = shiftOut.bind(null,[R1,G1,B1,R2,G2,B2],{clk:Clock});
  var dfnc = digitalWrite.bind(null,[Enable,Latch,Latch,D,C,B,A,Enable]);

  var en = Enable;
  var g = Graphics.createArrayBuffer(64,32,4);
  var buf = g.buffer;
  var ledBuf = new Uint8Array(64 * 32 / 2);//converted graphics.buffer to data for LED
  var arr = [];
  g.prep = function() {
    var bufpnt1,bufpnt2,ledpnt;
    bufpnt1 = 0; bufpnt2 = 512; ledpnt = 0;
    var pane = false,i,j;
    for(i = 0; i < 16; i++){
      for(j = 0; j < 64;j +=2){
        ledBuf[ledpnt] = (buf[bufpnt2] & 7) + ((buf[bufpnt1] & 7)<<3);
        ledpnt++;
        ledBuf[ledpnt] = ((buf[bufpnt2] & 0xf0) >>4) + ((buf[bufpnt1] & 0xf0)>>1);
        ledpnt++;
        bufpnt1++;
        bufpnt2++;
      }
    }
    arr = [];
    for(var y=0; y < 16;y++){
      arr.push(new Uint8Array(ledBuf.buffer,y*64,64));
      arr.push({callback:dfnc.bind(null,33|y<<1)});
    }
  };
  g.scan = function() {
    en.reset();
    sfnc(arr);
    en.set();
  };
  g.setBgColor(1);
  g.clear();
  g.setColor(2);
  g.fillRect(5,12,50,25);
  g.setColor(4);
  g.fillRect(10,14,40,20);
  g.fillRect(10,0,40,0);
  return g;
};
function tst(){
  led = connect2(D2,D16,D4,D17,D15,D27, D5,D18,D19,D21, D26,D22,D25);
  if(led.prep) led.prep();
  var t=getTime();
  led.scan();
  print((getTime()-t) * 1000);
}

Next tried to work with graphics and whatever I did, panel displays something different. :-(
During testing I added some printf's here and there
First confusing was how often jswrap_io_shiftOutCallbackFast was called. My expectation was 1024, but the counter I added returns 8704
Counter was added like this

int xx = 0;
void jswrap_io_shiftOutCallbackFast(int val, void *data) {
xx++;
  jswrap_io_shiftOutData *d = (jswrap_io_shiftOutData*)data;
  int n, i;
  for (i=0;i<d->repeat;i++) {
.....
void jswrap_io_shiftOut(JsVar *pins, JsVar *options, JsVar *data) {
xx = 0;
  jswrap_io_shiftOutData d;
  d.cnt = 0;
  d.clk = PIN_UNDEFINED;
.......
  // Now run through the data, pushing it out
  jsvIterateCallback(data, allFast ? jswrap_io_shiftOutCallbackFast : jswrap_io_shiftOutCallback, &d);
printf("xx:%d\n",xx);
}

Checking jsvIterateCallback was next step, some more printf like this in
BTW, this is the short version of a long story, ....

  // Handle the data being an array buffer
  else if (jsvIsArrayBuffer(data)) {
jsWarn("ArrayBuffer:%j\n",data);
    JsvArrayBufferIterator it;
    jsvArrayBufferIteratorNew(&it, data, 0);
jsWarn("byteLength:%d\n",it.byteLength);
    if (JSV_ARRAYBUFFER_GET_SIZE(it.type) == 1 && !JSV_ARRAYBUFFER_IS_SIGNED(it.type)) {
      JsvStringIterator *sit = &it.it;

See log, Sum of all byteLength gives exactly 8704, which is the number how often callbackFast is called.
Here we reach the point where the story is beyond my knowledge. Hope you can help.

tst()
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 36, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:64
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:128
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:192
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:256
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 12, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:320
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:384
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:448
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:512
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:576
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 10, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:640
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:704
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:768
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:832
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:896
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 17, 17, 17, 17, 17, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:960
WARNING: ArrayBuffer:new Uint8Array([9, 9, 9, 9, 9, 17, 17, 17, 17, 17, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 33, 17, 17, 17, 17, 17, 17, 17, 17, 17, 17, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9, 9])
WARNING: byteLength:1024
xx:8704

push data out is jsvIterateCallback(data, allFast.....

I'll check it soon.

even in BytePort you had to grab the binary data out of a variable each call
Thats correct, but no need to grab pins, set them to output, calculate mask, ... on each call
Just tinking, binary data, couldn't this be added to initialization, and we only have to set a pointer ? Or would this cause problems if jsvars are restructured ?, hmmm
Anyway, we got some speed in a lot of places (I2C, SPI, ....)
And the way you use an array to avoid executing JS, very interesting.

First of all, duplicating a function under a different name was not my intention.
The idea was, on a long term, to mark shiftOut and digitalWrite as deprecated and replace it with something like bytePort. The example for bytePort includes an option to have default handling and familiy specific handling. At least, this is the idea. And it is faster in sending data.
To get a better understanding of where time is going, I tested duration of the scan loop, and switched off one part after the other in source from the branch Gordon posted.
This is the result, looks like shifting out data is fast, but preparing options and GPIOs takes a lot of time. At least for ESP32.

scan loop			X	X	X	X	X	X	X	X
	shiftout Data(sfnc)		X	X	X	X	X	X	X
		set options for internal use	X	X	X	X	X	X
		set array of pins	X	X	X	X	X
		assign output, and pin mask	X	X	X	X
		set clock	X	X	X
		push data out	X	X
	set row address(dfnc)		X
duration(msec)			25,300	18,160	14,350	13,820	11,090	9,290	6,780	3,810

To avoid misunderstandings because of the 500usecs.
Sorry for writing this like being measured exactly. I shouldn't have done that.
What I did during testing is to

1. Comment everything in shiftOut, ran the loop and measured whole time
   
2. Comment writing data in shiftOut only, ran the loop and measured whole time
   
3. did the same for digitalWrite
   
   

Tests have been done on ESP32 only, and duration has not been stable.
I had up to 2 msecs difference in whole loop, running the test multiple times.
All together a lot of time is used to check pins, set them to be output etc.

In my understanding bind optimizes interpreting source code.
Since args are always the same, bind stores the result of interpreting source.
So translating text to jsVars, is done once only, obviously this saves a lot time.
But it does not skip parts of the underlying function, in this case jswrap_io_shiftOut

I hope this is reasonably correct, and I'm not embarrassing myself ;-)

I'm not absolutely sure about 500 usecs. It's some time ago, and I tested a lot of different options, at least it was remarkable.
It is compiled with release=1, absolutely sure, since I got same hint from wilberforce. And this brought up 15% of speed.
Tested the uint8Array in a lot of different cases. There is no general behaviour. Sometimes it is close to array, sometimes its slower. So, looks like a problem with ESP32
Looks like your assumption of jsvIterateCallback is correct. After switching to that in my test, time goes up to 22msec.
I did a lot of testing with a lot of different sources, don't remember each of them in detail.
Very often, one change caused another one. Therefore its hard to assign effects to one special change. Its fighting for msecs.

One major point, why I like the bytePort class, is the option to have a default solution for all boards, and still the option to use the strength of other boards.
In your approach, setting pins with a register limits other solutions. In case of ESP32, I2S supports parallel mode, which would be a really fast solution. And it could open the world for more colors.
At the end, the question is "support as much boards as possible with same technology" or "support use of strength for special boards, even if this a kind of restricting your boards"
To be open, if I would be looking from your perspective, I would not know what's the better solution.

Couldn't resist and tested today ;-)
direct_io branch : 26msec
bytePort branch : 18msec
There is one more problem with direct_io. LED Matrix does not show what expected.
Its time bed time now. Will take a closer look tomorrow

Fully agree to "it does less staff compared to shiftOut". Simple reason is, I stopped implementing all options, and use existing code, to get first feedback. If this idea will not make it to Espruino, at least I didn't waste too much time.

Main target was to arrive at about 20msecs for each refresh. Please see attached file for JS code, its also in an early state. There are some additional time saver, in predefining arrays instead of creating new arrays all the time. Thats all I could find.
BTW, found out that an uint8Array was slow compared to an simple JS Array, at least on ESP32

Lets show, what I did:
My first step was to get shiftOut faster, and failed at a point.
One problem was that shiftOut always handles pins, on each call. Sorry, but even if this takes 500usecs it sums up to 8ms. Thats a lot, if you have 20 msecs for one refresh only.
From my point of view, creating a class which splits shiftOut into several steps, could be an answer.
And it would open the option for more byteport functions like reading 8 pins at a time. allObjects mentioned good old Centronics interface, ....

Next came up with use of GPIO.outw1tc, first version added up all bits and at the end sent it to GPIO.out_w1.... Similiar to your JshPinAddress. Once again there was an end of optimization for speed.
Working with pin by pin was too slow.

Helpful step was to create a translation table from byte to pins in GPIO.out_w1....
Obviously this needs some jsVars to store the table
Implementing this in shiftOut would mean, add a lot of #ifdef ESP32. IMHO, we should try to avoid too much board specific ifdefs in core.

Let me try your changes tomorrow.
Its funny to see same naming. In one of my tests I choose a function called jswrap_io_shiftOutCallbackFast :-)

some weeks ago, a discussion started around P3 RGB pixel panel
Feedback by Gordon and by allObjects brought me to the idea to create a new device for pins.
It should

1. support 8 ports in parallel
   
2. be a javascipt class
   
3. replaces shiftOut and digitalWrite
   
4. be faster than these functions
   
5. supports general source and board optimized source
   
   

In a first proof of concept, attached source came up to life. Gave it the name BytePort. It includes

1. BytePort class
   
2. init function to assign GPIOS and mode
   
3. supports sending an array of bytes in parallel, with clock signal
   
4. supports sending a byte in serial bits
   
5. implementation for ESP32, btw. its preliminary, without DMA or some other fancy stuff
   
6. and gets the job for LED P3 64x32 done in about 20msec
   
   

Before spending more time on that, and may be running into a wrong direction, I would like to get feedback. Please see attached zip

Sorry,
there is a major change in BLE API.
I'm still working on a solution for that.
GATTC needs ble_addr_type which is not used in Espruino (at least AFAIK)
According to esp-idf examples it appears in an GAP event (ESP_GAP_BLE_SCAN_RESULT_EVT)

Definition is

typedef enum {
    BLE_ADDR_TYPE_PUBLIC        = 0x00,
    BLE_ADDR_TYPE_RANDOM        = 0x01,
    BLE_ADDR_TYPE_RPA_PUBLIC    = 0x02,
    BLE_ADDR_TYPE_RPA_RANDOM    = 0x03,
} esp_ble_addr_type_t;

Any idea to understand this parameter would be big help

Sending data from WebIDE to ESP32 is very slow.
I compared WEBIDe with putty.
In both cases baudrate is 115200. In WEBIDE Throttle Send is disabled.

Pasting about 5KB into putty takes less a second
Pasting same into terminal window of WEBIDE takes more than 6 secs

Any idea, why we have this big difference in speed ?

Changes are uploaded to branch ESP32-V3.1
@Gordon, could you please check, mainly changes in make to support board specific Crypto
@Wilberforce, hope you get it running with your BuildTools, please see changes in sdkconfig

More detailled description about changes is in targets/esp32/Changes_V3.1
I've added an issue in github for this upgrade. Lets use it for next steps.
Sorry for the delay, but sometimes life becomes complex

My idea would be to

1. remove old branches (ESP32 and ESP32-V3.0). Both are some commits ahead since may or june. From my best knowledge, we don't need these commts. I've done my testing and converting based on Espruino Master and ESP-IDF V3.1 release.
   
2. create a new branch ESP32-V3.1
   
3. pull up my changes to ESP-V3.1
   
4. see, if you can build. If there are problems we have to fix
   
5. once its running, merge into master
   
   

Anyway, I'm absolutely open for any other route.

correct, its flash only,
here are the changes, @wilberforce could you please check. I have in mind a change in WIFI, but don't remember. Something around buffers or channels ?

- commented partition in partitions_espruino.csv
- shorten path to include esp_partition.h in main.c
- esp32_neopixel.c, changed ***_PERI_REG_MASK functions(deprecated) to DPORT_***_PERI_REG_MASK functions.
- added folder crypto to /make
- created file standard handling of mbedtls
- created ESP32 specific file handling of mbedtls, ESP-IDF needs new version, Espruino core works with old one
- replaced ifdef USE_CRYPTO with includes of standard or board specific from make/crypto
- make/family/ESP32MAKE sorted LDFLAGS, removed double entrys, added entrys needed for V3.1
  (smartconfig_ack, newlib/platform_include, lmesh, ld_include_panic_highint_hdl)
- jswrap_crypto.c, added ESP32-defines MBEDTLS_CIPHER_MODE_xxx, there should be a better way, but I did not find
- make menuconfig
- - Serial flasher config
- - - Flash size (4 MB)
- - Partition Table
- - - Partition Table (Custom partition table CSV)
- - - (partitions_espruino.csv) 
- - Compiler Options
- - - Optimization Level(Release....
- - - Assertion level (Disabled...
- - Component config
- - - Bluetooth enable
- - - - Bluedroid Enable
- - - - - Disable BT debug logs 
- - - ESP32 specific
- - - - Support for external, SPI Connected Ram enable
- - - - SPI RAM Config
- - - - - Ignore PSRAM when not found enable
- - - - - Reserve this amount of bytes 16384
- - - - Also watch CPU1 tick interrup disable
- - - - Initialize Task Watchdog Timer on startup disable
- - - FreeRTOS
- - - - Halt when an SMP-untested function is called disable
- - - Log output
- - - - Default log verbosity Error
- - - - Use ANSI terminal colors disable
- - - mbedTLS
- - - - Enable hardware AES acceleration disable
- - - - Enable hardware MPI (bignum) acceleration disable
- - -  Wear levelling library sector size 512

I've a version running with new ESP-IDF V3.1 now.
Main point for Espruino is support of PS-RAM which opens the option to have 20000 jsVars, or even more.

I'm not convinced, that using V3.1 is a good step for Espruino.
We have to switch to new version of mbedtls, and size of binary raises to unbelievable 1300 kBytes.
May be, we could easily add PS-RAM support to a specific V3.0.x

Should we open an issue on GitHub for that ?

Espruino supports different boards and can be customized by defines like Net, Gtaphics, Neopixel etc.
May be, you have your own extensions. In that case it would be helpful to have an API documentation for your project.
In a first try I've added -BBoard parameter to build_docs.py, which changes argument to call common.get_jsondata, and adds a define in switch-path which handles -B parameters.

This would open the option to create board specific API documentation during make by calling
python build_doc.py $(FAMILY) $(WRAPPERSOURCES)
And then add it to board zip file.

If this is of general interest I would open a pull request

ESP32 supports I2S in parallel mode. This can be used to set multiple pins at a time.

There is an example in ESP32 showcase (https://esp32.com/viewtopic.php?f=17&t=3188) which I converted to be used in Espruino. It's running fine under Espruino, supports 24bit colors.
Handing over address of buffer one time is all I've to do, no converting, no refresh.
And last not least, CPU load is poor, less than 1 %
With other words, I've a solution for my needs.

Problem of I2S itself is poor documentation/support in ESP-IDF, therefore converting the example to Espruino was more or less a kind of copy/paste. With other words, my knowledge about I2S on ESP32 is poor ;-)

@Gordon
Gave it a try and came down to 25 hz instead of 14 hz. This is still too slow, at least for ESP32.
Therefore I will go back to a special function outside the original Espruino code.
I opened a github repository for special code about 2 years ago and will bring it back to life
And maybe, I will spend some time on my makeFirmWare service, you never know

My ideas to speed up shiftout are

• split into 2 parts, first init and second shiftout data
  
• + init could be done before the loop
  
• + number of parameters for shifting is reduced
  
• - init needs to be done before, and data has to be stored somewhere
  
• instead of an sub array send start and length
  
• use a memory address instead of iterate
  
• + faster compared to iterate
  
• - works for large arrays only (?)
  
• one loop instead of jsvIterateCallback
  

@allObjects, agree to your first point, Let me give an answer in (a kind of) german.
Esch ischt halt so geworde or with others words, the tree is grown this way ;-)
Writing in compiledC would work for the boards supported by Gordon not for ESP32 or others, Correct me if I'm wrong.
Anyway, I could imagine to have something like E.convertForLEDBoard function in Espruino.
And there should also be some options to speed up shiftout (significant).
Even an empty for next loop is not faster than one of the first boards. RTOS takes some cpu power, but we use it mainly for multitasking, and tasks can change each msec.
For me looks like the processor is not the fastest even with its high clock (80/160 mhz)

One more problem of ESPIDF, it's hungry for memory. With V3.1 we reach 1300 kBytes, where V3.0 needs 1100 kBytes. Ok, we have a change around mbedtls, but this should never be the reason for additional 200kBytes.

Oh, before I forget, my assumption about speed of set/reset pins was not correct, as you can see in compasion table above.