🐛 PROS 3.8: Fix Issue with RTOS Not Started At Constructor Runtime

[WillXuCodes]

Summary:

If you call a constructor before RTOS initializes, it sometimes crashes.

Test Plan:

• [ ] Test this with a pros::Serial object... calling a constructor in a header will normally lead to a crash (verify this on a non-fixed branch).

[djava]

this could potentially be implemented using this idiom to prevent calling that FreeRTOS status function a bunch of times for no reason, since once the scheduler is started it should always just return that it's running.

If you want to take this a step further, you could have a std::once_flag in a global scope and wrap all calls to rtos_start_check() in a std::call_once referring to that one std::once_flag. Then it would only be called once globally and ignored every other time.

[djava]

Nick says:

Regarding the global constructor problem: you should be able to customize when this calls by modifying the entry point for the program (i.e., where vexos actually invokes user code to execute). This is 100% feasible and is actually done all the time for embedded systems, since it is not uncommon for some things to need to be done before global constructors can run (e.g., copying the data segment from flash to RAM, configuring external memory peripherals, etc.) this is really just a special case of that. The global constructors can then be run on the actual initialization task (i.e., the same task that initialize is run on)

[WillXuCodes]

Nick says:

Regarding the global constructor problem: you should be able to customize when this calls by modifying the entry point for the program (i.e., where vexos actually invokes user code to execute). This is 100% feasible and is actually done all the time for embedded systems, since it is not uncommon for some things to need to be done before global constructors can run (e.g., copying the data segment from flash to RAM, configuring external memory peripherals, etc.) this is really just a special case of that. The global constructors can then be run on the actual initialization task (i.e., the same task that initialize is run on)

yeah ngl this would be the more elegant solution.

[nickmertin]

I agree :)