• If I keep DFU PACKET characteristics length in bootloader at 20, can longer MTU help me?

    don't think so :( As I understand it you can send/receive >1 packet per connection interval, but that can be done already without the increased MTU.

    If I increase the length of the characteristics (to e.g 256) will this be backward compatible when MTU is negotiated to be standard 23?

    I think in the bootloader it'll be fine. AFAIK In the firmware updater you'll have to check the MTU somehow and then sent the right size - maybe try it and see if it fails?

    In theory more packets per conenction interval can make it faster too

    Yeah, I'm not sure. I sort of assumed if you chucked a load of writes at it, it'd do what it could. Definitely on Espruino's side with the UART is does seem you can queue up more than one write per connection interval.

    I even don't know how to make connection interval shorter from linux side

    I don't know if you can, but it's trivial to do from the device side just by changing some connection parameters - see the NRF.setConnectionInterval implementation

    I got python DFU flasher working in linux on the Raspberry Pi via builtin BLE but the speed is 1.5KB/s so wondering how this can be improved.

    Nice! I didn't even realise that existed. I have a super hacky implementation based on the Node.js secure DFU implementation and I get 3kB/sec on linux now. I do that by issuing 8 write without responses at a time and then a CRC check (which I ignore the response of). The CRC check (which sends a notification) helps to 'sync' the writes - I guess you might be able to do something similar.

    I like the gatttool hack - makes me wonder if that couldn't be used to get a nice simple BLE implementation for Espruino linux builds.

    I was trying to improve DFU speed and at least with adafruit bootloader

    That's awesome! It'd be great to get that into the standard Espruino bootloader.

    So you still had to change your firmware uploader to use the larger packet sizes to take advantage of it, but otherwise that was it?

    BTW is there any way to discover characteristics length remotely?

    I don't know of anything, short of trying a write (with response?) and seeing if it fails?

    It seems that the connection starts off at 23 bytes and then there's a negotiation. At least on Android there's an event that is created when the MTU changes - but no idea how you'd see that with gatttool :)

  • So you still had to change your firmware uploader to use the larger packet sizes to take advantage of it, but otherwise that was it?

    Yes, exactly. However when I simply used MTU-3 for packet size it failed with unmodifed adafruit bootloader as it only accepts 20 bytes even when it negotiates MTU247. And I figure out that it doesn't work only after first notification that reports 0 bytes written so then I scale packet size down to 20 and restart from zero.

    So if it really cannot be determined remotely in advance I guess I need to flag it somewhere else.

    I will put up latest flasher code in the evening but here is that point in older version without this feature when I miss notification and get how many bytes are written and resume. So if I am still at zero offset there after sending first batch of long packets I now scale packet size back. But maybe I can call REPORT_RECEIVED_IMAGE_SIZE already after sending first packet.

    EDIT: I took just legacy DFU procedure into my desay/adafruit flasher but I hope same could be done for secure one too and eventually plan to try with SDK12 espruino bootloader too. BTW I now have pretty good understanding of legacy DFU procedure so next thing I'll try is adding legacy DFU to existing web bluetooth/javascript/node secure procedure you have there or the one which is here https://github.com/thegecko/web-bluetoot­h-dfu/


Avatar for Gordon @Gordon started