In this project we built a car with accompanying software that makes it easy to write autonomous control logic for the students at HVL. The system we have developed gives the students easy access to the data from the different sensors and makes it intuitive how to control the car based on this data.
MIT License
0
stars
0
forks
source link
Rewrite code to utlilize async/await fully in the SensorVehicle-main app (requires async I2c library) - responsive UI #4
There is a mix of async and synchronous code in the SensorVehicle-main application.
Async/await should be used "from bottom to top".
When the code is running on a PC (against the simulator), the implementation for IVehichleCommunication that is used is "SimulatedVehicleCommunication". This utilizes an AppService to communicate with the simulator, which only offers async methods.
When the code is running on the physical car, the implementation for IVehicleCommunication is "VehicleCommunication" which utilizes the UWP I2c library. This offers only synchronous methods. Async is not an option here.
For this reason, we have been forced to mix async and non-async code.
The way we have solved this:
Inside "SimulatedVehicleCommunication"-class:
When sending data to simulator (setting wheel speed) we send without awaiting the task.
Problem caused by this: any exceptions that occurs behind this method will be swallowed since we are not awaiting them.
When requesting data from simulator we force the method to run synchronously by adding ".GetAwaiter().GetResult();" to the async method.
Potential problem: may cause code to deadlock, however this has not occured while we have been testing the code.
Better way of fixing issue - if async I2C library can be found
If Microsoft releases an async version of the I2C library, then it would be better to rewrite all the code to async, since this would also ensure that the GUI remains responsive.
(If I2c communication fails there will be approximately a seconds delay before an exception is thrown. If the update was initiated from the GUI, this will cause a momentary UI freeze).
PS: This suggestion for fix is only relevant if an async I2c library can be found.
There is a mix of async and synchronous code in the SensorVehicle-main application. Async/await should be used "from bottom to top".
When the code is running on a PC (against the simulator), the implementation for IVehichleCommunication that is used is "SimulatedVehicleCommunication". This utilizes an AppService to communicate with the simulator, which only offers async methods.
When the code is running on the physical car, the implementation for IVehicleCommunication is "VehicleCommunication" which utilizes the UWP I2c library. This offers only synchronous methods. Async is not an option here.
For this reason, we have been forced to mix async and non-async code.
The way we have solved this:
Inside "SimulatedVehicleCommunication"-class:
When sending data to simulator (setting wheel speed) we send without awaiting the task. Problem caused by this: any exceptions that occurs behind this method will be swallowed since we are not awaiting them.
When requesting data from simulator we force the method to run synchronously by adding ".GetAwaiter().GetResult();" to the async method. Potential problem: may cause code to deadlock, however this has not occured while we have been testing the code.
Better way of fixing issue - if async I2C library can be found
If Microsoft releases an async version of the I2C library, then it would be better to rewrite all the code to async, since this would also ensure that the GUI remains responsive. (If I2c communication fails there will be approximately a seconds delay before an exception is thrown. If the update was initiated from the GUI, this will cause a momentary UI freeze).
PS: This suggestion for fix is only relevant if an async I2c library can be found.