Why not to merge such functions as tn_eventgrp_modify and tn_eventgrp_imodify

Issue #14 on hold
iTiger
created an issue

I use TNeo in my project. And have some functions that can be called as from task thread as from interrupt. This function is short enough to call from interrupt, but use

tn_eventgrp_modify

function. So, instead writing of two functions - one for thread and one for interrupt, I make some modification in

tn_eventgrp_modify

This function now may be called and from interrupt. In both of these functions exists check

tn_is_isr_context()

So, this does not increase execution time .

Of course, you wrote this kernel to have maximum compatibility with TNKernel, but now TNeo is independent and API may be improved.

Comments (2)

  1. Dmitry repo owner

    I was wondering about that too. Separate set of functions to be called from ISR is a kind of annoying, but:

    The thing is that these functions, just like almost any other kernel function, enable/disable interrupts. And there are (or might be) architectures, in which enabling/disabling interrupts should be done differently from task and from ISR. Some time ago, I've asked a question on electronics.stackexchange.com: Are there platforms where disabling/restoring interrupts from ISR should be done differently than from non-ISR context?

    Additionally, I've examined API of other kernels (AVIX, FreeRTOS, some others, don't remember exactly now), and they all have separate set of functions to be called from interrupts.

    So, I decided to leave it as it is.

    Maybe, it's worth getting rid of all ISR functions, so both kernel functions will exist in two variants: regular and "polling" (which is the same as regular, but with zero timeout).

    Again, the fact that other kernels have ISR-related versions for their functions makes me think that it may be needed some day.

    It's rather easy to get rid of them, but it won't be so easy to bring them back, if one day we need.

  2. Log in to comment