Assembly Language Survey Results and Comments

Fred Cady
Department of Electrical Engineering
Montana State University
Bozeman, MT 59717
(406) 994-5976
fcady(aatt_sign)ece.montana.edu

Download this report as a text file
Look at the survey instrument
Many thanks to all who responded with information and opinions about teaching assembly language to students in their first microcomputer course. As you read the comments below, you can see that many people responded in very thoughtful and insightful ways.

Here are the numerical results for the main questions in the form.
----
Did you have an assembly language course when in college?
Yes - 32, No - 4
---
If yes, do you think it was a valuable learning experience?
Yes - 28, No - 2, Questionable - 1
---
Did you have a high level language course which was related to embedded system design?
Yes - 7, No - 28. C was the language used by most of the yes respondents.
---
Have you used assembly language since you graduated?
It is interesting to break the responses into those who are now in an embedded systems job and those who are not.
Embedded systems designers: Not embedded systems designers:
Yes - 18, No - 6 Yes - 6, No - 6
---
Have you used a high level language since you graduated?
Embedded systems designers: Not embedded systems designers:
Yes - 22, No - 1 Yes - 10, No - 0
---



In the responses quoted below I have indicated the year of graduation and the profession (working in embedded systems or not) for the respondent.

Was learning assembly language a good educational experience?
This, and the following questions, are best answered by reading the great responses received. The bottom line for this question is that overwhelmingly it was a good experience.
---
Yes. It gives a firm grounding in the actual hardware. This is useful even if you never do "embedded systems" since most high-level programming still benefits from a "low-level" understanding. ( 84 Not Embedded Systems)
---
I thought the lab was valuable in learning the material. I never really had a good understanding of what was trying to be taught in the class. So basically I could program the HC11 to do what I wanted but I didn't always know how it was working. ( 93,'95 Embedded Systems)
---
I believe that the courses taught at MSU on microprocessors and their programming clearly illustrated the basic architecture and workings of a modern microcomputer. This knowledge has been very useful when talking to programmers and hardware engineers. ( 96 Not Embedded Systems)
---
I would say INvaluable. It is inappropriate for an EE to take a computer design/architecture class without having learned to program assembly language, in my opinion. I learned a *lot* about how computers do arithmetic, how they do flow of control, how to substitute memory for time and time for memory. I also learned that I never wanted to do a large program in assembly language -- a lesson that some people end up having to learn the hard way by trying it. ( 76 Embedded Systems)
---
Yes. First learned MIX at MSU and picked up Sigma-7 assembly language on my own. Have used knowledge of assembly language on almost every system I have used in 25 years. ( 69 Embedded Systems)
---
It is a necessary evil. (Not Embedded Systems)
---
Absolutely. Even though about 90% of my work is in C, I understand pointers and intrinsics of the language much better as a result of my assembly understanding. ( 82 Embedded Systems)
---




Do you think students in their introductory course should be taught assembly language or a high level language?

