ADD answer to questions
This commit is contained in:
		
							
								
								
									
										24
									
								
								README.md
									
									
									
									
									
								
							
							
						
						
									
										24
									
								
								README.md
									
									
									
									
									
								
							| @@ -60,8 +60,26 @@ bikeSystem.start(); | ||||
| ``` | ||||
|  | ||||
| # Some questions | ||||
| ## If you print CPU statistics at the end of every major cycle (in the super-loop), what CPU usage do you observe? How can you explain the observed CPU uptime? | ||||
| ## Question 1 | ||||
| `If you print CPU statistics at the end of every major cycle (in the super-loop), what CPU usage do you observe? How can you explain the observed CPU uptime?` | ||||
|  | ||||
| We observe a 100% usage because on each CPU cycle it compare if time is done.  | ||||
|  | ||||
| ## If you run the program after the change from busy wait to sleep calls, what CPU usage do you observe? How can you explain the observed CPU uptime? | ||||
| We can observe only a usage of 75% because the CPU is more on Idle with Thread sleep. | ||||
| ## Question 2 | ||||
| `If you run the program after the change from busy wait to sleep calls, what CPU usage do you observe? How can you explain the observed CPU uptime?` | ||||
|  | ||||
| We can observe only a usage of 75% because the CPU is more on Idle with Thread sleep. | ||||
|  | ||||
| ## Question 3 | ||||
| `If you run the static_scheduling_with_event program, what CPU usage do you observe? How can you explain the observed CPU uptime?` | ||||
|  | ||||
| We observe a light usage of 1% of CPU. The CPU is now sleeping all the time and doing small task only on event.  | ||||
|  | ||||
| ## Question 4 | ||||
| `When you run multiple tests for computing the response time of the reset event, what do you observe? Is there an improvement as compared to the static_scheduling::BikeSystem implementation?` | ||||
|  | ||||
| `    - If you do not press long enough on the push button, the event may be missed and no reset happens.` | ||||
|  | ||||
| `Based on the program itself and on the task scheduling, explain these two behaviors. Explain also why such behaviors may be problematic.` | ||||
|  | ||||
| We notice, that we miss such less event when is event driven (or not at all). But with a static scheduling the response time is still long because the reset task is call with a certain period.     | ||||
		Reference in New Issue
	
	Block a user