Service locking

[sandeepmistry]

Service locking

[sandeepmistry]

@bettse I'm starting to run into code size limits as well, while working on adding unauthenticated security.(this is a fairly ambitious Arduino library).

I wasn't planning to add OTP, but it should be pretty straight forward, the diff is pretty much

-            0x06,0x06,0xf0,0x00,0x03,0x15,0x39,\
+            0x06,0x06,0xf0,0x00,0x83,0x84,0xb1,\

So in nRF8001.cpp - send CRC:

data.buffer[4] = 0x03;

needs to be changed to:

data.buffer[4] = 0x83;

The other change is not to send run/calculate setup messages, but still calculate the pipe numbers.
We'll need to experiment if splitting the setup message part to a new method and not calling in in OTP mode will actually result in code savings.

Also, this is pretty dangerous for the average Arduino user, if you get it wrong, you can't change the OTP (you can still send memory resident setup data on power up). We'll have to provide some action the user needs to take, for example Nordic's generated services_lock.h requires you to remove a #error.

I'm leaning towards looking into reduce code size another way first, maybe there is stuff in the utilities folder (imported from the Nordic nRF8001 SDK) that can be removed or reworked? Also, reworking other parts of the library, or pre-calculating all setup messages at build time ... thoughts?

[bettse]

Yeah, certainly a dangerous thing that should require non-trivial confirmation by the developer to execute. If there are code savings that could be made without that, it seems like that would be the safer path.

Its nice to know that, if it comes to it, the changes for using the OTP are already known.