✨ Newlib Stub Improvements

[WillXuCodes]

Summary:

This PR intends to add proper functionality to _exit, and adds implementations for usleep and sleep.

Still needs testing and peer review... far from perfect in terms of implementation.

Closes #318

[edjubuh]

Should be fine so long as vexSystemHighResTimeGet doesn't rely on vexBackgroundProcessing, which I doubt very much.

[WillXuCodes]

yep, which is why I need to do testing in the near future.

[nathan-moore]

Is there a reason why we're not calling pros::delay/calling into the scheduler (at least up to the accuracy of that)?

[HotelCalifornia]

do we have access to a microsecond timer in freeRTOS? I don't think we've yet otherwise exposed the vexOS high res timer...

[WillXuCodes]

The reasons for doing this are the following:

1. As Hotel said, we don't have a uDelay function that delays in microseconds (*potentially something to work on).
2. We do have microsecond timing in the form of getting the system time via pros::micros (I believe nick added it a couple months ago), which at the end of the day calls the same vexOS function.

[nathan-moore]

It looks like FreeRTOS works by counting interrupts , so a more precise delay implementation has trade offs. What I'm saying is that we likely want to sleep until we'd overstep the period on the next tick, then do this spinning.

[WillXuCodes]

Transferred from Discord:

The plan is to now two kill birds with stone one by not just coupling these stubs to our scheduler, but also adding microsecond timing to our API. We could also add a delay in seconds to our API as well while we're at it.

[WillXuCodes]

usleep confirmed to work, this was the test code:

void opcontrol() {
	pros::Controller master(pros::E_CONTROLLER_MASTER);
	while(true){
		printf("Delay Started\n");
		usleep(1000000);
		printf("Delay Finished\n");
	}
}

Ready for re-review

[nathan-moore]

std::atomic<bool> flag;
void opcontrol() {
	flag = false;

	pros::Task task([]{flag = true; }, 3);

	while (!flag)
	{
		usleep(10000);
	}
}

Will currently deadlock.

[nathan-moore]

Suggested change

	uint64_t endTime = vexSystemHighResTimeGet() + period;
	while(vexSystemHighResTimeGet() < endTime) asm("NOP");
	uint64_t endTime = vexSystemHighResTimeGet() + period;
	if (period > 1000)
	{
	task_delay(period / 1000);
	}
	while(vexSystemHighResTimeGet() < endTime) asm("YIELD");

Looks to be the best that we can do? You can also put a loop around the yield instruction, which would make things easier for the vex processor.

[WillXuCodes]

Yeah, I agree. I also realized I forgot to add an overflow check on the parameter.

[WillXuCodes]

std::atomic<bool> flag;
void opcontrol() {
	flag = false;

	pros::Task task([]{flag = true; }, 3);

	while (!flag)
	{
		usleep(10000);
	}
}

Will currently deadlock.

Yes. But attaching this to the scheduler as discussed would involve some extremely fundamental changes to the scheduler that are not worth it given how most people most likely will not use this function.

[nathan-moore]

Right, but my point is sort of that we can do better then what's currently here, since that's in the millisecond range. That and we'll likely want to document that this currently doesn't do any context switches to lower priority tasks when called with less then a millisecond resolution.

[HotelCalifornia]

Alternatively, since our scheduler operates at millisecond resolution, we could just have it set errno to ENOSYS and be done with it. do we really need microsecond delays to work?

[WillXuCodes]

After thinking about the best way to implement this, I've come to a compromise:

If the value is 1000 or above, it will call task_delay(period / 1000) and neglect the microsecond range.

If the value is less than 1000 microseconds, it will delay in the microsecond range but neglect interrupts.

[kunwarsahni01]

LGTM