Bit banging a serial to parallel shift register to drive a 7 segment display is very slow.

[chrisidle]

I am trying to write a display multiplexer by bit banging a 16 bit register to an external serial to parallel shift register. The issue is that the code is running very slowly! I have tried to see how fast the device will run by writing a very simple while loop which sets and clears a pin (while(true){digitalWrite(D6,0);digitalWrite(D6,1):}) On the Espurino this code produces a square wave of about 4kHz. The same code running on a MicroBit using Make Code produces a square wave of about 300kHz. If i flash the Micro Bit with Espurino and run the code i get 4kHz. The issue must therefore be the Espurino code rather than the hardware. Does anyone have any thoughts or ideas as to how i can improve the performance. Thanks

[gfwilliams]

Hi,

As I understand it, Microsoft Make:code actually does some compilation on the code you write, so it's going to be a bit faster than running the JS which is interpreted from the text on the fly. Espruino has a bunch of options though...

• Use the E.shiftOut function which basically bit-bangs for you: https://www.espruino.com/Reference#l__global_shiftOut
• Just use SPI - hardware or even software SPI should be pretty quick and you can run it on whatever pins you want. You just convert the 16 bit number into 2 8 bit numbers which you can do with new Uint16Array([number]).buffer
• JIT-compile a JavaScript function - but that isn't in micro:bit builds, it's only official boards: https://www.espruino.com/JIT
• Use the compiler to compile C code: https://www.espruino.com/Compilation (again, only official boards)

There are other options too, but those are going to be the easiest/best.

[fanoush]

Which version of Microbit it is? The old V1 is nrf51822 and has small RAM and flash size so not much can be enabled there but nowadays the 'normal' Microbit is V2 which is nrf52833 and there both JIT and the inline C compiler could be used. However for inline C you need to run your own server on local machine and JIT is currently not enabled. Is there a reason to not enable JIT here by default?https://github.com/espruino/Espruino/blob/a454207e03449be32c06bde013d4b0439813eba5/boards/MICROBIT2.py#L43

EDIT: with JIT enabled it builds as is with patch below and everything fits. I will test with real device. And BTW we already have 128k RAM enabled so some board comments/values are wrong(?)

diff --git a/boards/MICROBIT2.py b/boards/MICROBIT2.py
index d0e428427..8a4418874 100644
--- a/boards/MICROBIT2.py
+++ b/boards/MICROBIT2.py
@@ -17,7 +17,6 @@ import pinutils;

 # TODO:
 # Move to SDK17 with proper nRF52833 support
-#   - expand RAM to 128k
 # Proper event handling for accelerometer/etc
 # Functions for sound

@@ -39,7 +38,8 @@ info = {
 #     'NET',
      'GRAPHICS',
      'NEOPIXEL',
-     'TENSORFLOW'
+     'TENSORFLOW',
+    'JIT'
    ],
    'makefile' : [
      'DEFINES += -DCONFIG_GPIO_AS_PINRESET', # Allow the reset pin to work
@@ -59,9 +59,9 @@ chip = {
   'part' : "NRF52832", # actually 52833 but we're using SDK12 for this at the moment, and it doesn't support it
   'family' : "NRF52",
   'package' : "QFN48",
-  'ram' : 64,
+  'ram' : 128, # increased by LD_SRAM_SIZE=0x20000 above
   'flash' : 512,
-  'speed' : 64, # TODO: actually 128k
+  'speed' : 64,
   'usart' : 1,
   'spi' : 1,
   'i2c' : 1,

[gfwilliams]

To be fair it's probably just in the DKs because they're very useful for me to test on. I don't mind adding JIT though if you wanted to do a PR - especially on Micro:bit which is intended for education.

But interesting about the RAM field - it may not actually have any noticeable effect then.

[fanoush]

I don't mind adding JIT though if you wanted to do a PR - especially on Micro:bit which is intended for education.

OK, will test the patch above on real device and will make a PR including the JIT. I forgot to update 'ram' value in the initial patch with linker file and it worked without it. But when checking now it does affect the #define RAM_TOTAL in gen/platform_config.h so there are some bits of code affected https://github.com/search?q=repo%3Aespruino%2FEspruino%20RAM_TOTAL&type=code

[fanoush]

ok, it works, PR here espruino/Espruino#2639, in last commit I have also synced board file with other nrf52 boards regarding MTU size, centrals and other stuff, it works for me and shouldn't hurt? I was also testing led scrolling text and found a (documentation) bug espruino/EspruinoDocs#750

Also I noticed one feature/bug, microbit v2 has reset button on the back and by holding it it should turn off red led and go to sleep mode as desctibed here https://microbit.org/get-started/features/overview/
It doesn't work with espruino firmware, led goes off after holding the button but then goes back on. not sure how we are supposed to support this.

EDIT: there is something here https://support.microbit.org/support/solutions/articles/19000120358-how-do-i-power-off-or-put-the-micro-bit-to-sleep- and here https://tech.microbit.org/software/spec-power-management/ but I still don't see what is needed to let it stay 'off' when button is held and released when led goes off.

[gfwilliams]

Thanks! Just merged...

I still don't see what is needed

Maybe we have to have something that checks a pin state at boot time and goes to sleep depending on the state?

If I'm honest, I never really hear much about Espruino for micro:bit usage so I'm not inclined to spend too much time on it. I mean, we haven't even had a response from the original poster (when software SPI/shiftOut probably would have worked great).

[fanoush]

If I'm honest, I never really hear much about Espruino for micro:bit usage so I'm not inclined to spend too much time on it.

Yes, I am a bit surprised people don't buy it more as generic nrf52 board since the price of V2 is relatively low and the hardware is interesting and 52833 could even do long range. There is even segger j-link https://www.segger.com/products/debug-probes/j-link/models/other-j-links/bbc-microbit-j-link-upgrade/ for the debugger interface chip so can be used as nice devboard when one likes nordic/segger tools. EDIT: sadly only the 2.0 board with KL27 is supported

I don't use it too as I have lot of other stuff but maybe I should look more into it.

Maybe we have to have something that checks a pin state at boot time and goes to sleep depending on the state?

looks like the interface MCU (KL27 in 2.0 or nrf52833 in 2.20 or nrf52820 in 2.21) acts as i2c slave with commands described here
https://github.com/microbit-foundation/spec-i2c-protocol/blob/main/spec/index.md
so we can turn the led off (because espruino is by default in deep sleep anyway) as per this
https://tech.microbit.org/software/spec-power-management/#power-mode-transitions
"Target MCU sends the I2C command to the Interface MCU to set the power-led-sleep-state to OFF"

however it also says that the target MCU is halted while button is pressed and reset after releasing button
https://tech.microbit.org/software/spec-power-management/#waking-up-the-interface-mcu
The Interface MCU must halt the Target MCU while the button is pressed down
...
When the button is released the Interface MCU must reset the Target MCU

and what is interesting is that according to schematics https://github.com/microbit-foundation/microbit-v2-hardware the reset pin 18 of the 52833 is not connected! so the interface MCU probably uses SWD to reset it. So this cannot be turned off without rebuilding the Daplink firmware for the interface chip. I managed to press the button by mistake few times so would actually prefer to use it as ordinary button as one can reset the device by simply disconnecting power.