Laboratory exercises (Digital Systems)
Is science a kind of playing? – Tom Spivey
The course has five lab exercises, each designed to be done in a single session or less. There's another page with hints for demonstrators.
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 languageA symbolic representation of the machine code for a program.. 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.
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 five subdirectories in the repository, corresponding to Labs zero to four. 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.
- 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
- (Fixed in rev 1:fe4a93) Use
gccfor linking and not
lddirectly for all but Lab 1. In that lab, use a more portable way of finding
- (Fixed again in rev ??) On some
gccinstallations, the list of places to look should be longer, and contain one or more additional directories.
- (Fixed again in rev ??) On some
- 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(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. 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.
- 005 The
acceptroutine blithely accepts control characters (such as those generated by pressing the arrow keys) and adds them to the buffer. When the buffer contents is interpreted as a number, chaos results.
- (Fixed in rev 2:7d75bb) Ignoring non-printing characters will make escape sequences like the arrow keys add visible junk, but that's better than invisible nonsense. We could go further and implement the usual timeout-based parsing of escape sequences, but that is a bit much for a bargain-basement test lash-up.
- 006 Upper case letters are not allowed as hex digits on input.
- (Fixed in rev 2:7d75bb) Why would anyone? But then again, why not?
- 007 Saying "
make add" instead of "
make add.hex" results in an attempt to build a program for the host using
make's default rules, and much confusion.
- (Fixed in rev 2:7d75bb) It's safer to nuke the default rules and print an helpful message instead.
- 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.)
- 501 The collection of editors associated with
.cfiles is bizarre. "Joe's Own Editor" appears three times, and Gnome Edit doesn't appear at all. The default editor (one of the instances of JOE) has a File menu that doesn't include Save or Exit. [Add a screenshot here.]
- Gnome Text Editor is installed for those who want to use it. Try right-clicking on a C source file, choosing 'Open with other application', then click on 'Show all applications' and scroll down. Having selected Text Editor once, it will appear immediately with a right-click subsequently.
- 502 The workstation desks have been designed so that it's impossible to plug in any mains-powered device such as (a) a student's laptop power supply, (b) an oscilloscope for debugging.
- 503 It would be really nice if we could procure several low-performance oscilloscopes for use in timing experiments. The cost would be moderate. Buying Chinese off-brand oscilloscopes is false economy, and buying USB scopes even more so. When you're looking for that signal, UI matters a lot. (At the moment I'm using my own Agilent scope, plus any others I can borrow.)
- 504 Typing an unknown command at the shell prompt (one of our participants tried
main) results in running Fedora's missing-command-perhaps-you'd-like-to-install-this-package script. It's misconfigured on the lab machines, and an unhelpful message results. Here's a sample.
tr02[~]$ main bash: main: command not found... Failed to search for file: cannot update repo 'updates': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried; Last error: Status code: 400 for http://mirror.ox.ac.uk/sites/download.fedora.redhat.com/pub/fedora /linux/updates/28/Everything/x86_64/ http://mirrorservice.org/sites/dl.fedoraproject.org/pub/fedora/linux/updates/28/Everything/x86_64/ http://dl.fedoraproject.org/pub/fedora/linux/updates/28/Everything/x86_64/repodata/repomd.xml tr02[~]$
- 505 Some participants could not log on. After typing username and password, they seemed to be logged in, but were immediately logged out again.
- 506 Plugging in the micro:bit for some participants did not result in its appearing as a disk drive.
- This may be related to (505), or alternatively in some cases, to there being a previous user not properly logged out of the machine.
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.