Why Function pointer is used in Call back function any other usecase?

Question

What is the Use case of Function pointer in Embedded C and why which is used in Call back function? why we can not use normal function call? We can not use normal function call?

I could not understand the use case of Function pointer

Answer 1

A function pointer is a pointer to executable code that is already loaded in memory. Function pointers may point to code inside a module, or outside of it. The function pointer doesn't care.

When the called module is not linked together with the calling module, the address of the calling module is unknown to the called function at compile+link time, and neither at run time.

Let's take Windows (specifically, the win32 API) as an example:

In the beginning, the called function (Windows) does not know where the "callback code" (in your application) is. Note, in Windows the "controlling program" is your application; it calls functions in win32.dll; but sometimes win32.dll needs to delegate processing back to the application, it needs to call you back.

For code outside the called function (win32.dll) to be usable (i.e. addressable), it needs to be informed of the address of that code. In case of a callback, the simplest solution is for the calling application to pass a pointer to code of itself (to be more specific, one of its internal functions, the actual callback function) to the called function in one of the parameters (or as a field of a structure passed as a parameter).

In the famous Windows WNDPROC Callback Function https://en.wikipedia.org/wiki/WindowProc it is the application which first calls Windows, but Windows wants to call you back to process the windows event messages (mouse clicks, buttons pressed, menu items selected, and so on), because it is the duty of the application to process those events (after all it's the application which knows what to do with it). So, Windows needs to know the address of your WindowProc, and actually the application has already communcated a pointer to that function in the RegisterClass win32 function. The RegisterClassA (or W) Function takes one parameter, the WNDCLASSA structure (which the application needs to fill in), and -lo and behold- the second member in that structure is the address of (= a pointer to) the to-be-called-back windows event-handler procedure WndProc of your application.

typedef struct tagWNDCLASSA {
  UINT      style;
  WNDPROC   lpfnWndProc;  <----- The Callback Window Function
  int       cbClsExtra;
  int       cbWndExtra;
  HINSTANCE hInstance;
  HICON     hIcon;
  HCURSOR   hCursor;
  HBRUSH    hbrBackground;
  LPCSTR    lpszMenuName;
  LPCSTR    lpszClassName;
} WNDCLASSA, *PWNDCLASSA, *NPWNDCLASSA, *LPWNDCLASSA;

Windows takes the "detour" of window classes (which have nothing to do with object oriented classes by the way; a window class is a common set of parameters to be used by windows of the same type (and the same processing requirements, i.e. the same WndProc), for example multiple open files in an editor). When you actually create the window with the CreateWindow call, you pass it the window class, so Windows knows the appropriate WndProc Windows Event handler function from there.

Callbacks are quite an elegant method. Perhaps other methods could be thought of, such as the application implemented as a DLL, then to register the applications functions through DLL functions, but that would not make things simpler, IMHO.

Hope this helps.