Laboratory exercises (Digital Systems)
The course has four-and-a-bit lab exercises, each designed to be done in a single session or less. There's another page with hints for demonstrators.
I've added a couple of exercises related to things in the Trinity Term part of the course. They are there as a way of preserving and making available materials – the Thumb simulator and a simulation of a carry-lookahead adder – in case participants want to experiment with them. There are no lab sessions in Trinity, and no expectation that participants will actually do these labs.
Is science a kind of playing? – Tom Spivey
Each lab has its own page with instructions.
- Lab zero: getting started. Follow the instructions for building, loading and running a simple program that echoes input sent over the serial port. (Beyond building and running the program, there's nothing to do here – it's just a way of getting started and becoming more familiar with the tools.)
- Lab one: assembly language. Implement various arithmetic operations in assembly language.
- Lab two: general purpose I/O. Enhance an electronic Valentine's card to respond to button presses.
- Lab three: interrupts. Investigate a program that uses interrupts to overlap computing a list of primes with printing it.
- Lab four: Phōs. Experiment with an embedded operating systems that supports concurrent processes communicating by messages.
Though there are no lab sessions scheduled for Trinity Term, nevertheless there are some (entirely optional) lab exercises that illustrate the material in the lectures and problem sheets.
- Lab five: Thumb simulator. Enhance an architectural simulation of a processor that implements the Thumb instruction set.
- Lab six: Carry-lookahead adder. Complete a Haskell simulation of a fast adder.
Software resources for the lab exercises are provided via a Mercurial repository, allowing for updates during term. You can browse the repository using a web interface, and instructions for making a local clone are provided as part of Lab zero. There are seven subdirectories in the repository, corresponding to Labs zero to six. Several files appear as independent copies in multiple directories, for example, the file
hardware.h that specifies the locations of various I/O registers on the micro:bit, and the file
startup.c containing the code that runs when the micro:bit comes out of reset. As far as possible, all files with the same name are identical, but in any event, they are consistent with each other. Naturally enough, each directory has its own unique
Other pages contain information about programming the micro:bit and using the Linux-hosted toolchain to compile programs.
- A very quick quide to programming in C.
- Links to hardware documentation.
- Instructions for using the toolchain.
- Instructions for installling the toolchain.
- Step-by-step instructions for capturing micro:bit signals with an oscilloscope or logic analyser.
- Hints for demonstrators.
Problems and fixes
Problems marked "(Fixed in rev n:123abc)" can be solved by pulling from the software repository and updating your working copy. Instructions for that are given below.
- 001 Building the
echoprogram gives the message,
/usr/lib/gcc/arm-none-eabi/5.4.1/armv6-m/libgcc.a: file not found
- This problem is fixed, but may recur if the list of places to look for
libgcc.aturns out to be insufficient.
- 002 Typing in the
minicomwindow when the
addprogram is stopped in the debugger leads to a lock-up.
- This is inevitable: when the program is stopped, it is not able to fetch characters from the UART buffer quickly enough, and the UART enters an error state (see also this FAQ entry). Simple programs like those in Labs 0 and 1 assume they are able to fetch the characters fast enough to avoid this, and are not written to recognise or handle such error states, even when they are restarted by the debugger.
- 003 Adding a delay between successive characters output by
serial_putc(such as simulating the seven stars of death) leads to a lock-up if characters are typed too quickly.
- This happens for a similar reason to problem 002, because the
serial_putcto echo each character of input. If that is too slow, an overrun error is the result. The solution is to have the serial I/O and blinking lights run by independent processes: watch this space.
pyocd-gdbserverreports the micro:bit as an 'unknown board'.
- This doesn't seem to matter much, if at all: the debugger works well for most participants. It certainly is not the cause of the problem reported in 002.
- 008 On a Mac, the linking step for lab 1 may possibly find the wrong version of
libgcc.a. The symptom is that the integer division subroutine doesn't work, and the program crashes after printing
foo(and before converting the argument to decimal for printing.
- This is potentially due to misconfiguration or misguided Makefile editing by the participant. A good compromise would be to provide, commented out, the linking command that invokes
gcc, so that it can be enabled in case of difficulty.
General lab problems
(Feel free to contribute. Last year's problems have mostly been fixed; a list for reference can be found on an old version of this page.)
Updating your working copy
The lab materials are delivered via a Mercurial repository. The first act on starting the labs is to make a clone of the master repository, which remains linked to the master for downloading updates. Your working copy consists of a replica of the master repostitory, together with 'checked out' copies of all the files in it, plus other files you have added yourself.
At any time you can safely download updates from the master repository to your own replica, without affecting your 'checked out' copies. The command for this is
$ hg pull
(issued from any directory inside your working copy).
If that command reports that new revisions have been downloaded, then you can incorporate them into your working copy with
$ hg up
This will keep the changes to files you have edited or added, and merge in the changes to other files from the repository. The only problem arises if a file has been edited both by you and by Mike as part of the new revision(s) in the repository. In this case, Mercurial tries to merge the changes, but it doesn't always succeed, and may report a 'conflict'. This is most likely to affect Makefiles, where you have manually incorporated a fix to the build process, and Mike has later added the fix to the master repoitory. If conflicts happen, the
Makefile will contain a mixture of the two versions, with lines marked as coming from one or the other. Your original file is preserved as
Makefile.orig. If you get into this situation, it's generally safe to go with the updated master copy of
Makefile, but I suggest you ask us for help.
A normal part of interaction with a version control system is to push your modifications back the server. In this case, the server is read-only for you, and attempts to push to it will be rejected. If you have improvements to suggest, you can send Mike a patch.
An alternative instruction encoding for the ARM in which each instruction is encoded in 16 rather than 32 bits. The advantage is compact code, the disadvantage that only a selection of instructions can be encoded, and only the first 8 registers are easily accessible. In Cortex-M microcontrollers, the Thumb encoding is the only one provided.
A symbolic representation of the machine code for a program.
(Universal Asynchronous Receiver/Transmitter). A peripheral interface that is able to send and receive characters serially, commonly used in the past for communication between a computer and an attached terminal. It is commonly used in duplex mode, with the transmitter of one device connected to the receiver of the other with one wire, and the receiver of the one connected to transmitter of the other with a different wire. The asynchronous part of the name refers to the fact that the transmitter and receiver on each wire do not share a common clock, but rely instead on the signalling protocol and precise timing to achieve synchronisation.