Most recent activity
-
Gps antenna maybe?
Oh, indeed, it is whole gps module, looks similar to e.g. this https://www.rhydolabz.com/wireless-gps-c-130_186/gps-smd-module-with-antennapa6h-p-1911.html
-
the 'puck' shape you can see in the video
I wonder what is the part shown in the video at 1:09 see also https://ibb.co/fHrDtHX
The other three that come next are button areas but what is the first one? -
Wow, this is great. Both the kickstarter and NodeConfEU badge. I hope this will make Espruino community grow. Not everyone enjoys tinkering with GPIO pins, LCDs and sensors as such, having usable smart watch on your hand that also runs javascript is something completely different. At least all attenders of NodeConfEU conference will surely agree.
And looks like the goal is almost reached after just a half day or less :-)
Congratulations! -
Yes default here is 20. My current numbers with getting exactly one notification per each 4096 based object is 1 minute and 18 seconds when sending 263228 bytes of application. When I remove explicit CRC check command before committing/executing each block I am down to 1 minute and 12 seconds (=3655 bytes/s). So 6 seconds for extra crc checks would not be so bad, however the notification also contains crc check so if I set it to receive one notification right after sending each whole 4096 block I get crc check for for free, without needing to send any explicit CALC_CHECKSUM command.
my changes in python flasher for secure dfu procedure are here
the output looks like thispi@raspberrypi:~/dsd6-ota-dfu-python $ ./dfu.py --secure -a CF:1E:35:40:14:92 -z espruino_2v04.187_dsd6_sdk12.zip ================================ == == == DFU Server == == == ================================ Sending file espruino_2v04.187_dsd6_sdk12_app.bin to CF:1E:35:40:14:92 Binary imge size: 263228 Binary CRC32: 1958051001 Connecting to CF:1E:35:40:14:92 Checking DFU State... Init packet successfully transfered MTU: 158, packet size: 62 Max object size: 4096, num objects: 65, offset: 0, total size: 263228 Progress: |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx| 100.0% Complete (263228 of 263228 bytes) Upload complete in 1 minutes and 12 seconds DFU Server doneAnd BTW, I finally understand relation between larger MTU and DLE - data length extension. They are not directly related. One can have larger MTU but no DLE. That is why iphone has MTU 158 or 185 so that it would fit in 6 or 7 classic 27 byte packets. So it is nice if there are larger packets via DLE and it fits in just one, but if DLE is not enabled, it is sent as set of packets hopefully in one connection interval.
That's great, thanks! Yeah, I thought usually ORIGIN+LENGTH should have contained all of RAM - didn't realise that they added heap on top. It's surprising the build didn't fail for me too.
It contains all of RAM, heap and stack is allocated inside it. You made RAM to be 0x9A48. But now when thinking about it, it worked fine because it was originally too small! It was below 0x8000=32KB before, but nrf52832 has 64KB which is 0x10000. In fact in normal espruino linker file here it is correct, 0x2c40+0xd3c0=0x10000. For bootloader it was previously 0x2C00+0x5380=0x7F80. So perhaps it was 32KB minus 0x80 space for bonding or some other info passed from application(?) Or is it intentional to have only 32KB for bootloader and leave the other 32KB for appliciation?
-
Just a followup, I have recompiled espruino bootloader with larger MTU and after doing it almost right I found you already did it in your increased_mtu branch too :-)
BTW here you increased ORIGIN but kept the length. However when fixing it it did not build as the data+heap overflowed so I had to build bootloader with -D__HEAP_SIZE=0, then it would link fine (by default it reserves 0x2000 for heap).
Anyway, the bootloader still works after changes, so I modified the secure dfu method of python flasher to send larger data packets and it somehow works. The secure DFU design is more complicated than legacy one and is slower - with legacy you send all data and in the end there is one crc check. With secure there is additional level - instead of whole firmware you do the same but in 4096 (page size) chunks called objects which is crc checked and commited/executed separately. Anyway even with this overhead and 62 byte data packets there is speedup. I can do 2.8KB/s which is slower than legacy but still faster than before. Interesting is that when I write larger packets than 62 the bootloader completely freezes and device needs reset. So maybe there is some limit around 64 bytes but did not find it. The only limits I founds is code here and it should be enough. I also tried to increase chunk count from 4 to 8 there but it does not help. The interesting piece handling the packet is here and I don't see why
p_req->req_lenbeing over 62 would be a problem an any code below it. Maybe stack overflow or some BLE issue? I don't have debug output from bootloader, how NRF debug log work, can it do serial or only some segger specific tracing stuff? Anyway, this is just FYI. No need for you to spend extra time on debugging this.BTW, thanks for mentioning the removed legacy dfu web bluetooth implementation, found it, that saves some time :-)
And as for "send 8 and wait for response" this is not hacky but normal(?) You initially send to bootloader how often you want notifications, with legacy you may even disable it completely. numbers over 10 are normal there. It it this and this but maybe you mean something different?
-
I will put up latest flasher code in the evening
changes here
But maybe I can call REPORT_RECEIVED_IMAGE_SIZE already after sending first packet.
That idea worked fine and is much faster than recovering later after sending 15 long packets and not receiving notification :-)
I guess next time I can try to put secure DFU there too and try with SDK12 based espruino. As for bootloader changes hopefully it will be just changing this to 244 and possibly also NRF_BLE_MAX_MTU_SIZE definition few lines below to 247.
-
As for simple BLE implementation over gatttool, yes, everything is there, DFU procedure needs all basic features I guess and it works. pexpect python module makes it very easy, not sure what would be best in C for spawning process and pattern matching its output. So far gatttool just works when scripted like that however one peculiarity is that commands (like 'characteristics' that lists all of them) run asynchronously over prompt so it is a bit harder to match where the output ends as you get the prompt result [xxx][LE]> immediately and also each output line just overwrites the prompt so basically each line of output data is prefixed by prompt with some control and \r characters. So you cannot get all command output simply by waiting for next prompt and taking everything above it. So e.g. with 'characteristics' I simply have 3 seconds timeout to get the list and hope I got all of it. Other commands have specific string output pattern to match (receiving notification, MTU negotiation) so that is not an issue. Also you can miss something when waiting for two things - e.g. when pattern matching current command output and notification comes first instead. Anyway if there is easy pexpect like library for C it should be doable and not that hard.
-
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/
-
just a followup, I was trying to improve DFU speed and at least with adafruit bootloader (where the MTU can be already negotiated at 247 without my changes) it was really matter of just increasing length of characteristics here from 20 to 244 and recompile. Then flashing 150KB zip with my python dfu flashing code took 32 seconds instead of 2 minutes and 6 seconds (when writing 244 bytes instead of 20). And it is even backward compatible with nrfconnect - at the slower speed, it still writes just 20 bytes to the characteristics.
BTW is there any way to discover characteristics length remotely? I can't find it anywhere in nrfconnect, maybe that is not part of the information that can be discovered about services/characteristics?
This can be done over existing Bluetooth LE without putting anything inside? the 433 transmitter could be attached to something else (let's say Pi Zero W or cheap nrf52 board) that sits at home and connects to the watch over BLE. Seems easier to me than breaking the watch.