Content tagged c

This post revisits the game project some half a year after the game already worked. The game used timers to handle asynchronicity, which was pretty messy. This post introduces an RTOS, complete with multiprocessing, a scheduler, and semaphores.

Installing and running Zephyr RTOS on Arduino 101 using custom-built open source toolchains.

Installing and running Zephyr RTOS on FRDM-K64F.

The last thing we need is some randomness for the game not to be boring. We will build a Linear Congruential Generator that reads out the timer register on the first button event to get a seed. We will also need a game engine so that things don't get too messy.

It would not be a cool game if it did not make funky noises. This post describes a way to build a sound device using a DAC and a bunch of resistors. This device will be able to play Nokia's RTTTL tunes.

We need to handle IO to move the defender and fire at the invaders. GPIO-connected buttons will do fine to trigger the shots, and we will read out a potentiometer through an ADC to determine the defender's position. This post describes the HAL functions for that and for handling timers, which is always helpful.

It's obvious, but Silly Invaders needs a display to display invaders. This post describes HAL calls to handle an old Nokia phone display through SSI and other things that were necessary to make it work, such as heap management.

I want my Alien Invaders to be portable and work on other microcontrollers. For that reason, the game logic will use a Hardware Abstraction Layer to communicate with the device. This post describes a stem of that layer dealing with hardware initialization and UART. Every future post will extend it with new functionality.

I have decided to build a simple Alien Invader game to learn more about microcontrollers. It will use Tiva as a base and a bunch of simple peripherals for I/O. This post describes a convenient development environment without any proprietary fluff.

Final thoughts. What's next?

What do you do when you need to signal state changes between threads? Condition variables are likely what you need. Futexes are general enough to be helpful here as well.

Chapter seven deals with read-write locks. They come in handy when many readers may access a resource mutated by relatively few writers.

Linux allows for assigning priorities to tasks and scheduling their execution according to various strategies. It has implications for locking, where the thread's priority may change after it has acquired a mutex. We deal with all that here.

Chapter five discusses cancelation. Threads may be canceled either synchronously or asynchronously. When they are canceled, they can call cleanup handlers. The process is quite involved and invokes some heavy Linux machinery.

Chapter four discusses detaching and joining threads, passing the return value to the parent, and dynamic initialization of data used concurrently by groups of threads.

In part three, we deal with synchronizing access to shared resources. As you know, bad things happen when multiple threads write to the same memory. We will implement basic mutexes using atomic operations on memory and futex syscalls for sleep management.

In the second chapter of the threading saga, we need to find a way to store and retrieve the pointer to the current thread by calling a function. It will be necessary for various internals and the thread-local storage. We can keep it in the Segment Register typically not used in x86_64 long mode but still taken care of during the context switch.

This is the first in a series of posts describing a threading library I built on top of Linux syscalls without Glibc. This post describes how to call syscalls, manage heap memory with custom-built malloc, and use the clone syscall to create a thread.