Terminal output from opcontrol appearing before banner

[theol0403]

This issue is very minor and low priority.

Expected Behavior:

The PROS banner should show in the terminal, then any user text should be printed after the banner.

Actual Behavior:

User text is printed before or in the middle of the banner:

Steps to reproduce:

void opcontrol() {
	std::cout << "This print is at the top of opcontrol()" << std::endl;
	while (true) {
		pros::delay(20);
	}
}

Solution

One solution would be to delay about 200ms before starting the competition control tasks.
This will have the added benefit of giving the ADI ports time to initialize.

System information:

PROS Kernel Version: 3.2.0

Additional Information

This is strange behavior, considering

pros/src/system/startup.c

Lines 36 to 52 in 6394b23

	__attribute__((constructor(101))) static void pros_init(void) {
	rtos_initialize();
	vfs_initialize();
	vdml_initialize();
	display_initialize();
	// NOTE: this function should be called after all other initialize
	// functions. for an example of what could happen if this is not
	// the case, see
	// https://github.com/purduesigbots/pros/pull/144/#issuecomment-496901942
	system_daemon_initialize();
	invoke_install_hot_table();
	}

and

pros/src/system/system_daemon.c

Line 125 in 6394b23

void system_daemon_initialize() {

[Octogonapus]

This will have the added benefit of giving the ADI ports time to initialize.

Maybe this is related to getting garbage data out of the ADI ports at the start of the program. Is there a way for us to poll if the ADI ports have been initialized?

[HotelCalifornia]

Wondering if the solution could be as simple as swapping the order vfs_initialize and vdml_initialize. The fact that serial output is initialized before VDML could potentially explain the appearance of garbage data as @Octogonapus mentioned.

[HotelCalifornia]

Actually, now I think about it, the two issues may be separate after all.

The terminal output timing issue may just be because vfs_initialize takes a while to start up and/or gets preempted by the competition tasks. Inserting a small delay would probably fix it, hacky as that seems. @theol0403 does this happen on kernel versions <3.2.0? or is this a new issue?

[theol0403]

This appears to be a new issue. Testing on 3.1.6 gives expected behavior:

[HotelCalifornia]

As far as I can verify the only thing that's changed in that neck of the woods was moving display_initialize to before system_daemon_initialize... If that's what ended up causing this then there's some pretty fragile timing at play here.

I'll try to repro this later and mess around with it a bit.

[HotelCalifornia]

@theol0403 is this still happening?