- Joined
- Jun 21, 2012
- Messages
- 4,878
There are many dimensions to electronics, ranging from the design of microscopic integrated circuits to complex systems with thousands or millions of components. I decided early in my career not to get too involved with the the minutia of circuit design, leaving that to others who did not mind devoting years of their life to obtaining a single ambitious goal. Those people exist and are well paid for what they do. Their end-product is millions of identical components that do wonderful and almost unimaginable things, sold at reasonable prices. Most of these folks design dozens or even hundreds of devices before the end of their career. Some even start their own companies based on their original designs. Pretty risky business, that, but no rewards without risk in this world.
My goal, first and foremost, was to always have fun. If I didn't enjoy what I was getting paid to do, the salary didn't matter. Time to move on to something more interesting if or when that occurs. To obtain this kind of flexibility requires a broad theoretical background coupled with practical experience and a spirit of adventure. The theoretical background is the bed rock on which you base your career. Without it, you are just a hobbyist hoping for the best, almost blindly trying this or that in the hope of succeeding. Nothing wrong with that, and it could be part of the learning process, but it is not a good basis for a professional career in electronics.
I happen to also be a hobbyist, going back to when I was about six years old or so, when I built my first "crystal set," a simple AM radio that needed no power to operate. Between then and graduation from University with a Bachelor of Electrical Engineering degree in 1978, some twenty-eight years later, was quite interesting. At first I thought I knew more than I really did. Then I found out how much I didn't know and took courses to correct the deficiency. Finally I reached my level of incompetence when I took an honors course in Linear Algebra. Had to drop out of that one somewhere in the neighborhood of Abelian Rings. Why did I take this course? Well, I enjoy designing control systems, and modern design typically uses a transfer matrix to describe the system. I thought linear algebra had something to do with that. I should have asked my adviser before signing up for the course.
Don't over emphasize the practical experience. When I obtained my current position I knew virtually nothing about particle accelerators and had zero experience operating or maintaining them. In fact, I was not their first choice to hire. The company wanted someone with experience who could not only operate particle accelerators (we had two of them) but also troubleshoot and maintain them. They spent several months intensively trying to recruit a local fellow who operated a low-energy ion implant accelerator for a semiconductor manufacturer whose headquarters was here in Dayton. This guy was basically an appliance operator. Someone gave him an implant recipe and he set up the accelerator. Fortunately he also knew his limitations. He may have been able to keep our low-energy accelerator running by replacing modules and components, but our high-energy tandem was way beyond his capabilities and experience. He turned their offers down, despite several interviews and pleas, and who-knows-what bonus incentives. Meanwhile, the physicist who did operate these two accelerators wasn't having fun, nor did he know how to maintain or repair them. He might have been a good physicist (he certainly understood how the accelerators operated), but he had neither the incentive or skills to troubleshoot and maintain them. He found a real physics position at Argonne National Laboratories and gave the company two or maybe three months notice to find his replacement.
One week before his departure they called me in for an interview. I had responded to a local newspaper ad months previously, submitting my resume but had received no response... not even an acknowledgement that someone had even looked at. I was unemployed at the time, working part-time through a temporary labor service to make ends meet. They hired me more or less on the spot and I received one week of on-the-job training from the departing physicist. I had no idea what I was getting into, but the salary offered was good. That was in 1997 and I am still having fun, although at age 70 semi-retired and working about 20 hours per week.
My advice: stick with the books and learn a lot of theory, even if you can't put it into practice immediately. I know it's hard to just read how or why something works without actually seeing how it works, but make the effort anyway. In particular, look into computer architectures to get an overall view of what is going on inside.
My first "real" microprocessor was an Intel 8080 which has an 8-bit data path to the outside world with a 16-bit linear address space. It fetches instructions as one-, two-, or three-byte sequences from memory. Inside, an instruction decoder addresses a ROM containing microcode that tells the internal circuits how to function. This "microcode" knows how many bytes to fetch for each op-code, and what to do with them. It takes 4, 5, 7, 10, or 11 clock cycles for these internal circuits to complete a single 8080 instruction, the length depending on what the instruction must fetch from internal register or external memory and what the instruction does with the operands. Decision instructions involving conditional branches take the largest number of cycles.
This is more than I ever wanted to know about 8080 internals. I didn't care then (and don't care now) how the program counter causes an instruction to be fetched, decoded, and one or two operands (if necessary) subsequently fetched before the instruction actually executes and the program counter moves on to the next instruction. Sometimes I did need to know how long this would take, as when writing interrupt service routines for real-time processing.
My goal, first and foremost, was to always have fun. If I didn't enjoy what I was getting paid to do, the salary didn't matter. Time to move on to something more interesting if or when that occurs. To obtain this kind of flexibility requires a broad theoretical background coupled with practical experience and a spirit of adventure. The theoretical background is the bed rock on which you base your career. Without it, you are just a hobbyist hoping for the best, almost blindly trying this or that in the hope of succeeding. Nothing wrong with that, and it could be part of the learning process, but it is not a good basis for a professional career in electronics.
I happen to also be a hobbyist, going back to when I was about six years old or so, when I built my first "crystal set," a simple AM radio that needed no power to operate. Between then and graduation from University with a Bachelor of Electrical Engineering degree in 1978, some twenty-eight years later, was quite interesting. At first I thought I knew more than I really did. Then I found out how much I didn't know and took courses to correct the deficiency. Finally I reached my level of incompetence when I took an honors course in Linear Algebra. Had to drop out of that one somewhere in the neighborhood of Abelian Rings. Why did I take this course? Well, I enjoy designing control systems, and modern design typically uses a transfer matrix to describe the system. I thought linear algebra had something to do with that. I should have asked my adviser before signing up for the course.
Don't over emphasize the practical experience. When I obtained my current position I knew virtually nothing about particle accelerators and had zero experience operating or maintaining them. In fact, I was not their first choice to hire. The company wanted someone with experience who could not only operate particle accelerators (we had two of them) but also troubleshoot and maintain them. They spent several months intensively trying to recruit a local fellow who operated a low-energy ion implant accelerator for a semiconductor manufacturer whose headquarters was here in Dayton. This guy was basically an appliance operator. Someone gave him an implant recipe and he set up the accelerator. Fortunately he also knew his limitations. He may have been able to keep our low-energy accelerator running by replacing modules and components, but our high-energy tandem was way beyond his capabilities and experience. He turned their offers down, despite several interviews and pleas, and who-knows-what bonus incentives. Meanwhile, the physicist who did operate these two accelerators wasn't having fun, nor did he know how to maintain or repair them. He might have been a good physicist (he certainly understood how the accelerators operated), but he had neither the incentive or skills to troubleshoot and maintain them. He found a real physics position at Argonne National Laboratories and gave the company two or maybe three months notice to find his replacement.
One week before his departure they called me in for an interview. I had responded to a local newspaper ad months previously, submitting my resume but had received no response... not even an acknowledgement that someone had even looked at. I was unemployed at the time, working part-time through a temporary labor service to make ends meet. They hired me more or less on the spot and I received one week of on-the-job training from the departing physicist. I had no idea what I was getting into, but the salary offered was good. That was in 1997 and I am still having fun, although at age 70 semi-retired and working about 20 hours per week.
My advice: stick with the books and learn a lot of theory, even if you can't put it into practice immediately. I know it's hard to just read how or why something works without actually seeing how it works, but make the effort anyway. In particular, look into computer architectures to get an overall view of what is going on inside.
My first "real" microprocessor was an Intel 8080 which has an 8-bit data path to the outside world with a 16-bit linear address space. It fetches instructions as one-, two-, or three-byte sequences from memory. Inside, an instruction decoder addresses a ROM containing microcode that tells the internal circuits how to function. This "microcode" knows how many bytes to fetch for each op-code, and what to do with them. It takes 4, 5, 7, 10, or 11 clock cycles for these internal circuits to complete a single 8080 instruction, the length depending on what the instruction must fetch from internal register or external memory and what the instruction does with the operands. Decision instructions involving conditional branches take the largest number of cycles.
This is more than I ever wanted to know about 8080 internals. I didn't care then (and don't care now) how the program counter causes an instruction to be fetched, decoded, and one or two operands (if necessary) subsequently fetched before the instruction actually executes and the program counter moves on to the next instruction. Sometimes I did need to know how long this would take, as when writing interrupt service routines for real-time processing.