Migrate docs from the other repo

This commit is contained in:
Michal Moskal
2016-03-25 16:47:20 -07:00
parent 38d2cf06d2
commit a08eb53f92
895 changed files with 36888 additions and 0 deletions

21
docs/device/contents.md Normal file
View File

@ -0,0 +1,21 @@
# micro:bit - the device
The micro:bit device #docs
The micro:bit is a very capable device with many components:
* [the USB connector](/microbit/device/usb)
* [the LED screen](/microbit/device/screen)
* [the buttons]
* [the accelerometer]
* [the compass]
* [the pins](/microbit/device/pins)
* [the battery plug]
The micro:bit embodies many fundamental concepts in computer science. To learn more, read:
* [the micro:bit - a reactive system](/microbit/device/reactive)
Sometimes, your micro:bit may display an error code. For more information, see:
* [the error codes](/microbit/device/error-codes)

View File

@ -0,0 +1,26 @@
# crocodile clips
The on pin pressed accessories.
Register an [event handler](/microbit/reference/event-handler) that will execute whenever the user attaches one side of the crocodile clip to the `GND` pin, then connects and disconnects the unattached side of the crocodile clip to pin `0`, `1`, or `2`.
### Example: on pin pressed with random numbers
This example displays a random number every time the crocodile clip holds `GND` then connects and disconnects the `P0` pin. Each time the crocodile clip is firmly connected and disconnected from pin `P0`, the micro:bit will return a random Number between 0 and the parameter limit
![](/static/mb/crocodile-clips-0.png)
### Connecting Crocodile Clips
![](/static/mb/crocodile-clips-1.jpg)
![](/static/mb/crocodile-clips-2.jpg)
### Lessons
[love meter](/microbit/lessons/love-meter)
### See also
[micro:bit pins](/microbit/device/pins), [pin is pressed](/microbit/reference/input/pin-is-pressed), [analog read pin](/microbit/reference/pins/analog-read-pin), [analog write pin](/microbit/reference/pins/analog-write-pin), [digital read pin](/microbit/reference/pins/digital-read-pin), [digital write pin](/microbit/reference/pins/digital-write-pin)

View File

@ -0,0 +1,17 @@
# Error codes
The micro:bit error codes #docs
Your micro:bit may encounter a situation that prevents it from running your code. When this happens, a frowny face will appear on your micro:bit screen (see picture) followed by an error number.
Below is a list of error numbers and what they mean:
* **10** (`MICROBIT_I2C_LOCKUP`): the micro:bit's I2C bus is not working
* **20** (`MICROBIT_OOM`): there is no free memory on the micro:bit
![](/static/mb/device/error-codes-0.png)
### See also
[Run scripts on your micro:bit](/microbit/device/usb)

63
docs/device/pins.md Normal file
View File

