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

[espruino-discuss]

Posted at 2019-07-22 by user101931

Hi

I am trying to use Espruino Pico to extract data from the IMU(LSM6DSL). In order to configure the IMU, I need to configure by writing and reading the value to the register. However, from the espruino library, I am not very certain how to write and read the value to the IMU registers. I am wondering if anyone has done something similar? Thank you very much for your help.

[espruino-discuss]

Posted at 2019-07-22 by AkosLukacs

In most modules, there is a r and w function for low level access to the device. I think you can use those.

---

Posted at 2019-07-22 by user101931

Hi AkosLukacs,

Thank you for your help.
Sorry that I did not make the question very clear, I am trying to use SPI to be the communication protocol.
and I am having some issue using the Espruino Javascript library to read and write the register.

Thank you

---

Posted at 2019-07-22 by AkosLukacs

Ooops, missed the SPI part, sorry.
If you search for SPI in the docs, you get all the modules that use SPI, and you can look at the code.

For example from the LIS2DH12 that has SPI interface as well (at the bottom of the file):

exports.connectSPI = function(spi,cs,options) {
  if ("function"==typeof options)
    throw new Error("Use require(LIS2DH12).connectSPI(..., {callback:function() { ... }} instead");
  return new LIS2DH12(function(reg,len) { // read
    return spi.send([reg|0xC0,new Uint8Array(len)], cs).slice(1);
  }, function(reg,data) { // write
    return spi.write(reg, data, cs);
  },options);
};

The interesting part:

// reg - the register address
// len - how many bytes to read
function read(reg,len) {
    return spi.send([reg|0xC0,new Uint8Array(len)], cs).slice(1);
 }

// reg - the register address
// data - the data you want to send
function write(reg,data) {
    return spi.write(reg, data, cs);
  }

---

Posted at 2019-07-22 by @gfwilliams

I think @AkosLukacs has hit it on the head. SPI should be pretty straight forward. The main gotchas are:

• The register is usually sent as the first byte
• When you read, you need to send the register and then another byte (usually 0 or 255). The first byte you get back is then basically garbage and what comes after is the data.
• Often devices set the top bit of the register to indicate a read or write (so reg|0x80 - the code above uses 0xC0 which I think is specific to the LIS2DH12. You'd have to check your chip's datasheet.

If you post the code you have up here we might be able to help you a bit more.

---

Posted at 2019-10-13 by user101931

Hi all,

I am fairly new to javascript and Espruino.

I just started to implement the SPI, but the code does not seem to recognize my SPI. write function. I think it was because some header files were missing, but I am not sure what and how to include them.

Except for the SPI, I am having some trouble finding these function's library

function to convert decimal to binary
fopen,fclose -- (file open, file write, file close)
getTime

Thank you very much for your time

---

Attachments:

• Screen Shot 2019-10-13 at 1.01.22 AM.png
  
• Screen Shot 2019-10-13 at 1.01.39 AM.png
  
• Screen Shot 2019-10-13 at 1.01.48 AM.png

---

Posted at 2019-10-13 by AkosLukacs

You have a typo in the first line: it should be var start = new Date(), not new Data() :)

---

Posted at 2019-10-13 by Robin

Sun 2019.10.13

for @AkosLukacs 'You have a typo in the first line:' Good catch but;

Should also be var d = new Date() in order for second line to be valid ;) ;)

@user101931 See: http://www.espruino.com/Pico+Clock#line=3,11
or any of the examples beneath the Date constructor topic in the 'Reference' page link that follows

This will be of help using the Date functions:

http://www.espruino.com/Reference#Date
http://www.espruino.com/Reference#l_Date_now

Binary to Decimal, can't go wrong with the tutorials at W3Schools:

https://www.w3schools.com/js/
https://www.w3schools.com/js/tryit.asp?filename=tryjs_bitwise_convert

'the code does not seem to recognize my SPI. write function'

Is it possible that SPI is not being used correctly concept-wise? (for read write)

http://www.espruino.com/SPI
http://www.espruino.com/Reference#SPI

 

'I think it was because some header files were missing, but I am not sure what and how to include them'

Locate the heading 'constructor SPI' from the 'Reference' page link above and click on the right facing arrow adjacent to that heading. This will link to:

https://github.com/espruino/Espruino/blob/master/src/jswrap_spi_i2c.c#L55

