In 1997 I was doing an apprenticeship. It had a very well organized curriculum and well thought courses. One course was based on 8080/8085 cpu. You know what they gave us: A development board (roughly the size of a modern mainboard) with onboard hex keyboard 0-9a-f and 3-4 function keys (halt, run, write at ... something like that). And a book and templated paper. So the exercises, 3-4 hours every week, were: Implement that algorithm on paper in assembler, use the book to translate to hex code on your memory layout, hack the program into your board and press execute. And PRAY that you did not make a mistake in the assembler or the typing.
I still think, that this is the most efficient way to teach kids CPU/Memory and assembler.
I can still "sight-read" much of the x86 instructions from a hexdump or even (E-)ASCII --- the ISA is much easier to memorise and more regular in octal. This is a habit I acquired from the days when I did a lot of binary patching, for various reasons, and good disassemblers weren't yet easy to come by.
A couple years ago, a junior dev was absolutely astonished at my ability to interpret a hex dump as ASCII. I don’t think I remember any numeric opcodes for anything.
My first 6502 bringup on a breadboard was just a CPU and ROM (no RAM) with A9'H'A9'e'A9'l'A9'l'A9'o' while it was attached to a logic analyser so I could see if it was running. Shortly after I got ram working and added a UART, but it was the easiest instruction to see something I recognised and keep the PC moving forward through memory (Of course NOP is good too, but then I don't know if reading is working right or if I'm just reading the same thing over-and-over).
Also my assembler wasn't working, so I had to enter that directly in the TL866 ROM programmer's hex editor & didn't remember any other opcodes.
Yah! I was familiar with old "microprocessor trainers" and I tried to recreate that. There's nice on-chip debug that makes writing a monitor to do this pretty easy.
I was more thinking-- curriculum? How old were you? Anything particular stick with you that I should be sure to include?
I was 17 to 19 at the time. We had everything, from math, physics, electronics, chip design (board layout simulation etc), micro processors (and after a year assembler on a DOS PC), networking, operating systems (mainframe + Unix + NT), C, Pascal, VBA. Add generic programming, English, project management and some other courses you need for soft skills. 18 months, 40 hours a week, two tests a week all with a full stipend for everyone. After that, you are hardened.
So the curriculum mentioned was more contextual than specific to microcontrollers. They created generalists which are capable of deep diving where they are then used within the company. For microprocessor in detail, I think they focused on translating algorithmic problems and higher level constructs into op codes (something like tail calls).
Wow-- that's really awesome-- a very deep generalist curriculum.
This is along the lines of what I'd like to ultimately create. It's hard, though, because I am offering this in the form of electives, and students have limited slots to fill and as they get older their willingness to take any risk in selecting a class decreases. I teach in both high school and middle school, and I've found I can be a lot "bolder" in what I teach in the middle school so far.
IMHO middle and high school do not have the life focus and specialization yet. Hacking on a microprocessor trainer is no fun and definitely does not bring you anything if you are not in CS and even then you can survive without.
I did give them system calls to draw sprites and things on the LCD.
My students had fun competing over all the challenges. Scored very well in the anonymous post-class surveys, too, though I did have one critical score. Also the majority of the students from that class are electing at least one of my classes next year.
Each year I teach one "crazy" class with undergraduate level material to MS students. This year it's going to be circuits. They're going to learn KCL/KVL, transistor biasing, oscillators, amplifiers and gates, how to use decoders and logic gates to spell things on 7seg displays, etc.
> definitely does not bring you anything if you are not in CS
I think knowing what a computer actually is is valuable information to know.
> IMHO middle and high school do not have the life focus and specialization yet.
That's one of the nice things about having an elective-heavy school. They do a deep class on computer architecture, then they go participate in a musical, then they take a 3d art class. Immerse yourself deeply in lots of things to see what's interesting and to get exposure to many ideas.
When I was faced with that task, I rapidly got fed up with hand-assembling and relocating my code and went off to write an assembler to run on a computer with somewhat less anaemic IO. I doubt I actually used it more than once or twice, but it was fun to write.
I still think, that this is the most efficient way to teach kids CPU/Memory and assembler.