This question was somewhat poorly posed because I assumed that students would, in an introductory programming course, learn an HLL before taking a microcomputer course. I wanted to find out about whether or not a student should learn assembly language or HLL in their introductory microcomputer/microcontroller course.
---
Without question, students should be required to have experience in both higher level languages and in assembly language. When I went through those courses at MSU, we were still learning on the x86 architecture machines. The following year the curriculum changed to use the MC68HC11. I have had experience with both now, x86 and 6811. I believe that students should need experience in both of those architectures in terms of assembly language. ( 94 Embedded Systems)
---
Yes. Assembly language is not a course many engineers would normally think of taking on their own. Since so much electronic equipment is microcontroller driven these days, students are bound to come into contact with some sort of micro design problem some day. ( 95 Not embedded Systems)
---
Yes. High level languages are perfect for making small programs to do repetitive and time consuming tasks. Even if there is a "Software Group" as there is at AMI to do the programming, it is still good to have a general understanding of programming to more effectively communicate and understand your needs and limitations. ( 95 Not Embedded Systems)
---
Yes, I might not use the assembly language, but you must know some high level language to be useful in any job. ( 95 Not Embedded Systems)
----
I think students should be taught Assembly Language in their introductory microcomputer course, rather than a high level language. First, I don't believe that the student would have a grasp of the higher level language yet in their career to understand what is happening. Second, it is beyond me how you could teach the hardware basics of a microprocessor without using the basic assembly commands. ( 95, Not Embedded Systems)
---
I feel that if you can program in assemble level language you should be able to program in any higher level language at some level. It is much harder to accomplish things in assembly then in a higher level language (typically) but at the same time the programs you're going to write in the working world will probably require more than the average EE could do in assembly language. The ideal situation would be to have both assembly and a higher level language like C, C++, or Perl. If I had to pick one I would choose the higher level language since it seems more practical for me here at HP. ( 95, Embedded Systems)
---
High-level languages should be taught in introductory courses. Programming concepts are easier to teach with high-level languages, and the students are probably familiar with them. Assembly language should be a "200-level" class and should be a lab associated with a course on computer architectures. ( 85, Embedded Systems)
---
Both. Often one will be much more useful for a certain project than the other. I feel by taking the high level language first that it became more clear to me what was happening in the registers when I took the assembly language and I then understood the process the computer went through. I feel like I enjoyed the assembly language much more and got a much better understanding from that class. ( 96, Embedded Systems) ---
I believe that the introductory courses should use a high level language because 1) I believe concepts can come across more clearly in a higher level language (or more properly, "register bookkeeping" is pushed back to a lesser role), 2) efficiency (speed/time) will come from choosing proper algorithms instead of just clever coding tricks, and 3) save the assembly for a "improving particular hotspots" section. ( 87, Embedded Systems)
-----
A combination of both would be most useful. I can only speak for myself when I say that there are many, many, many employment opportunities for software developers with hardware background. ( 96, Not Embedded Systems )
---
Depends on who the course is geared to & how much detail is possible. Definitely as a second course. Learning Assembly really clarifies how the machine works, something that is often left out or glossed over with higher level languages. This knowledge is very applicable when programming in higher level languages - you get experience using logical operations (AND OR, ect.), the structure behind constructs such as a FOR & WHILE loop becomes apparent. Even structured programming benefits from the experience of maintaining data types manually. (Student)
---
I feel the students should know at least one assembly language before finishing a microcomputer course. To be stuck with only knowing high level languages restricts your options when using the limited resources of a microcontrollers. Programming a Basic stamp is quick and easy, but you pay for this with speed and memory. If you're designing a system without knowing assembler, you will overlook some useful solutions. ( 80 Not Embedded)
---
Both. Must have ( 92 Embedded Systems)
---
Yes. To learn programming principles at the uP level. ( 81, Prof Embedded Systems)
---
Assembly - because it is "Micro" controller class - students will learn more about the inner workings of microcontroller from assembly than they will from a higher level language. ( 95, Not Embedded)
----
Here where I teach there is a School of Technology but no engineering school. The focus of our program is software engineering, and most of our graduates work as programmer analysts. The Small-Scale Systems course I developed is designed to balance out the warped view of computer applications which our graduates might otherwise have; i.e., that most "computer systems" are in fact Embedded systems with a microprocessor or microcontroller.

The course I teach is based around a project involving the M68HC11E1 . The students come in with very little hardware background other than an Intro to Computer Technology course which I also teach. The students have an assembly course where they learn some VAX assembly and something about computer organization. This background is not nearly enough for them to understand how the 'HC11 actually works.

When I was first designing the course I leaned towards doing the programming in a high-level language like smallC or some such. For pedagogical reasons I now use assembly language exclusively, because otherwise the students do not understand what the micro-controller does and why. Without it they cannot begin to understand the Motorola reference manuals.

As some other respondents have noted, 6811 assembly has taught
many of my students how pointers work, about the stack, etc., things that in principle they have been exposed to in other courses but didn't master.

Unlike the situation in a computer engineering department, only a few of my students will ever be involved with Embedded system design and development after graduation. Compared with the projects that the engineering students at other schools write about, most of my students' projects are pretty rinky-dink. But the learn a great deal from them, not just about Embedded systems and interfacing, transducers, etc., but also about computer organization and function.

