Friends, quick question. The SDK is designed such that there is only one GPIO IRQ callback function, instead of, say, a function per GPIO. It seems like adding a function per GPIO is possible -- just keep an array of said callback pointers, and jump to the callback at the appropriate offset in the array when a given GPIO's interrupt condition occurs.
I assume there is some reason why this was not done, but I am curious if anyone can explain it to me. In my use-case, I am integrating several different drivers, each of which is designed to receive interrupts on certain GPIO events. I'd prefer to code each driver to register its own handler when it is instantiated. In many cases the interrupt handler will be very simple -- e.g. "wake up this FreeRTOS task". I understand that I can put a big switch in a single gpio handler function, but as someone new to the microcontroller game, this feels icky to me.
So, my request is for someone to explain the pitfalls of the strategy I proposed above, so that I can understand why the SDK has the architecture it does.
I assume there is some reason why this was not done, but I am curious if anyone can explain it to me. In my use-case, I am integrating several different drivers, each of which is designed to receive interrupts on certain GPIO events. I'd prefer to code each driver to register its own handler when it is instantiated. In many cases the interrupt handler will be very simple -- e.g. "wake up this FreeRTOS task". I understand that I can put a big switch in a single gpio handler function, but as someone new to the microcontroller game, this feels icky to me.
So, my request is for someone to explain the pitfalls of the strategy I proposed above, so that I can understand why the SDK has the architecture it does.
Statistics: Posted by jags84 — Mon May 06, 2024 12:00 am — Replies 1 — Views 46