• FREE RTOS

    From Ed Prochak@edprochak@gmail.com to comp.arch.embedded on Tue Nov 14 12:34:30 2023
    From Newsgroup: comp.arch.embedded

    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
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Wed Nov 15 12:29:31 2023
    From Newsgroup: comp.arch.embedded

    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.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Ed Prochak@edprochak@gmail.com to comp.arch.embedded on Wed Nov 15 20:09:32 2023
    From Newsgroup: comp.arch.embedded

    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.
    It's not perfect, but I don't know of anything better, and I will
    happily use it in the future.
    Thanks.
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From pippo2@pippo2@disney.com (Jack) to comp.arch.embedded on Thu Nov 16 08:09:07 2023
    From Newsgroup: comp.arch.embedded

    Ed Prochak <edprochak@gmail.com> 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

    There is also https://www.zephyrproject.org

    Bye Jack
    --
    Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From David Brown@david.brown@hesbynett.no to comp.arch.embedded on Thu Nov 16 09:19:09 2023
    From Newsgroup: comp.arch.embedded

    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.

    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Ed Prochak@edprochak@gmail.com to comp.arch.embedded on Fri Nov 17 19:13:01 2023
    From Newsgroup: comp.arch.embedded

    On Thursday, November 16, 2023 at 2:09:13 AM UTC-5, Jack wrote:
    Ed Prochak <edpr...@gmail.com> 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
    There is also https://www.zephyrproject.org

    Bye Jack
    --
    Yoda of Borg am I! Assimilated shall you be! Futile resistance is, hmm?
    Thanks for the suggestion but
    I forgot to mention the key constraints:
    This is a maintenance project, so HW platform and OS are already chosen.
    The bulk of the code apparently is written.
    Ed
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Ed Prochak@edprochak@gmail.com to comp.arch.embedded on Fri Nov 17 19:16:52 2023
    From Newsgroup: comp.arch.embedded

    On Thursday, November 16, 2023 at 3:19:16 AM UTC-5, David Brown wrote:
    On 16/11/2023 05:09, Ed Prochak wrote:

    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.
    Yes, good points. Thanks
    Ed
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Dave Nadler@drn@nadler.com to comp.arch.embedded on Sun Nov 19 07:53:56 2023
    From Newsgroup: comp.arch.embedded

    On Tuesday, November 14, 2023 at 3:34:34 PM UTC-5, Ed Prochak wrote:
    Any opinions about FREE RTOS?
    I've used it successfully for many many projects, on several
    different hardware architectures. It's solid, well-supported via
    great forum, no big difficulties or challenges. Yes the naming
    is annoying but that's not a big problem! Lack of supported
    C++ bindings is a hindrance but not hard to add wrappers as needed.
    Hope it works well for you too,
    Best Regards, Dave
    PS: An important advantage is many IDEs include FreeRTOS-aware
    debug windows (process status with stack use, queue status).
    --- Synchronet 3.20a-Linux NewsLink 1.114
  • From Ed Prochak@edprochak@gmail.com to comp.arch.embedded on Fri Nov 24 08:24:44 2023
    From Newsgroup: comp.arch.embedded

    On Sunday, November 19, 2023 at 10:54:01 AM UTC-5, Dave Nadler wrote:
    On Tuesday, November 14, 2023 at 3:34:34 PM UTC-5, Ed Prochak wrote:
    Any opinions about FREE RTOS?
    I've used it successfully for many many projects, on several
    different hardware architectures. It's solid, well-supported via
    great forum, no big difficulties or challenges. Yes the naming
    is annoying but that's not a big problem! Lack of supported
    C++ bindings is a hindrance but not hard to add wrappers as needed.
    Hope it works well for you too,
    Best Regards, Dave

    PS: An important advantage is many IDEs include FreeRTOS-aware
    debug windows (process status with stack use, queue status).
    Thanks Dave.
    I'll be using C and likely SiLabs Simplicity Studio (Eclipse based)
    Next week I get the full details of the work. I'll try to post highlights
    and lowlights as I make progress.
    Thanks all.
    Ed
    --- Synchronet 3.20a-Linux NewsLink 1.114