database - Embedded C data storage module design -
i'm in process of designing embedded c data storage module. included files/modules want access "shared" system-wide data. multiple tasks aggregate dozens of inputs (gpio, can, i2c/spi/ssp data, etc) , stores values off using api. then, other tasks can access data safely through api. system embedded app rtos, mutexes used protect data. these ideas used regardless of implementation
i've designed in past, , i'm trying improve upon it. i'm halfway through new implementation , i'm running few hiccups , benefit fresh perspective.
quick rundown of requirements of module:
the question how go designing this? enumerations, structures, accessors, macros, etc? i'm not looking code here, discussing general overall design ideas. if there's solution on internet addresses these sorts of things, perhaps link sufficient.
i've been in situation couple times myself. every time i've ended "rolling own", , don't suffer not invented here (nih) syndrome. space, processing turnaround time or reliability/recoverability requirements make least painful path.
so, rather writing great american novel on topic, i'll throw out thoughts here, question pretty broad (but thank @ least forming question & providing background).
is c++ on table? inline functions, templates, , of boost libraries might useful here. i'm guessing straight-up c.
if you're using c99, can @ least use inline functions, step above macros when comes type safety.
you might want think using several mutexes protect different parts of data; though updates quick, might want break data sections (e.g. configuration data, init data, error logging data, trace data, etc.) , give each own mutex, reducing funnel/choke points.
you consider making access data go through server task. reads & writes go through api communicates server task. server tasks pulls reads & write requests in order queue, handles them writing ram mirror, sending responses if needed (at least read requests), , buffers data nvm in background, if necessary. sounds heavyweight compared simple mutexes has advantages in use cases. don't know enough application know if possibility.
one thing say, idea of getting/setting tag (e.g. maybe list of enums config_data, address_data, etc.) huge step forward directly addressing data (e.g. "give me 256 bytes @ address ox42000). i've seen many many shops suffer great pain when whole physical-addressing scheme breaks down & need re-factor / re-design. try keep "what" decoupled "how" - clients shouldn't have know or care stuff stored, how big is, etc. (you might know this, sorry if so, see time...)
one last thing. mentioned mutexes. beware of priority inversion... can make "quick accesses" take long time in cases. kernel mutex implementations allow account this, it's not enabled default. again, sorry if old news...
Comments
Post a Comment