fix: 🐛 Wait for serial port to be properly configured by VEXos

[ion098]

Summary:

This PR changes all serial functions to wait for VEXos to configure the smart port as generic serial.

Motivation:

VEXos takes some time to configure a smart port as generic serial, which can lead to the serial API mysteriously failing when called too soon after serial_enable.

Test Plan:

• test it compiles
• test that serial data can be sent immediately after calling serial_enable

[aghangurde]

How did you come to the 500ms figure? And what motivates specifically 5 100ms intervals?

[ion098]

re @aghangurde

How did you come to the 500ms figure? And what motivates specifically 5 100ms intervals?

According to the testing done by vexide here, generic serial generally takes 10ms to configure. I chose 500ms to provide a safety margin (The extra 490ms shouldn't matter too much since the delay should only ever happen once). Also, the code does 100 5ms intervals, not vice versa (most of the devices code that delays for some reason use 5ms as the delay time, so I used it as well).

[AndrewLuGit]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[AndrewLuGit]

@ion098 what is the reason why you add the delay on claim_port_i, instead of delaying until it is configured properly in serial_enable? Because to me it seems like delaying on serial_enable would be cleaner.

[ion098]

re @AndrewLuGit

@ion098 what is the reason why you add the delay on claim_port_i, instead of delaying until it is configured properly in serial_enable? Because to me it seems like delaying on serial_enable would be cleaner.

Delaying in serial_enable would be cleaner, but might cause issues when a pros::Serial object is declared globally, since the constructor would call serial_enable, which would call delay, which would most likely not work since global constructors run before the RTOS is started in main. This is conjecture though, so it's possible that delay will work fine, in which case the delay can be moved to serial_enable.

[AndrewLuGit]

@ion098 you are right, calling delay in a global constructor doesn't work. This is an issue, since if you set the baudrate in the constructor for a Serial object, it will now result in a data abort. We could just get rid of that constructor, considering that it probably couldn't set the baudrate correctly in a global constructor anyways.

[ion098]

@AndrewLuGit I think the best solution here would be to make the serial_claim_port_i macro call vexBackgroundProcessing in the loop instead of delay if the RTOS has not started yet.

[AndrewLuGit]

I have modified claim_serial_port_i to call vexBackgroundProcessing as you suggested. From my testing, it seems like it only takes 1 loop iteration for the registry to update, even without calling delay, which is interesting.

[ion098]

re @AndrewLuGit

From my testing, it seems like it only takes 1 loop iteration for the registry to update, even without calling delay, which is interesting.

From the testing done by the vexide folks, it seems like the delay is dependent on previous program runs: if the port was configured as a serial port in a previous program run, there will be little or no delay in future runs. I would try testing it with a power cycle between each program run.