Baremetal Target TaskIdRepr Definition

[teddylambert]

GT-2 Team here again,

We are trying to generate and build a simple deployment in fprime 2.0.1 for a Baremetal ATmega128 target. However, on generation, we are running into an error that TaskIdRepr is not defined, specifically:

/home/vagrant/src/gt2-software/fprime/Os/TaskId.hpp:24:9: error: 'TaskIdRepr' does not name a type; did you mean 'TaskId'?
         TaskIdRepr getRepr(void) const;
         ^~~~~~~~~~
         TaskId
/home/vagrant/src/gt2-software/fprime/Os/TaskId.hpp:26:9: error: 'TaskIdRepr' does not name a type; did you mean 'TaskId'?
         TaskIdRepr id;
         ^~~~~~~~~~
         TaskId

We have traced this back to the following include path:
Task.cpp -> #include <Os/Task.hpp> -> #include <Os/TaskId.hpp> -> #include <Os/TaskIdRepr.hpp>, and within TaskIdRepr.hpp we have the following #ifdef:

#if defined(TGT_OS_TYPE_VXWORKS)
    typedef int TaskIdRepr;
#elif defined(TGT_OS_TYPE_LINUX) || defined(TGT_OS_TYPE_DARWIN)
    typedef pthread_t TaskIdRepr;
#endif

There are a few issues we are running into with this statement:

1. If targeting a pure baremetal system, like the ATmega128, we have defined TGT_OS_TYPE_BAREMETAL which means both conditions will fail and TaskIdRepr does not get defined, which produces the error above.
   a. This seems to have a pretty simple solution of changing the first line to #if defined(TGT_OS_TYPE_VXWORKS) || defined(TGT_OS_TYPE_BAREMETAL), however this would be a change within fprime itself so we wanted to start a discussion around it
2. As @SterlingPeet has brought up, consider the case of building a deployment for a Linux target with bare-metal scheduler. In this case, no error will be generated, as there does exist a typedef for TaskIdRepr. However, this defines the variable as a pthread_t type, but how would the bare-metal scheduler handle threading?

In general, it seems like there are changes that would need to be made for bare-metal support, but not sure whether our one-line fix is the best way to go about it given point 2 as well

[Joshua-Anderson]

It looks like you're right and that this may have been broken for some time... we really should consider adding a bare metal scheduling build to CI to make sure regressions like this don't reoccur.

@SterlingPeet is right, there is a use case for a linux deployment using bare metal scheduler, primarily for testing purposes, and I think it's probably worth trying to support that. It's may be as straightforward making FPRIME_USE_BAREMETAL_SCHEDULER a compile time definition and switch the taskidrepr type check to be

if baremetal
else if vxworks
else if linux or darwin

[astroesteban]

Support for a baremetal scheduler is something I'm interested in as well. I'm starting to explore the feasibility of getting F'running on a different baremetal platform. If it's achievable then a baremetal scheduler is something I will need eventually too. Adding some more baremetal support to F' would be great.