How to change the values defined in header file in embedded c during runtime? - embedded

I am working on a project using MSP430FR6047 and there is certain header file I need to access and change parameters previously defined.
At the moment I have to flash the MCU with modified header file every time I change the parameter but I was exploring if there is another option to do theses changes without flashing the new code, preferably by UART or some other communication protocol.
So my question is how to change these parameters during runtime? Does any one know where should I start?
Thanks

A running program cannot change its source code, supposed that you mean something like #define PARAMETER 23. You need variables instead of constants.
One primitive solution is this:
Invent a global variable per parameter, declare all of them in an extra header file and define all of them in an extra source file for better maintenance.
In the new header file undefine all parameter macros and redefine them to use the variable instead of the literals.
In the using source files, include the original header file, after that include your new header file.
Initialize the variables initially, and change parameters as you wish during run time. (Initialization could be done in the new source file.)
This solution avoids heavy editing the using source files and leaves the original header file intact.
Example:
/* original.h */
#define PARAMETER 23
int f(void); /* returns PARAMETER */
/* new.h */
#if defined(PARAMETER)
#undef PARAMETER
#define PARAMETER parameter
#endif
extern int parameter;
/* new.c */
#include "new.h" /* ensures that declarations and definitions match */
int parameter = 23;
/* original.c */
#include "original.h"
#include "new.h"
int f(void) {
return PARAMETER;
}
/* main.c */
#include <stdio.h>
#include "original.h"
#include "new.h"
int main(void) {
PARAMETER = 42;
printf("%d\n", f());
}
If you like to change the original source code, feel free to get rid of all this preprocessor stuff, and directly use variables instead of constants. But then you should re-think your design and provide parameters as arguments to existing or new functions. Global variables should be avoided, reasons are left as an exercise to you.

There are 2 cases which change parameter in header file.
Case 1: Header define default value
For example, in header file you have:
#define DEFAULT_VALUE 10
then in .c file if it is using like:
if (a < DEFAULT_VALUE)
{ /* Do something */ }
If this is the case you could update as following:
Modified the original line:
if (a < var_DefaultValue)
{ /* Do something */ }
With var_DefaultValue is global variable:
int var_DefaultValue = DEFAULT_VALUE;
By default, this will work as original.
If you want to change value, you could create a thread to receive new value somewhere and then update to var_DefaultValue.
Case 2: Header file define some precompile tag. For example:
#define DEFAULT_FEATURE 1
and in .c file you refer to feature as following:
#if DEFAULT_FEATURE
/* Do Something */
#endif
For this case, it is impossible to change it by any mean.

Related

Visual Objects - Retrieving string DEFINE dynamically - #ifdef is returning false

This is regarding the Visual Objects programming language based upon Clipper.
I'm trying to load the values of a few DEFINE constants, I've tried using #ifdef to determine if they exist however it doesn't seem to work with strings, just numbers or logics, e.g.:
DEFINE TEST_LOGIC := True
DEFINE TEST_NUM := 1
DEFINE TEST_STRING := "HELLO"
#IFDEF TEST_LOGIC
// Runs
#ENDIF
#IFDEF TEST_NUM
// Runs
#ENDIF
#IFDEF TEST_STRING
// Does not run
#ENDIF
Is there some other way of determining whether they exist and returning their values? I've tried VarGet() and MemVarGet() but they can't see the constant and cause a runtime error, and #ifdef cannot accept a method call like !Empty(TEST_STRING) (will not compile), using a direct comparison like #ifdef TEST_STRING > " " also doesn't work (compiles and runs but the code block does not execute).
There doesn't seem to be a way to do this using DEFINE statements containing strings, however if it's changed to a GLOBAL declaration then the #ifdef statement will work as expected.

How to redefine `YYSTYPE` in `bison/yacc`?

