read accelerometer(LIS302DL) on STM32F4DISCOVERY ?

Is there a way to read acceleromter on STM32F4Discovery ?
I tried the example on http://www.espruino.com/LIS302DL,
but it always returns 0 for accx and accy on my board.
Checked it with Espruino version 1.45

What happens if you place your board is at an angle?

Just a thought, but could it be that an SPI1.setup with the correct mosi/mosi/sck pins is required?

• placing the board in an angle does not change anything.
  
• Adding a line
  SPI1.setup({sck:A5, miso:A6, mosi:A7});
  did not change anything.
  
• On any call to read register I get back [0,0];
  for(var i = 0;i < 63; i++){console.log(i,SPI1.send([i+128,0], E3));}
  
• Adding a wait between each call did not change anything
  
  

BTW, testing same with SPI2 gives same result. Is there any way to recognize connected SPI devices ?

2ndBTW, dump returns this(and a lot of other lines)
SPI1.setup({sck:A5, miso:A6, mosi:A7});
pinMode(A6,input_pullup);
pinMode(B14,input_pullup);
digitalWrite(E3,1);
Where is B14 comin from ?

I'm not sure about B14 - it's because pin state is read from the device itself, so if it's set that way at reset (could be JTAG) that's what it thinks it should be.

could you try shorting A6 to A7 and typing SPI1.send("Hello")? That would help to check if SPI is actually working or not.

• I used reset() and this command does not reset the hardware. So B14 was set by testing with SPI2 some time before.
  
• shorted A6 and A7 sent Hello and got back ="\x00\x00\x00\x00\x00"
  
• same with C2 and C3 and SPI2
  

Hmm. looks like an SPI problem on the F4 then. Sorry about that... Maybe you could try the 1v44 from the website? I did some SPI tweaks recently and I guess that could have somehow broken it.

I checked with 1v44 and it works fine.
There must have been a change between 16th of dec and 18th of dec.
Nightly build from 16th works fine, from 18th it doesn't.
Hope this helps
Juergen

Thanks - yes, that's a huge help. 18th dec is a while ago.

Just made a bug for it: https://github.com/espruino/Espruino/iss­ues/181

Just a thought, but does it work if you specify a baud rate?

SPI1.setup({sck:A5, miso:A6, mosi:A7,baud:100000});

I'm sorry, but the answer is no

I read the accelerometer on a STM32F4-DISCOVERY board.
I wanted to have 40 samples /s and I got 40 messages displayed on the Terminal screen, after accumulating data on a moving average process.

print("X= "+accx+" Y= "+accy+" Z= "+accz+" [16bit]" );

accv_start = setInterval(function () { print(getAcc()); }, 25); // 40 Hz
acc_stop = setInterval(function () { clearInterval(acc_start); print(console.log("ACC STOP"));}, 1000); // stop after a while

As expected the timer behavior was pretty deterministic , having a minimum timer resolution of 1 ms.
Now my question is :

Are you going to improve the timer's resolution , I say in example to 10 us, in a near future ?

The timer on the STM32F4 should be pretty good - to below 1us. The issue is the time that it takes to execute JavaScript code. Below 1ms, the JavaScript execution will be getting in the way of the timer.

You can however measure times using setWatch very accurately, as no JS is involved until after the event.

I'll be looking at increasing JS execution speed - there are many obvious ways to do it, but right now that is not actually a huge priority.

May it be that the new upgrade of version 1v51 introduced some bugs: with respect SPI and I2C programming ?

This works fine : Added Number.toFixed test056)

but this seems to haveSPI or I2C communications no longer working at leads on STm32F4Discovery.

Now use jshardware's SPI for SD filesystems - more multi platform.

Looking with a scope non signal is sent over the MOSI line, even clocks ar properly generated over the SCK line.
All serials are working fine.

Not sure I understand... So at that point, SPI stopped working - but it still sends clocks signals out?

How did it stop working - did you stop being able to receive data, or stop being able to send data?

I don't want to bother you with stupid problems, but…
something really unexpected is happening, at least on my STM32F4DISCOVERY board.

I checked on two different boards, the behavior was the same.
Then taking for grant a same board, I went back installing the past versions of Espruino.
When I installed version 1v41 the SPI behaved as expected.
Using later version I always got ZERO as output.
When I checked with the scope , seeing no data activity over theMISO , MOSI lines but correct clocks over the SCK line, I was using version 1v51.( my custom complilation )
The same wrong behavior happens with my backup versions: 1v48, 1v50.
I am going to look deeply at the code.
I noticed this behavior just now, because other functionalities gave no problems, so I proceeded installing new versions.

Is there a place in the code were I can easily and immediately check for ?

Of course the Javascript code was the same.
function onInit() {
SPI1.send([0x20,0b01000111], E3);
}

var avrx=0.0, avry=0.0;
function getAcc() {
var accx = SPI1.send([0xA9,0], E3)[1];
var accy = SPI1.send([0xAB,0], E3)[1];
if (accx>127) accx-=256;
if (accy>127) accy-=256;
avrx = 0.1*accx + 0.9*avrx;
avry = 0.1*accy + 0.9*avry;
console.log("X= "+avrx+" Y= "+avry);
}
onInit();

