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

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.

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

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?

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?

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

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.

Haha ^ ^

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

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__glo­bal_getTime

setInterval() requires a value in msec

http://www.espruino.com/Reference#l__glo­bal_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.

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

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

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|REA­D,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.

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)'?

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)