Hello!In the program, I decided to redo some of the functions and added the structure:
typedef struct { GPIO_TypeDef * GPIOx; uint16_t PINx; }GPIO_PINdef;
Previously, the function looked like this: void GPIO_InitPIN(GPIO_TypeDef* GPIOx, uint16_t GPIO_Pin_x)
Now it looks like this: void GPIO_InitPIN(GPIO_PINdef GPIOx)
So here is the question, calling a new function now works both in the old and new way, i.e. to call a function in this form: GPIO_InitPIN(GPIOB, GPIO_Pin_8)
and in this form:
GPIO_PINdef SPI_CS;GPIO_InitPIN(SPI_CS);the compiler does not swear and the program runs correctly.But everything was fine until I started getting rid of "warning" during compilation, namely "function" GPIO_InitPIN "declared implicitly".I copy the function description into the header file and after that everything stops working:void GPIO_InitPIN (GPIO_PINdef x); - adding this description in header file, swears that there are too many arguments when calling this function GPIO_InitPIN(GPIOB, GPIO_Pin_8)How can this function be written in the header file to get rid of "warning"?
Hello,
Thank you for using the Keil tools for Arm.
I assume this is C code for a Cortex-M device, and you are using Arm Compiler 6?
To give you a better answer, why refactor the function? What advantage are you trying to make? Are you trying to do function overloading?
www.geeksforgeeks.org/.../
====
A bit of context, the first four parameters in a function call are typically passed in the registers of the Cortex-M. From this forum post:community.arm.com/.../can-t-pass-pointer-parameters-correctly-why
The way in which all ARM compilers (should) pass arguments is defined in the "ARM Architecture Procedure Call Standard" (AAPCS).
infocenter.arm.com/.../IHI0042D_aapcs.pdf
plz look at page 15 and 16 for important information with register use.
If you pass a struct, rather than a pointer to a struct, that instead gets placed on the Cortex-M stack which is requires costly pushes and pops to access. There are some options available however:
www.keil.com/.../armcc_chr1359124224750.htm
If I can better understand what the new code is doing, we can give a more intelligent answer on the compiler warning.
The mystery here is not that the code fails now, after you added the required declaration. The mystery is that it worked before. The code, as-is, is just blatantly wrong. Calling a function with a different sequence of arguments than the one it actually has generally causes undefined behaviour.
Changing the header file is not the way to fix this. The declaration in the header has to match the actual implementation of the function. What you have to fix are the invocations.
methinks that "worked" in the original post means compiled w/o errors justwarnings
Unlikely. They did claim thusly:
TechnoMan said:the compiler does not swear and the program runs correctly.