var t = setInterval(getAcc, 10);
// clearInterval(t);

X= 10.342832 Y= -1.9707
X= 10.308549 Y= -1.97363
X= 10.277694 Y= -2.076267
X= 10.249925 Y= -2.06864
X= 10.224932 Y= -2.061776
X= 10.302439 Y= -2.055598
X= 10.272195 Y= -2.050039
X= 10.244975 Y= -2.045035
X= 10.220478 Y= -2.140531
X= 10.29843 Y= -2.026478
X= 10.268587 Y= -2.02383
X= 10.241728 Y= -2.021447
X= 10.317555 Y= -2.019302
X= 10.2858 Y= -2.017372
X= 10.25722 Y= -2.015635
X= 10.331498 Y= -2.014071
X= 10.298348 Y= -2.012664
X= 10.268513 Y= -2.011398
X= 10.241662 Y= -2.010258
X= 10.217495 Y= -2.009232
X= 10.295746 Y= -2.008309

Do you ever call SPI1.setup({sck:..,mosi:...,miso...}) ?

On newer versions I guess it might not choose the right pins properly?

Same code.
Different behavior on two official Espruino versions. (STM32F4DISCOVERY)
1v41 OK
1v50 WRONG
I' ll have to check in detail the C code.
I am now going to check the I2C, too.
Any idea about what is going wrong ?

4 Attachments

Excuse me I noticed the wrong usage of pin E3.

Not working.
It must be a reason for that ?

_____ _ | |_ ___ ___ _ ||___ ___ | |_ -| . | _| | | | | . | ||| || |_|||_|_|

      |_| http://espruino.com  1v50 Copyright 2014 G.Williams

echo(0); X= 0 Y= 0 X= 0 Y= 0 X= 0 Y= 0 X= 0 Y= 0 X= 0 Y= 0
=undefined X= 0 Y= 0

function onInit() {   SPI1.setup({ sck: A5, miso: A6, mosi: A7 , cs:
E3, int1: E0, int2:E1 } );   SPI1.send([0x20,0b01000111], E3); }

 var avrx=0.0, avry=0.0; function getAcc() {   var accx =
SPI1.send([0xA9,0], E3)[1];   var accy = SPI1.send([0xAB,0], E3)[1];  
 if (accx>127) accx-=256;   if (accy>127) accy-=256;   avrx = 0.1*accx
+ 0.9*avrx;   avry = 0.1*accy + 0.9*avry;   console.log("X= "+avrx+" Y= "+avry);    } onInit();

var t = setInterval(getAcc, 10); // clearInterval(t);

SPI1.setup({ baud:400000,  sck: A5, miso: A6, mosi: A7 , cs: E3, int1: E0, int2:E1 } );

Nothing changed at all.

I looked at the C code of the two versions 1v41 and 1v51.
Everything seems oK.
However, you now manage the SPI port using an interrupt and putting the data into a buffer before returning to the Javascript caller code.
May it be that
either
the interrupt is not generated ? ( Even NVIC structure seems programmed OK )
or
data is put in a wrong way or position into the 4 byte buffers ?
( conversion from unsigned char to int. !!! )
May it be that something the Head and Tail pointers disagree and some garbage is returned back… ?
Another difference with respect the 1v41 version is that now before sending data you do not flush the receiving SPI shift register to disregard eventual garbage.

I was not able to see any errors, but it is evident that something must now go wrong .
The ultimate solution is to DEBUG at C code level, the differences among the versions 1v41 and 1v51 being now known.

STM32F4 DISCOVERY and Version 1v51
Data is sent and received but ZERO is got from the Javascript side.

function onInit() {
  SPI1.setup({ mode:0, sck: A5, miso: A6, mosi: A7, cs: E3 } );
  SPI1.send([0x20,0b01000111], E3);
  getAcc();
}

var avrx=0.0, avry=0.0;
function getAcc(){
  var accx = SPI1.send([0xA9,0], E3)[1];
  var accy = SPI1.send([0xAB,0], E3)[1];
  if (accx>127) accx-=256; 
  if (accy>127) accy-=256;
  avrx = 0.1*accx + 0.9*avrx;
  avry = 0.1*accy + 0.9*avry;
  console.log("X= "+accx+" Y= "+accy);
  
}
onInit();

1 Attachment

Thanks for doing that testing... I'll have to see what's up. The new irq-based code works fine on the Espruino board so I doubt it's anything very deep rooted in that. The strange thing is that 0s are being returned and not 255.

Really an hard to be logically fixed BUG.
The code is written properly.
I tested introducing inside the interrupt routine additional checks for the OVR or BSY flags but nothing changed.
I then thought about introducing a delay between reads in order to give the sensor enough time to compute results from a CS to the next , but nothing changed.
Interrupts are received in a proper way ( I measured 5 of them ) for the 1 write + 2 reads, but if ZERO is assigned instead of the first dummy 0x255 it "is likely" that this content is got from another SPIBuffer instead of the one addressed by the SPI port in use.
But looking at the code this cannot be…

Mah ???

Hmm. I don't get what changed. It's possible it's actually something on a more physical level - maybe the MISO pin is now not configured properly... I'll try and take a look at this...

Right, I just fixed this... The fix will be in 1v51.