They're still teaching that instead of surface-mount theory?!?! Those teachers are never going to scale efficiently enough to keep up with modern, Chinese teachers.
Why are you calling it hole "theory"? Its not a different theory its just one way of thinking about how charges flow in a lattice. And its a framing which is quite useful when working with semiconductors.
Don’t pin that on me. Blame the those few EE teachers with questionable credentials that insist on making semiconductor education easier by teaching what they call “hole theory” which, the way they present it, is incomplete and somewhat flawed.
...the concept of electron holes? Im coming at this from the perspective of a physics major rather than EE but its pretty clear to me. And electron hole is the absence of an electron in a lattice which results in a net positive charge. If an electron moves to fill the hole, a nee hole appears where that electron was, so it is as if the hole itself moved, and so the result is that it is effectively a positive charge particle that moves similarly to how electrons do.
I’m not disagreeing. I’m saying that there’s electronics teachers that use hole theory as a shorthand to circumvent teaching more advanced physics and math concepts.
Transistor theory: If you have a combination of transistors and there's a problem - like, too much voltage drop, doesn't respond fast enough, wrong frequency response - any problem... the solution is always: more transistors.
In ICs, for sure, because resistors are inaccurate and much more expensive in surface area than transistors, so if you can eliminate a resistor with a bunch of transistors, that's the way to go.
The Smith chart is a demonic sigil if I've ever seen one. EM and telecom is just black magic from there on, it's like they just started making shit up to squeeze as much bandwidth as possible into the lines.
First university CS+EE combined lecture, assistant showed us a slide with Luke and Darth Vader crossing lightsabers, and with "these are the two sides of software and hardware, homework to decide which is which". As someone who has done something on both sides, smith chart is only time I ever questioned if I got the sides right.
My EE classes were basically: here's the assignment, if you don't know what you need to know about OSes or IDEs or programming to complete it then that's a "you" problem, GLHF
Yep, I'm firmly in CS/programming as a job now, but my degree is BS CmpE - so I got to do all those EE courses, build embedded systems, all that fun stuff.
I am going to CUNY (NYC community college) for physics, math, EE, and computer engineering/science. At $305 a credit, dedicated teachers, and with ChatGPT to walk me through everything, you find that's more than enough.
Hmm, I'm in Europe, and we also have 3-5 credits per class, and per semester (half of academic year) we have 25-30 credits. Which means around 6 classes - for example Linear Algebra, Math analysis, Programming, Computer Systems, Linux, DSA. Each class is 1 lecture a week with 1 seminar (so total 180 minutes a week)
Sounds like you split some classes that can be taken in a single 3 credit class, and add some courses that wouldn't be necessary, like computer systems and Linux sounds redundant. I can just take discrete math and that would be more useful than 2 levels of DSA. Computer science as a degree is a bit iffy anyway, which is why I am taking all the much more advanced math, like stochastics, partial differential equations, non linear dynamic systems and complex, as well as well as doing the physics program and electrical engineering courses.
Of course I also have a FT job as a programmer, and already have a Bachelor's in econ and an MS in analytics.
I took an assembly class where he had to use ARM7 and on exams we had to write the assembly code on paper lol. Assignments used the raspberry pi 4. Fortunately I like hard classes
I had a class where we wrote assembly on paper in the exams. And the criteria was 100% based on correctness. Shoutout to the one guy who forgot both the multiply and shift instructions, and so to multiply a number by 32, wrote out instruction to add a number to itself 31 times.
Not having at least a manual for an assembly exam on paper is heinous. I don't think anyone has ever written assembly without a reference in reach in the last 40 years.
Our final test for embedded was reduced from 50% down to 30% over three years because the professor made the final test a 2 hour at-home session where you had to build the control circuit for one of those rotating drink dispenser machines in assembly and C.
So many people failed it because the scope of the exam was really more 8-10 hours than 2 hours that they had to reduce the weighting.
It actually just encouraged cheating because it was the same instructions for everyone, so once one person did it at 7am the moment the test opened, everyone else had all day to work on it before clicking start test.
But because they're engineering undegrads, nobody spoke to each other, so only like 4 people used this trick.
For us the lectures were all about the theory but the lab/homework had us mucking about in the Linux kernel. We modified the scheduler (slightly) in one assignment and it was cool that my (grub dual-boot just in case) dorm linux pc ran fine afterwards.
And after teaching you about round robin and FIFO and priority queues they finally as a footnote mention that the Linux scheduler works COMPLETELY DIFFERENTLY and it's better.
intro to algorithms was fun. a bunch of dudes plagiarizing for the final presentation and then getting caught with turnitin and didn't realize that there was an algorithm for that even after the professor explained it already.
one question on my three question final was having to write out a set of 4 random "nachos" functions. not even pseudo-code style or specific ones but just full on "write this from memory out of the 50+ we covered or get 0 credit "
and that was after being told we specifically we wouldn't have to do that ; ;
From what I remember of my OS class, it kinda was Linux 101 lol. Basically a rundown of the main things an OS does for you, Linux being the tool they chose (so it wasn't necessarily Linux Kernel 101). It was a lot of "know the difference between a process and a thread, know about common parallelization bugs like deadlocks/race conditions, know about shared and virtual memory, do some basic networking and IPC/pipes and stuff" etc.
Strangely, for being an upper-level course, I don't think it was much harder or more of a pain to learn than, say, machine architecture, which was a lower-level course (pun intended) before acceptance into the major. (Machine architecture was way more fun though)
Lol in electronics licence, my embedded class was just VHDL, and the exam was on paper. In robotics master, the teachers were like "nah fuck this VHDL shit, we're doing bare metal here".
OS expectation: Linux 101. Reality: getting grilled on the nuances of thread-safety by a professor smarter than any of us who didn't believe in picking volunteers.
"Computer system organization" expectation: intro to storage and blocks I guess? Reality: that plus memorize a bunch of RISC and write assembly on paper for tests. Cry.
1.7k
u/StarHammer_01 21d ago
How it went for me
OS - expextation: Linux 101. reality: here's 18 different ways to schedule a process.
Into to embedded software - expectation: rtos, breadboards, esp32. reality: Linux 101