Programming

You're looking for what's called Embedded Programming, which is that low-level stuff where the software you create makes things happen in real life outside of just a computer screen. There are lots of hobby beginner kits that come with things like motors, lights, etc. That's probably your best bet for actually getting some hands-on experience.

If you want something a little higher-level, go for something like a Raspberry Pi (a Single Board Computer or SBC). On these, you'll have a full-fledged Linux kernel and operating system, but still have ways of interacting with hardware like lights and such. If you want to get lower level, try Arduino or something based on ESP32 (the key word here is microcontroller). On these, you'll either use a smaller OS or go "bare-metal". Though note that Raspberry Pi makes things at this level as well (their "Pico" line).

For making that connection between computer theory and programming, I recommend experimenting with microcontrollers. You can even do some projects in assembly and understand what all the key registers are doing. I started on PIC micros, which was a great beginner thing. Not sure if they're still around.

If you want recommendations on a starter kit, let me know your budget and what country you're in, and I can send some suggestions.

Source: embedded programming for 20+ years.

I'm going to give a slightly different suggestion.

You may find it interesting to develop an program without using libc.

Use raw syscalls and make a completely freestanding binary.

This is not as low level as bare-metal but might give you a better understanding of how operating systems work.

You could try writing some core utils replacements

This will only really work on Linux though. Any systems programming language with inline assembly will work fine.

Get one of those learning kits that come with most of SBC/MCUs (like raspberry pi or ESP32) which have a lot of random stuff (like LEDs, motors etc.) that you can hook up to the pins and write C programs to control them. Learn the different protocols that are used to talk to other devices, like i2c, uart, spi etc. and then buy some hardware that you can talk to via this protocol. Like a sensor, a gps module or an IMU or EEPROM.

It's conceptually pretty similar to how computers and device drivers do it. There is some communication protocol and you can write or read some values over it to use any device. It's just way easier to start small and build up experience from there.

As a first time user in Lemmy, I'm so fascinated by the community, thank you all! I will be around so hopefully I can help others as much as everyone who commented here helped me.

For bare metal definitely get a microcontroller and do some fun electronics project.

Easiest to get into is Arduino, but don't stick with that because its only redeeming feature is that it's easy to get into. The IDE sucks, the build system sucks, the APIs really suck, and the code quality is very low (probably because it's easy to get into so you get a lot of inexperienced people doing stuff).

After Arduino I would recommend either going to the Nordic nRF5x series - you can do some cool Bluetooth stuff, or even make you your own radio protocol since the radio peripheral is fully documented... Or ESP32 with Rust and Embassy is probably the most modern and slick way to do microcontrollers.

It does require learning Rust but Rust is really really good so you should do that anyway.

There are some extremely good videos on YouTube about that: https://youtube.com/@therustybits

I would probably still start with Arduino though since you know C. Just don't stay there for too long.

Tangentially related to your question, Ed from Low Level has really good reverse engineering content that might pique your interest as well as a series of developer courses.

Get a second-nature understanding of memory and the execution loop and you'll be grand

This answer is going to go in multiple directions.

If you're looking for practice on using C to implement ways to talk to devices and peripherals, the other commenter's suggested to start with an SBC (eg Raspberry Pi, Orange Pi) or with a microcontroller dev kit (eg Arduino, MSP430, STM32) is spot-on. That gives you a bunch of attached peripherals, the datasheet that documents the register behavior, and so you can then write your own C functions that fill in and read those registers. In actual projects, you would probably use the provided libraries that already do this, but there is educational value in trying it yourself.

However, just because you write a C function named "put_char_uart0()", that isn't enough to prepare for writing full-fledged drivers, such as those in the Linux and FreeBSD kernel. This next step is more about software design, where you structure your C code so that rather than being very hardware-specific (eg for the exact UART peripheral in your microcontroller) you have code which works for a more generic UART (which abstracts general details) but is common-code to all the UARTs made by the same manufacturer. This is about creating reusable code, about creating abstraction layers, and about writing extensible code. Not all code can be reusable, not every abstraction layer is desirable, and you don't necessarily want to make your code super extensive if it starts to impact your core requirements. Good driver design means you don't ever paint yourself into a corner, and the best way to learn how to avoid this is through sheer experience.

For when you do want to write a full-and-proper driver for any particular peripheral -- maybe one day you'll create one such device, such as by using an FPGA attached via PCIe to a desktop computer -- then you'll need to work within an existing driver framework. Linux and FreeBSD drivers use a framework so that all drivers have access to what they need (system memory, I/O, helper functions, threads, etc), and then it's up to the driver author to implement the specific behavior (known in software engineering as "business logic"). It is a learned skill -- also through experience -- to work within the Linux or FreeBSD kernels. So much so that both kernels have gone through great lengths to enable userspace drivers, meaning the business logic runs as a normal program on the computer, saving the developer from having to learn the strange ways of kernel development.

And it's not like user space drivers are "cheating" in any way: they're simply another framework to write a device driver, and it's incumbent on the software engineer to learn when a kernel or user space driver is more appropriate for a given situation. I have seen kernel drivers used for sheer computational performance, but have also seen userspace drivers that were developed because nobody on that team was comfortable with kernel debugging. Those are entirely valid reasons, and software engineering is very much about selecting the right tool from a large toolbox.