@ -0,0 +1,63 @@
# micro:bit pins
The micro:bit pins
![](/static/mb/device/pins-0.png)
The micro:bit has 25 external connections on the edge connector of the board, which we refer to as pins. The edge connector is the grey area on the right side of the figure above.
There are five large pins, that are also connected to holes in the board labelled: 0, 1, 2, 3V, and GND. And along the same edge, there are 20 small pins that you can use when plugging the micro:bit into an edge connector.
### Large pins
You can easily attach crocodile clips or 4mm banana plugs to the five large pins.
The first three, labelled 0, 1 and 2 are flexible and can be used for many different things - which means they are often called general purpose input and output (shortened to GPIO). These three pins also have the ability to read analogue voltages using something called an analogue-to-digital converter (ADC). They all have the same function:
* **0**: GPIO (general purpose digital input and output) with analogue to digital convertor (ADC).
* **1**: GPIO with ADC
* **2**: GPIO with ADC
The other two large pins (3V and GND) are very different!/td/td
### ~hint
Watch out! The pins labelled 3V and GND relate to the power supply of the board, and they should NEVER be connected together.
### ~
*power input*: If the micro:bit is powered by USB or a battery, then you can use the 3V pin as a *power output* to power peripherals with.
* **3V**: *3 volt power output* or *power input*. (1) *power output*: If the micro:bit is powered by USB or a battery, then you can use the 3V pin as a power output to power peripherals with; (2) *power input*: If the micro:bit is not being powered by USB or battery, you can use the 3V pin as a power input to power the micro:bit
* **GND**: attaches to ground in order to complete a circuit (required when using the 3V pin)
If you hold the GND pin with one hand, you can program the microbit to detect yourself touching the 0,1 or 2 pins with your other hand, giving you three more buttons to experiment with (you just used your body to complete an electrical circuit).
### Small pins
There are 20 small pins numbered sequentially from 3-22 (these pins are not labeled on the micro:bit, however, they are labelled in the picture above).
Unlike the three large pins that are dedicated to being used for external connections, some of the small pins are shared with other components on the micro:bit board. For example, pin 3 is shared with some of the LEDs on the screen of the micro:bit, so if you are using the screen to scroll messages, you cant use this pin as well.
* **pin 3**: GPIO shared with LED Col 1 of the LED screen; can be used for ADC and digital I/O when the LED screen is turned off.
* **pin 4**: GPIO shared with LED Col 2 of the LED screen; can be used for ADC and digital I/O when the LED screen is turned off.
* **pin 5**: GPIO shared with Button A. This lets you trigger or detect a button "A" click externally. This pin has a pull-up resistor, which means that by default it is at voltage of 3V. To replace button A on the micro:bit with an external button, connect one end of the external button to pin 4 and the other end to GND. When the button is pressed, the voltage on pin 4 is pulled down to 0, which generates a button click event.
* **pin 6**: GPIO shared with LED Col 9 of the LED screen; can be used for digital I/O when the LED screen is turned off.
* **pin 7**: GPIO shared with LED Col 8 of the LED screen; can be used for digital I/O when the LED screen is turned off.
* **pin 8**: Dedicated GPIO, for sending and sensing digital signals.
* **pin 9**: GPIO shared with LED Col 7 of the LED screen; can be used for digital I/O when the LED screen is turned off.
* **pin 10**: GPIO shared with LED Col 3 of the LED screen; can be used for ADC and digital I/O when the LED screen is turned off.
* **pin 11**: GPIO shared with Button B. This lets you trigger or detect a button “B” click externally.
* **pin 12**: this GPIO pin has been reserved to provide support for accessibility.
* **pin 13**: GPIO that is conventionally used for the serial clock (SCK) signal of the 3-wire Serial Peripheral Interface (SPI) bus.
* **pin 14**: GPIO that is conventionally used for the Master In Slave Out (MISO) signal of the SPI bus.
* **pin 15**: GPIO that is conventionally used for the Master Out Slave In (MOSI) signal of the SPI bus.
* **pin 16**: Dedicated GPIO (conventionally also used for SPI Chip Select function).
* **pins 17 and 18**: these pins are wired to the 3V supply, like the large 3V pad.
* **pins 19 and 20**: implement the clock signal (SCL) and data line (SDA) of the I2C bus communication protocol. With I2C, several devices can be connected on the same bus and send/read messages to and from the CPU. Internally, the accelerometer and the compass are connected to i2c.
* **pins 21 and 22**: these pins are wired to the GND pin and serve no other function
### Connecting to the small pins
It is recommended that an edge connector be acquired to connect to the small pins. More information on compatible edge connectors will be available later.

147
docs/device/reactive.md Normal file
View File