showing that SPI is part of the firmware build and no other 'includes' are needed.

Would you provide the link to the source code or tutorial that is being worked from please.


*If* this is the correct data sheet:

https://www.st.com/resource/en/datasheet/lsm6dsl.pdf

p.40 p.42 it appears the address and data are required to be sent simultaneously as 16 bits.

Data byte missing?

Chip Select 'Actually' going lo and not inadvertently inverted?

Does the Pico MOSI actually go to the inertial device MOSI and not flipped with MISO?


It appears the inertial module is programmed very similar to the GPS device. This link:

http://forum.espruino.com/conversations/332295/#comment14688770

might provide some insight on how I solved communication using the FX2 Logic Analyzer. Saved a ton of time rather than just guessing. . . .

---

Posted at 2019-10-14 by @gfwilliams

Hi - I think it might be best to start out from some existing SPI code like http://www.espruino.com/SPI and work from there...

The code you've written seems to have a few issues (like :integer= not being valid JS) and I think you'll be banging your head against a wall for quite some time just trying to stop it erroring.

For SPI, the issue is you're using SPI which is the class name for an SPI peripheral, but isn't an SPI peripheral itself. Try changing it for SPI1 - the first SPI peripheral - and it should be fine.

In terms of your other stuff - try using the search box at the top right of Espruino.com and specifically the reference at http://www.espruino.com/Reference:

function to convert decimal to binary

If you want to convert a number to a binary string, just use ...toString(2) - eg (42).toString(2)

... but you don't need to convert anything to binary to send it over SPI

fopen,fclose -- (file open, file write, file close)

http://www.espruino.com/Reference#fs

http://www.espruino.com/File+IO

Or since you don't have an SD card, http://www.espruino.com/Reference#Storage

getTime

It's literally a function called 'getTime()' - or you can use Date.now() - http://www.espruino.com/Reference#l__global_getTime

---

Posted at 2019-10-19 by Robin

Sat 2019.10.19

Hi @user101931,

Is the WebIDE right-hand editor panel being used to it's full potential?

Make sure the following is *UN-checked*

WebIDE >> Settings >> General >> Disable Code Hints

When viewing code in that panel when code hinting is enabled, any syntax issue will display a red circle with an 'X' in it. Rollover to gain additional insight.

After all code lines syntax check, the use of the debugger; keyword inside functions will allow for additional run-time detail.

https://www.espruino.com/Debugger

