Possible to enable nRF SPI2 on puck.js v2?

[espruino-discuss]

Posted at 2021-01-27 by erikboto

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?

[gfwilliams]

Posted at 2021-01-27 by @gfwilliams

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.

[espruino-discuss]

Posted at 2021-01-27 by erikboto

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.

[gfwilliams]

Posted at 2021-01-27 by @gfwilliams

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.

[espruino-discuss]

Posted at 2021-01-27 by erikboto

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.

[espruino-discuss]

Posted at 2021-01-27 by erikboto

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

[espruino-discuss]

Posted at 2021-01-27 by erikboto

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.

[gfwilliams]

Posted at 2021-01-27 by @gfwilliams

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

[espruino-discuss]

Posted at 2021-01-27 by erikboto

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 :)

[gfwilliams]

Posted at 2021-01-28 by @gfwilliams

Ok, great - yes, your build looks fine.

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

[espruino-discuss]

Posted at 2021-01-29 by erikboto

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!

[gfwilliams]

Posted at 2021-01-29 by @gfwilliams

That's great! Thanks for letting me know!