Author Topic: Parameter System  (Read 2804 times)

Offline paulk

  • Newbie
  • *
  • Posts: 45
    • View Profile
Parameter System
« on: May 26, 2010, 09:30:48 PM »
Hi Mark,

I need to modify the uParameterSystem for my project.  The parameter system is quite complex, and I've had some trouble getting familiar with the architecture.  I understand that there are essentially four locations for parameters: two in RAM (working and temporary) and two in FLASH (valid and swap). 

Here is my understanding, please correct me if I am wrong:  you can use the RAM-temp parameters to make changes, and then commit them to the RAM-working and/or FLASH-swap.  When the FLASH-swap are validated (in case of critical--ie: ethernet changes), they are moved to the FLASH-working section and deleted. 

Also, I'm a little confused on the valid / validated bytes at the beginning of the block(s).  ie: why would we have a valid+validated SWAP block? 

I read the uFileSystem document that talks about fnSaveNewPars, fnGetPar, fnSetPar and fnDelPar.

However, I also see that there are other functions that deal with the parameters not described in this document.  This includes:


At first glace, it appears there is some redundancy here, but I'm sure there is a reason???

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3093
    • View Profile
    • uTasker
Re: Parameter System
« Reply #1 on: May 26, 2010, 10:16:42 PM »
Hi Paul

The functions in the document are those belonging to the parameter system.

The others belong to the application and are thus an example of its use by the application. The application in this case uses the generic parameter system to save and restore different blocks of data. It has a backup so that it knows what has been modified, what was in FLASH etc., etc. Therefore the application is probably the complicated part.

Since the application code is a rather flexible example of a typical possible use you can modify that in any way that you like. You would simply retrieve a complete block or you could also stuff in some other data to suit.

The application basically has two copies of the parameters (retrieved from the parameter system) and in some places temporary parameters are used immediately and at others they are not, but will only be used after storage (the mix is decided by the particular application code).

Therefore remember that the demo project contains an example which may or may not be that what you are looking for. If it doesn't match you can modify or simplify it as required. The part that stays the same is the basic retrieval from FLASH and the possibility to save to FLASH for immediate use or for trial use (temporary). Disabling the swap block removes the temporary storage with retrieval capability of the old set - it also has a small risk in that parameters could be lost during update if the power to be removed in that moment.