I define a user class to hold all object. But the yacc is going to made a header file, which the yylval's type must be YYSTYPE. If I do not use %union, it will hold it as a int. But if I use %union, it will a union. and union is ugly - It cannot hold a class or a shared_ptr (can but not a good idea), It only want me to use pointer.
I just want to make YYSTYPE has a type as a user class type. How can I do it?
Don't use YYSTYPE.
With bison -- which is what you are actually using as a yacc implementation-- the correct way to define the semantic value type is
%define api.value.type { MyType }
If you require that one or more header files be included for the declaration to be valid, put them inside a %code requires block:
%code requires {
#include "MyType.h"
}
The code generated by these two directives is copied into the header file which bison produces, so other files need only include the generated header file.
Warning: Note that unless you use bison's C++ interface, the semantic value type must be trivially copyable, which will eliminate most standard C++ library types. Failing to obey this rule will produce undefined behaviour which may go undetected until you attempt to parse a sufficiently complex input. In other words, tests with simple inputs may not reveal the bug.
As you see, the source file that made by lex and yacc need the header file that made by yacc.
the header is short so we can look for some solution in it.
the part that define the type of yylval is this:
/* Value type. */
#if ! defined YYSTYPE && ! defined YYSTYPE_IS_DECLARED
typedef int YYSTYPE;
# define YYSTYPE_IS_TRIVIAL 1
# define YYSTYPE_IS_DECLARED 1
#endif
extern YYSTYPE yylval;
so we can define YYSTYPE before we include the yacc's header file, looks like:
#include "your-header-file-that-define-the-class.h"
#define YYSTYPE your-class-type
#include "the-header-file-that-made-by-yacc.h"

Two different CMake difinitions

With CMake when some definitions are defined they are defined in this way:
add_definitions(-DMY_DEFINITION)
Sometimes I see people make the definitions in a different way:
add_definitions(-DMY_DEFINITION=1)
Then my question is what's the difference between them in the generated C++ project. Thanks.
This is not really related to CMake but more to the C/++ compiler.
In the code the difference is the same between :
#define MY_DEFINITION
and
#define MY_DEFINITION 1
Actually there's not need to define a value for a C/++ macro if the only thing you want is to know if the macro exists (has been defined), like a "flag". Best example is the header include guards :
#ifndef MYHEADER
#define MYHEADER
// ...
#endif
But sometimes people prefer setting a value (like =1) even if they don't need it, because it's more exhaustive, or clear.
More generally speaking when you affect a value to a macro it is because you expect the macro name to be expanded to the value. When not you just expect the value to exist. The way tests are done may be different :
With -DMY_DEFINITION:
#ifdef MY_DEFINITION
// Do something
#else
// Do somthing else
#endif
With -DMY_DEFINITION=1
#if MY_DEFINITION
// Do something
#else
// Do somthing else
#endif

Float counted as zero when it isn't