It would help us enormously in the future if code snippets could be entered here using the ``` back tick delimiter (Shft ~ ) or highlighting and pressing the < / > code button just to the left of the 'Preview' button in the menu of this edit window.

var d = new Date();
var start = d.getTime();

This will enable us to block copy and test that code snippet!

---

Posted at 2019-11-03 by user101931

Thanks to y'all help, I am making a lot of progress now. The code all seem working, but I am encountering this error "Prompt not detected - upload failed. Trying to recover..." when I run a long while loop in Espruino. I am trying to extract the FIFO data from the IMU(LSM6DSL) continuously for a long time. The data look correct at the beginning but the pattern got messed up after a couple of sets of data and then this error "Prompt not detected - upload failed. Trying to recover..." occurs and the entire program just stops.
Does anyone have any ideas of why this would happen and how to fix this? Thank you very much for y'all help.

Figure 1 While loop code

Figure 2 Correct data pattern before the first 7th set. The number in the middle indicates the number of data left in the FIFO (2048 is when its full), it seems SPI is reading too slow to catch up the FIFO data generator, but I actually set SPI transmission rate to 10 MHz(max rate that the IMU can torrent), I would expect the SPI speed is sufficient enough.
Sorry the print title does not match up with the actual data, the correct order should be "gyro x ,gyro y,gyro z, acceleration x, acceleration y, acceleration z,temperature, timestamps"

Figure 3 shows the error I am getting and the program crashed.

---

Attachments:

• Screen Shot 2019-11-02 at 10.00.01 PM.png
  
• Screen Shot 2019-11-02 at 10.00.11 PM.png
  
• Screen Shot 2019-11-02 at 10.01.45 PM.png

---

Posted at 2019-11-03 by user101931

I check the setTimeout method in this case based on this link, but due to the project requirement, I would prefer reading the data without any interruption for hours (with setTimeout, the code pause about at around 20s automatically with no error), I am wondering if there is a way to do it without pause the program?

Or Does Espruino Pico support this kind of application?

Thanks

---

Posted at 2019-11-03 by Robin

Sun 2019.11.03

'I would prefer reading the data without any interruption for hours'

@user101931

Note that there isn't the function setTimeout() in the code snipit provided

It appears the setTimeout() found in link in #12 is allowing everything to settle before executing the function. Maybe it is setInterval() that will repetitively call the function, after the timeout duration is over, perhaps?

http://www.espruino.com/Reference#l__global_setInterval

Tutorial

https://www.w3schools.com/js/js_timing.asp

> ' I am wondering if there is a way to do it without pause the program?'

Would a better tutorial assist here?

http://www.espruino.com/Data+Collection
http://www.espruino.com/Tutorials

From #11

'but I actually set SPI transmission rate to 10 MHz'

Is hardware or software SPI in use?

See Note: "baud:integer=100000, // ignored on software SPI"
http://www.espruino.com/Reference#l_SPI_setup

 

'Figure 3 shows the error I am getting and the program crashed.'

"Prompt not detected - Upload failed"

Was code on the Right-hand editor side of the WebIDE being uploaded while the * while{} * loop was still executing?

EDIT: > After thinking this through, I believe the while loop is executing faster than the SPI send-response can keep up. Using setInterval() instead of the loop would be a better practice. See the data collection logging tutorial link above.

The following paragraph may not apply then.

In the code block in #11, variable start is never re-evaluated or re-assigned. Loop execution would be unpredictable. Infinitely fast looping until 20 seconds have elapsed. Also in line tm = readtime() the function definition is not present. Please upload *all* code using the following:

I placed instructions for easy code insertion within each post at the end of #10. Including that way will allow us to block copy your code and comments from hilighting using Ctrl+C right here in the forum edit window. We would have line numbers to reference as well. Would greatly assist us.

---

Posted at 2019-11-04 by user101931

Hi Robin,

Thank you very for replying and helping.

I set them to setInterval and that error does not occur anymore.

I believe I am using the hardware SPI and this is my SPI set up

function SPI_setup()
{
  SPI1.setup
  ({sck:A5,
     miso:A6,
     mosi:A7,
     baud: 10000000,
     mode: 0,
     order:'msb',
     bits:8
    });
}

The read time is to read the timestampes from the IMU, which is part of the data collection from the IMU.
the readtime Code looks like this:

function readtime(ss)
{
        hi = SPI_read(FIFO_DATA_OUT_L,ss);
        hi2 = SPI_read(FIFO_DATA_OUT_H,ss);
        non = SPI_read(FIFO_DATA_OUT_L,ss);
        lo = SPI_read(FIFO_DATA_OUT_H,ss);
        step = SPI_read(FIFO_DATA_OUT_L,ss);
        step = SPI_read(FIFO_DATA_OUT_H,ss);
        hi2 = hi2 << 16;
        hi = hi << 8;
        Value = hi2 | hi | lo;
        return Value;
}

I checked the time needed to collect one set of data is fixed at .029ms, IMU generate each set of data at 833Hz = 1/833 ~=0.0012, the time for the IMU to generate one set the data is a lot faster than the program excution. I think the problem is when the FIFO is full, the pattern will be messed up.

I am not very sure why PICO takes so long to read a set of data. I tried to look up the default system clock rate and it seems 84MHz already based on this E.setClock(Correct me if I am wrong), is there a way to improve the program execution/reading speed?

Changed version code

function extraction()
{
          st = getTime();
          s2 = SPI_read(FIFO_STATUS2,ss);
          if(((s2)&0b00010000) != 0b00010000)
          {
             console.log( omx = read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_L,ss),
              omy = read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_L,ss),
              omz = read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_L,ss),
              ax  = read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_L,ss),
              ay  = read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_L,ss),
              az  = read_FIFO(FIFO_DATA_OUT_H,FIFO_DATA_OUT_L,ss),
              temp = read_FIFO(TEMP_OUT_H, TEMP_OUT_L, ss),
              tm = readtime(ss), getTime()-st);
          }
}

setInterval(extraction,0.00000000001);

Output:

///////////////The last number is the excution time//////////////
8273 -829 -15075 -77 -53 4231 -562 7840166 0.02954864501
6509 -2139 -9095 -88 -57 4253 -513 7840215 0.02941513061
5273 -2745 -8939 -86 -61 4244 -548 7840264 0.02940368652
4831 -2701 -8543 -84 -57 4250 -548 7840312 0.02936649322
4447 -2693 -8315 -89 -64 4251 -553 7840361 0.02934265136
4105 -2713 -7793 -85 -55 4250 -527 7840409 0.02941608428
3779 -2715 -6983 -86 -63 4240 -541 7840458 0.02939796447
3465 -2695 -5959 -90 -56 4245 -542 7840506 0.02937698364
////////////Data start to have wrong pattern//////////////
////////////Data start to have wrong pattern//////////////
3191 -2637 343 -267 -337 -45 -548 16699391 0.02938270568
-21 21 53 -9 255 43 -548 5888 0.02933788299
29 21 3 17 5 17 -541 4864 0.02938842773
-249 9 15 255 5 15 -535 4352 0.02937221527

Spi:

function SPI_write(addr,data,ss)
{
  SPI1.send([WRITE|addr,data],ss);       //write to address
}


function SPI_read(addr,ss)
{
  result=SPI1.send([addr|READ,0x00],ss)[1];
  return result;
}

---

Posted at 2019-11-04 by AkosLukacs

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.

---

Posted at 2019-11-05 by Robin

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.

---

Posted at 2019-11-06 by Robin

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.

---

Posted at 2019-11-07 by user101931

Hi Robin and AkosLukacs,

Thank you for taking your time helping me.

Here is my code and output for measuring one read_FIFO, (compare with 1/833Hz = 0.0012s). I just realized getTime() was actually returning million seconds (Correct me if I am wrong), the speed is actually very fast if the value that return is ms. (500-1000 times fast than the data generated).

I am concerning if that's my IMU's configuration, I will double-check that.

However, when I decrease the speed to 52Hz or 26 Hz, the data was actually generated properly. and when I optimize the code, a couple more correct data set will appear before it gets messed up.

Not really sure what might be the issue now.

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

omx  = read_FIFO(ss);

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

And the corresponding output is:

start of SPI call 0.00700378417 946685774.25032615661
elapsed 0.01593494415

Enable extraction and disable read_FIFO() in the code

start of SPI call 0.00715160369 946686294.47058963775
elapsed 0.02543163299

The code to run one complete extraction() with no print

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



function extraction()
{
              omx  = read_FIFO(ss),
              omy  = read_FIFO(ss),
              omz  = read_FIFO(ss),
              ax   = read_FIFO(ss),
              ay   = read_FIFO(ss),
              az   = read_FIFO(ss),
              temp = read_normal(ss),
              tm   = readtime(ss)
}

extraction();

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

Output

start of SPI call 0.00709629058 946686935.69506931304
elapsed 0.04530811309

Here is my read_FIFO code, I am calling two SPI_read in this function, FIFO_DATA_OUT_H/L are two registers to store the generated FIFO data

function read_FIFO(ss)
{
  return signshort(SPI_read(FIFO_DATA_OUT_H,ss)<<8|SPI_read(FIFO_DATA_OUT_L,ss));
}

Thank you very much.

---

Posted at 2019-11-08 by Robin

Thr 2019.11.07

My DISCLAIMER from #16 still applies,

Hi @user101931, a quick cursory peek implies the SPI part of the code is working as it should. The timing values don't appear out of range. I'll do a math check this weekend.

> 'a couple more correct data set will appear before it gets messed up'

What isn't shown is the repeating part. Would you please post the setInterval() line of code.

Although not absolutely needed, but . . . It would help immensely if you could also provide a timing check on just single individual lines, so that some quick mental cross checks could be performed.

// such as

ax   = read_FIFO(ss);

// from inside the read_FIFO() function - a single request
SPI_read(FIFO_DATA_OUT_H,ss);

> 'I just realized getTime() was actually returning million seconds (Correct me if I am wrong)'

There are a few links in other posts within this thread, searching w3schools.com and MDN developer.mozilla.org should allow the discovery of that answer. If you are still stuck, please post the final links where discovery ends, and I'll do some digging after that. I'm sure the learning how to find those links will enhance the discovery process and boost your ego. ;-)

When successful, please post the link for future enthusiasts reading this thread. Thanks.

I'll have a bit of time to dig into this over the weekend.

Is this the datasheet for the device?

https://www.st.com/resource/en/datasheet/lsm6dsl.pdf

---

Posted at 2019-11-10 by user101931

Hi Robin,

Thank you for helping me so much

Sorry if I misunderstand, I am not so sure how to measure the repeated part if you mean measure how fast the interval is running.

I put the measure time in the all read_FIFO, read_Normal, and read_Time and this is my output

Read FIFO 0.00033950805 946686551.91729545593
elapsed 0.00323581695
Read FIFO 0.00033664703 946686551.92159366607
elapsed 0.00324440002
Read FIFO 0.00037765502 946686551.92586135864
elapsed 0.00328826904
Read FIFO 0.00033760070 946686551.93021202087
elapsed 0.00324249267
Read FIFO 0.00037860870 946686551.93448162078
elapsed 0.00328826904
Read FIFO 0.00033855438 946686551.93883323669
elapsed 0.00324440002
Read Normal 0.00038623809 946686551.94312000274
elapsed 0.00335884094
Read Time 0.00034713745 946686551.94751930236
elapsed 0.00702095031
8793 -567 -18040 -23 -102 4237 undefined 3902886 0.03861045837
Read FIFO 0.00034427642 946686551.95695877075
elapsed 0.00325965881
Read FIFO 0.00038528442 946686551.96123790740
elapsed 0.00331974029
Read FIFO 0.00034427642 946686551.96561431884
elapsed 0.00326347351
Read FIFO 0.00038528442 946686551.96989727020
elapsed 0.00330162048
Read FIFO 0.00034523010 946686551.97425270080
elapsed 0.00325775146
Read FIFO 0.00034427642 946686551.97857093811
elapsed 0.00325298309
Read Normal 0.00034999847 946686551.98289966583
elapsed 0.00330257415
Read Time 0.00035190582 946686551.98722839355
elapsed 0.00691509246
8029 -1069 -14708 -24 -117 4237 undefined 3902939 0.03862571716

and the code looks like this

//Read timestamp function

function readtime(ss)
{
        var t = getTime();
        var elapsed = 0;
        console.log( "Read Time " + (getTime()-t) + " " + t );
        hi = SPI_read(FIFO_DATA_OUT_L,ss);
        hi2 = SPI_read(FIFO_DATA_OUT_H,ss);
        non = SPI_read(FIFO_DATA_OUT_L,ss);
        lo = SPI_read(FIFO_DATA_OUT_H,ss);
        step = SPI_read(FIFO_DATA_OUT_L,ss);
        step = SPI_read(FIFO_DATA_OUT_H,ss);
        hi2 = hi2 << 16;
        hi = hi << 8;
        Value = hi2 | hi | lo;
        elapsed = getTime()-t;
        console.log( "elapsed " + elapsed );
        return Value;
}

var st = 0;
//var s2 = 0;
//print( "OMX", "OMY", "OMZ","AX", "AY", "AZ",,"TEMP","TimeStamps");
//var start = getTime();

function extraction()
{
       // "compiled";
          //print(Ntotaldata());
          st = getTime();
          //if(((SPI_read(FIFO_STATUS2,ss))&0b00010000) != 0b00010000)
          //{
             console.log( 
              omx  = read_FIFO(ss),
              omy  = read_FIFO(ss),
              omz  = read_FIFO(ss),
              ax   = read_FIFO(ss),
              ay   = read_FIFO(ss),
              az   = read_FIFO(ss),
              temp = read_normal(ss),
              tm   = readtime(ss), 
               getTime()-st);
         // }
}


setInterval(extraction,0.002);

ss

function read_FIFO(ss)
{
  var test;
  var t = getTime();
  var elapsed = 0;
  console.log( "Read FIFO " + (getTime()-t) + " " + t );
  
  test = signshort(SPI_read(FIFO_DATA_OUT_H,ss)<<8|SPI_read(FIFO_DATA_OUT_L,ss));

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

function read_normal(ss)
{
  var test1;
  var t = getTime();
  var elapsed = 0;
  console.log( "Read Normal " + (getTime()-t) + " " + t );
  test = signshort(SPI_read(TEMP_OUT_H,ss)<<8 | SPI_read(TEMP_OUT_L,ss));
  elapsed = getTime()-t;
  console.log( "elapsed " + elapsed );
  return test1;
}

I believe the time I measure is in millisecond, and I also measure the clock frequency of the SPI is running correctly at 10 MHz, so I think both system and SPI should techninilly running fast enough? and thank you again : )

yes, that is the IMU datasheet.

I configured FIFO as continuous mode so I can keep the data from the IMU with a set timestamp and it can keep running for hours.

The goal is to do the data collection at 833 Hz for hours and the output timestamps gap should be fixed (increment by 48 or 49 each timestamp). The FIFO mode provides the correct data but I have to reset every time to get the new set of data since it will stop filling after it full. The reset process result in missing some data, so it is not very ideal

Attached is the SPI clock frequency measured from the oscilloscope

---

Attachments:

• WechatIMG195.jpeg

---

Posted at 2019-11-10 by Robin

Sat 2019.10.44

For L2

'elapsed 0.00323581695'

Three msec is about what I see with other devices using SPI

L27 setInterval(extraction,0.002);

Are you still getting errors with the above?

A typical value for the duration would be 2 to represent 0.002, but my belief is that is still too small. I would expect a value around 50+

Try setInterval(extraction,150);

So my guess is that we need to look at how the request for data is made, not the actual transfer of data that seems to be returning accurate values. If setInterval() which needs to be in msec is changed to a value of 100-2000 does the error after around eight or so iterations still occur?

Was the datasheet link in #19 accurate?

---

Posted at 2019-11-10 by Robin

'The goal is to do the data collection at 833 Hz for hours'

Would you point to a page within the datasheet, that suggests using that frequency or range of frequencies for your use. When I read over, my interpretation of how to request data was a bit different.

How are the gyro, or accelerometer used? It might be that your requirement is different than I envision.

Are you picking up the device from a stationary position and expecting the Espruino device to respond to that input?

p. 35 of datasheet Are we in 'continuous' mode?

Is so, the FIFO buffer is probably filling up before each data item is removed from the buffer and the device is cramming in bytes until errors in output are seen. Could this be a possibility?

How often do you actually need the data, the device outputs? It seems that it is desired in the msec range, but my interpretation is that reading those values should be in the many tens of msec range, say every half second or so.

---

Posted at 2019-11-10 by user101931

I just tried setInterval(extraction,150);
but it is only outputting one correct data set this time.

8539 -645 -18294 -256 126 4104 -668 4262111 0.02233409881
11 15 15 229 225 227 -669 3328 0.02214241027
11 11 19 229 227 223 -653 4864 0.02214145660

Oh sorry, on page 57/114 FIFO ODR can be 833Hz frequency range from 12.5 to 6.6kHz. so we choose 833Hz because it is a nice frequency for the algorithm that we are developing for processing the data

---

Posted at 2019-11-10 by Robin

May I ask which time zone you are in?

I'm in CST 6 hours behind GMT. Getting a bit late for me, so trying to make a determination of how long I might choose to hang in there this evening.

Did you see the code example at: > http://www.espruino.com/LSM6DSL

Have you tried using setWatch(io_RunMode, . . . . . or would that even be appropriate?

http://www.espruino.com/Reference#l__global_setWatch

It's not clear to me yet how the device is desired to be used and what data is required.

---

Posted at 2019-11-10 by user101931

Haha, no problem. I am in the mountain time zone

---

Posted at 2019-11-10 by Robin

Let me get another Whiskey, and I'll read over that page ref

Just grabbed 'Old Ezra #7' Bourbon 101 proof. Love the stuff. Neat.

---

Posted at 2019-11-10 by user101931

I will integrate the gyro over that time period, so I think I will every single set of data that output at 833Hz,
then I will use UART to pass the integrated data and accelerometer to the data handling unit.

"Is so, the FIFO buffer is probably filling up before each data item is removed from the buffer and the device is cramming in bytes until errors in output are seen. Could this be a possibility?"

I think this is possible. but if this is true, wouldn't it make it very hard to pull the data in high frequency?

Haha have a good time

---

Posted at 2019-11-10 by Robin

Just read over p.57

Have you tried just reading a single set of values while 'NOT' in continuous mode?

My gut feel is that the device is responding with an accurate data payload to a request, so the SPI part seems to be working as it should.

From all the data sets posted, it seems there is an issue while in continuous mode.

What are the expectations of the gyro/accelerometer? How is it expected to be used?

---

Posted at 2019-11-10 by Robin

What is being used as the trigger to fetch the data? Is it the movement of the device, or is it human input, via a switch perhaps?

> 'I think this is possible. but if this is true, wouldn't it make it very hard to pull the data in high frequency?'

Your data posts, show that it is possible to fetch data reliably at 4 msec 0.004 as the timing is around 0.003+ and that seems a good value based on other devices I have used. So, is 200+ samples per second what is needed in your design? It certainly seems doable, and my gut feel is that the Javascript engine will be able to keep up at that demand. What isn't clear is what is needed in the design.

1 / 833 = 0.0012 in msec
At that frequency, My understanding is that the FIFO will fill up faster than it is possible to fetch the data (0.003+) Have you tried a slower update frequency? Have you considered inline 'C ' to speed up execution?

http://www.espruino.com/InlineC

While anything goes, aren't accelerometers polled at say a tenth second interval, then acted upon when that duration is exceeded?

---

Posted at 2019-11-10 by user101931

The FIFO mode provides the correct data but I have to reset every time to get another round of FIFO data, since it will stop filling after it full. The reset process clear everything that might stall in the FIFO and results in missing some data (because timestamp incremented a lot ), so it is not very ideal

So ideally, I would like to save the program in flash memory in Epsurino, and when I supply the power to Epsurino or turn on some switch, it will start to fetch data

So this is how I would use those data:

For now,
I will integrate the gyro over that timestamp that's outputting at 833Hz, then use UART to pass the integrated gyro data and accelerometer to the data handling unit.

So I would prefer to integrate every set of data at every 833Hz = 0.0012s

I just realized you edit #24 I am gonna look at those links now

---

Posted at 2019-11-10 by Robin

Yes, you are correct, our edits are stomping on each other. Maybe I'll slow down on the Bourbon. . . . . Not!

'So I would prefer to integrate every set of data at every 833Hz = 0.0012s'

As your tests show, a data fetch over SPI is taking 0.003+ sec, so that confirms your preference won't be possible.

Are you attempting something like the Wii controller would need as real-time input? Just trying to get an idea of why so much data in such as short period of time is required.

---

Posted at 2019-11-10 by user101931

Haha ^ ^

and I thought gettime() returns in ms. Isn't 0.003 is in ms?

---

Posted at 2019-11-10 by Robin

Ahhhhh, we are on to something.

Yes. 0.003 is a value that represents msec. But the setInterval() function needs a value that * IS * the number of msec. So a value of 3 would be needed.

Experience tells me though, as you approach below 20 for instance, that the time to interpret
and execute a Javascirpt statement (remember we have an interpreter, not compiled 'C' as in Arduino) then print out using console.log() will start to bog down depending on the actual lines of code.

EDIT:
getTime() returns a value in seconds

http://www.espruino.com/Reference#l__global_getTime

setInterval() requires a value in msec

http://www.espruino.com/Reference#l__global_setInterval

Check out the link in #29

Inline 'C' will speed things up. But I don't know if it will solve your specific issue.

---

Posted at 2019-11-10 by user101931

I just tried 3 and it looks like the same output as 0.02 that I have before

is there a way to check the data without using print? and another way to call the function repeatedly if we want to call it fast? for visualizing the data, one other method I can think of is writes file, I believe the write file should be faster than console.log(), but I am concerning if write file write it to the flash memory? if so, i am afraid I do not have enough flash for the data in espruino .

Yes, I will try that inline c, I tried the one with adding "complied" in the code and it did not work, but does increase a bit speed.

OHHHHH no, if gettime return in second, that proof the 833 Hz is impossible with javascript

---

Posted at 2019-11-10 by Robin

Sun 2019.11.10

Good Morning @user101931 ran out of steam last evening as I'm an hour ahead.

'OHHHHH no, if gettime return in second, that proof the 833 Hz is impossible with javascript'

Wanted to make sure it was understood that adding the getTime() function was only to get visual feedback on locating where the bottleneck is. It wasn't meant to be left in. IMPORTANT POINT: It is the duration of the loop (which will be in the msec range) has little to do with using that function (which returns a value in decimal seconds) to determine the iteration elapsed time. It is setInterval() and not getTime() we need to be concerned about. I also wanted to verify that SPI was functioning okay, and I believe we are in agreement that the device is filling the FIFO buffer, and that is overflowing.

The time killer is the actual use of console.log() in an attempt to update the WebIDE console panel.

> 'is there a way to check the data without using print?'

Q: Is it really necessary to make an attempt to print *ALL* the values to the console?

While it might be necessary to sample at a high rate, the data really isn't changing that fast between samples. My S.W.A.G. guess is that more than 90% aren't even needed as human perception is at a much slower rate. Isn't the need just to determine when the accelerometer changes state?

What about using a counter and a conditional statement to say log every twentieth pass, instead of every pass?

What about only fetching data when say the device is bumped for instance?

See use of setWatch at end of snippet at:
http://www.espruino.com/LSM6DSL

 

'another way to call the function repeatedly'

Other than a while loop, which will be tough at times to break out of, (not recommended stick with setInterval) writing the loop with inline 'C' will remove the interpreter having to read and parse each Javascript line of code.

> 'but I am concerning if write file write it to the flash memory?'

Some ideas from the data logging tutorial to toss around:

http://www.espruino.com/Data+Collection
http://www.espruino.com/Tutorials

---

Posted at 2019-11-19 by @gfwilliams

Sorry I'm a bit late to this. Basically Espruino's JS execution speed isn't that fast because it's interpreted.

Looking at the code I've seen I think there are a few things you could do to really improve speed:

• Inline all the SPI reads/data conversion into one function
• If you can read all the data from the FIFO with one long SPI read (rather than the ~16 1 byte commands you have currently) then that would be a million times better. It should be possible - that's the whole point of the FIFO really, but I can't see any examples of anyone doing that :(
• Failing that you can at the very least read 2 bytes at once with something like SPI1.send([FIFO_DATA_OUT_H|READ,0,0],CS).slice(1)
• Add "compiled" at the top of that JS function (http://www.espruino.com/Compilation) - assuming you're just using simple JavaScript that will cause your function to be sent off to the Espruino server, compiled, then uploaded - it should be way faster. It may not actually be needed though with the other changes.

Because you're doing the same command over and over, you can also use bind which basically works out the arguments and creates a new function that contains them. Here's some code that should be pretty fast

var FIFO_READ_CMD = SPI1.send.bind(SPI1,[FIFO_DATA_OUT_H|READ,0,0],CS);
var data = new Uint8Array(14);
var sdata16 = new Int16Array(data.buffer);
var udata16 = new Uint16Array(data.buffer);

function getData() {
  "compiled"  
  var f = FIFO_READ_CMD;
  data.set(f().slice(1),0);
  data.set(f().slice(1),2);
  data.set(f().slice(1),4);
  data.set(f().slice(1),6);
  data.set(f().slice(1),8);
  data.set(f().slice(1),10);
  data.set(f().slice(1),12);
}

// call getData and then read signed 16 bit data from sdata16, or unsigned from udata16

But I'm struggling to see the complete code you're using at the moment so I can't be sure this will do exactly what you want. Using the same form you should be able to modify it to do what you need though.

---

Posted at 2019-11-19 by @gfwilliams

Just to add to this...

another way to call the function repeatedly

setInterval should be fine - right now it's just being slowed down by the code execution

is there a way to check the data without using print?

Could you just write the data to a global variable? Then when you want to check it you can write 'print(mydata)'?

---

Posted at 2022-04-13 by user142686

setTimeout() and setInterval() functions allow you to execute a piece of JavaScript code/function at a certain point in the future. setInterval repeats the call, setTimeout only runs it once.

JavaScript setTimeout(expression, timeout); runs the code/function once after the timeout. It is a time based code execution method that will execute script only one time when the interval is reached, and not repeat again unless you gear it to loop the script by nesting the setTimeout object inside of the function it calls to run. If geared to loop, it will keep firing at the interval unless you call clearTimeout(). If you want something to happen one time after some seconds Then use setTimeout... because it only executes one time when the interval is reached.

setTimeout(function() {
  console.log('Wait 3 seconds and I appear just once');
}, 3000);

setInterval(expression, timeout); runs the code/function repeatedly, with the length of the timeout between each repeat. It is a time interval based code execution method that has the native ability to repeatedly run specified script when the interval is reached. It should not be nested into its callback function by the script author to make it loop, since it loops by default. It will keep firing at the interval unless you call clearInterval(). If you want to loop code for animations or clocks Then use setInterval.

setInterval(function() {
  console.log('Every 3 seconds I appear on your console');
}, 3000)