Most recent activity
-
Is there a way to force the buffers to immediately flush?
Sometimes I want to send just a specific chunk of data as a uart update.
On the other end, I have a function called from an on data callback that adds another temporary listener to combine the output of multiple packets into one buffer. The issue is that the initial packet sent to the first callback is still in the buffer by the time I run the code, so it becomes part of the start of the combined buffer.
There’s a workaround I’ve found to wrap it in a timeout of 0, but that’s not the cleanest to deal with
-
In the Bluetooth.on callback, would it be safe to assume that the data received event will be called in order of being received?
If I have a callback that takes longer, will the firmware wait to call the callback for the next chunk of data, or is there a chance that multiple instances of the same callback could be running at the same time?
If I sent 572 bytes of data in 28 characteristic updates, would it cache all 28 updates, or would you risk having some lost?
Sorry for all the questions.
-
What I would like to do is have a function I call that allows me to attach my own handler to the BLE UART RX/TX and basically disable the espruino interface until the device disconnects.
Is this possible?
Being able to send JavaScript over UART is convenient, but it’s not ideal if you’re sending binary data back and forth.
I’ve somewhat implemented what I want, but it doesn’t actually use the UART, but rather alternative characteristics that behave similarly
Ideally I would just keep UART and add my two additional characteristics with advertisement, but as things are now, I have to change out the services
-
-
-
Well, I was referring to the BLE UART, not a physical serial connection.
Flushing the transmit buffer isn’t a huge deal, I currently just set a timeout, but if there was a way to pause js execution until the last BLE UART packet has been sent, it could definitely simplify things and eliminate guessing.
I only really have one situation where I don’t want the buffer combined with previous repl output, but that’s just when I move it to Serial1 and send a string to let other end know I’m ready.
The receive buffer has the workaround mentioned above, although one thing that might be helpful is a way to tell espruino to not fire the next on(data) event until so many bytes have been received, with the option of a timeout.
Maybe something like this to receive 500 bytes with a max timeout of 100ms between rx events Bluetooth.receive(500, 100, dataReceived, rxTimeout)
My project might not be typical, but I chose to forego the REPL console on Bluetooth for the additional speed of sending data.
An example of an exchange is
-> 0x03 0x01
<- 0x03 0x01
-> (572 bytes)
<- 0x03 0x01