If I ever need to develop a second course in Embedded systems design, I would probably use a high-level language like C++ and more exotic, expensive development tools. But in summary, for the _first_ course I use and will continue to use assembly language. I would advise you to do the same, unless you are reasonably sure that the students have learned some microprocessor assembly beforehand. ( 59 ,'70, Prof, not Embedded)
---
I don't see how you teach instruction sets and basic models of computation without some kind of assembly language. This has nothing to do with the value of knowing how to write programs in assembly language, it has to do with learning the way processors work.

I think people doing embedded design or computer engineering are likely to need that kind of basic machine model for the foreseeable future, whether they need to write programs in assembly language or not. ( 70,'81, Embedded)
---
Assembly. Learning assembly first gives a deeper understanding of pointers, registers, addressing, and I/O... all of which are vital for an understanding of C. ( 94, Embedded)
---
Assembly - it forms a foundation for the higher level languages, much like math does for engineering in general. It helps to understand what's going on at the lower levels. ( 86 Embedded Systems)
-----
Both - To understand how a computer works you need the basics just like teaching math you have to teach the foundation first the you can build on it.

I have written a program in C and then looked at the compiled Assembly to try to speed it up. I have found many places where I could make it more efficient.

I don't think a person can design effectively without understanding how the internals work. The only way I know is to teach Assembly. Keep teaching it. ( 87)
---
I think it is a necessary foundation to allow the student to understand the tradeoffs that he/she must make when programming in a high-level language. If the program is to be used in an embedded system, it is imperative that these tradeoffs be understood or the cost/performance of the system will be wrong. ( 80 Embedded Systems)
---
Favor C primarily because our students take an introductory ANSI C course and don't have to learn another language in order to program the HC11. Illustration of basic subsystem concepts and operation can be done with very little C code. ( 66 Prof)
---
In practical terms, a high-level language is more relevant to real systems development. None of the systems we have built has more than a few lines of (our own) assembly code in it. However, there does need to be some reference to machine language concepts where one is dealing with a very small machine, such as the embedded controller in many instruments. So.. the answer is to major on a high-level language, but to ensure that the concepts of accessing hardware, dealing with events, etc. are adequately treated ( 72 Embedded Systems)
---
You start with assembler, since it helps understanding the hardware and debugging the software written in (say) C. Without capability to read compiler listing files you are like a baby in the woods! ( 77 Embedded Systems)
---
Yes, as it gives the students practical experience in how a microprocessor actually operates internally and how it interfaces via I/O. ( 91 Embedded Systems)
---
I think it is critical that they learn both. I would start them on a high-level language to teach fundamental concepts (conditional testing, variables, expressions, boolean operations, subroutines, ...), then teach them assembly language so they can appreciate what is going on when they do those operations.

Assembly language is important to teach because it brings engineers to a better understanding of the hardware underneath, gives a better appreciation for what compilers do, is a useful skill once in a while when exploring the capability of a specific machine to implement a specific inner loop, and occasionally to do a useful (hopefully small) program in. It is *not* the implementation language of first choice, but it is something that will be preserved as an option in an engineer's palette of skills should the need arise.

All engineers should learn to be competent in a high-level programming language. In fact, "competent" is probably not good enough -- expert is more what is needed much of the time. The computer is an essential tool. The choice of programming language is problematic: for some disciplines, MathCAD or Mathematica is a much more appropriate programming language than C or Fortran. However, exposure to a high- level language in order to learn fundamental concepts is crucial, so in practice, it probably doesn't matter what language(s) gets used for an early programming introduction. C is an acceptable choice.

I think teaching assembly language BEFORE teaching a high-level language is probably bad for an engineer's long-term development; this may or may not be a common opinion, but I feel strongly about it. Because it is a feature of human learning that people tend to create mental paradigms the first time they encounter something new, and forever interpret things in that problem domain in terms of those paradigms, it is important not to "poison" someone into a permanently inefficient style of thought. It is more efficient for people to think in terms of subroutines, expressions, and complex conditional tests than it is to think of what register to use to hold the temporary result from adding two numbers together. There's always room in a brain for more detail -- asking a brain to generalize a concept out of detail is a taller order. ( 72, 76, Embedded Systems)
---

High-level language; the process of programming an embedded system is language-independent. Use of a high-level language would allow more time to concentrate on the fundamental aspects of embedded systems (timing, memory layout etc.). Assembly language is increasingly not required in real-world embedded programming, and a competent programmer can learn a new language quickly anyway ( 81 Embedded Systems)
---
Yes to understand the details of what is done by a higher level language ( 65, Not Embedded Systems)
---
Students must learn assembly language at some point. It should not be the focal point of a microcomputer course. If possible, students should have an understanding of computer architecture which should have already introduced them to typical Instruction Set Architectures and at least one assembly language. They should also understand how languages (C, C++ especially) are represented in assembly language (calling sequences, linkage conventions, local variable allocation, efficiency of various types of constructs, etc.) and what kind of environment (stack frame, exception handling, etc.) is required to support a high level language on a 'bare' processor. More important to the actual course should be the relationship between external signals and the embedded application, how real-time responses are handled, complexity analysis of algorithms, memory requirements, etc. that can be done just as well in C as in assembly language (given that students know how C is translated into assembly language). 90% of class time should be spent on making the microcontroller perform typical embedded applications, not on how the actual program will be written. ( 69 Embedded Systems)
---
They should. If the course involves specialized hardware applications (typical for the HC05/HC11), cost-effectiveness will be an issue. Code has to be fast and compact. For hardware prototyping, you may use high-level languages, but the final application will be better off with assembly. ( 93 Embedded Systems)
---
Software is important to any engineer. They should be taught a high level language and I believe C is a great one, because it can be used on many platforms (like the HC11). The students should have one or (preferably) more courses on C programming. Students should then be introduced to the HC11 using assembly. Once they have a reasonably good grasp of that, THEN give them C. C on a microcontroller isn't nearly as sanitized as it is on a PC so they need a good understanding of the fundamentals underneath C. That being assembly language, strong stack knowledge and parameter passing, and a good understanding of the HC11's architecture. Why? Because if they ever have any programming bugs (and they will) they will often need to "get down to the metal" to find out what went wrong and why.

Having said that, I think C is the ultimate destination. I've really enjoyed using it. I took a poll of the students though, and they were less enthusiastic. Many of them felt that C on the HC11 had a steep learning curve. Data types and typecasting played a far greater role than one can imagine. (Professor)
---
Depends on whether you're trying to teach programming or micros -- asm teaches more about the low-level details of registers and bit flags and shifting, etc. C is more practical if the goal is to quickly produce working code. Both are probably necessary ...( 84 Embedded Systems)
---
I think the first language should be Pascal as it would be necessary to learn first how to make programs in any language. Then it is quite easy to learn other languages and even assembly.

I think Forth is an ideal language to program yC's, but perhaps it is too controversial to suggest it. (Not Embedded Systems)
---
In an introductory course, I think teaching them how to use the system is the most important thing. Not everyone knows how to use a PC, or a Mac or whatever. Having an understanding of the basics should be the requirement, fighting file systems and editors can be a nightmare, then moving on to the language is next.

If the users understand how to use the system, then teaching them any language should be easy. Learning C might be a good first step, as long as it is taught with a view towards how the microcontroller works (++I is like INC, pointers are memory, etc). ( 82 Embedded Systems)
---
I believe a higher level language would be appropriate in an introductory course, simply because by using a higher level language one can learn the constructs of 'good' programming style (functions, parameters, etc..). Also, even though most students have taken a higher level language course already, there is little time spent on 'coding' and more time spent on learning the language. I believe time spent on looking at 'real' code in a higher level language would allow them to see and understand the advantages of constructs that are common in all code, as well as seeing code that is particularly well suited for embedded/micro-controller applications. Also, in my experiences too often EEs are portrayed as folks who are not capable of writing 'maintainable' code, but instead write code that gets the job done with no attention paid to readability. The trend in industry has shown that there is a desire for 'maintainable/re-usable' code, and that getting the job done may be secondary to getting it done so that it can be used again. Software maintenance is by far one of the biggest programs facing most companies, and with most 'hardware-only' solutions being brought into the 'firmware' area, good programming skills are a must. ( 94 Embedded Systems)
---
Yes, I did learn assembly language as an undergraduate. Heck, way back then we were punching holes in 90 column NCR cards with our stone axes and still trying to figure out whether analog or digital would win. [Ever programmed by patch panel?] One of my first courses included as part of the exam being able to pull the tube covers off in the dark after a power failure. [I think I still have some of the burn scars! ]

Now, *some years* later, I have a small military/civilian consulting firm, specializing in embedded processor systems. I also teach, when the mood strikes me, for the Elect Engr. dept at The University of Texas.

*Most* of what we do is in assembly language. Whether it is designing a seismic drop-tube for the petroleum guys, or a countermeasures system for the Air force, that is the best way to get the most bang out of the system. We are always on a power/heat/space budget, and that means the least of everything doing the most it can.

The last class I taught at UT was "Microprocessor Design and Programming" and we used the MC68000, followed by the 68HC11 -- a backward arrangement that I am still trying to convince the Dean to let me change. Assembly language is used as the teaching tool, *not* because the majority of the students will ever write that much stuff in assembly (even *I* will admit that ours is a rather niche market), but rather because that is be best way to understand the internals of the processor, the data busses, and how the whole thing manages to actually *be* a computer.

I would be the last to suggest that a major accounting package for Windows '95 be written in assembly -- but what Bill Gates can do in 33 megabytes, I can do in assembly in a few dozen K. One of the examples I use in my class is similar

"-- if you want a real nice user interface for a program you are going to run a few times, then hey, VisualBasic is real nice. But suppose you are programming the Remote Control unit for a new color TV, and the company plans to make 11 million of these. In C the program will take two weeks to write and debug, and need a 64kbyte ROM and an external RAM, plus glue chips. In Assembly I can do the whole thing in single chip mode, using the HC11's internal mask rom and ram.

The savings per unit is about 100 yen, or about 80 cents per unit. But it will take three months to write and carefully test/debug. Okay, 80 cents, times 11 million = $8,800,000, which allows for the programmer to be paid $35 million dollars per year and still improve their profit on the deal. I don't know too many programmers being paid that kind of money -- but it shows that there *is* still a place for assembly language programming, and for programmers who really understand performance programming."

Enough of the soapbox -- I think *my* bias is clear. If you are actually trying to teach how the thing works, how to make it "sit up and beg," and if you are teaching students that are supposed to be learning the HARDWARE as well as the software -- then let me *strongly* cast a vote for starting them off with assembly. (Embedded Systems/Professor)
---
Assembly language. They need to understand microprocessor operations at the register level. Gotta understand the hardware before you can design with it. Even when using C or some other high level language, there comes a time they will need to do stuff at the register or I/O address level that is made much more understandable if assembly language level instructions is understood. Also, lots of debugging of designs is done by creating little assembly language tools to twiddle bits. These routines may be called by high level shells. I also believe that there should be a follow-on course that uses C with some embedded assembly routines and PLDs to design and build some gizmo, the logical follow-on to EE361/4 and EE465. EE465 doesn't go far enough. Need a course that uses C (tweaked with embedded assembly routines) and PLDs for functions where the overhead on the processor is unwarranted.

You should give serious consideration to using an 80C51 base for the microcontroller courses. This is the industry de facto standard device family. The Motorola microcontrollers are in niches but not pervasive like the 80C51 stuff. ( 96 Embedded Systems)
---
Teach assembly language. Students gain a better understanding of computer architectures this way. They also learn how the design of a computer's instruction set can make it difficult/easy to generate efficient code. Finally, if the course deals with embedded systems design, then they'll likely have to write some assembly language code to control peripherals, deal with the processor status and control registers, etc. and so they'll need to learn it anyway. ( 91 Embedded Systems)
---
Yes! With a higher-level language, the exact working of the uP is not seen; there is a level of "magic" between the code and the actual running of the CPU. In my classes I go one step further; I have the students translate from assembly code into machine code --by hand--. After they experience this, and see the one-for-one mapping from assembly language to the machine language, then I let them use assemblers. Of course these first programs are small (3 to 20 lines), and the following programs are approaching hundreds of lines, which I do not advocate translating by hand.

I feel it is a must for today's students to understand the logical constructs, and to appreciate the flow from high-level language down to the machine-code which the CPU is executing. Without seeing, and working with the assembly language, and the corresponding machine code, many students don't see the clear connection. Too many hidden, magical, things in a system will confuse and intimidate some students, leaving barriers up which obscure the actual workings of the system.

Once the system is viewed from this level, I can then talk in higher-level concepts and use high-level languages or pseudo-code to map out logical program structures. I also find it useful to contrast various assembly languages, and to take a simple program (C or BASIC), and translate it into many different assembly languages for the students.

One last technique I use is to look at the resulting assembly code generated by a C compiler for simple programs. This helps the students see actual mappings from C to assembly code. ( 90 Embedded Systems/Professor)
---
The goal in this class is "to study" the organization of the microprocessors not "to use" the microprocessors/microcontrollers. The assembly language is a tool to study the organization of the microprocessors. Writing the program in high level language could be used later in the student projects. (Prof)
---
===============================================
When you look 5 years into the future, what skills do you think today's students should be learning to find jobs in areas which apply microcontrollers/microcomputers?
---
All engineers are going to have to continue to improve their programming skills both in higher level programming and at the machine level. Students at MSU are not coming out with enough programming experience. ('94, Embedded Systems)
---
We put micros on everything from cars, to planes, to heavy equipment, to printers, to keyless entry systems. It is hard to imagine many areas in electronics where micros won't have a significant place in 5 years. Therefore, today's students should be learning not only assembly language, but also a high level language (preferably C).They should also learn their way around a microcontroller and microcomputer well enough to see a block diagram of one and recognize every part and be able to read a micro data book and understand it. If they are interested, I highly recommend learning how to design micros down to the transistor level. ( 95, Not Embedded Systems)
---
I'm not sure if assembly should be first or if it should be strongly emphasized, but I think getting some experience with assembly during the initial experience with a high-level language will give EEs a much better grounding the subject. I would contrast this to CS folks, who might have less reason to think about the hardware details.

Experience with high-level languages is a must. This category is actually so broad that I don't think one language is enough anymore. Non-traditional categories include Lab control (e.g. LabView),Simulation/analysis (e.g. MatLab, IDL, or any specialized or general-purpose language), and CAD/CAM (e.g. specific tools such as VLSI layout languages) ( 84, Not Embedded Systems)
---
Courses in Computer Architecture and CMOS VLSI design seem to me to be critical. Most of the people I know are nonworking in a field requiring knowledge in these areas and everyone of us that came from MSU had to do self study to learn enough to get in the door. As I go on I find that I am still taking courses to learn this material to keep up with the people I work with. ( 93, 95, Embedded Systems)
---
They must know assembly language. They must understand how a compiler translates high-level languages into assembly. They must understand that microcontrollers are memory and power constrained unlike desktop computers. ( 82, 85, Embedded Systems)
---
Java will be a player for its code density -- a concern in any embedded project. Knowing how to choose algorithms that are efficient in space will be important; plentiful VM on today's workstations has led to a certain lackadaisical approach to using memory efficiently.

Other than that, I believe that the important skills for continued success (and promotion) will involve being able to look at system-level solutions, problem decomposition and mapping onto other (already solved or solvable problems), and some of the classic management/leadership skills: estimation, tracking, and teamwork. ( 81,'83, 87, Embedded Systems)
---
Programming, system theory, self/time management. ( 80, Not Embedded Systems)
--
Entrepreneurship! The amount of opportunities in this area will be unlimited for people with the right ideas, the right knowledge, and sufficient business know-how to go into business on their own. ( 96, Not Embedded Systems)
---
PLD/FPGA design, VHDL or Verilog HDL hardware description language. ( 92 Embedded Systems)
---
Knowledge of lower level functionality, both h/w and s/w, as well as proficiency in higher level languages such as C/C++, and a knowledge of hardware communications interfaces. The ability to work with programmable logic devices is becoming increasingly important as well. ( 86 Embedded Systems)
---
Automated design. DSP. Busses, networks, and communication between many devices. ( 94, Embedded Systems)
---
I would think that some experience in assembler, a high level language *and* a real-time OS would be very valuable. ( 80, Embedded Systems)
---
One or more high-level languages
Operating system concepts (scheduling, resource-sharing) Hardware - timing requirements, trivia like handling the reset state
Logical thought
Written communications - particularly spelling and grammar. ( 72, Embedded Systems)
---
Sound engineering design skills. Everything else can then be learnt with relative ease. ( 91, Embedded Systems)
---
DSP techniques, digital filter design, hardware modeling / simulation techniques, programmable logic / ASIC design. ( 77, Embedded Systems)
---
DSP skills, an understanding of real-time scheduling and programming, excellent comprehension of the state of the art in data structures and fundamental algorithms, good programming skills. ( 72, 76 Embedded Systems)
---
A sound appreciation of microcontroller architecture would be a great asset. Exposure to more than one embedded architecture in the course would be very valuable. ( 81 Embedded Systems)
---
Program in assembly and C ( 65 Not Embedded Systems)
---
Requirements and domain expertise that will allow them to solve real problems which define product solutions. Performance analysis, validation, and verification skills to ensure that the actual implementation meets what the final customer expects. Ability to trade-off multiple HW & SW implementation methods to provide a cost-effective solution. Simulation and modeling skills that will allow the system design and software implementation to proceed in parallel with silicon or PC board development. Clear understanding of make vs buy decisions to get the product delivered on-time and cost effectively. ( 69 Embedded Systems)
---
Assembly on several cpu's, C, basic electronics, project management. ( 93, Embedded Systems)
---
C / C++ / Java; 16/32-bit microcontrollers; DSP; fuzzy logic; RTOS; Emulators / debugging techniques ( 84, Embedded Systems)
---
High level languages, development systems (ICE, debuggers, etc), networking ( 82, Embedded Systems)
---
Let me preface all of the below comments with the statement that my company doesn't have a very good 'training' program in place, and as such as a new hire you pretty much have to sink or swim. After a few months of acclimating to the work environment, you are responsible to get your job done in a timely manner with little help from co-workers. This tends to color my view of a new hire pretty significantly.

I believe the #1 area is experience of any kind. As a student I understand this is difficult to do with the busy schedules, but if they take the time to write *any* software (in or out of class) it will give them a 'leg-up' on the road. This software doesn't necessarily have to be in the area of embedded systems since solving problems with software is usually similar, especially given that most students have so little experience already.

Also, studying software written by others and trying to understand it is also a big help, since it gives the student the ability to judge for themselves the difference between 'good' and 'bad' software.

As a recent recruiter, the most difficult problem I had was trying to differentiate the more 'qualified' students from the 'average' students. The easiest way to do that was with grades, but grades alone aren't enough. Any kind of experience a student has gives them an edge over someone who has simply taken the classes, because it implies they care enough about their job to do something outside of class, and means they are that much more prepared for the job I have for them.

Finally, getting 'experience' with tools/controllers/OS's that are used in industry would be very helpful. In my interviews with Tektronix and Intel, they wanted experience with VxWorks and iRMX. I understand that keeping up with industry is a difficult prospect, but it would be nice to see MSU using products in class that are used by many of the companies that hire MSU EEs. ( 94, Embedded Systems)
---
Programmable Logic and ASIC design. Most applications that in the past would have been implemented with a microprocessor or microcontroller are today being done using FPGAs and other programmable logic devices. The power of the available devices is incredible, even compared with just a year ago. The EDA tools in industry allow for the direct conversion of a state-machine design to silicon in a matter of hours. Protos will use FPGAs and production will be done using an ASIC. ASIC design is becoming easier and easier with all the core designs that can be bought and combined, literally off the shelf. ( 96, Embedded Systems)
---
The basics are:
Microprocessor architecture (buses, memory, etc.). I feel every student should pick up a 68000 and wire-wrap a simple system from scratch to appreciate and understand these basics.
How the CPU operates (machine code)
I/O interfacing
Interrupts
Timing

These skills can be learned on small, simple systems, like the HC11. Once mastered, these skills are easily transferrable to other systems and architectures. a student who doesn't know assembly language, and the hex machine codes, will be at a loss when they need to hook up a logic analyzer to a data bus to see what the processor is doing. ( 90 Embedded Systems/Professor)
---
====================================================
Other comments:

I would like to see MSU offer a new Hardware Design Class. EE361/362 was excellent for teaching assembly and micro basics. EE465 was excellent for teaching micro system applications. But when it came down to transistor level/block level hardware design and implementation, there weren't any adequate courses offered at MSU. ( 95, Not Embedded Systems)
---
At some time in their college life, students should learn:
1) how to solve problems, and 2) how to manage themselves. ( 80, Not Embedded Systems)
---
Stick with HC11's. They have the features an engineer is likely to use in the field, and they're easier to learn than, say, an 8051. ( 94, Embedded Systems)
---
Include one or more team development tasks or even competitive assignments to help students understand that getting a product out fast and meeting customer requirements is what really counts. ( 69, Embedded Systems)
---
I think the trend is that future yC's are becoming more complex and using assembly is sometimes not even possible anymore, so good skills with higher level programming would be even more important in the future. But I think some skills with assembly are useful even if one never would use it.

I think assembly will be necessary with 8-bitters (except if you use forth, but sometimes there is also some assembly).

Personally I do not think C is a good way to start, but I am afraid that everything is going to be that way. I think Pascal is a very nice language to learn programming as there is all the necessary structures. But perhaps some object oriented language would be more suitable, perhaps even Modula-3. C is too close to assembler so people sometimes get confused with all the details and not to see the structure of the program.

I would teach students first some programming theory and then for example Pascal language to let students see some self made programs to work. I think it would be necessary to have some practical exercises and most important give student some feedback how they are doing. I have seen some really horrible ways how some people make programs (plug and play). Then in the next term the structure of a microprocessor and assembler in the side. Learning a new language is not so difficult if you know one language well. I learned Basic in about two hours with manual in my hand after two courses of Pascal.

A funny sideline is that when I made my Fortran exercise some friends asked me if I am writing pascal with a Fortran accent. (Not Embedded Systems)
---
Be SURE graduating students can do state-machine designs in their sleep. The following is a list of MUSTs for computer engineers and embedded systems engineers:
1) State-machine design
2) ANSI-C programming
3) Assembly language, preferably 80C51 (Intel).
4) VHDL, Verilog, AHDL, etc. Be sure they can design and debug using ABEL, MAX Plus II or similar packages. Xilinx and Altera cover the bulk of industry applications.
5) Schematic capture (not JUST for technology students!) Personally, I think all "engineers" should have to take the EEET 381/2 series and that Harley needs contemporary, powerful tools for those classes.
6) Device research. Need to be able to find devices and analyze the trade-offs between features.
7) EMI, RFI, ESD design practices.
8) High speed design rules.
9) Group dynamics. How to relate to others and handle project management tasks.
( 96, Embedded System)
---
Keep it simple and reachable by the majority of the students. The motivated ones will easily pick up the concepts and push them to their logical limits. Part of our degree program is a 2-semester senior project. Before I pushed these uP basics, none of the senior projects used microprocessors, and many of the projects were pretty lame. Over the last few years many of the senior projects are built around a CPU or microcontroller, and the overall level of the projects has increased significantly. It has been a true pleasure to see my seeds of uP knowledge take hold and influence these students. I highly encourage you to adopt a similar approach. ( 90, Embedded Systems/Professor)
---