@ -0,0 +1,147 @@
# The micro:bit - a reactive system
The micro:bit is a reactive system. #docs
### Computing systems
What sort of a *computing system* is the micro:bit?
### ~hint
There are different types of computing systems, to address different kinds of problems that arise in practice: *transaction processing systems* are used by banks to handle huge numbers of financial transactions by their customers; *distributed systems* make a set of networked computers appear as one big computer (like Googles search engine); there are also *parallel systems*, such as graphic cards, which perform a huge number of primitive operations simultaneously, using a great number of small processing cores.
### ~
The micro:bit is a *reactive system* it reacts continuously to external events, such as a person pressing the A button of the 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, thats 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, its frustrating if you press a button to make a character jump, but it doesnt 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.
Lets consider a simple example: you want to program your 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](/microbit/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](/microbit/reference/basic/show-number) function will scroll the digits of a number across the screen so you can read it.
Lets 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 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.
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 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.
Lets think about three sequences of instructions:
* Sequence S1 contains the instructions (lets say several hundred thousand or so) that scroll the number 42 across the LED screen;
* Sequence S2 contains a few instructions to check if button A is pressed;
* Sequence S3 contains a few instructions to increment a counter.
In order to be responsive, we would like to *interrupt* the execution of sequence S1 *periodically* to execute the sequence S2, which will check if button A is pressed, which looks like:
TODO Diagram
The result is that it takes sequence S1 a little longer to complete, due to the interruptions to execute sequence S2, but we are checking often enough to detect a press of button A . When S2 detects a press of button A, then the sequence S3 can be executed before S1 resumes:
TODO Diagram
As well soon see, there are other choices for how the sequences can be ordered to achieve the desired result.
### The micro:bit scheduler and queuing up subprograms
The micro:bits *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.
```
export function countButtonPresses() {
input.onButtonPressed("A", () => {
count = count + 1
})
basic.forever(() => {
basic.showNumber(count, 150)
})
count = 0
}
```
The program above contains three statements that execute in order from top to bottom. The first statement
```
input.onButtonPressed("A", () => {
count = count + 1
})
```
informs the scheduler that on each and every event of the A button being pressed, a subprogram (called the event handler) should be queued for execution. The event handler is demarcated by the do/end keywords; it increments the global variable `count` by one. The second statement
```
basic.forever(() => {
basic.showNumber(count, 150)
})
```
queues a `forever` loop for later execution by the scheduler; the body of this loop (between the do/end keywords) displays the current value of global variable `count` on the LED screen. The third statement
```
count = 0
```
initializes the global variable `count` to zero. The function ends after the execution of these three statements, but this is not the end of program execution! Thats because the function queued the `forever` loop for execution by the scheduler.
The second job of the scheduler is to periodically interrupt execution to read (poll) the various inputs to the micro:bit (the buttons, pins, etc.) and fire off events (such as “button A pressed”). Recall that the firing of an event causes the event handler subprogram associated with that event to be queued for later execution. The scheduler uses a timer built into the micro:bit hardware to interrupt execution every 6 milliseconds and poll the inputs, which is more than fast enough to catch the quickest press of a button.
### Cooperative passing of control
How does the forever loop get to start execution? Furthermore, once the forever loop is running, how does any other subprogram (like the event handler that increments the count) ever get a chance to execute?
The answer is “cooperation” and “passing”. Think of a football team doing a drill there is one ball and each footballer gets to dribble the ball for a certain number of touches, after which they pass to another footballer. A footballer who never passes prevents all other footballers from dribbling. A cooperative footballer always passes to some other footballer after taking a few touches.
If you hadnt 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 Alices subprogram (and remembering where it stopped) and starting/resuming execution of Bobs subprogram.
We will call this “passing control of execution” rather than “passing the ball”. However, in the world of the micro:bit, the concurrently executing subprograms are not aware of each other, so they dont 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.
Lets take a look at the implementation of the `forever` statement to see an example of cooperative scheduling:
![](/static/mb/device/reactive-2.png)
The `forever` loop actually is a function that takes a subprogram (an *Action* in Touch Develop) as a parameter. The function uses the `control -> in background` function of the micro:bit runtime to queue a `while true` loop for execution by the scheduler. The while loop has two statements. The first statement runs the subprogram represented by the `body` parameter. The second statement passes control to the scheduler (requesting to “sleep” for 20 milliseconds).
Though the `while true` loop will repeatedly execute the body subprogram, between each execution of the body it will permit the scheduler to execute other subprograms. If the while loop did not contain the call to `pause`, then once control passed into the while loop, it would never pass back to the scheduler and no other subprogram would be able to execute (unless the body subprogram contained a call to `pause` itself).
### Round-robin scheduling
Now, we come to the third and final job of the scheduler, which is to determine which subprogram to pass control to next. The scheduler uses two queues to perform this task, the sleep queue and the run queue. The sleep queue contains the subprograms that have called the pause function and still have time left to sleep. The run queue contains all the non-sleeping subprograms, such as the event handlers queued by the firing of an event.
The scheduler moves the subprogram that has just paused into the sleep queue and then removes the subprogram at the head of the run queue and resumes its execution. Once a subprograms sleep period is over, the scheduler moves it from the sleep queue to the back of the run queue.
The property of such round-robin scheduling is that under the assumption that every subprogram periodically enters the sleep queue, then every subprogram will periodically get a chance to execute.
### Putting it all together
Lets go back to the `count button presses` function and revisit its execution based on what we have learned about the micro:bit scheduler. As detailed before, the function executes three steps to: (1) set up the event handler for each press of button A; (2) queue the forever loop to the run queue; (3) initialize the global variable `count` to zero.
The function then ends execution and control passes back to the scheduler. Lets 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:
![](/static/mb/device/reactive-3.png)
While "Show 0" (the blue sequence) is running, periodic interrupts by the scheduler (every 6 milliseconds) poll for button presses and queue an event handler for each press of button A. Lets say that one button press takes place during this time, as shown above. This will cause an event handler (labelled “inc”) to be queued for later execution by the scheduler. Once the "Show 0" has completed, the loop then calls `basic -> pause(20)` to put the forever loop to sleep for 20 milliseconds and give the scheduler an opportunity to run any newly queued event handler. Control passes to the “inc” event handler which will increment the global variable `count` from 0 to 1 and then complete, returning control to the scheduler. At some point, the `forever` loop moves from the sleep queue to the run queue; the `forever` loop then will resume and call `basic -> show number(1,150)`.
### Final thoughts
Through this example, we have seen that the 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.
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:
```
export function countButtonPressesWithReset() {
input.onButtonPressed("A", () => {
count = count + 1
})
basic.forever(() => {
basic.showNumber(count, 150)
})
count = 0
input.onButtonPressed("B", () => {
count = 0
})
}
```

