Avatar for DanTheMan827


Member since Jul 2020 • Last active May 2023
  • 14 conversations

Most recent activity

  • Avatar for DanTheMan827

    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

  • Avatar for DanTheMan827

    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 Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    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.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    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

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    The shop says it doesn't include it, but isn't it part of the NRF52832 soc?

    I also noticed that the board script for the firmware includes the NFC module.

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    The script file for my project depends on a custom build of espruino, so I was wondering if there was a way I could just include the boot code with the espruino update itself and get both in one shot

    The puck.js Bluetooth update zip

  • in Puck.js, Pixl.js and MDBT42
    Avatar for DanTheMan827

    Is there any way to bundle a script with the Espruino update file?

    Ideally without clearing the entire storage with each update.