4 ms·
Hi, embedded developer here. Learning electronics and lower-level computing concepts is very fun, and I'll always encourage it. But I also don't think you need
by mafuyu 3y ago
Hi, embedded developer here. Learning electronics and lower-level computing concepts is very fun, and I'll always encourage it. But I also don't think you need to feel particularly anxious about it. For some perspective, web stuff scares me, and while I have some passing knowledge of things like CSS, React, SQL databases, Docker, etc., I'd be hard pressed to actually use those technologies to create and stand up a modern web service without lots of research and learning.
"How a computer works" is very broad, and covers a lot of different disciplines. Like everything else in computing, it's layers of abstraction, and there's a lot of depth you can go into at any level. What you're describing is basically an ECE undergraduate curriculum, but it's very possible to get a "tour" of various layers in less time than that without going to school for it.
There's a lot of different ways to approach learning, and the bottom-to-top tourist approach is certainly one way to do it. I personally would not recommend it, as you're going to run into lots of different concepts that will take time to digest, and some of the tooling will be rather opaque or foreign, without a mentor to guide you. Another approach would be top-to-bottom, where you do some C systems and kernel hacking and work your way down from there. If you the art of programming and Computer Science, that might be a better fit, but there's also lots of arcane stuff in Linux and x86 that can be demotivating. The approach I advocate is usually the "maker" one, where you hang out in embedded systems land, and come up with projects you want to make. The benefit of embedded projects is that your projects will be physical things that interact with the real world (which may or may not be actually useful). That lets you explore a breadth of topics as needed, but is a bit adjacent to your goal of "knowing how a computer works".
Re: geohotz's curriculum, have others actually done his course? The curriculum looks interesting, but laser focused on bringing up a CPU in Verilog and bootstrapping the OS in C. I'm not sure how easy the course would be without at least some Verilog and systems programming background. 12 weeks seems very aggressive, and you're gonna end up missing concepts if you try to do it at that pace. The course I usually see recommended is nand2tetris, but I haven't tried it myself.
For foundational curriculum, I would probably recommend:
* The CSAPP Book (https://csapp.cs.cmu.edu/ https://csapp.cs.cmu.edu/) - The introductory systems programming book/course. The labs are really good; do them! You could probably spend a year just with this course and come away satisfied. It'll have you interfacing with computers in C, learning about how cache works, writing your own malloc, doing some networking code, etc.
* Circuit Design - Optional, but some electronics knowledge doesn't hurt, depending on how far down the stack you want to go. Don't need to go into the fancy stuff, but should at least know enough of the basics to understand how transistors work, and how they can be used to form gates.
* Digital Design / FPGA stuff - I don't have a good rec for this. Nand2Tetris? There are some interesting projects out there that make FPGAs more accessible, like fomu and the reverse engineered open lattice toolchains.
* Computer Architecture by Hennessy & Patterson - Guides you through the concepts of a CPU, and has you writing your own MIPS CPU in Verilog. ARM is cool and all, but for a toy CPU, MIPS is a little more manageable, IMO. If you try to go straight to comp arch without some base level of digital design/FPGA/Verilog experience, you will probably have a bad time or end up with some gaps in your knowledge.
- mafuyu 3y agoI should add my personal opinion, too. FPGAs and comp arch can be fun, but are largely academic, IMO. Unless it's your _thing_, it just provides you with lots of background knowledge when writing OS and systems level code. Messing around at the systems/OS/embedded level will be more fulfilling and scratch the same itches.