In my game I have a header file that contains properties and functions for seasons in my game. These properties are all static and include a float representing the current season and another float representing the current point in the transition between seasons, being zero if it isn't transitioning.
Several functions throughout my game rely on the transition (two at this point) and one is working perfectly. Although, in another instance this isn't working at all.
In the class responsible for controlling the background for my game, when ever the "SeasonTransition" variable is referenced it just comes up zero. But in the other class, where the variable is referenced exactly the same way, it comes up with the real value.
This is a picture after a breakpoint has been called after the game could update a few frames:
Once again these variables are declared in a c header file:
#import "somestuff.h"
static float SeasonTransition
etc...
This shouldn't be doing this right? How could I fix this?
EDIT:
The Season.h file is as follows:
//GL.h contains different functions and global variables to be used anywhere in the project.
//This file, like Season.h is a singular header file with static declarations, and is setup
//the same way. I have been developing this from the start of the project and havent had any
//problems with it.
#import "GL.h"
static float currentSeason;
static float SeasonTransition;
static void UpdateSeason(){
currentSeason += 0.0002f;
float TransitionLength = 0.15f;
float SeasonDepth = Clamp(currentSeason - floorf(currentSeason), 0, TransitionLength);
float bigTL = TransitionLength / 4;
float endTL = TransitionLength;
float Speed2 = 0;
float Speed1 = 1;
float bRatio = SeasonDepth / bigTL;
float eRatio = SeasonDepth / endTL;
SeasonTransition = (SeasonDepth < TransitionLength) ?
((SeasonDepth < bigTL) ?
(Speed1 * bRatio) + (Speed2 * (1.0f - bRatio)) :
(Speed1 * (1.0f - eRatio)) + (Speed2 * eRatio))
:
Speed2;
}
If you put static float SeasonTransition; into two separate C files (or one header file included by two separate C files), each C file will have its own independent copy of the variable.
If one of those C files then modifies the variable, it will modify its copy. It will not touch the one in the other C file. That sounds like the situation you're in.
The normal way to do this is to define the variable in one and declare it external in the other, something like:
file1.c:
int myVar; // it exists here.
file2.c:
extern int myVar; // it exists, but elsewhere.
You don't want to mark it static in the first since that effectively makes it invisible to the second. And you mark it extern in the second so that it knows the variable exists elsewhere (in the first).
You would actually see the effect if it weren't static. When the linker came to link those two files together, it would complain about having two variables with the same name.
There are many variations on how to do that, I've shown the simplest. It's probably better to have something like:
file1.h:
extern int myVar; // so everyone knows about the variable
// just by including this.
file1.c:
#include "file1.h" // or import for ObjC.
int myVar; // the actual variable.
file2.c:
#include "file1.h" // now we know about it, in the OTHER C file.
I could be wrong but I think the problem might be you don't quit understand how include/import work. These are not quit language features but preprocessor feature. When you include somewhere in a file, your say take the entire contents of that other file and stick it in here before your start compiling. So if you include the same header file in multiple different other files you will end up with multiple version of that static variable, with out the static you will get a compiler error because you have redefined the same variable multiple times. import works almost the same except if the preprocessor determines that the included file has already be include into the destination file (could be indirectly through another include), then it will not include the file again. If you understand this you can then see that declaring static variable within you header is quit strange, because you will end up with multiple versions of that variable everywhere that header is included. Normally you want to make the variable global in which case you define it in a .c or .m file and then declare it extern in the header or you want the variable to be private then you declare it static in the .c or .m file.
What static does is to hide the variable declaration from the linker, so the linker can not recognise that all the different declarations of the same name should be treated as the same variable.
#ifndef Season_h
#define Season_h
... your header stuff
#endif
Also, if you dont call updateSeason seasonTransition will be zero.

All values of an enum in an NSArray?

Hi all I have an enum type that holds my error codes.
The problem is that they are not sequential i.e.
enum{
ErrorCode1 = 1,
ErrorCode2 = 4,
ErrorCode3 = 74
}; typedef NSInteger MyErroCodes;
Also there are maybe 50 codes + so I really wouldn't want to have to duplicate the data or do it manually, which is what I've seen so far in my searches. Any help would be greatly appreciated.
The enum construct only exists at compile time. At run time, your MyErrorCodes instances are plain integers, and the ErrorCodeN values are just plain integer constants. There is no way to extract metadata from your enum in runtime (well, maybe there is in the debug info etc, but you don't want to go there...).
I suggest:
Create a small script (Python, Perl or whatnot) to generate functions that map the numeric code to string values. In XCode, you can even run code generators during the compilation phase if you really want.
Use metaprogramming or preprocessor macros to generate these functions during compilation. This requires some thought, but it can be done.
this is often accomplished using an include of a file which contains all the values within some body and sometimes using macros:
ErrorCode_enum.h
MON_ENUM_VALUE(ErrorCode1, 1)
MON_ENUM_VALUE(ErrorCode2, 4)
MON_ENUM_VALUE(ErrorCode3, 74)
where MON_ENUM_VALUE would be a variable macro expansion.
and your enum declaration might take this form:
enum {
#include "mon_enum_value_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_value_end.h" // undefines MON_ENUM_VALUE and everything else defined in mon_enum_value_begin.h
};
typedef NSInteger MyErroCodes;
then later you might write:
#include "mon_enum_NSNumber_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_NSNumber_end.h" // undefines MON_ENUM_VALUE and…
or
#include "mon_enum_NSError_begin.h" // defines MON_ENUM_VALUE and such
#include "ErrorCode_enum.h"
#include "mon_enum_NSError_end.h" // undefines MON_ENUM_VALUE and…
which may add or stringize those tags and values to other types.
Personally, I think the macros are gross, and just take alternate approaches (which, admittedly, may be more tedious to write).