This is a bit of a side step to the article, but I recommend anyone who wants to really learn low level programming try to write a simple piece of software for the NES. The 6502 is well known, how the NES operates is likewise well known. Is not easy by any means, but I found it to be very rewarding and instructional to how computers work. Alternatively, following Ben Eater’s 6502 computer videos is likewise instructional.
I admit this may have had the effect on me because the NES had a special place in my childhood.
I would go for the GBA, which has a much more comfortable processor, and some very nice graphics hardware. It really hits a sweet spot for capability vs. constrainedness.
You build up a computer from simulated logic gates, constructing the ALU, CPU, Ram, I/O etc. The opcodes are comparable to those in the CPUs you mentioned, but you have the added benefit of the magic that occurs when it is able to process those opcodes. The best part is, thanks to the courses exceptional guidance and streamlining, it only takes about half a day or so to get it to that point.
After that you can follow the rest of the course to making a compiler, etc. Or you could move to an NES emulator as you mentioned. The nand2tetris halfway mark would also be a good jumping point for the principles, compiler, and RISC equipment mentioned in the OP's course.
I once designed a microcoded bit slice processor on paper. It's useful because it's conceptually simple enough to get in your head. And there isn't anything software related that really can't be mapped to it. Or an extension of it.
I've been working on a project off and on where I'm implementing the processor described in that course on an FPGA. Most of the digital design is done at this point: https://github.com/ibeckermayer/Nand2TetrisFPGA
I never cared about low-level programming, until I got my hands on the PineTime/Colmi P8 smart watch. With just 64KB of RAM and 514KB of Flash memory, you can't avoid it.
In just a few days, I learned a lot about:
- Memory allocation
- Image encoding
- Bluetooth
- Drivers
I recommend it to anyone interested in learning embedded systems programming.
This is actually pretty great. I was looking for a way to dip my toes into low level stuff. After skimming a bit it seems very focused on hardware though. Out of curiosity how does it compare to https://jaycarlson.net/embedded-linux/ ?
Most of what embedded is, is hardware. To build the low level software and drivers requires a detailed understanding of the hardware and its datasheets. It would be pretty hard to give a generic overview of the software side these days, because there is just so much out there. I mean you have the TI parts for the beagle bone which have a pair of microcontrollers on them each having access to the same memory as the main processor. There's the video processor on Broadcoms chip in the raspberry pi. Understanding any of the details of these components requires understanding most of thousands of pages of documentation. Most people wait for someone else to do it for them!
In the old days the only peripherals were timers and ADCs. You could make a generic and useful tutorial for those. Not anymore!
After a few decades in the biz I'm seeing things change. Almost all drivers these days are written. Embedded is more about integration. It's also interconnected with many web-based tools and operating systems.
I wish all drivers were written. Aside from things like arduino/pyboard the choice in my experience has been using some massively bloated questionably tested vendor code or just going to the data sheet and writing it yourself.
Everything is analog, your rise time, your standing waves, your sensors and everything has parasitics. My rule of thumb is that anytime you tell yourself you will avoid learning something in electronics you will eventually have to learn it. That said, you can get a very long way by knowing almost nothing at all beyond high school science and playing lego, and I'm not talking about arduino at all. Need an Analog Front End? Take one from a reference design, take their code while you are at it. Want to know what is messing with your circuit? Learn and understand Maxwell's equations, or put it on a scope and google about. If you want to get products manufactured there is a lot to learn but if you do normal well understood things you don't need to be brilliant or talented.
Thanks, I got the idea. So basically the deeper you go the more fundamental you have to go back, right?
I'm also considering a bottom up method that starts from (re)learning circuits from high school physics classes. Back then, IIRC we also used breadboard and I very much enjoyed the experiment part of the course.
Check out "Introductory Microcontroller Programming" by Peter Alley (to be clear, not me.) for Wocester Polytech; I came across this by accident the other day -
Over the period of being the TA for these courses multiple times, I learned a great deal, but also noticed several recurring issues the students seemed to face. In addition to furthering my own knowledge on the care and feeding of microcontrollers, this thesis is an attempt to provide students with a resource to overcome some of their difficulties, to provide a better understanding of the hardware level operation of a microcontroller, and as instruction into improving their knowledge and code.
edit: in addition, for really low level hardware, check out Ben Eater's series on YouTube building a breadboard 6502
I admit this may have had the effect on me because the NES had a special place in my childhood.