---
================================================
What Platform and what language (Professors)
---
68HC11
If yes do you teach assembly language or a high level
language?
Assembly and C++
If a high level language, which one?
C++ ( 81, Prof Embedded Systems)
---

O-O methods, SDL and MSC notations, performance modeling, simulation. ( 70,'81, Embedded Systems)
---
HC11

If yes do you teach assembly language or a high level language?

Using C (ICC11 IDE cross-compiler), will deal with some simple
assembly language essentials later.

If a high level language, which one?

Ooops, already answered above.

What are your plans for the next 5 years or so to
accommodate the need for graduates in this fast growing
area?

The plan actually started last year, when the decision to move
away from assembly language and the Z80 to C and the HC11.So
what remains is to refine the HC11 sequence of courses. Exact
nature of the refinement may depend on your forwarding me a copy
of the summary of the results of this survey. I think the future
lies in serial communications networks between microcontrollers
of varying intelligence and PCS. ( 66, Prof)
---


--- 
Hello All:
============================================================
Assembly Language Programming Survey
December 1996

I'd like to ask for feedback and ideas on the value of
teaching assembly language in our microcomputer and
microcontroller course.  As we prepare for a new
Computer Engineering degree here at Montana State
University, and as the next catalog decisions will be
made soon, we have an opportunity to change the way we
do things.  At MSU all EE students are required to take
Microcomputer Software and Hardware Engineering.  This
course is based on the Motorola M68HC11
microcontroller, and the students learn assembly
language here.  Our overall goals are to prepare a
student to be able to either use, specify, design with,
or design embedded controllers in dedicated
applications.  The student should be proficient, or at
least have been exposed to, both hardware and software
engineering principles and practice.  The question is: 
"Should we continue to teach assembly language
programming to students in their first course in this
area?"  Your answers and comments, in the following
survey, will be very helpful to us in plotting our
courses for the next several years.

PLEASE FEEL FREE TO FORWARD THIS SURVEY TO ANYBODY YOU
THINK WOULD BE INTERESTED IN HELPING US.

PLEASE RETURN THE FORM BY EMAIL TO: 
fcady(aatt_sign)ece.montana.edu

Many thanks.  

Fred Cady

---------------------------------------------------
PLEASE GIVE US SOME INFORMATION ABOUT YOURSELF AND YOUR
JOB:

Year of graduation __________

Can your work be classified as "Computer Engineering"
or "Embedded Systems"? Y ___ N ___

Please briefly describe your job or your interest in
microcontrollers/microcomputers.
(OPTIONAL)





Did you have an assembly language course when in
college? 
Y ___ N ___

If yes, do you think it was a valuable learning
experience? 



Did you have a high level language course which was
related to embedded system design?  
Y ___ N ___

If yes, which language?


Have you used assembly language since you graduated? 
Y ___ N ___

Have you used a high level language since you
graduated? 
Y ___ N ___


Do you think students in their introductory
microcomputer course should be taught assembly language
or a high level language?  Please tell me why.




---------------------------------
ADDITIONAL QUESTIONS FOR STUDENTS:

Are you now taking or have you taken a course where you
learned assembly language?  
Y ___ N ___

If yes, do you think this has helped you learn more
about the hardware?  
Y ___ N ___




---------------------------------------
QUESTIONS FOR PROFESSORS OR INSTRUCTORS:

Do you have a course where students learn software and
hardware engineering for embedded systems?  
Y ___ N ___

If yes, what platform/processor is used?


If yes do you teach assembly language or a high level
language?



If a high level language, which one?


What are your plans for the next 5 years or so to
accommodate the need for graduates in this fast growing
area?




-----------------------------------------------
QUESTIONS FOR PROFESSIONALS WORKING IN INDUSTRY:

When you look 5 years into the future, what skills do
you think today's students should be learning to find
jobs in areas which apply
microcontrollers/microcomputers? 


-----------------------------------------------
DO YOU HAVE ANY OTHER COMMENTS YOU WOULD LIKE TO OFFER?




----------------------------------
DEMOGRAPHIC INFORMATION (OPTIONAL):

Name

Address




email address