> On Jun 12, 2018, at 8:24 AM, Jacob Rosenthal <jakerosent...@gmail.com> wrote:
>
> I dig the config id package for what it has available, but several things
> puzzle me.
>
> Obviously I can fork this and make all these changes for my project, but
> just feeling out how people are using this.
>
> I tend to think of the id package kind of replacing or being the source of
> truth for Device Information service.
>
> As such I feel like were missing a model/style and manufacturer name value
> in here.
I think that’s true, those are often used. It started with hwid, and as people
don’t want to use that as device id for their stuff, then the serial number.
>
> Also the serial puzzles me, Is anyone using this? It seems odd to me that
> youd have user settable serial number.. Isnt it more likley wed burn a
> serial into user registers on the micro? And on top of that its holding
> 64byte array by default empty.
People are using it. Whether it takes space in RAM or not could be made
configurable though.
What is missing is a more fine-grained access control,
which would allow people access to specific operations, e.g. allow
config read but prevent config writes. I would have needed this already,
but haven’t had time to think what it should look like :)
Updating serial number makes no sense, but you need to be able to set
it at the factory.
>
> What if we expose id/serial to the bsp definition like we do in say
> nrf52_hw_id.c and let the user populate it however they like, most likely
> from (in this nordic case) UICR->CUSTOMER
I would recommend writing a new backend to config, which reads data
from UICR. As you might’ve noticed, you can specify multiple sources
as a source of config. I have not verified that all the right APIs are exposed
by the sys/config to allow config backend to live in a different package,
but the intent was that you’d be able to make part of config anywhere.
EEPROM has most often been brought up.
