On 14/11/2023 21:34, Ed Prochak wrote:
> Any opinions about FREE RTOS?
> I like a priority scheduling kernel for the product that I
> about to work on, but are there any significant
> issues or just annoying features?
>
> I am checking out the Free RTOS documentation and other resources.
> Just curious if anyone has experienced any undocumented issues with it.
>
> That's all.
> Ed

I've used it on a couple of projects. It works fine.

My biggest complaint with it is the old-fashioned style. It uses the
hideous "systems Hungarian notation" naming, has lots of macros, opaque
void* pointers, and the like. Many RTOS and library developers seem to
view "pure ANSI C" (by which they mean C89/C90) as a good thing for
portability and compatibility - to me, it means coding styles that went
out of fashion 20 years ago for good reasons.

But FreeRTOS is not alone in that, and many alternative RTOS's have the
same sort of thing. At least it does not use insane cmake or kconfig
configuration and build systems.

It is supported on a wide range of target architectures - that is both
an advantage and a disadvantage.

It's not perfect, but I don't know of anything better, and I will
happily use it in the future.

On 16/11/2023 05:09, Ed Prochak wrote:
> On Wednesday, November 15, 2023 at 6:29:38 AM UTC-5, David Brown wrote:
>
>> I've used it on a couple of projects. It works fine.
>>
>> My biggest complaint with it is the old-fashioned style. It uses the
>> hideous "systems Hungarian notation" naming, has lots of macros, opaque
>> void* pointers, and the like. Many RTOS and library developers seem to
>> view "pure ANSI C" (by which they mean C89/C90) as a good thing for
>> portability and compatibility - to me, it means coding styles that went
>> out of fashion 20 years ago for good reasons.
>
> Oh I HATE Hungarian notation. hate, Hate HATE!
> Well I'll deal with it.
>

/Real/ Hungarian notation, as proposed by the Hungarian Charles Simonyi,
was to give additional information that was not part of the variable's
type. Thus "usInputString" might be a char* that holds an "unsafe
string" (not yet checked for weird characters, SQL injection attacks,
etc.), while "ssQueryString" would indicate that this is a "safe
string". Calling these "pchInputString" and "pchQueryString" is,
however, pointless, distracting, and harder to maintain. (In untyped
languages, it could be useful.)

It's also fine to have, say, "mutBusLock" and "semDataReady" naming a
mutex and a semaphore, since the types of these variables (in FreeRTOS)
will be the same.

Basically, Hungarian notation - like any other convention - is a good
thing if it adds helpful information in a convenient manner without
distracting from the code, and without imposing a maintenance burden.
It is a bad thing when it duplicates something that is better expressed
in a different manner (such as types), makes code harder to read, or
harder to maintain.

However, it's not uncommon to have your own wrapper functions anyway.
For example, you don't want things like this in your main code :

void do_bus(...) {
if (!xSemaphoreTakeRecursive(bus_mutex, pdMS_TO_TICKS(100))) {
panic("Can't get the lock - something is badly screwed!);
} else {
start_bus_transaction();
...
end_bus_transaction();
xSemaphoreGiveRecursive(bus_mutex);
}
}

Your main code will look like :

void do_bus(...) {
get_bus_lock();
start_bus_transaction();
...
end_bus_transaction();
release_bus_lock();
}

Or, if you work in C++ (and this is a good idea, IMHO), you will have :

void do_bus(...) {
Bus_locker lock;
start_bus_transaction();
...
end_bus_transaction();
}

The ugly raw FreeRTOS calls are hidden inside your wrappers. Then you
only have one place to pick the lock type. (Remember, it's C, and
old-fashioned C at that - the compiler can't help you if you mix up
mutexes, recursive mutexes, semaphores, or queues of any kind. They are
all just handles and there is no type safety.)

>
>> It's not perfect, but I don't know of anything better, and I will
>> happily use it in the future.
>
> Thanks.