Author Topic: Parameters Problem  (Read 3028 times)

Offline hervé

  • Jr. Member
  • **
  • Posts: 98
    • View Profile
Parameters Problem
« on: October 25, 2011, 11:25:43 AM »
Hi Mark,

Sorry but I get lost using Parameters (My board uses uTaskerV1.4)
I use this board with two programs for two customers.
I have two differents struct PARS .
My problem is :
When I update a board which is running one of the program with the other customer program, the telnet password get lost.
I check that the parameter file is read but with bad data.
I changed PARAMETER_BLOCK_VERSION to force PARAMETER_BLOCK_1 or PARAMETER_BLOCK_2 to be read, but both are bad in my case.
After fnRetrieveAllParameters() is called, parameters is copy to temp_pars->temp_parameters, then there is a check of temp_pars->temp_parameters.ucParVersion to verify the parameters match the current PARAMETER_BLOCK_VERSION.
As it is not the case temp_pars->temp_parameters is initialized with cParameters : but not parameters.
as
Code: [Select]
#define POINTER_USER_NAME parameters->cUserName
#define POINTER_USER_PASS parameters->cUserPass

I could not enter my password  :'(.

Is it normal that temp_pars->temp_parameters and parameters get different ?

I need to know If I correctly analysed my problem.

Thanks

Offline mark

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3069
    • View Profile
    • uTasker
Re: Parameters Problem
« Reply #1 on: October 25, 2011, 12:15:00 PM »
Hi Hervé

Your analysis is correct.

1) The use of the parameters is an example and can therefore be modified as required to suit a project.
2) The demo project keeps two sets of the parameters; one called parameters and one called temp_pars->temp_parameters. Generally the set that is used by code is temp_pars->temp_parameters. When the user updates values temp_pars->temp_parameters is changed and generally also starts to be used immediately.
3) parameters is thus a backup of the original set of parameters and it allows a restore of the original set in case the changes in temp_pars->temp_parameters are not correct.
4) The problem that you have with the password is that it is being used from parameters and not temp_pars->temp_parameters. It may be that there was a reason for this but probably it can also be changed to be used from temp_pars->temp_parameters instead.
5) I too think that, when the parameter version doesn't match, both parameters and temp_pars->temp_parameters should in fact be initialised with the default set of values (the idea is that changing the parameter version number causes the old parameters to be invalid and the default set to be taken again).
6) In many cases the parameters set may be superfluouse and can be removed to save some memory. This would simply not allow a restore to be made.
7) The simplest and safest modification is probably to add
uMemcpy(parameters, &cParameters, sizeof(PARS));
when the parameter version doesn't match. I have now done this in my reference version.

Regards

Mark

Offline hervé

  • Jr. Member
  • **
  • Posts: 98
    • View Profile
Re: Parameters Problem
« Reply #2 on: October 26, 2011, 07:14:42 AM »
Hi Marks,

Thanks for your reply.
I made the modifications and it works well.
It was a strange behaviour to lose the password...

Regards