Possible to enable nRF SPI2 on puck.js v2?

Looking in targets/nrf5x/jshardware.c I found this comment:

SPI0 / TWI0 -> Espruino's SPI1 (only nRF52 - not enough flash on 51)
SPI1 / TWI1 -> Espruino's I2C1
SPI2 -> free

This seems to indicate that it should be possible to add support for a second hardware SPI exposed as Espruinos SPI2? Or am I missing something that makes that more work then making sure the related functions in targets/nrf5x/jshardware.c handles SPI2 in addition to SPI0?

No, you're right. SPI2 support could be added by modifying jshardware to use either SPI port.

However what use case do you have that needs this? Software SPI actually works pretty quickly, especially in write-only mode. Since NRF52 hardware SPI is limited to 8Mbps you're not going to be seeing massive speed gains by going with hardware.

It's related to a previous topic, http://forum.espruino.com/conversations/358892/. We sort of hit the limitations of having the IMU connected via I2C, where we can't read the data fast enough from the FIFO. So we'd like to try with an IMU connected via SPI instead.

How many samples/second are you trying to get? Puck.js's I2C to the accelerometer should be able to push at least 400kBits/sec I'd have thought.

Even at 400kHz that's maybe 20,000 6 byte samples/second if you're using I2C half the time.

Do you have your code online somewhere? I could take a look and see if there seems to be anywhere obvious we could speed things up.

Right now Espruino's I2C isn't asynchronous, but potentially it would be possible to use it by DMA so you can be reading from the accelerometer at the same time as writing to flash

However, even if you decided to use software SPI you're still going to be able to get up to 1Mbps out of the sensor, maybe more.

I'm looking into getting the code online sooner rather than later, since the end goal is to see if the FIFO changed could be upstreamed.

In the meantime, here's the code snippet that empties the FIFO.

  JsSysTime time3 = jshGetSystemTime();
  // Read samplesToRead * 6 (3 words gyro + 3 words accel) * 2 (two bytes per word) bytes
  unsigned char fifo_read_addr[1];
  fifo_read_addr[0] = 0x3e;
  jsi2cWrite(&i2cAccel, ACCEL_ADDR, 1, fifo_read_addr, false);
  jsi2cRead(&i2cAccel, ACCEL_ADDR, samplesToRead*6*2, (unsigned char *)dst, true);

  JsSysTime time4 = jshGetSystemTime();

If I read e.g. 104 samples, so 1248 bytes of data, time4-time3 is approximately 150 ms. This seems like a lot slower then expected then, since it's only ~66kBits/s.

And now the code is available on GitHub: https://github.com/erikboto/Espruino/tree/imu-fifo

Basically we want to be able to sample as fast as possible. Currently we can do 416 Hz with the built in IMU, if we try 833 Hz the FIFO will fill faster than we can empty it and will end up overflowing after just a short while.

Ok, thanks! Hmm - that does seem a bit on the slow side. Are you definitely compiling with RELEASE=1?

You could definitely switch over to using the hardware I2C (currently it's software) and get up to 400kHz out of it, which should help you out a bunch

First, let me just thank you for being so helpful!

I'm using this to build, so it's a release build:

DFU_UPDATE_BUILD=1 BOARD=PUCKJS RELEASE=1 make

Oh, I didn't realize it's using software I2C! Switching over to HW I2C should just be a matter of using the jshI2C* functions instead of jsi2c*, after initializing using jshI2CSetup(EV_I2C1,...) right? I still have much to learn here I see :)

Ok, great - yes, your build looks fine.

Yes, you're spot on - those should be the only real changes you need.

Just checking to update you on that moving to HW I2C made a huge difference. Getting approx 350kbit/s read speed when emptying the buffer now.

Again, thanks a lot for your help!

That's great! Thanks for letting me know!