Talk:Digital Systems

Comments from 2022

Suggestions about the lectures

• I would have liked larger overviews of how each topic works before getting into more specific examples.

I like to go bottom-up, gathering some observations about programs that work, then reflecting on what we can learn from them. That way we can begin with some things we can actually do, even if we have to take some other things for granted.

• More demos during lectures? With explanation of how we could create our own on the website.

Demos during lectures are very time-consuming, more so than usual this year because of the difficulty of capturing them for remote participants. I like to do a bit to get you started, but really these are pointers to what you can do for yourself in the lab.

• Explanation for each ARM instruction keyword, instead of only showing examples, as it is slightly confusing, e.g. the lsrs and adrs.

Precise descriptions of each instruction are in the documentation, which is organised alphabetically by mnemonic. It would be boring to go through all the details in lectures, rather than just what is needed to understand specific, motivating (I hope), programming examples.

• Assembly language code examples of things written in high level language. Also pictures.

The first six lectures and the first two problem sheets consist of nothing but examples of assembly language programs, usually given as a C program first. What more could I provide? I think that this time the need to make usable recordings inhibited me a bit from drawing impromptu diagrams on the whiteboard; sorry about that.

• More time could be spent on the special registers and their abbreviations (e.g., pc = program counter).

That information is contained in Lecture 2, where the three registers pc, sp and lr are named. The special uses of the sp and lr registers emerge only later as our sphere of interest enlarges: the sp for addressing the stack frame, and the lr for holding the return address. There are other registers accessible via the mrs/msr instructions that we don't cover in detail but don't really need.

• Less time could be spent on very specific features of the processor (some problem sheet questions seem to expect us to have learnt the 400 page manual).

Coming to terms with the documentation is an important skill, needed and sometimes even practiced by every engineer who joins an embedded software project. You don't need to memorise all 400 pages in order to look up specific instructions, and the official and unofficial reference cards (and the rainbow chart) provide a good road map. I don't think you should be distressed, either, if you can't find a perfect answer to every question on a tute sheet.

• Some of the tutorial sheet questions were on something I had never seen or heard about before, wasn't in the notes and didn't have an answer online. [I] felt like there were too many questions for which I was completely guessing / interpreting someone's poorly written stack overflow answer.

There's a page that I mentioned and showed in the lectures where all the documentation for the micro:bit is gathered – the ARM core, the Nordic microcontroller chip, and the board itself. Granted, some of the documentation is in lengthy manuals, but there are also shorter reference materials, including programming cards both official and unofficial. One of the skills we must address in the course is navigating this huge amount of information, and that's what some of the problem sheet questions are about. And in a course where the audience has diverse experience, you should not expect to answer perfectly every question on the problem sheets, or to get benefit from every question: some question might be too trivial for you, and others might need you to draw in prior knowledge that you don't have. And when I say "list all the instructions that set r0 to zero, I don't really expect a comprehensive answer, just some attempt to find out about the instruction set.

• Possibly could improve explanation of some of the micro:bit interface dealing with GPIO for buttons, etc., and using/coding interrupts.

Examples of these are in the practical materials, leaving some things for you to find by experiment, glean from documentation, or ask us about.

• More on how handlers and buffers and interrupts are actually coded.

You have the lab sources that you can look at whenever you want detailed code that actually works. For example, the code in lab3-primes/primes.c contains code for a UART interrupt handler, code for a circular buffer, and code to set up the UART so that it generates interrupts when it finishes transmitting a character, and the Nordic and ARM reference material describes explicitly what each register does. My aim in lectures is to give you what you need to consult these other sources.

• More detail about setting interrupt flags and how to find the documentation for them would be nice.

Did you miss the pointers to the Nordic documentation for the peripherals on the chip?

• More on C (e.g. pointers?)

You certainly have to pick up quite a lot of C from the examples, but have you seen the brief guide to C that I adapted from a document of Andy Tanenbaum's? It's linked from the labs page on the Wiki. If that's not enough then I wish you'd asked a question – in the lecture, by sending me e-mail, or by adding to the FAQ page here.

• More time taken with introduction to C and/or a more gradual walk through initial practicals.

Dry presentations of the rules of a language are not a very effective way to learn it; concrete examples make more sense. Did you try asking questions about what you didn't understand? You could use any of the routes above, or talk to the lecturer when he appears at the lab sessions.

• Some problem sheet questions weren't linked very clearly with the notes, so it was hard to figure them out.

The questions are supposed to encourage you to find things out from the documentaton, so I don't see the problem with that.

• Operating systems could be taught better.

Specific suggestions would be welcome.

General comments

• A very interesting and well taught course.
• The notes provided are very useful.
• The labs made the material a lot easier to understand – doing more at the start on early material would be helpful.

I agree, so that's why there were unofficial early sessions in the weeks before the official labs started. Did you come to them?

• I like having very open practicals, but more (maybe still optional) direction for projects seems useful.

Each lab contains specific instructions for some things you can try more easily. After that, I hope you are driven by curiosity to do something different from others.

• Small critique but the hypothetical users, programmers and personified processes in this course probably shouldn't be imagined as he/him by default.

Normally, I would personify a process in the circumstance where it "wants" to do something, but is prevented by something else – so to get a small sample I just checked my notes (as you can do yourself here: Notes for Digital Systems), and each of the seven occurrences of "wants" is closely associated with the pronoun "it". I'm not surprised by that, because it's what I would naturally write. As far as I can tell, the words "he" and "him" don't occur in the notes at all. As regards users, you will recall that our chief user, and recipient of the electronic Valentine's card with added primes, was imagined as Andrew Wiles, a male number theorist. In the back of my mind, I maybe chose him because the idea of sending him an unsolicited Valentine's card didn't seem too creepy to contemplate. But it might explain, if you can find any, instances where a user is glossed as he. If you can find any other instances in the published materials, I would be glad to hear of them. I can take little responsibility for what is heard as I give improvised explanations during lectures.

Previous years

• Comments from 2019