I have a problem with my C code for a stm32 target.
I get this error :
warning: pointer targets in passing argument 3 of 'Proc_Start' differ in signedness
I can't really figure out why, I searched the web for similar topics but none of the solutions proposed in the topics helped me.
I give you the code of where it breaks problem and the definition of the macro that registers the error
where the compilation generates the error
void AppGestRelay_Init(u8 u8lvoie)
{
//Init Dac value for alim
u16 u16lDacValue = (((41435.4-Param.vcoil[u8lvoie])/16376.2)/2.48)*1024;
DrDac_SetValueChip(u8lvoie+1, u16lDacValue);
//Init discharge mode
mProcStartParam(AppGestRelay_DischargeMode, &u8lvoie);
//test
TrackAlt[TRACK1] = ALTER_POS;
TrackRunning[u8lvoie] = TRACK_NOT;
}
definition of the macro
#define mProcStart(fonct) Proc_Start(fonct, NULL, (const s8*)#fonct)
#define mProcStartParam(fonct,param) Proc_Start(fonct, (TProcParam)(param), #fonct)
the function called with the macro
P_PROC(AppGestRelay_DischargeMode)
{
static u8 u8lvoie;
P_BEGIN;
u8lvoie = *(u8*)P_PARAM;
if(TRUE == Param.zener[u8lvoie])
{
PcfDataW.pin7[u8lvoie] = PIN_OFF;
printf("on\r");
P_DELAY(mTICK_MS(10));
PcfDataW.pin7[u8lvoie] = PIN_ON;
printf("off\r");
}
else
{
PcfDataW.pin6[u8lvoie] = PIN_OFF;
printf("on\r");
P_DELAY(mTICK_MS(10));
PcfDataW.pin6[u8lvoie] = PIN_ON;
printf("off\r");
}
P_EXIT();
P_CLEANUP;
P_END;
}
Thank you very much for your future help
EDIT :
I already tried but adding a 3rd argument doesn't give a warning but an error saying that the macro only takes 2 parameters
macro "mProcStartParam" passed 3 arguments, but takes just 2
The code works by slightly modifying the AppGestRelay_Init() function but there is still the warning, I would like to know where it comes from
Thanks :)
void AppGestRelay_Init(u8 u8lvoie)
{
static u8 u8lTrack;
//Init Dac value for alim
u16 u16lDacValue = (((41435.4-Param.vcoil[u8lvoie])/16376.2)/2.48)*1024;
DrDac_SetValueChip(u8lvoie+1, u16lDacValue);
//Init discharge mode
u8lTrack = u8lvoie;
mProcStartParam(AppGestRelay_DischargeMode, &u8lTrack);
//wait discharge mode is set
while(Proc_IsActif(AppGestRelay_DischargeMode))
{
P_SCHEDULE();
}
TrackRunning[u8lvoie] = TRACK_NOT;
}
SOLVE :
the warning disappears by adding the (const s8*) in front of #fonct in the definition of mProcStartParam as it is the case in the definition of mProcStart
#define mProcStartParam(fonct,param) Proc_Start(fonct, (TProcParam)(param), (const s8*) #fonct)
Thanks
Presumably the function Proc_Start requires a (signed char*) for its third argument.
#fonct evaluates to a string, which has type (char*).
You have already written (const s8*)#fonct in one macro, why not try that in the other?
I'm writing my own enums-based backtrace. Basically each function call will append it's error to a pre-defined stack which will eventually include all errors across all function calls.
I want to create an efficient way to parse it. In the end I got int backtrace[] with enum values from all over my codebase, and I'd like to relate each enum value to it's name.
This should of course be done post-failure (not at runtime), so what I'm missing is a way, maybe as a part of the compilation step, to dump all my enums and there values to a file. Then i can write a script that parse the errors.
Is there an easy (cross-platform) static tool that does that?
Not sure how you log the errors, but how about:
typedef enum
{
E_SUCCESS = 0,
E_FAIL,
...
} error_t;
typedef struct
{
error_t code;
char * error_name;
} backtrace_entry_t;
backtrace_entry_t backtrace[..];
#define FUNC_EXIT(error_code__) \
do { \
backtrace[func_id].code = (error_code__); \
backtrace[func_id].error_name = #error_code__; \
} while (0)
Then, when you call FUNC_EXIT(E_SUCCESS);, you'll get for the backtrace for the function to be: {.code = 0, .error_name = "E_SUCCESS"}
The problem is, you can't get the right name if you call FUNC_EXIT(var);, where var is some local variable.
Another option, although still not an automagical one:
typedef enum
{
E_SUCCESS = 0,
E_FAIL,
...
NOF_ERROR_CODES
} error_t;
#define MAP_E_CODE_TO_NAME(error_code__) [error_code__] = #error_code__
const char * error_to_name_mapping[NOF_ERROR_CODES] = {
MAP_E_CODE_TO_NAME(E_SUCCESS),
MAP_E_CODE_TO_NAME(E_FAIL),
...
};
Will give a const char * array with {"E_SUCCESS", "E_FAIL", ...}, which you can use like this:
printf("The name of error code %d is '%s'", error, error_to_name_mapping[error]);
The problem here is that you have to have positive value to errors with increasing values.
I am trying to pass a struct of 2D arrays and to do calculations on them.
typedef struct{
float X[80][2];
float Y[80][2];
float Z[80][2];
int T[80][2];
int K[80];
} STATS;
void MovingAverage(STATS *stat_array, int last_stat) {
//Average = Average(Prev) + (ValueToAverage/n) - (Average(Prev)/n)
stat_array->**X**[last_stat][0] = stat_array->**X**[last_stat][0] +
(stat_array->**X**[last_stat][1] / stat_array->T[last_stat][0]) -
(stat_array->**X**[last_stat][0] / stat_array->T[last_stat][0]);
}
calling the function:
MovingAverage(*stat_array, last_stat);
My question is:
how do I access in a generic way to X Y and Z inside MovingAverage function?
Edit:
void MovingAverage(STATS *stat_array, int last_stat, (char *(array_idx)) {
//Average = Average(Prev) + (ValueToAverage/n) - (Average(Prev)/n)
stat_array->**array_idx**[last_stat][0] =
stat_array->**array_idx**[last_stat][0] +
(stat_array->**array_idx**[last_stat][1] /
stat_array->T[last_stat][0]) -
(stat_array->**array_idx**[last_stat][0] /
stat_array->T[last_stat][0]);
}
I know it won't work, but just to demonstrate my willings,
Somebody here (not me) could probably come up with some preprocessor magic to do what you're asking, but that is a solution I would not pursue. I consider it bad practice since macros can quickly get hairy and tough to debug. You can't have "variables" inside your source code, if that makes sense. During the build procedure, one of the first things that runs is the preprocessor, which resolves all your macros. It then passes that source code to the compiler. The compiler is not going to do any text substitutions for you, it cranks on the source code it has. To achieve what you want, write a function that operates on the type you want, and call that function with all your types. I'd change your MovingAverage function to something like this:
void MovingAverage(float arr[80][2], const int T[80][2], int last_stat)
{
arr[last_stat][0] = ... // whatever calculation you want to do here
}
int main(void)
{
STATS stat_array;
int last_stat;
// .. initialize stat_array and last_stat
// now call MovingAverage with each of your 3 arrays
MovingAverage(stat_array.X, stat_array.T, last_stat);
MovingAverage(stat_array.Y, stat_array.T, last_stat);
MovingAverage(stat_array.Z, stat_array.T, last_stat);
...
return 0;
}
I am attempting to compile some code, but am running into some problems that I cannot seem to figure out. Originally, I had three errors, but I have narrowed it down to one that I cannot seem to solve. There are three files I am working with right now: voltcon.c, mss_ace.c, and mss_ace.h. I have pasted the relevant code below:
Within mss_ace.c
void ACE_init( void )
{
/* Initialize driver's internal data. */
ace_init_flags();
/* Initialize the data structures used by conversion functions. */
ace_init_convert();
}
void ACE_configure_sdd
(
sdd_id_t sdd_id,
sdd_resolution_t resolution,
uint8_t mode,
sdd_update_method_t sync_update
)
{
...
}
Within mss_ace.h
typedef enum
{
SDD0_OUT = 0, /*!< Analog Module 0 Sigma Delta DAC */
SDD1_OUT = 1, /*!< Analog Module 1 Sigma Delta DAC */
SDD2_OUT = 2, /*!< Analog Module 2 Sigma Delta DAC */
NB_OF_SDD = 3
} sdd_id_t;
typedef enum
{
SDD_8_BITS = 0,
SDD_16_BITS = 4,
SDD_24_BITS = 8
} sdd_resolution_t;
#define SDD_CURRENT_MODE 1
#define SDD_VOLTAGE_MODE 0
#define SDD_RETURN_TO_ZERO 0
#define SDD_NON_RTZ 2
typedef enum
{
INDIVIDUAL_UPDATE = 0,
SYNC_UPDATE = 1
} sdd_update_method_t;
void ACE_init(void);
void ACE_configure_sdd(sdd_id_t sdd_id, sdd_resolution_t resolution, uint8_t mode, sdd_update_method_t sync_update);
Within voltcon.c
#include <stdint.h>
#include <math.h>
#include <string.h>
#include <stdio.h>
#include "../../N3V2_hardware/biarri/firmware/drivers/mss_ace/mss_ace.h"
sdd_id_t this_sdd_id = SDD0_OUT;
sdd_resolution_t this_sdd_resolution = SDD_16_BITS;
uint8_t this_mode = SDD_VOLTAGE_MODE;
sdd_update_method_t this_sdd_update_method = INDIVIDUAL_UPDATE;
void ACE_init();
void ACE_configure_sdd(this_sdd_id, this_sdd_resolution, this_mode, this_sdd_update_method);
The error I am getting is as follows:
voltcon.c: error: #92: identifier-list parameters may only be used in a function definition
What this error says to me is that it probably has to do with the third argument to my function.
---Update---
The error is caused by the last line in the code (the void ACE_configure_sdd one). My apologies on that. The #92 is just a code, it doesn't refer to the actual lines of code.
Try deleting the declaration of ACE_configure_sdd from voltcon.c. As it is already there in mss_ace.h.
It seems you are trying to call ACE_configure_sdd from voltcon.c but in c you can only call a function from inside of another function.
You can try doing this in voltcon.c :
void func1()
{
ACE_configure_sdd(this_sdd_id, this_sdd_resolution, this_mode, this_sdd_update_method);
}
now func1 can be called from some other function in your code or main() itself.
Hope this helps.
The last line within voltcon.c seems to be declaration of the function ACE_configure_sdd, but it's lack of type declarations of its variables. This is why the error "error: #92" came out.
I am working on an embedded application where the device is controlled through a command interface. I mocked the command dispatcher in VC and had it working to my satisfaction; but when I then moved the code over to the embedded environment, I found out that the compiler has a broken implementation of pointer-to-func's.
Here's how I originally implemented the code (in VC):
/* Relevant parts of header file */
typedef struct command {
const char *code;
void *set_dispatcher;
void *get_dispatcher;
const char *_description;
} command_t;
#define COMMAND_ENTRY(label,dispatcher,description) {(const char*)label, &set_##dispatcher, &get_##dispatcher, (const char*)description}
/* Dispatcher data structure in the C file */
const command_t commands[] = {
COMMAND_ENTRY("DH", Dhcp, "DHCP (0=off, 1=on)"),
COMMAND_ENTRY("IP", Ip, "IP Address (192.168.1.205)"),
COMMAND_ENTRY("SM", Subnet, "Subunet Mask (255.255.255.0)"),
COMMAND_ENTRY("DR", DefaultRoute, "Default router (192.168.1.1)"),
COMMAND_ENTRY("UN", Username, "Web username"),
COMMAND_ENTRY("PW", Password, "Web password"),
...
}
/* After matching the received command string to the command "label", the command is dispatched */
if (pc->isGetter)
return ((get_fn_t)(commands[i].get_dispatcher))(pc);
else
return ((set_fn_t)(commands[i].set_dispatcher))(pc);
}
Without the use of function pointers, it seems like my only hope is to use switch()/case statements to call functions. But I'd like to avoid having to manually maintain a large switch() statement.
What I was thinking of doing is moving all the COMMAND_ENTRY lines into a separate include file. Then wraps that include file with varying #define and #undefines. Something like:
/* Create enum's labels */
#define COMMAND_ENTRY(label,dispatcher,description) SET_##dispatcher, GET_##dispatcher
typedef enum command_labels = {
#include "entries.cinc"
DUMMY_ENUM_ENTRY} command_labels_t;
#undefine COMMAND_ENTRY
/* Create command mapping table */
#define COMMAND_ENTRY(label,dispatcher,description) {(const char*)label, SET_##dispatcher, GET_##dispatcher, (const char*)description}
const command_t commands[] = {
#include "entries.cinc"
NULL /* dummy */ };
#undefine COMMAND_ENTRY
/*...*/
int command_dispatcher(command_labels_t dispatcher_id) {
/* Create dispatcher switch statement */
#define COMMAND_ENTRY(label,dispatcher,description) case SET_##dispatcher: return set_##dispatcher(pc); case GET_##dispatcher: return get_##dispatcher(pc);
switch(dispatcher_id) {
#include "entries.cinc"
default:
return NOT_FOUND;
}
#undefine COMMAND_ENTRY
}
Does anyone see a better way to handle this situation? Sadly, 'get another compiler' is not a viable option. :(
--- Edit to add:
Just to clarify, the particular embedded environment is broken in that the compiler is supposed to create a "function-pointer table" which is then used by the compiler to resolve calls to functions through a pointer. Unfortunately, the compiler is broken and doesn't generate a correct function-table.
So I don't have an easy way to extract the func address to invoke it.
--- Edit #2:
Ah, yes, the use of void *(set|get)_dispatcher was my attempt to see if the problem was with the typedefine of the func pointers. Originally, I had
typedef int (*set_fn_t)(cmdContext_t *pCmdCtx);
typedef int (*get_fn_t)(cmdContext_t *pCmdCtx);
typedef struct command {
const char *code;
set_fn_t set_dispatcher;
get_fn_t get_dispatcher;
const char *_description;
} command_t;
You should try changing your struct command so the function pointers have the actual type:
typedef struct command {
const char *code;
set_fn_t set_dispatcher;
get_fn_t get_dispatcher;
const char *_description;
} command_t;
Unfortunately, function pointers are not guaranteed to be able to convert to/from void pointers (that applies only to pointers to objects).
What's the embedded environment?
Given the information posted in the updates to the question, I see that it's really a bugged compiler.
I think that your proposed solution seems pretty reasonable - it's probably similar to what I would have come up with.
A function pointer isn't actually required to fit in a void*. You could check to make sure that the value you're calling is actually the address of the function. If not, use a function pointer type in the struct: either get_fn_t, or IIRC void(*)(void) is guaranteed to be compatible with any function pointer type.
Edit: OK, assuming that calling by value can't be made to work, I can't think of a neater way to do what you need than auto-generating the switch statement. You could maybe use an off-the-shelf ASP-style preprocessor mode for ruby/python/perl/php/whatever prior to the C preprocessor. Something like this:
switch(dispatcher_id) {
<% for c in commands %>
case SET_<% c.dispatcher %>: return set_<% c.dispatcher %>(pc);
case GET_<% c.dispatcher %>: return get_<% c.dispatcher %>(pc);
<% end %>
default:
return NOT_FOUND;
}
might be a bit more readable than the macro/include trick, but introducing a new tool and setting up the makefiles is probably not worth it for such a small amount of code. And the line numbers in the debug info won't relate to the file you think of as the source file unless you do extra work in your preprocessor to specify them.
Can you get the vendor to fix the compiler?
To what extent is the pointer-to-function broken?
If the compiler allows you to get the address of a function (I'm from C++, but &getenv is what I mean), you could wrap the calling convention stuff into assembler.
As said, I'm a C++ssie, but something in the way of
; function call
push [arg1]
push [arg2]
call [command+8] ; at the 4th location, the setter is stored
ret
If even that is broken, you could define an array of extern void* pointers which you define, again, in assembly.
try this syntax:
return (*((get_fn_t)commands[i].get_dispatcher))(pc);
It's been awhile since I've done C & function pointers, but I believe the original C syntax required the * when dereferencing function pointers but most compilers would let you get away without it.
Do you have access to the link map?
If so, maybe you can hack your way around the wonky function-pointer table:
unsigned long addr_get_dhcp = 0x1111111;
unsigned long addr_set_dhcp = 0x2222222; //make these unique numbers.
/* Relevant parts of header file */
typedef struct command {
const char *code;
unsigned long set_dispatcher;
unsigned long get_dispatcher;
const char *_description;
} command_t;
#define COMMAND_ENTRY(label,dispatcher,description) {(const char*)label,
addr_set_##dispatcher, addr_get_##dispatcher, (const char*)description}
Now compile, grab the relevant addresses from the link map, replace the constants, and recompile. Nothing should move, so the map ought to stay the same. (Making the original constants unique should prevent the compiler from collapsing identical values into one storage location. You may need a long long, depending on the architecture)
If the concept works, you could probably add a post-link step running a script to do the replacement automagically. Of course, this is just a theory, it may fail miserably.
Maybe, you need to look into the structure again:
typedef struct command {
const char *code;
void *set_dispatcher; //IMO, it does not look like a function pointer...
void *get_dispatcher; //more like a pointer to void
const char *_description;
} command_t;
Let say your dispatchers have the following similar function definition:
//a function pointer type definition
typedef int (*genericDispatcher)(int data);
Assume that the dispatchers are like below:
int set_DhcpDispatcher(int data) { return data; }
int get_DhcpDispatcher(int data) { return 2*data; }
So, the revised structure will be:
typedef struct command {
const char *code;
genericDispatcher set_dispatcher;
genericDispatcher get_dispatcher;
const char *_description;
} command_t;
Your macro will be:
#define COMMAND_ENTRY(label,dispatcher,description) \
{ (const char*)label, \
set_##dispatcher##Dispatcher, \
get_##dispatcher##Dispatcher, \
(const char*)description }
Then, you can set your array as usual:
int main(int argc, char **argv)
{
int value1 = 0, value2 = 0;
const command_t commands[] = {
COMMAND_ENTRY("DH", Dhcp, "DHCP (0=off, 1=on)")
};
value1 = commands[0].set_dispatcher(1);
value2 = commands[0].get_dispatcher(2);
printf("value1 = %d, value2 = %d", value1, value2);
return 0;
}
Correct me, if I am wrong somewhere... ;)