-
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-bluetooth-dfu/
You are reading a single comment by @fanoush and its replies.
Click here to read the full conversation.
fanoush
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.
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?
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 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
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.
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?
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 :)