Author Topic: Program Parameters  (Read 2311 times)

0 Members and 1 Guest are viewing this topic.

Offline Jeroen3Topic starter

  • Super Contributor
  • ***
  • Posts: 4596
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Program Parameters
« on: January 04, 2017, 03:06:50 pm »
I'm currently doing a project for a device that has A LOT of parameters. It's not the first time I'll be doing parameters, but experience has thought me that sooner or later all literals you've put in the software require to be changed for some custom application. To prevent creating a mess with different custom software versions, the idea has come up to make all things a parameter.

Variable Frequency Drives also offer this, hundreds or parameters sorted by number and category. Some hidden from end-users.

However, having dealt with a few parameters, I have not with dozens. What would be an expandable way to handle parameters?
I could store then as an INI file in flash. But that has a rather large ROM footprint for a small micro. List of keys, their type, their range, the number parsers, the default ini.
The device does not feature a user interface. This will be made externally, on pc or smartphone.

Currently I'm thinking of creating a structure with all the parameters in it. And reserve three blocks of flash to put them in.
- One "defaults" block.
- One "active" block.
- One "previous" block.
Since flash has to be mass erased, new settings would be written to the current "previous" block, and a byte in the "active" block would be written to null to indicate it has been deactivated. On boot the correct block is loaded into the pointer.
This would also support reverting the settings.

Obviously, the parameters would be only changed during commissioning of the device. For runtime parameters, of which there are not that many, there is SRAM and FRAM.

Any critics? (there must be, criticism is what we're best at)
Anyone dealt with something like this before?
 

Offline senso

  • Frequent Contributor
  • **
  • Posts: 953
  • Country: pt
    • My AVR tutorials
Re: Program Parameters
« Reply #1 on: January 04, 2017, 06:13:18 pm »
I have one big project at hands with around 200 parameters that can be user configured, and what I use is structs, stuffed into the internal eeprom for default values and user set values, its about 1k of eeprom used for both sets.
 

Offline rstofer

  • Super Contributor
  • ***
  • Posts: 10089
  • Country: us
Re: Program Parameters
« Reply #2 on: January 05, 2017, 01:37:58 am »
It probably doesn't apply in a limited memory application but a lot of programs are storing parameters in .xml files.
 

Offline Jeroen3Topic starter

  • Super Contributor
  • ***
  • Posts: 4596
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: Program Parameters
« Reply #3 on: January 05, 2017, 08:28:56 am »
I have one big project at hands with around 200 parameters that can be user configured, and what I use is structs, stuffed into the internal eeprom for default values and user set values, its about 1k of eeprom used for both sets.
What do you use to access those parameters? Currently I have made direct memory access. You can directly address the memory they are in. Like modbus.
This however is obviously risky since you can have unaligned access. I could make the parameters accessible by number, but that would require another list of numbers, data widths, and data offsets.
 

Offline senso

  • Frequent Contributor
  • **
  • Posts: 953
  • Country: pt
    • My AVR tutorials
Re: Program Parameters
« Reply #4 on: January 05, 2017, 12:36:50 pm »
They can be set via the ethernet interface, or via serial, I have a small command line "console" with commands that are used to read/set all the parameters, then all the values are bound checked, and all the strings have limited length and are truncated if they are bigger than expected and the set command throws and error back to the user/GUI, the console is not much more than a gigantic strcmp if/else chain.

All in all, the WizNet5500 lib(that is an horror show of bugs, wasted two weeks correcting errors in that thing, it kinda works in an home network, but when you pair it with 400+ computer in a network it does weird things), the LwMesh lib, some parsing code, some setup code, and the command system, its around 80KB of flash, and around 6KB of RAM(2KB are for the WizNet from the get go, and I have about 512B in random buffers).
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf

 

-->