Search results for:

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

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!

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

@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.

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.

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.

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.

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.

iOS will automatically set MTU to 185 bytes. I think max. 200 bytes is a good size. This would be very handy if we are using the HTTP Proxy example.

Apart from that, is it correct that we would have to switch SDK to a newer version to support bigger MTU sizes? I feel like Espruino still runs on SDK 12.

Long writes have a big disadvantage compared to a bigger MTU:

1. A long write is a normal write distributed over multiple connection intervals which is a waste of time if you have long connection intervals
   
2. They need to be supported by a given characteristic and do not apply to the whole device
   
   

If both connected devices are BLE 4.2 or higher I'd always prefer to use a bigger MTU size. This is way faster and applies to all service/characteristics which is quite handy.

Yeah no, I still want to have a little space for my code ;) Thanks!

I see. What I did was to add the possibility to modify the MTU size which is something I need. I still need some storage, but not that much in general so reducing the flash memory sounds like a good option to me.

So:

'address' : ((118 - 10 - 10) * 4096), 
'pages' : 10 - 10,
'flash_available' : 512 - ((31 + 8 + 2 + 10)*4) - 10

???

Not sure how you mean it.

Hi,

I tried to modify (and add) functionality to the espruino bluetooth library. Then I tried to compile the new firmware, but the "check_elf_size.py" script exited with the above error. I guess I have to update the 'saved_code' segment of the chip inside the board definition of the MDBT42Q module. However, I'm a bit puzzled on how exactly I have to do that. Can someone help me?

Thanks!

Oh good to know. Thanks for the tip!

Hi,

I'm trying to read a passive NFC tag with the Thingy:52. However the NFCrx event seems to not work. I implemented the following methods based on the API ref:

NRF.on('NFCon', () => { console.log("Tag detected!"); });
NRF.on('NFCrx', (arr) => {
  Serial1.println(arr);
});

Did I miss something, or is there a different way to do it?

Thanks!

Ok I'll give it a try! Thanks.

Hi,

I have a pre-programmed DFU package from another mdbt42q module i made. I used the standard s132 bootloader/sd for it. I would like to run this code on the espruino mdbt42q module breakout, but I am not able to change the bootloader so it accepts the DFU application package.
Is there any way on how to do that? Or will I need to attach the SEGGER and flash it manually?

Thanks!

Okay great info thanks!

I'm afraid you can't. As far as I've seen iOS just caches the services and there's not that much that can be done about it - you just need to reboot the phone, or use an Android phone which won't cache them.

The sig has a gatt value called "Services Chagned" if this is set to true, the iPhone will reinit the cache. You might want to consider this for the future, I know nordic provides this falg to be set. https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.characteristic.gatt.service_changed.xml

It seems like your guess with the power was correct. I was powering it over the 3V line of my TTL converter, switching to 5V fixed the issue of rebooting.

A question arises for me though now. Will the NRF switch back to low power mode or do I have to trigger this myself then?
And how do I set the services changed flag so iOS is triggering a rescan of the characteristics and services instead of chaching them?

Thanks already!

Hi everyone,

I'm very new to the Espruino platform and I got myself the above mentioned module, beacuse I want to create a very basic Bluetooth application. The module shall be a peripheral exposing the battery service and one custom service which contains two characteristics.

I tried to use

NRF.setServices

via the NRF object and then flashed it onto the module via Serial, but it looks like the moment the code is activated the module is restarting several times and then no change to the software is visible. I guess I made a simple mistake, but I couldn't find a good full example explaining the way Bluetooth works on this platform.

Can anyone help me out on this? I'm running firmware versio 2v00.136 btw.

Thanks for any help!