inserting macros instead of hard coded board names
This commit is contained in:
@ -1,10 +1,10 @@
|
||||
# The BBC micro:bit - a reactive system
|
||||
# The @boardname@ - a reactive system
|
||||
|
||||
The BBC micro:bit is a reactive system. #docs
|
||||
The @boardname@ is a reactive system. #docs
|
||||
|
||||
### Computing systems
|
||||
|
||||
What sort of a *computing system* is the BBC micro:bit?
|
||||
What sort of a *computing system* is the @boardname@?
|
||||
|
||||
### ~hint
|
||||
|
||||
@ -12,21 +12,21 @@ There are different types of computing systems, to address different kinds of pr
|
||||
|
||||
### ~
|
||||
|
||||
The BBC micro:bit is a *reactive system* – it reacts continuously to external events, such as a person pressing the A button of the BBC micro:bit or shaking the device. The reaction to an event may be to perform a computation, update variables, and change the display. After the device reacts to an event, it is ready to react to the next one. If this sounds like a computer game, that’s because most computer games are reactive systems too!
|
||||
The @boardname@ is a *reactive system* – it reacts continuously to external events, such as a person pressing the A button of the @boardname@ or shaking the device. The reaction to an event may be to perform a computation, update variables, and change the display. After the device reacts to an event, it is ready to react to the next one. If this sounds like a computer game, that’s because most computer games are reactive systems too!
|
||||
|
||||
### Responsiveness
|
||||
|
||||
We want reactive systems to be responsive, which means to react in a timely manner to events. For example, when you play a computer game, it’s frustrating if you press a button to make a character jump, but it doesn’t immediately jump. A delay in reacting, or lack of responsiveness , can be the difference between life and death, both in the real and virtual worlds.
|
||||
|
||||
Let’s consider a simple example: you want to program your BBC micro:bit to accurately count the number of times the A button has been pressed and continuously display the current count on the 5x5 [LED screen](/device/screen). Because the LED screen is small, we can only display one digit of a number at a time on it. The [show number](/reference/basic/show-number) function will scroll the digits of a number across the screen so you can read it.
|
||||
Let’s consider a simple example: you want to program your @boardname@ to accurately count the number of times the A button has been pressed and continuously display the current count on the 5x5 [LED screen](/device/screen). Because the LED screen is small, we can only display one digit of a number at a time on it. The [show number](/reference/basic/show-number) function will scroll the digits of a number across the screen so you can read it.
|
||||
|
||||
Let’s say that the current count is 42 and the number 42 is scrolling across the LED screen. This means there is some code executing to perform the scroll. So, what should happen if you press the A button during the scroll? It would be a bad idea to ignore the button press, so some code should record the occurrence of the button press. But we just said there already is code running in order to scroll the number 42! If we wait until the code scrolling the 42 has finished to look for a button press, we will miss the button press. We want to avoid this sort of unresponsiveness.
|
||||
|
||||
### Concurrency
|
||||
|
||||
To be responsive, a reactive system needs to be able to do several things at the same time (concurrently), just like you can. But the BBC micro:bit only has one CPU for executing your program, which means it can only execute one program instruction at a time. On the other hand, it can execute millions of instructions in a single second. This points the way to a solution.
|
||||
To be responsive, a reactive system needs to be able to do several things at the same time (concurrently), just like you can. But the @boardname@ only has one CPU for executing your program, which means it can only execute one program instruction at a time. On the other hand, it can execute millions of instructions in a single second. This points the way to a solution.
|
||||
|
||||
Think about how a motion picture projector works - it projects only 24 frames per second, yet this is good enough to provide the illusion of fluid motion on the screen. The BBC micro:bit can execute millions of instructions per second, so it seems quite possible for the device to both to smoothly scroll the number 42 across the LED screen while looking for button presses and counting them.
|
||||
Think about how a motion picture projector works - it projects only 24 frames per second, yet this is good enough to provide the illusion of fluid motion on the screen. The @boardname@ can execute millions of instructions per second, so it seems quite possible for the device to both to smoothly scroll the number 42 across the LED screen while looking for button presses and counting them.
|
||||
|
||||
Let’s think about three sequences of instructions:
|
||||
|
||||
@ -44,9 +44,9 @@ The result is that it takes sequence S1 a little longer to complete, due to the
|
||||
|
||||
As we’ll soon see, there are other choices for how the sequences can be ordered to achieve the desired result.
|
||||
|
||||
### The BBC micro:bit scheduler and queuing up subprograms
|
||||
### The @boardname@ scheduler and queuing up subprograms
|
||||
|
||||
The BBC micro:bit’s *scheduler* provides the capability to concurrently execute different code sequences, relieving us of a lot of low-level programming. In fact, scheduling is so useful that it is a part of every *operating system*!
|
||||
The @boardname@’s *scheduler* provides the capability to concurrently execute different code sequences, relieving us of a lot of low-level programming. In fact, scheduling is so useful that it is a part of every *operating system*!
|
||||
|
||||
The first job of the scheduler is to allow multiple *subprograms* to be queued up for later execution . For our purposes, a subprogram is just a statement or sequence of statements in the context of a larger program. Consider the Touch Develop program below for counting button presses.
|
||||
|
||||
@ -98,7 +98,7 @@ The answer is “cooperation” and “passing”. Think of a football team doi
|
||||
|
||||
If you hadn’t guessed already, a footballer represents subprogram and dribbling the ball corresponds to that subprogram executing. Only one subprogram gets to execute at a time, as there is only one ball (processor). Footballer Alice passing the ball to footballer Bob corresponds to stopping execution of Alice’s subprogram (and remembering where it stopped) and starting/resuming execution of Bob’s subprogram.
|
||||
|
||||
We will call this “passing control of execution” rather than “passing the ball”. However, in the world of the BBC micro:bit, the concurrently executing subprograms are not aware of each other, so they don’t actually pass control directly to one another. Rather they pass control of execution back to the scheduler and the scheduler determines the subprogram to pass control to next. The programmer inserts a call to the `pause` function to indicate a point in the subprogram where control of execution passes to the scheduler. Also, when a subprogram ends execution, control passes to the scheduler.
|
||||
We will call this “passing control of execution” rather than “passing the ball”. However, in the world of the @boardname@, the concurrently executing subprograms are not aware of each other, so they don’t actually pass control directly to one another. Rather they pass control of execution back to the scheduler and the scheduler determines the subprogram to pass control to next. The programmer inserts a call to the `pause` function to indicate a point in the subprogram where control of execution passes to the scheduler. Also, when a subprogram ends execution, control passes to the scheduler.
|
||||
|
||||
Let’s take a look at the implementation of the `forever` statement to see an example of cooperative scheduling:
|
||||
|
||||
@ -118,7 +118,7 @@ The property of such round-robin scheduling is that under the assumption that ev
|
||||
|
||||
### Putting it all together
|
||||
|
||||
Let’s go back to the `count button presses` function and revisit its execution based on what we have learned about the BBC micro:bit scheduler. As detailed before, the function executes three steps to: (1) initialize the variable `count` to zero; (2) set up the event handler for each press of button A; (3) queue the forever loop to the run queue.
|
||||
Let’s go back to the `count button presses` function and revisit its execution based on what we have learned about the @boardname@ scheduler. As detailed before, the function executes three steps to: (1) initialize the variable `count` to zero; (2) set up the event handler for each press of button A; (3) queue the forever loop to the run queue.
|
||||
|
||||
The function then ends execution and control passes back to the scheduler. Let’s assume the user has not pressed any buttons . The scheduler finds the `forever` loop in the run queue and passes control to it. The loop first calls `basic -> show number(0,150)`. In the diagram below, we use “Show 0” to refer to the execution of this function:
|
||||
|
||||
@ -128,7 +128,7 @@ While "Show 0" (the blue sequence) is running, periodic interrupts by the schedu
|
||||
|
||||
### Final thoughts
|
||||
|
||||
Through this example, we have seen that the BBC micro:bit scheduler enables you to create a program that is composed of concurrent subprograms. In essence, the programmer needs to only think about the concurrent subprograms cooperatively passing control back to the scheduler, making sure no subprogram hogs control (or “dribbles the ball without passing”) for too long. While a subprogram runs, the scheduler polls the buttons and other IO peripherals at a high frequency in order to fire off events and queue event handlers for later execution, but this is invisible to the programmer.
|
||||
Through this example, we have seen that the @boardname@ scheduler enables you to create a program that is composed of concurrent subprograms. In essence, the programmer needs to only think about the concurrent subprograms cooperatively passing control back to the scheduler, making sure no subprogram hogs control (or “dribbles the ball without passing”) for too long. While a subprogram runs, the scheduler polls the buttons and other IO peripherals at a high frequency in order to fire off events and queue event handlers for later execution, but this is invisible to the programmer.
|
||||
|
||||
As a result, you can easily add a new capability to the micro:bit by just adding a new subprogram. For example, if you want to add a reset feature to the counter program, all you need to do is add a new event handler for a press of button B that sets the global variable "count" to zero, as shown below:
|
||||
|
||||
|
Reference in New Issue
Block a user