new UART characteristic write for each new line in forEach loop

I am trying to send a new line of data over UART BLE for each iteration of the following command that is sent to the device;

\x15\x03\x10require('Storage').list().fo­rEach(x=>Bluetooth.println(x)});\n\x10Bl­uetooth.println('END');\n

However, it gets concatenated together and sent as data in one write characteristic. I would like each iteration to be a separate (new) BLE write characteristic/notification. How could I do that so I get new data for each iteration of the loop?

It is unlikely to work the way you want. There is a MTU limit so data is split into 'random' packets. So you may not get complete line in one write/notification anyway due to that.
Guaranteed MTU is 21 bytes, anything above that depends on negotiation between two connected devices.

Can't you just add what you get to some string/buffer and then just parse and remove complete line(s) from beginning of that line by line?

@fanoush I had been doing that method originally (storing in string/buffer), but missing packets had became an issue that I wrestled with, so I wanted to assess whether I could venture down a "new line only" option for each write/notification.

Assuming that I could control/have a greater MTU size... would sending each iteration as a new write/notification be possible?

missing packets? that's very strange and should not happen. However you mean that you would really not mind missing complete lines from the output if it was sent line by line?

I don't know if there is something like Bluetooth.flush() or some character to write that would do it, maybe not. If not then splitting the loop so it goes to idle loop after each line could help. Like scheduling each write line via setTimeout

can you try something like

[1,2,3,4,5].forEach(d=>setTimeout(v=>pri­nt(v),0,d));

I did add Serial.flush() recently: https://www.espruino.com/Reference#l_Ser­ial_flush

So it's possible that doing Bluetooth.flush() may help too?

But really the UART in Espruino was designed specifically to avoid sending more packets than needed, so if you want fine-grained control it might be worth making your own characteristics

Thanks Gordon for the suggestions and clarification. I think the missing issue with my current implementation is the end carriage the UART in Espruino uses. If not mistaken, it’s simply >? I’ve noticed about 1/20 times it is absent in my stream of BLE characteristics so does the Espruino Web IDE implement a timeout to handle ? I’ve seen the 10 minute timeout for file transfers in the GitHub reposiTory, but haven’t deduced where in the code command terminals handled. For now, we send our own end carriage to signify the end of the message, but it is not foolproof (multiple characters that could be split if messages are chunked).

Ahh - no, > isn't the end carriage return.

Basically the REPL (the thing you can type JS into to execute it) is still on the UART.

So there's a prompt > and if you type 1+2 Espruino sends back:

1+2
=3
> 

If you use print then Espruino sends 0x08 (the delete key) to remove the >, prints your stuff, then sends > at the end of execution so the REPL still has the prompt at the end.

But if you use Bluetooth.println(x) as it seems you were doing, it avoids the REPL and just prints whatever you told it. Of course if some other code does a print you'll still see the > behaviour.

Depending on what you have planned you can move the console out the way with E.setConsole(null) but then debugging/uploading code gets hard

Gotcha, this makes sense. I have no reverted to the following:

\x03\x10require('Storage').list().forEac­h(x=>print(x)});\n

Which after execution, should always print > as a newline?

Which after execution, should always print > as a newline?

Yes, ish. Although in a way if you really do need to mark the end of what you're sending then just adding a print("END")/similar to the end of the line might be best.

The reason is, if you had some other code running in an event like setInterval then if that executed and printed something then that could print code before you received the >. Maybe if you have control of everything you can be sure that doesn't happen though