As my ME friend (at that time, roommate) was chugging through the book, he'd randomly come up and ask me questions or points of clarification. This culminated one evening during dinner.
He, my other roommate (a Linux sysadmin/applied mathematician), and I (software developer and former ME) were enjoying some Indian food, and the ME began bugging us about interrupts. He couldn't understand quite what they were useful for.
So, over the course of four or so hours, we probed him with questions geared towards increasing his understanding. Something along these lines transpired:
ME:"So, what are interrupts good for?"
SD: "Well, they're good for getting the processor's attention. How would you handle checking if a button is down?"
ME: "I could have processor check a line in."
SA: "And if that check happens to miss the button press?"
ME: "...erm, I could have something else check it, faster."
SD: "And how would you check it?"
ME: <thinking hard> "You...could have the switch be controlling a bit of the memory, I guess."
SD: "But you still haven't told us about how to solve interrupts."
ME: <several more suggestions that are basically around polling>
SD: "Let's think about the problem. What you want to do is have the processor poll the button, right?"
ME: "Yes."
SD: "And only do this when it's needed, right?"
ME: "Yep."
SD: "So, what if there was some kind of way of signaling the processor that data was ready?"
ME: "...oh. I guess you could use a pin for that."
SD: "What would that pin do?"
ME: "I think it would have to tell the processor to go handle input."
SD: "And how would that work?"
ME: <several suggestions about dedicated copying logic>
ME: <converges to idea of setting program counter to interrupt code in memory>
SA: "What happens if I want to go somewhere else to handle my interrupt code?"
ME: <suggests looking up equivalent of jump instruction to trampoline into handler>
SA: "You've just invented the interrupt trap vector!"
...etc...
So, by the end of the night, with proper questioning we'd gotten him to come up with MMIO, with virtual memory, with paging, and eventually gotten him to consider how to implement concurrency via scheduling and his newly discovered virtual memory mechanism.
It was delightful, and wouldn't have been possible unless he'd been getting the lay of the land from reading Code.
edit: oh god the spacing
edit2: processor's, not processors
The easiest way is probably through a hobby, in the widest sense. Be it a Science Fiction club, a HN meetup, a charity that helps connect disadvantaged high school kids with technology and programming, toastmasters international or some political activism. Basically any thing that involves meeting other people, and, as a filter, requires a certain minimum level of commitment and getting-off-your-ass.
If you are in Germany or Britain, I can give you more concrete pointers.
I just thought I'd mention this as well.
As my ME friend (at that time, roommate) was chugging through the book, he'd randomly come up and ask me questions or points of clarification. This culminated one evening during dinner.
He, my other roommate (a Linux sysadmin/applied mathematician), and I (software developer and former ME) were enjoying some Indian food, and the ME began bugging us about interrupts. He couldn't understand quite what they were useful for.
So, over the course of four or so hours, we probed him with questions geared towards increasing his understanding. Something along these lines transpired:
ME:"So, what are interrupts good for?"
SD: "Well, they're good for getting the processor's attention. How would you handle checking if a button is down?"
ME: "I could have processor check a line in."
SA: "And if that check happens to miss the button press?"
ME: "...erm, I could have something else check it, faster."
SD: "And how would you check it?"
ME: <thinking hard> "You...could have the switch be controlling a bit of the memory, I guess."
SD: "Congratulations! You've invented memory-mapped I/O!"
SD/SA: <give brief spiel on MMI>
SD: "But you still haven't told us about how to solve interrupts."
ME: <several more suggestions that are basically around polling>
SD: "Let's think about the problem. What you want to do is have the processor poll the button, right?"
ME: "Yes."
SD: "And only do this when it's needed, right?"
ME: "Yep."
SD: "So, what if there was some kind of way of signaling the processor that data was ready?"
ME: "...oh. I guess you could use a pin for that."
SD: "What would that pin do?"
ME: "I think it would have to tell the processor to go handle input."
SD: "And how would that work?"
ME: <several suggestions about dedicated copying logic>
ME: <converges to idea of setting program counter to interrupt code in memory>
SA: "What happens if I want to go somewhere else to handle my interrupt code?"
ME: <suggests looking up equivalent of jump instruction to trampoline into handler>
SA: "You've just invented the interrupt trap vector!"
...etc...
So, by the end of the night, with proper questioning we'd gotten him to come up with MMIO, with virtual memory, with paging, and eventually gotten him to consider how to implement concurrency via scheduling and his newly discovered virtual memory mechanism.
It was delightful, and wouldn't have been possible unless he'd been getting the lay of the land from reading Code.
edit: oh god the spacing edit2: processor's, not processors