60
docs/device/screen.md Normal file
View File

@ -0,0 +1,60 @@
# LED screen
The micro:bit LED screen
![](/static/mb/device/screen-0.png)
The micro:bit LED screen consists of 25 red LED lights arranged in a 5X5 grid (5 LEDs across by 5 LEDs down).
### Which LED?
You use ``x , y`` coordinates to specify a particular LED in the grid; where ``x`` is the horizontal position and ``y`` is the vertical position (0, 1, 2, 3, 4). To figure out the ``x``, ``y`` coordinates, position your micro:bit horizontally, like a credit card (see picture above).
Here are the x, y coordinates for the LEDs in the 5X5 grid:
`0, 0` `1, 0` `2, 0` `3, 0` `4, 0`
`0, 1` `1, 1` `2, 1` `3, 1` `4, 1`
`0, 2` `1, 2` `2, 2` `3, 2` `4, 2`
`0, 3` `1, 3` `2, 3` `3, 3` `4, 3`
`0, 4` `1, 4` `2, 4` `3, 4` `4, 4`
The x, y coordinates for the LED in the centre of the grid are `2, 2`. Starting from `0, 0` count over 2 columns and then down 2 rows.
### Row, column - 1
Since the row and column numbers start at 0, an easy way to figure out the x, y coordinates is to subtract 1 from the row and column number (when counting from 1). In other words, to specify the LED in the 4th column 5th row, subtract 1 from each number to get coordinates `3, 4`.
### Turn a LED on/off
Use [plot](/microbit/led/plot) and [unplot](/microbit/led/unplot) to turn a LED on or off
### Is a LED on/off?
Use the [point](/microbit/led/point) function to find out if a LED is on or off.
### Display images, strings and numbers
Instead of turning individual LEDs on or off, as above, you can display an [image](/microbit/reference/image/image) directly to the screen or show text/numbers on screen using the [show number](/microbit/reference/basic/show-number)/[show string](/microbit/reference/basic/show-string) function.
### The display buffer
The micro:bit runtime keeps an in-memory representation of the state of all 25 LEDS. This state is known as the "display buffer" and controls which LEDS are on and which are off. The plot/unplot/point functions access the display buffer directly. On the other hand, the functions that show an image, number or string overwrite the buffer completely. To illustrate, first try running this code sequence
```
basic.showString("d", 150)
led.plot(0, 0)
```
You will see the letter "d" displayed as well as the LED in position `0,0` lit up. Now try reversing the order of the two statements above:
```
led.plot(0, 0)
basic.showString("d", 150)
```
You will not see the LED at position `0,0` lit up because the `show string` function overwrites the whole display buffer.

137
docs/device/usb.md Normal file
View File

