* hexcache is no longer generated at repo root, so remove it from package.json
* Modified templates to depend on local packages
* Adding bluetooth template for offline HEX cache
* Fix wrong package name in dependencies of bluetooth template
* Change package versions to * in templates
* Adding radio API for receiving a packet
* More new radio API changes
* renaming some properties
* Redoing radio packet parsing and updating new callback api
* aligning uart apis with serial
* reorganizing serial/bluetooth blocks
* Autoupdate configuration for UART. (#279)
* Autoupdate configuration for UART.
* removing serial autoupdates.
* Fix i18n not working after 277d5a7
The translation strings file in "core" package should have file names
"core-strings.json" or "core-jsdoc-strings.json".
* Enable ja translation
Rename "core-strings.json" to "core-jsdoc-strings.json".
Add new "core-strings.json" as a copy of the template.
Add two lines for the files in "pxt.json".
* initial notes
* updated code samples
* splitting the page and preparing layout
* missing gamepad api
* added basic guitar activty md files
added initial draft of guitar lesson - in progress
* word smithing and adding detail for concepts listed
* word smithing and adding detail for concepts listed
* typo in file name
* missing macro
* replaced guitar.png with image from Julia Carlson
* adding a few pictures
* adding cards macros
* few tweaks
* image for accellerometer lesson xyz axis
* fixed the numbering buttons page
-fixed the numbering to restart for each section and asdded spaces after so they don't wrap
* adding a few video links
* pin-press - added circuit info
* more vids
* fixing latest commit
* edits to light sensor and pin-press
* updated descriptions, linking lesson
* pin-press and display-buttons updates
-added dode samples to pin press
* updated making video
* light-sensor updated numbering
* Clean up
Clean up of headings to template style, other fixes
* putting display in template
use h2 with "Step 1:" and image before text
* removed numbered lists for display & light
these topics are code complete
* more consistent formating
Acceleromenter, buttons, light sensosr
* Acceleration Lesson, added art
Lesson steps for Acceleration, art for degree F to C for Map anology+clean up of light sensor topic
* Pin Press code complete
some other basic fomats and edits
* Removed dashes in lesson names
renamed and fixed references to files with "-" in names
* rest of fles w/ dash in name changes
* fixed links to guitar activities
* updated acceleraomter section
* transparency 4 art, image text
added transarency and renamed art, added descriptive text for video and still images
* renamed art
* fixing the merge
* fixing hint
* moved step 2 outside ~hint block
* fixing snippets
* remove guitar from project list
* Duration/Materials consistent format
moved out of ~avatar block
I’m continuing to use the same menu bar image, as usually these are black and white on OS X, compared to coloured images being common on the Windows task bar.
A small section of this file is still required to build and run the app (it contains metadata that declares that AppDelegate.m is the main implementation, for example).
* Source for OS X uploader
* Readme for OS X uploader
* Export image
* .gitignore for Xcode project
* Remove redundant data
* Update readme instructions
* List formatting
* Remove personal copyright notice added by Xcode
* Added release build and updated readme
* point to doc cdn
* Documentation page for unsupported browsers
* Update unsupported documentation with mac info
* Blur irrelevant information in version screenshots
* Rename to Peli's suggested path
* Browser recommendation for each platform
* Images of micro:bit attached t ostuff
* Cropped and enhanced USB images
* Define paths for USB images
* Added new matching criteria for images
* Help URL
* Add paths for all images
* Cropped images so they look better on dialog
* Add link to uploader
* working on new part definitions
* draft of new part definitions
* updates comments
* starting new allocator
* starting from the old allocator
* alloc internals renaming
* alloc minor renaming
* alloc internal renaming
* progress on new parts definition
* progress on new part defs allocator
* refactors BBLoc; progress on new allocator
* more progress on new allocator
* finishing new allocator
* deleting old allocator
* moves new allocator and part definitions
* porting to new part definitions
* refactors instructions for new definitions
* debugging new allocator
* fixes ground and power wire colros
* fixing new part definition bugs
* fixes wire end offsets; fixes NeoPixel placement
* fixes colorGroup issue
* fixes led matrix wiring
* naming tweaks
* fixes instructions regressions
* typo
At some point Im guessing the help file has been renamed and its current url is https://codethemicrobit.com/reference/pins/set-pull. This change to the annotation of setPull removes the word "digital" so that the link should work again
Note that currently you can't follow through with these instructions because string literals aren't supported, and there isn't support for converting the JS in this doc.
PXT accepts bug fix pull requests. For a bug fix PR to be accepted, it must first have a tracking issue that has been marked approved. Your PR should link to the bug you are fixing. If you've submitted a PR for a bug, please post a comment in the bug to avoid duplication of effort.
PXT also accepts new feature pull requests. For a feature-level PR to be accepted, it first needs to have design discussion. Design discussion can take one of two forms a) a feature request in the issue tracker that has been marked as approved or b) the PR must be accompanied by a full design spec and this spec is later approved in the open design discussion. Features are evaluated against their complexity, impact on other features, roadmap alignment, and maintainability.
These two blogs posts on contributing code to open source projects are a good reference: [Open Source Contribution Etiquette](http://tirania.org/blog/archive/2010/Dec-31.html) by Miguel de Icaza and [Don't "Push" Your Pull Requests](https://www.igvita.com/2011/12/19/dont-push-your-pull-requests/) by Ilya Grigorik.
## Security
If you believe you have found a security issue in PXT, please share it with us privately following the guidance at the Microsoft [Security TechCenter](https://technet.microsoft.com/en-us/security/ff852094). Reporting it via this channel helps minimize risk to projects built with PXT.
## Legal
You will need to complete a Contributor License Agreement (CLA) before your pull request can be accepted. This agreement testifies that you are granting us permission to use the source code you are submitting, and that this work is being submitted under appropriate license that we can use it.
You can complete the CLA by going through the steps at https://cla.microsoft.com. Once we have received the signed CLA, we'll review the request. You will only need to do this once.
## Housekeeping
Your pull request should:
* Include a description of what your change intends to do
* Be a child commit of a reasonably recent commit in the master branch
* install the PXT command line (add ``sudo`` for Mac/Linux shells).
```
npm install -g pxt
```
@@ -24,31 +39,44 @@ npm install
### Running
Run this command to open a local web server (add ``sudo`` for Mac/Linux shells)
Run this command to open a local web server (add ``sudo`` for Mac/Linux shells).
```
pxt serve
```
If the local server opens in the wrong browser, make sure to copy the URL containing the local token.
Otherwise, the editor will not be able to load the projects.
If you need modify the `.cpp` files, turn on yotta compilation with the ``-yt`` flag (add ``sudo`` for Mac/Linux shells):
If you need modify the `.cpp` files, turn on yotta compilation with the ``-yt`` flag (add ``sudo`` for Mac/Linux shells). On Windows, you must be running
from the ``Run Yotta`` command prompt.
```
pxt serve -yt
```
To make sure you're running the latest tools, run (add ``sudo`` for Mac/Linux shells)
## Updates
To update your PXT version and make sure you're running the latest tools, run (add ``sudo`` for Mac/Linux shells)
```
pxt update
```
More instructions at https://github.com/Microsoft/pxt#running-a-target-from-localhost
## Universal Windows App
## Testing
The Windows 10 app is a [Universal Windows Hosted Web App](https://microsoftedge.github.io/WebAppsDocs/en-US/win10/CreateHWA.htm)
that wraps ``m.pxt.io`` and provides additional features.
The build automatically runs the following:
### Building
* make sure the built-in packages compile
* `pxt run` in `libs/lang-test*` - this will run the test in command line runner;
there is a number of asserts in both of these
* `pxt testdir` in `tests` - this makes sure all the files compile and generates .hex files
* Install Visual Studio 2015 Update 2 or higher. Make sure the Windows 10 templates are installed.
* open the ``win10/app.sln`` solution and launch the ``m.pxt.io`` project.
To test something on the device:
* do a `pxt deploy` in `libs/lang-test*` - they should show `1` or `2` on the screen (and not unhappy face)
* run `pxt testdir` in `tests` and deploy some of the hex files from `tests/built`
The `lang-test0` source comes from the `pxt-core` package. It's also tested with `pxt run` there.
## Code of Conduct
This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
[selfshowNotification:@"micro:bit upload failed"withDescription:[NSStringstringWithFormat:@"Couldn't transfer %@ to %@",file.lastPathComponent,microbit]];
The [BBC micro:bit](https://www.microbit.co.uk) is a [pocket-size computer](/device) with a 5x5 display of 25 LEDs, Bluetooth and sensors that can be programmed by anyone.
The BBC micro:bit was made possible by many [partners](https://www.microbit.co.uk/partners).
The micro:bit provides an easy and fun introduction to programming and making – switch on, program it to do something fun – wear it, customize it.
Just like Arduino, the micro:bit can be connected to and interact with sensors, displays, and other devices.
## Hardware: The Device
Learn about about the [hardware components](/device) of the micro:bit to make the most of it!
## Programming: Blocks or JavaScript
The student can program the BBC micro:bit using [Blocks](/blocks) or [JavaScript](/typescript), via the [micro:bit APIs](/reference):
```blocks
basic.showString("Hi!");
```
## Compile and Flash: Your Program!
When a user has her code ready, she can connect her BBC micro:bit to a computer via a USB cable, so it appears as a mounted drive (named MICROBIT).
Compilation to ARM thumb machine code from [Blocks](/blocks) or [JavaScript](/typescript) happens in the browser.
The student is prompted to save the ARM binary program to a file, which she then simply drags to the micro:bit mounted drive,
which flashes the micro:bit device with the new program.
## Simulator: Test Your Code
Before a student compiles her code for the micro:bit, she can run it using the micro:bit simulator, all within the confines of a web browser.
The simulator has support for the LED screen, buttons, as well as compass, accelerometer, and digital I/O pins.
## C++ Runtime
The [C++ BBC micro:bit runtime](http://lancaster-university.github.io/microbit-docs/), created at [Lancaster University](http://www.lancaster.ac.uk/), provides access to the hardware functions of the micro:bit,
as well as a set of helper functions (such as displaying a number/image/string on the LED screen).
The [micro:bit library](/reference) mirrors the functions of the C++ library.
When code is compiled to ARM machine code, the calls to JavaScript micro:bit functions are replaced with calls to the corresponding C++ functions.
## Open Source
The editor for the BBC micro:bit is [open source](/open-source) on GitHub. Contributors are welcome!
The large holes at the bottom of the board are designed to attach alligator/crocodile clips.
Register an event 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
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
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 can’t 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.
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 Google’s 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, 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 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 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.
Let’s think about three sequences of instructions:
* Sequence S1 contains the instructions (let’s 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 we’ll 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: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 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(Button.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(Button.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! That’s 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 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 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.
Let’s take a look at the implementation of the `forever` statement to see an example of cooperative scheduling:

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 subprogram’s 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
Let’s 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. 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:

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. Let’s 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:
The micro:bit LED screen consists of 25 red LED lights arranged in a 5X5 grid (5 LEDs across by 5 LEDs down).
In the screen above, we created a checkerboard pattern using the LEDs.
### Which LED?
You use `(x ,y)` coordinates to specify a particular LED in the grid;
where `x` is the horizontal position (0,1,2,3,4) 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.
### Check your understanding
Which LEDs are turned on in the checkboard pattern above?
### 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](/reference/led/plot) and [unplot](/reference/led/unplot) to turn a LED on or off
```blocks
led.plot(0,0);
led.plot(1,1);
basic.pause(1000);
led.unplot(0,0);
basic.pause(1000);
led.unplot(1,1);
```
### Is a LED on/off?
Use the [point](/reference/led/point) function to find out if a LED is on or off.
```blocks
if(led.point(0,0)) {
}
```
### Display images, strings and numbers
Instead of turning individual LEDs on or off, as above, you can display an [image](/reference/images/image) directly to the screen or show text/numbers on screen using the [show number](/reference/basic/show-number)/[show string](/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
```blocks
basic.showString("d")
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:
```blocks
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.
The [serial](/reference/serial) supports [serial communication](https://en.wikipedia.org/wiki/Serial_port) between the BBC micro:bit and another computer. Basically, this allows you to send data from the micro:bit to your own computer. This is very useful for debugging purposes: you can add `write line` statements in your code and see them display on your computer as the program executes.
The code below shows a simple script that sends a line when the BBC micro:bit starts and another line each time the button ``A`` is pressed.
```blocks
serial.writeLine("started...")
input.onButtonPressed(Button.A, () => {
serial.writeLine("A pressed")
})
```
Data is also automatically streamed to serial by the ** bar graph** block
and picked up by the editor. This data can be streamed to the cloud as well.
## How to read the micro:bit's serial output from your computer
Unfortunately, using the serial library requires quite a bit of a setup.
### BBC micro:bit Chrome Extension
If you are using the Google Chrome browser, you can use our extension to get serial data streaming in the editor.
* Install the [Extension for BBC micro:bit](https://chrome.google.com/webstore/detail/extension-for-bbc-microbi/cihhkhnngbjlhahcfmhekmbnnjcjdbge?hl=en-US) on the Chrome Web Store.
* Restart Chrome and open the web editor.
### Windows
You must install a device driver (for the computer to recognize the serial interface of the micro:bit); then, you must also install a terminal emulator (which is going to connect to the micro:bit and read its output). Here's how to do it:
* Follow instructions at https://developer.mbed.org/handbook/Windows-serial-configuration in order to install the device driver
#### Windows > Tera Term
* Install the terminal emulator [Tera Term](https://ttssh2.osdn.jp/index.html.en). At the time of this writing, the latest version is 4.88 and can be downloaded [from here](http://en.osdn.jp/frs/redir.php?m=jaist&f=%2Fttssh2%2F63767%2Fteraterm-4.88.exe). Follow the instructions from the installer.
Once both the driver and the terminal emulator are installed, plug in the micro:bit and wait until the device is fully setup. Then, open TeraTerm.
* Hit `File` > `New Connection`
* Check "Serial"; in the dropdown menu, pick the COM port that says "mbed Serial Port". Hit `Ok`.
* In the menus, hit `Setup` > `Serial Port` and set the baud rate to `115200`.
You should be good. Feel free to hit `Setup` > `Save Setup` in the menus to erase the default configuration file with a new one so that you don't have to type in the settings again.
Please note that Windows will assign you a different COM port if you plug in another micro:bit. If you're juggling between micro:bits, you'll have to change the COM port every time.
#### Windows > Putty
If you prefer another terminal emulator (such as [PuTTY](http://www.putty.org/)), here are some instructions.
* Open Windows's [Device Manager](https://windows.microsoft.com/en-us/windows/open-device-manager); expand the section called "Ports (COM & LPT)"; write down the com number for "mbed Serial Port" (e.g. COM14)
* Open PuTTY; on the main screen, use the following settings: Serial / COM14 / 115200. Replace COM14 with the COM port number you wrote down previously. Feel free to type in a name and hit "Save" to remember this configuration.

* (optional): in the "Terminal" section, check "implicit cr in every lf"

### Linux
(Untested).
* Plug in the micro:bit
* Open a terminal
* `dmesg | tail` will show you which `/dev/` node the micro:bit was assigned (e.g. `/dev/ttyUSB0`)
* Then, do: `screen /dev/ttyUSB0 115200` (install the `screen` program if you don't have it). To exit, run `Ctrl-A` `Ctrl-D`.
Alternative programs include minicom, etc.
### Mac OS
* Plug in the micro:bit
* Open a terminal
* `ls /dev/cu.*` will return to you a list of serial devices; one of them will look like `/dev/cu.usbmodem1422` (the exact number depends on your computer)
* `screen /dev/cu.usbmodem1422 115200` will open up the micro:bit's serial output. To exit, hit `Ctrl-A` `Ctrl-D`.
The JavaScript simulator allows to test and execute most BBC micro:bit programs in the browser.
It allows to emulate sensor data or user interactions.
```sim
input.onButtonPressed(Button.A, () => {
basic.showString("A");
});
input.onButtonPressed(Button.B, () => {
basic.showString("B");
});
input.onPinPressed(TouchPin.P0, () => {
basic.showString("0");
});
input.onPinPressed(TouchPin.P1, () => {
basic.showString("1");
});
input.onPinPressed(TouchPin.P2, () => {
basic.showString("2");
});
input.temperature()
input.compassHeading()
input.lightLevel()
```
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.