We have done some test on how fast we can receive data from a BLE service, which is around 6KB/sec and this is all fine. This test was fairly easy to make, as we could just turn op the number of packages we sent from the device to the Master Control Panel. However. As far as I recall, we can have 6 packets outstanding from the device to the client (and I guess that there is then multiple Ack's returned in a single packet). But what about the other way?
I'm wondering if it will be fast enough to update the firmware via a custom BLE service. I did a test with indication (which I guess corresponds to 1 outstanding packet) where I could reach a maximum of 1,2KB/sec. So the question is - can I assume that we can obtain the same speed and payload from the client to the device. Then we could probably update the firmware in just about 1 minute (60-80KB), assuming our firmware will never grow bigger than half of the available space. Currently it is only 20-30KB, so there's plenty of room. So we could upload all the pieces in the unused half of the flash, perform a checksum validation afterwards, and then flash the pieces into the program area.
We won't have any buttons on the device, so I'm a little unsure on whether it will be a good idea always to send out a magic packet on startup, in order to figure if we should enter firmware update mode or not. Well, we could probably also enter this mode via a BLE service as well - though it would mean that we would have to interrupt the service - which is maybe not nice behaviour.
Any better ideas ?
