I think you're saying create a CONFIG_NVMC much like we have CONFIG_FCB and CONFIG_NFFS
Looking more into the config system "Configuration items are stored as key-value pairs, where both the key and the value are expected to be strings" Im not sure strings and config are a good fit as at least on the nrf devices Im familiar with we have a total of 32 32bit registers. So I think its more likely well have to have custom functions at the bsp/mcu layer much like exsiting nrf52_hw_id.c and then something that registers those into strings dynamically into the id package (again like hw_id) rather than waste all the memory to duplicate the data as a string... Maybe the bsp/mcu itself can just register a config like "bsp/serial", "bsp/custom1" instead of us trying to infinitely extend the id package for custom nvmic functions On Tue, Jun 12, 2018 at 3:47 AM marko kiiskila <ma...@runtime.io> wrote: > > > > 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. > >
