both places you call tap then you can see that you can definitely get it into a position where you're calling .tap before the last one has finished, which will cause an error:
[tap]
[tap done]
Starting kbTimer
Clearing kbTimer until finished typing
[tap]
e.state: true
e.time: 1538038837.98822593688
e.lastTime: 1538038837.25543785095
duration: 0.73278808593
[tap done]
Starting kbTimer
Clearing kbTimer until finished typing
[tap]
e.state: false
e.time: 1538038838.10324668884
e.lastTime: 1538038837.98822593688
duration: 0.11502075195
[tap]
[Short press]
Uncaught Error: BLE HID already sending
at line 1 col 55
NRF.sendHIDReport([0,0,0,0,0,0,0,0],funcĀtion(){a&&a()})
^
in function called from system
[tap done]
However, no BLE error code 12292.
What I'm pretty sure is happening is a few things are all conspiring against you:
After some inactivity, Espruino will now enter a low-bandwidth, low-power mode. (can be fixed with NRF.setConnectionInterval as that post you linked shows
First thing you do after a button press is print a load of stuff over Bluetooth. This uses up most of the available TX slots (apart from one for HID)
The HID report is sent - all TX slots are used up, but that's fine
Not all of the TX packets get sent the next time (possibly because of negotiation to exit the low power mode)
Espruino gets notified that TX packets were sent - it has no way of knowing which ones, so it assumes HID has been sent and tells your code.
Your code sends another HID packet, but it fails this time because there are no free TX slots
Basically there's not much I can do about it apart from to only send one TX packet at a time instead of 5, reducing Espruino's TX speed by a factor of 5 - so that is what I've done. Hopefully if you try a cutting edge build now it'll be fixed.
I don't think on the whole people will notice too much as it's really the RX speed that's the killer.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Ok, just tried this, with the
console.log
on Serial... If you try:both places you call tap then you can see that you can definitely get it into a position where you're calling
.tap
before the last one has finished, which will cause an error:However, no
BLE error code 12292
.What I'm pretty sure is happening is a few things are all conspiring against you:
NRF.setConnectionInterval
as that post you linked showsBasically there's not much I can do about it apart from to only send one TX packet at a time instead of 5, reducing Espruino's TX speed by a factor of 5 - so that is what I've done. Hopefully if you try a cutting edge build now it'll be fixed.
I don't think on the whole people will notice too much as it's really the RX speed that's the killer.