How to use spi to write and read some specfic register address

I don't know the maximum speed of the Pico, but UART may be a bottleneck.

I haven't used that IMU, but looks like you can read multiple bytes in a single operation. That definitely will be faster.

The number of characters you execute has a direct effect on execution speed. For example

return SPI1.send([addr|READ,0x00],ss)[1];

is almost surely faster than

  result=SPI1.send([addr|READ,0x00],ss)[1]­;
  return result;

Related to that, read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_­L,ss) is "terribly long" , but you can try minification and pretokenisation, as those speed up execution, and most likely you won't have to manually shorten function and variable names.

Mon 2019.11.04

Thank you for posting the upgraded snippets @user101931

Big DISCLAIMER here - I didn't research the parts here, nor even what the SPI traffic is doing. One line stuck out so just provided a quick untested response

'I believe I am using the hardware SPI '

Yes. Based on the setup function snippet, as there isn't an assignment to a var used to declare the software SPI pinout such as

var spi = new SPI();
spi.setup({mosi:B5, miso:B4, sck:B3});
spi.write([1,2,3,4])

and the use of Espruino defined SPI1 SPI2 SPI3 hardware constants.

The following reference from image 3 from #14

I like the new extraction() function.

I do see a possible area of contention. L18 has an argument (the value of the interval parameter) for setInterval() that is waaaaaay out of range. I did some quick look up, but can't locate the range of the low end, although the Espruino docs from #13 link do indicate the upper end. As the value needs to specify msec, experience tells me that approaching a value of 20 may start to show signs of struggle. Normal ranges, 30sec down to 20msec, would equate to a value in the 30000 - 20 range.

My S.W.A.G. guess is that the decimal value is getting rounded to an integer, and that is still too small a value in an attempt to fetch the SPI payload. Shouldn't this be more like a sampling request every second or so, and the SPI traffic from the device would then be able to respond timely? This is akin to having an attempt to fetch that is 100-1000 times faster than the data that actually is attempted to be fetched. The requests are queueing up and eventually running out of room/time to perform the actual task. As I said, just a quick S.W.A.GG'd response. That would explain why a few accurate lines of data do in fact get through, then the whole works gets bogged down. (I'll have more time to dig deeper this weekend)

for @AkosLukacs

'is almost surely faster than'

  result=SPI1.send([addr|READ,0x00],ss)[1]­;
  return result;

One reason might have been to enable the debugger to return a value for human viewing, before actually returning that value. I fall victim to that requirement and sometimes overlook and catch during code cleanup. Point well taken though.

Tue 2019.11.05

@user101931

'I am not very sure why PICO takes so long to read a set of data'

To help us better visualize the actual duration, modify the extraction() function by commenting out the other lines, such that only one line is executed and lets time that to see what the actual duration is. Something like:

    var t = getTime();
    var elapsed = 0;
    console.log( "start of SPI call " + (getTime()-t) + " " + t );


// The call to the extraction() function here
extraction();
// With only this line uncommented for timing
omz = read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_­L,ss);


    elapsed = getTime()-t;
    console.log( "elapsed " + elapsed );

It would be nice if a table of duration times could be generated for each of the vars there. This would give us an idea of where the bottleneck might be.

Posting the code for function read_FIFO() might assist here, and it may be timing for the guts of that function might be needed also, if the duration test(s) above are much greater than several msec.

To show the delay using the embedded console.log() statement is taking, place a single console.log() statement beside the var being tested and run two tests, the other commenting out the log() statement. It is likely that continuous writing to the Left-Hand console side is bogging down the works. Your test will help us identify.