@ -0,0 +1,137 @@
# Run Scripts on your micro:bit
How to compile, transfer, and run a script on your micro:bit. #docs #USB #compile #transfer
While you're writing and testing your Block Editor or Touch Develop scripts, you'll mostly be running scripts in your browser by clicking the `Run` button (see [run code in your browser](/microbit/js/simulator) for info about this).
Once your masterpiece is complete, you can compile your script and run it on your micro:bit.
## Requirements
You need the following things to transfer and run a script on your micro:bit:
* A-Male to Micro USB cable to connect your computer to your micro:bit. This is the same cable that is commonly used to connect a smart phone to a computer.
* a PC running Windows 7 of later, or a Mac running OS X 10.6 or later
* access to the Internet
## Step 1: Connect your micro:bit to your computer
First, connect the micro:bit:
1. Connect the small end of the USB cable to the micro USB port on your micro:bit.
2. Connect the other end of the USB cable to a USB port on your computer.
Your computer should recognise your micro:bit as a new drive. On computers running Windows, MICROBIT appears as a drive under Devices and drives. On a Mac it appears as a new drive under Devices.
Windows
![](/static/mb/device/usb-0.jpg)
Mac (picture bvabdbco)
WARN: unknown picture: bvabdbco:5x3
### ~hide
If your computer doesn't recognise your micro:bit, please see [troubleshooting USB problems](/microbit/diagnosing-usb).
### ~
## Step 2: Compile your script
Next, compile your script:
1. Sign in to Touch Develop on your computer.
2. Open your script (find the script in **My Scripts** and click `Edit`).
3. Click `compile`. Your script is converted into a hex file that you can transfer and run on your micro:bit.
4. When prompted, choose to save the compiled file on your computer (or anywhere other than the micro:bit). Depending on which browser you are using, the download will adopt the download behaviour of that particular browser.
### Windows
** Chrome**
Your .hex file appears as a download at the bottom of the browser. Open up your windows file explorer. Your micro:bit appears as a drive called MICROBIT.
**Right click** on the download and select **show in folder**. Drag and drop the hex file from the download folder onto the MICROBIT drive.
Alternatively, you can drag and drop the downloaded hex file from the bottom of the browser onto the file explorer and onto the MICROBIT drive.
![](/static/mb/device/usb-1.jpg)
**Firefox**
A dialogue box will appear, asking whether you would like to open or save your hex file. Select **Save**, then **OK** and the file will appear in your downloads in the top right of your browser. Select the **blue arrow**, select the relevant file and drag and drop it onto your Windows Explorer and onto your MICROBIT drive.
![](/static/mb/device/usb-2.jpg)
![](/static/mb/device/usb-3.jpg)
**IE10**
Click on compile. You will see a message “Do you want to save this .hex file.” Select **Save**.
### Mac
** Safari**
When you select **compile** in Safari on Mac, your file will be downloaded to your downloads folder. Go to your downloads folder and open the file. In Safari the file will appear as unknown.txt rather than a named .hex file. Drag and drop it onto your MICROBIT drive.
![](/static/mb/device/usb-4.jpg)
**Firefox**
A dialogue box will appear, asking whether you would like to open or save your hex file. Select **Save** and **OK** and the file will then appear in your downloads in the top right of your browser. Click on **Show in Finder** and the file will appear in your downloads folder. Select the file and drag and drop it onto your MICROBIT drive.
![](/static/mb/device/usb-5.jpg)
![](/static/mb/device/usb-6.jpg)
**Chrome**
When you select **compile** in Chrome, the file will be downloaded to the bottom of the browser in .hex format. Click on the small arrow and select **Show in Finder**. This will show the file in your download folder. Drag and drop the file onto your MICROBIT drive.
![](/static/mb/device/usb-7.jpg)
## Step 3: Transfer the file to your micro:bit
1. The file will transfer onto your micro:bit.
2. If you're using Windows, you can use **Send to** as described below.
3. The LED on the back of your micro:bit flashes during the transfer (which should only take a few seconds).
4. Once transferred, the code will run automatically on your micro:bit. To rerun your program, press the reset button on the back of your micro:bit. The reset button automatically runs the newest file on the micro:bit.
**Send to**: If you're using Windows you use *Send to* in File Explorer:
- In File Explorer, right-click on the hex file (created in Step 2 above), choose **Send to**, and then **MICROBIT**.
![](/static/mb/device/usb-8.jpg)
By copying the script onto the 'MICROBIT' drive, you have programmed it into the flash memory on the micro:bit, which means even after you unplug the micro:bit, your script will still run if the micro:bit is powered by battery.
## Troubleshooting
You cant drag and drop more than one hex file at once onto your micro:bit. If you try to drag and drop a second hex file onto your micro:bit before the first file has finished downloading, then the second file may fail in different ways.
When the first program has been written to the micro:bit, the drive will disengage. If you drag and drop a second file at this point it may not find the drive and the second write will fail.
The errors may look like this:
**Windows**
![](/static/mb/device/usb-9.jpg)
**Mac**
![](/static/mb/device/usb-10.png)
Or it may appear that there are two hex files on your micro:bit so the micro:bit wont be able to run multiple files. To rectify this, unplug your micro:bit and plug it in again. Make sure that your micro:bit appears as MICROBIT and not MAINTENANCE.
### See also
[Run code in a browser](/microbit/js/simulator)