binux

Most recent activity

• CODE AND STORAGE OVERLAP while building firmware for NRF52

  @binux started

  • 54 comments
  • 17,812 views

  @fanoush replied
• Issues compiling Espruino from source

  @binux started

  • 2 comments
  • 1,246 views

  @binux replied
• Issues compiling Espruino from source

  in Puck.js, Pixl.js and MDBT42 • 4 years, 10 months

  

  Oh, I see, I forgot to set RELEASE=1. Now it works!

• Issues compiling Espruino from source

  in Puck.js, Pixl.js and MDBT42 • 4 years, 10 months

  

  Hi,

  I wanted to build the release 2.04 via the Espruino project make script, but I got the following error:

  user@bash: ~/Espruino$ BOARD=MDBT42Q make
  python scripts/check_elf_size.py MDBT42Q espruino_2v04_mdbt42q.elf
  Testing espruino_2v04_mdbt42q.elf for MDBT42Q
  STORAGE: 442368 -> 483328
  CODE: 126976 -> 467548
  CODE AND STORAGE OVERLAP
  make: *** [espruino_2v04_mdbt42q.app_hex] Error 1
  

  I made a git clone and switched to the release tag RELEASE_2V04. Am I doing something wrong?
  I remember it was working properly.

  Thanks!

• CODE AND STORAGE OVERLAP while building firmware for NRF52

  in General • 5 years, 2 months

  

  That's great! However the firmware builder seems to be offline.

• CODE AND STORAGE OVERLAP while building firmware for NRF52

  in General • 5 years, 2 months

  

  @Gordon why not have different firmware versions? Some people may not need more than 23 bytes, but some others will need it. You could have a BLE4 and a BLE5 firmware, with different features active.

• CODE AND STORAGE OVERLAP while building firmware for NRF52

  in General • 5 years, 2 months

  

  Even so, I think it would be worth losing a bit of RAM permanently for - maybe not to max out the MTU, but at least to go for something significantly higher than 20.

  I second that. It would allow more flexibility.

• CODE AND STORAGE OVERLAP while building firmware for NRF52

  in General • 5 years, 2 months

  

  I'll give it another spin. Maybe I also made a mistake in the implementation. Whenever I set a bigger MTU size of 23 the SDK returned me an error 7 which is INVALID_PARAM. In the docs they say it's due to the fact that the maximum MTU size is smaller than the requested one, but I did update all the maximum MTU size definitions.

• CODE AND STORAGE OVERLAP while building firmware for NRF52

  in General • 5 years, 2 months

  

  Yeah long writes were the go-to feature in BLE 4.0 and 4.1, since bigger MTU sizes were not available before 4.2.

  You could also combine a bigger MTU with a long write enabling you sizes up to kilobytes which is huge for a LE transport. For my special use-case bigger MTUs however would be more appealing because it would reduce the lag between a http request and its response.

• CODE AND STORAGE OVERLAP while building firmware for NRF52

  in General • 5 years, 2 months

  

  They do automatically negotiate. I think though that the max MTU has to be set before initializing the softdevice so I'm unsure if you are able to change this in runtime. That's why the

  NRF.requestMTU(byte size)
  

  function would be way more useful.