I couldn't live without function pointers! Agreed, nowadays I use a language (Forth) which makes it much easier to use function pointers, but I wrote my Forth compiler by basically using three tables - one of which with function pointers using something resembling your second technique.
This coming off the heels of me just learning to use function pointers is super helpful. It contextualizes use cases really well, and i wish there was a discussion of their applications for the use cases at the end of the video.
Thanks for the suggestion. Maybe something I'll do in the future in a different video. The idea of this one was to be a super short talk that discusses the technique. I agree more indepth looks would be helpful!
Just to contribute an actual use case. I use an object that ties together the essential elements of running a simulation. The function pointer parameters allow different functions for different platforms. For example, the millisecond elapsed function is different for arduino and windows: FrameTimer(uint16_t frame_int, uint16_t aux_int, U32_CALLBACK p_time_fn, VOID_CALLBACK p_frame_fn, VOID_CALLBACK p_render_fn, VOID_CALLBACK p_aux_fn) An example of usage would be: pTimer = new FrameTimer(1000 / MAX_FPS, 500, millis, Update, Draw, Debug); FrameTimer is a rubbish name but has proven to be a very useful object for running simulations.
Regarding "Make sure function pointers are NOT stored in RAM"... when I register a callback function, isn't that callback function pointer stored in RAM somewhere (e.g., UART0_ISR->function), even if it's done in pre-compiled or auto-generated code?
I think you misspoke at ~ 6:19, "You don't want these (function pointers) in FLASH...". I think you meant, "You don't want these (function pointers) in RAM...".
Another problem is that calculating the maximum stack usage becomes non-trivial. For each function pointer invocation it has to be clear which functions can potentially be called.
Interestingly, I violated the rule that said it should be constant and my code was crashing because it was pointing to the 0x0. As I was debugging the issue, I found out another bug index out range. So one bug exposed another nasty bug. Note that, before implementing function pointer other bug was still there but I couldn't find out because my program haven't crashed or going into hard fault. :D
@@beningoembedded I ordered it but I have not received it. I hope I will indeed enjoy it as much as I enjoyed your videos. The thing is, my expertise level is not that advanced. I am afraid I won't understand all or most of your book's contents. But I like your video contents and style and background.
@@beningoembedded Do you mind if I ask you a simple question? I have read your article, where you mentioned that we are supposed to "write rock-solid embedded software". But I can only design and solder an STM32 board with HCD1080, using someone's Keil project code that I downloaded from the Internet. So, how do I write my own entire project/code? How do I improve myself from using others' code to "write my own rock-solid embedded software"? The architecture seems so difficult to master to write from scratch or modify here and there....
Function pointers will not have a negative impact on the real-time performance. They can improve readability, scalability, and reusability though. They can also decrease maintenance too. If you were to look at what a function call really is, it's just a pointer to the functions code anyway!
Function pointers are evil? I have always used them and I never had any problem with them, unless you have a bad memory or stack overflow or damaged memory section then this will never happen, assuming there is an active WDT monitoring those special cases. I have always recommended to use an auxiliary MCU in case the first had damaged memory then the second takes over - in case of medical or security applications.
Exactly. Unless this, unless that. There are companies that deem them evil and that they should be avoided at all costs. I love and use them all the time. If you know what you're doing, you can avoid all those "unlesses"! Thanks for the comment!
I couldn't live without function pointers! Agreed, nowadays I use a language (Forth) which makes it much easier to use function pointers, but I wrote my Forth compiler by basically using three tables - one of which with function pointers using something resembling your second technique.
This coming off the heels of me just learning to use function pointers is super helpful. It contextualizes use cases really well, and i wish there was a discussion of their applications for the use cases at the end of the video.
Thanks for the suggestion. Maybe something I'll do in the future in a different video. The idea of this one was to be a super short talk that discusses the technique. I agree more indepth looks would be helpful!
Thank you Jacob, your presence in here and on different blog article is helping so much to learn and understand.
Happy to hear that!
Just to contribute an actual use case. I use an object that ties together the essential elements of running a simulation. The function pointer parameters allow different functions for different platforms. For example, the millisecond elapsed function is different for arduino and windows:
FrameTimer(uint16_t frame_int, uint16_t aux_int, U32_CALLBACK p_time_fn,
VOID_CALLBACK p_frame_fn, VOID_CALLBACK p_render_fn, VOID_CALLBACK p_aux_fn)
An example of usage would be:
pTimer = new FrameTimer(1000 / MAX_FPS, 500, millis, Update, Draw, Debug);
FrameTimer is a rubbish name but has proven to be a very useful object for running simulations.
Really good video! Thanks for taking the time to make it.
Regarding "Make sure function pointers are NOT stored in RAM"... when I register a callback function, isn't that callback function pointer stored in RAM somewhere (e.g., UART0_ISR->function), even if it's done in pre-compiled or auto-generated code?
I think you misspoke at ~ 6:19, "You don't want these (function pointers) in FLASH...". I think you meant, "You don't want these (function pointers) in RAM...".
The use cases gives me inspiration to enhance my C code, so a big thank you from me.
Great to see you again!!!
Thanks Peter! I'm planning to post a lot more this year so stay tuned!
Could you please explain how the ATTiny85 bootloader works? It's a very basic MCU.
Thank you.
What a great little vid! Thanks.
Another problem is that calculating the maximum stack usage becomes non-trivial. For each function pointer invocation it has to be clear which functions can potentially be called.
Absolutely! Thanks for the comment and observation!
It gets harder still when using C and VLA's. Imagine even trying to guess when the size comes from the user too.
Interestingly, I violated the rule that said it should be constant and my code was crashing because it was pointing to the 0x0. As I was debugging the issue, I found out another bug index out range. So one bug exposed another nasty bug. Note that, before implementing function pointer other bug was still there but I couldn't find out because my program haven't crashed or going into hard fault. :D
I just bought your book today.❤
Excellent! I hope you enjoy it!
@@beningoembedded I ordered it but I have not received it. I hope I will indeed enjoy it as much as I enjoyed your videos. The thing is, my expertise level is not that advanced. I am afraid I won't understand all or most of your book's contents. But I like your video contents and style and background.
@@beningoembedded Do you mind if I ask you a simple question? I have read your article, where you mentioned that we are supposed to "write rock-solid embedded software". But I can only design and solder an STM32 board with HCD1080, using someone's Keil project code that I downloaded from the Internet. So, how do I write my own entire project/code? How do I improve myself from using others' code to "write my own rock-solid embedded software"? The architecture seems so difficult to master to write from scratch or modify here and there....
I haven't tried but i know putty used this, but I haven't figured out how to use this yet in my apps
Very interesting talk, thank you!
Thank you for your information😊
Great content!
Do they affect the real time performance?
Function pointers will not have a negative impact on the real-time performance. They can improve readability, scalability, and reusability though. They can also decrease maintenance too.
If you were to look at what a function call really is, it's just a pointer to the functions code anyway!
Function pointers are evil? I have always used them and I never had any problem with them, unless you have a bad memory or stack overflow or damaged memory section then this will never happen, assuming there is an active WDT monitoring those special cases. I have always recommended to use an auxiliary MCU in case the first had damaged memory then the second takes over - in case of medical or security applications.
Exactly. Unless this, unless that. There are companies that deem them evil and that they should be avoided at all costs. I love and use them all the time. If you know what you're doing, you can avoid all those "unlesses"!
Thanks for the comment!
Great video thank u
Glad you enjoyed it