Embedded systems lab: registers, pins, PWM and interrupts on a simulated chip

This lab gives each student a JupyterLab of their own with a small made-up 8-bit chip in it, written in plain Python so every line can be read. The chip has seven registers, a clock that steps in ticks, a timer that drives a PWM pin, and a button that raises an interrupt. The work folder holds the chip, mcu.py, a starter notebook and short scripts, one idea each.

It is a simulator of a chip that does not exist, not a real board, and real chips differ: they have more registers, other names and many more rules, so a data sheet is what to read for a real one. It is not an attack lab either. Every copy has no route to the internet and none to any other student.

What students learn

That a register is a byte whose bits each mean something, printed in binary, hex and ordinary numbers. Then setting, clearing and toggling single bits with a mask, making a pin an output with the data direction register, driving it and reading it back, and a blink pattern over eight ticks. Then a timer and a compare value that make a PWM signal, where compare values of 4, 8 and 12 over a period of 16 ticks give 25, 50 and 75 percent. Last, a button that bounces: a polling loop counts one press as two, and an interrupt calls its handler for the same two edges until the handler waits out the bounce. It suits introductions to embedded systems, computer architecture and electronics.

Run it in your browser

The lab starts one service, jupyter, which writes the chip, the notebook and the short scripts into its work folder and is ready in a few seconds, inside the 512 MB a service may have. JupyterLab asks for no token, because the platform’s own door already knows who is opening it. The terminal beside the lab has no Python of its own, so it reaches the lab’s with docker exec jupyter, followed by the command to run inside. Every script prints the same each time.

  1. Open the Container page. Open Build on the bar and choose Run a container. Anybody may open it, and the Git lab and the SQL lab start with no account. Every other lab needs a free account: create one, sign in, then press Start.
  2. Find the lab. The Sample labs card lists every sample. Find JupyterLab: embedded systems with a simulated chip.
  3. Press Start. Start runs it as it is, in one press. Edit the file first opens the compose file so you can change it before you start.
  4. Open it. On the lab’s page, the lab bar has a link called JupyterLab: press it to open JupyterLab in your browser and double-click start.ipynb. Then press Open terminal and type docker exec jupyter python3 steps/registers.py to see the seven registers, every one 0b00000000 after a reset.

What to ask students to hand in

A short script or notebook of their own that imports mcu.py, such as a blink pattern of their own over eight ticks or a PWM signal with a duty cycle they chose and worked out, downloaded from JupyterLab with File, Download. Then a sentence or two in their own words on what the registers showed. Nothing is marked automatically: the sentence shows whether it was understood. For stronger work ask for a button handler that counts one press once, and for the student to say where the simulator differs from a real chip.

A basic lesson on this lab

Embedded Systems Basics is a small lesson worked in this lab. In it a student lists the work folder, prints the registers, sets, clears and toggles bits, drives a pin and blinks it, makes a PWM signal at three duty cycles, and compares polling with an interrupt on a button that bounces, then opens the same work in the starter notebook.

It is deliberately small: it shows a teacher what a lesson worked in a lab is, and the lab does the rest. Copy it into a module of your own to change it.

The code on GitHub

The compose file has no Dockerfile: it runs one stock public image, the Jupyter Docker Stacks’ own scipy-notebook, pinned to a dated tag, as its own unprivileged account with 512 MB of memory. The image is licensed BSD-3-Clause and is not distributed by us. The file writes the chip and the scripts when it starts, so every copy prints the same and nothing is downloaded. The limits are honest ones: it is one made-up chip, there is no real timing and no electronics, nothing can be installed from the internet, and a real board has more to learn. Nothing is kept when the lab stops, so a student downloads their work first.

Set it as work

Say in the task what to hand in.

  1. Make the lab. In your module add a task and choose the Container lab card, then In a GitHub repository. Give https://github.com/mitsurutech/lab-embedded-sim with the branch main. The compose file is the default, compose.yaml. Fork the repository first if you want to change it, for example to for example to give the chip another register.
  2. Publish and try it. Publish pins the commit you were shown, so a later change in the repository does not alter a lab you have already set. Start your own copy first.
  3. Hand it out. Assign it like any task, with a due date if you want one, and say in the task what to do and what to hand in.
  4. Mark what is handed in. Open a student’s copy and the work they handed in, mark it, and send it back with a reason if it needs more.

Try this lab, and what it costs

A free personal account can work through the basic lessons in this lab, with enough free credit each month to follow most lessons and no card. For a class, a school or college has its first 365 days free for up to 50 students, then pays per student a year, with every lab included and staff free.

Questions people ask

Why is there no token or password to type?
A lab’s web page is reached only through the platform’s own door, which already knows who you are and lets in only you and the staff who teach your module. So JupyterLab is started with no token. Do not run it like that on a machine anybody else can reach.
Why does the terminal use docker exec jupyter?
The lab’s terminal carries curl, psql and a few other clients, and no Python. docker exec jupyter runs a command inside the lab’s own container, which has Python. JupyterLab also has a terminal of its own, under File, New, Terminal.
Is this a real chip?
No. It is a small made-up chip written in Python so the ideas real chips share, registers, bits, pins, timers and interrupts, can be read and run. A real chip has other register names and bit positions, real electrical behaviour and real timing, and none of that is simulated here.
Can students change the chip?
Yes. mcu.py is in the work folder, short and commented, so a student can add a register or change the timer period and run the scripts again. Changes last only until the lab stops. For a different chip for the whole class, fork the repository, change the file the compose file writes, and set the fork as the lab.