My project will have a lot of configuration data. It's designed to be very generic, but be able to be used in over 100 different locations and each location has site-specific configuration. The units need to be movable to any location without needing to be reconfigured (other than some dip switches)
So while not all the data will need to be loaded into RAM at the same time, I do need (ok, I want) to have it all stored in one file for ease of management.
So the amount of data is over the 4K EEPROM size, so it will need to be stored on the SD card, or the flash I put on the audio card. But most likely the SD card for a reason you will soon see. Now if that was the only requirement, We'd be done here. But it's not..
One of the my requirements is that the configuration file be human readable. This really throws a wrench in the mix. The reason for this is so that the file can easily be edited in the field if needed
So the challenge is now instead of just storing a struct, I have to have string names for everything. As if the amount of data wasn't big enough... Then I'd have to do the slow process of parsing it all. There really wouldn't be any quick access to any of the data.
I started looking at database and dictionary libraries. None of them really is what I need. My data consists of all kinds of types. My data isn't really rows of the same data so databases aren't really useful. A lot of the libraries are locked to a specific type or at least make it difficult to handle structs. I considered using JSON libraries, but that also seemed to suffer from similar issues. Most of my programming I do is php so I'm pretty spoiled with loose types.
Another factor is, at least in the beginning stages, is not locking myself into a fixed length. I would much prefer some sort of arbitrary key/value type setup that is not so rigid. I was hoping not to have to explicitly move each variable into RAM but I don't think there's going to be way around that.
In a former life I did PalmOS programming, so I considered a linked list sort of method Palm used in their PDB file types. This wouldn't lock me into a fixed length, but also isn't human editable.
Other than the writing on the wall of having to make some compromises, anyone have any suggestions?
Thanks!
So while not all the data will need to be loaded into RAM at the same time, I do need (ok, I want) to have it all stored in one file for ease of management.
So the amount of data is over the 4K EEPROM size, so it will need to be stored on the SD card, or the flash I put on the audio card. But most likely the SD card for a reason you will soon see. Now if that was the only requirement, We'd be done here. But it's not..
One of the my requirements is that the configuration file be human readable. This really throws a wrench in the mix. The reason for this is so that the file can easily be edited in the field if needed
So the challenge is now instead of just storing a struct, I have to have string names for everything. As if the amount of data wasn't big enough... Then I'd have to do the slow process of parsing it all. There really wouldn't be any quick access to any of the data.
I started looking at database and dictionary libraries. None of them really is what I need. My data consists of all kinds of types. My data isn't really rows of the same data so databases aren't really useful. A lot of the libraries are locked to a specific type or at least make it difficult to handle structs. I considered using JSON libraries, but that also seemed to suffer from similar issues. Most of my programming I do is php so I'm pretty spoiled with loose types.
Another factor is, at least in the beginning stages, is not locking myself into a fixed length. I would much prefer some sort of arbitrary key/value type setup that is not so rigid. I was hoping not to have to explicitly move each variable into RAM but I don't think there's going to be way around that.
In a former life I did PalmOS programming, so I considered a linked list sort of method Palm used in their PDB file types. This wouldn't lock me into a fixed length, but also isn't human editable.
Other than the writing on the wall of having to make some compromises, anyone have any suggestions?
Thanks!