ADD answer to questions
This commit is contained in:
		
							
								
								
									
										24
									
								
								README.md
									
									
									
									
									
								
							
							
						
						
									
										24
									
								
								README.md
									
									
									
									
									
								
							| @@ -60,8 +60,26 @@ bikeSystem.start(); | |||||||
| ``` | ``` | ||||||
|  |  | ||||||
| # Some questions | # 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.  | 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? | ## Question 2 | ||||||
| We can observe only a usage of 75% because the CPU is more on Idle with Thread sleep. | `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