EEVblog Electronics Community Forum
Electronics => Microcontrollers => Topic started by: Vernichtung on August 29, 2017, 12:42:38 am
-
Hi guys,
There isn't a dedicated processor thread so I figured I will put this in with Micros and FPGA's.
I am studying Electronic and Communications engineering at RMIT University. For the most part the experience has been reasonable albeit expensive.
Something which has kind of irked myself and my fellow students is our perceived absurdity of our Digital signal processing micro apps class.
The instructor is having us program a Motorolla DSP56800 processor using assembly language. |O
This processor is older than most of my fellow classmates and as far as I can tell it isn't used in industry anymore. Learning to use a device that isn't used in industry
to me is absurd.
From an employers prospective i'm thinking why would I hire me who knows how to program on old hardware which isn't used over someone who can program current hardware....?
Moreover the device needs specific programming hardware not obtainable by students meaning we are limited to class specific lab time to have hands on with the tech.
Something like the Discovery Dave reviewed last week would be ideal as it's low cost and "all inclusive" layout means the students can purchase and learn via tinkering on the actual hardware itself rather than relying exclusively on theory and testing in class.
I am the Student Staff Consultative comity representative and have been asked by my Cohorts to raise this with the university.
We are wanting the class to teach ARM processors over this ancient tech.
Therefore I have a few questions i'm hoping someone on here can help with.
I need to demonstrate to the program manager / Dean that,
1) The hardware isn't used in industry / isn't in demand enough to warrant it's use in education.
2) The skills gained from learning on said hardware are not easily applied to learning current hardware.
3) The cost benefit of changing hardware is positive.
4) Changing the hardware will be of significant benefit to the students and the reputation of the university.
5) The fundamentals can be equally taught using modern ARM processors.
Can anyone offer any advise on how I can demonstrate the above 5 criteria?
If you cant could you just answer the following few questions, it may be helpful to show the answers to the Dean and Program manager.
A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)
Thank you all very much and we look forward to working with you in the near future. =D
-
I studied programming (IBM 370 assembly, FORTRAN, COBOL) using punched cards (years 1985 to 1990). Ended having a successful career working for several multinational computer hardware and software companies. The tools you use to learn is not important.
-
I studied programming (IBM 370 assembly, FORTRAN, COBOL) using punched cards (years 1985 to 1990). Ended having a successful career working for several multinational computer hardware and software companies. The tools you use to learn is not important.
Thanking you kindly for the reply.
We don't doubt that we can transfer the skills to new hardware and as such that we will have successful careers in the industry.
We are caring about ensuring we are prepared for the industry, About our employability and ensuring the skills we are learning are relevant and position us above or on equal ground
to the thousands of other graduates applying for the same limited positions here in Australia.
-
Microcontroller/CPU classes still commonly use a 8080/8085/Z80. The goal is to teach you the basic principles which you can then apply in the real world.
DSP56k is still in use.
-
A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?
I hope they teach principles, not processors. If so, it doesn't matter what they use. If not, you have bigger problems than worrying about processors.
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
Irrelevant. Modern HR machine hires by matching resumes. Resume doesn't say what processors were used by your teachers in your classes. And I don't think anyone would ask you that on the interview.
C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?
This question is too vague to answer.
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
Programming is, first and foremost, a problem solving skill. I would try to figure out if the candidate is capable of solving problems. It would be of no concern to me what languages he thinks he can program.
E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)
The one which meets the requirements.
-
Microcontroller/CPU classes still commonly use a 8080/8085/Z80. The goal is to teach you the basic principles which you can then apply in the real world.
DSP56k is still in use.
I don't know anything about the device but it's in stock at DigiKey.
The 8085 is an excellent device for learning and from what I read, the 8051 is still being used.
-
I studied programming (IBM 370 assembly, FORTRAN, COBOL) using punched cards (years 1985 to 1990). Ended having a successful career working for several multinational computer hardware and software companies. The tools you use to learn is not important.
:bullshit: If you were a hiring manager, you'd be singing a very different tune. Those graduates will be at a serious disadvantage relative to their peers who will be familiar with more modern DSP platforms.
-
I propose that they are actually teaching this correctly, and there is a method to the madness.
Take the original Windows NT development cycle. NT was developed on non-x86 hardware on purpose so that it would reduce the chance of it becoming exclusively tied to x86 by depending on tempting x86-only features. As a result, it became on MIPS, Alpha, Itanium, and ARM.
I would just hold out and do as you're told without getting cocky with your uni about this. It may not seem relevant now, but these old computers can teach you not to be a bloat-infested high-level abstraction-addicted developer if you are willing to learn how to properly optimise your code without getting trapped in the "oh who cares about resource management, there are plenty on modern CPUs" mentality.
If more modern developers were taught this way, I reckon the software world would be a better place and I may just be inclined to work in that field.
Also there are only so many processors a uni can teach their students while allowing them to complete a degree in a reasonable amount of time. You don't get a Bachelor's Degree in ATmega with a Xilinx devices major or a Master's Degree in Obscure Moribund Hipster Architectures as it would be rather useless and limiting.
Another explanation is that these processors were used for 20 years and clearly they helped to teach the students successfully. If the uni sees this success rate continuing then it isn't necessary for them to spend extra on new equipment. Ultimately a uni wants productive students who will be headhunted, as it gives them the ability to market themselves better. Remember, "if it ain't broke, don't fix it."
-
Arguably you need a teaching CPU, MCU or DSP chip that's simple enough for the top 10% of the class to fully understand in detail within the course duration, and for the next 80% to fully understand in overview. If you pick a chip that's too complex, all you are doing is training 90% of the class to be cargo cult code monkeys stringing together manufacturer supplied library routines with little to no understanding of how and why they work.
IMHO the Microchip range of MCUs is probably a good place to start looking for educational processors, because of the wide range of cores - all the way from their 12 bit instruction word baseline core up to the PIC32 range with high performance MIPS M4K cores. Some of the low end PICs really suck from a programmer's point of view, but learning to cope with a severely resource constrained device with an idiosyncratic architecture helps you become a more well-rounded programmer.
Many of their chips are available in easily breadboardable DIP packages that will run with minimal external components, and their low cost programmer/debugger PICkit 3 covers the whole range, and clones of it are available for less than a burger meal for two so every student can afford to work at home. Free versions of all their compilers are available with the only restriction being limited optimisation. The 8 bit families use the proprietary XC8 C compiler or MPASM assembler, but the XC16 and XC32 compilers for the higher end devices are GCC based, and include the GNU assembler.
Look at the dsPIC33F range of DSP capable MCUs or possibly the dsPIC33EV range if you need 5V supply and logic level chips (so a simple USB PSU can be used to power the breadboard).
-
I propose that they are actually teaching this correctly, and there is a method to the madness. Take the original Windows NT development cycle. NT was developed on non-x86 hardware on purpose so that it would reduce the chance of it becoming exclusively tied to x86 by depending on tempting x86-only features. As a result, it became on MIPS, Alpha, Itanium, and ARM.
They began development on the i860, which was a bad decision that harmed the project schedule and accomplished nothing. And Windows NT was written in C/C++, not i860 assembly.
Also there are only so many processors a uni can teach their students while allowing them to complete a degree in a reasonable amount of time. You don't get a Bachelor's Degree in ATmega with a Xilinx devices major as it would be rather useless.
You have to consider how far behind the curve the 56000 architecture is, though. There is nothing portable about 56K assembly code, which means there are no analogies to be drawn with Windows NT.
Frankly, a modern DSP course shouldn't be using a dedicated processor at all. It should be taught with native code, interfaced to the real world using something like one of the Digilent ADC/DAC boards. The curriculum should also emphasize FPGA work.
-
Worry about whether or not you are properly being taught the fundamentals, not the features of a transitory product.
The fundamentals are why you are attend university.
-
I studied programming (IBM 370 assembly, FORTRAN, COBOL) using punched cards (years 1985 to 1990). Ended having a successful career working for several multinational computer hardware and software companies. The tools you use to learn is not important.
:bullshit: If you were a hiring manager, you'd be singing a very different tune. Those graduates will be at a serious disadvantage relative to their peers who will be familiar with more modern DSP platforms.
I have to agree: in a short-list (job-hire) contest between graduates who have experience with up-to-date tech, and those who don't, the ones with it will tend to win. This applies to experienced engineers as well. Keep current, or watch as your career prospects and market value fall away.
In a perfect world, hiring managers would recognize talented candidates who, for through no fault of their own, don't have the "right" resume. Breaking news: we don't live in that world. Film at eleven.
-
Which class is this specifically? Is this class your first introduction to CPU architectures and assembly, or a later year class specifically about signal processing in the digital domain?
(I'm avoiding the term DSP as it is used to describe both the practice of digital signal processing and a microcontroller optimised for the maths and operations involved in digital signal processing).
-
When I graduated in 2014 my school was teaching their undergrad DSP class with TI TMS320C6000. This will at least give you a data point to compare with
-
Worry about whether or not you are properly being taught the fundamentals, not the features of a transitory product.
The fundamentals are why you are attend university.
:palm: Here on this planet, classroom time is a limited resource. 56000 programming is not a good use of it.
Those students are going to spend a lot of time learning tools and, yes, techniques, that they will never see again, unless they retire after a successful career and volunteer at a computer museum.
This is nothing but sheer laziness on the part of the faculty. I don't blame the students for being annoyed about it.
-
Worry about whether or not you are properly being taught the fundamentals, not the features of a transitory product.
The fundamentals are why you are attend university.
:palm: Here on this planet, classroom time is a limited resource. 56000 programming is not a good use of it.
Those students are going to spend a lot of time learning tools and, yes, techniques, that they will never see again, unless they retire after a successful career and volunteer at a computer museum.
This is nothing but sheer laziness on the part of the faculty. I don't blame the students for being annoyed about it.
Yes. Classroom time IS a limited resource. This is why one focuses on the fundamentals.
By this logic, college students would ignore opamps, discrete logic, etc. as so much is integrated into a micro now. The likelihood of my using 7400 series logic in a design is low, yet there I was with everyone else, assembling state machines out of them.
The OP is learning to program in assembly language. That's a fundamental skill which largely does not depend on the specific processor and frankly, the simpler the toolchain, the better. The processor is merely a means to an end.
And before you go accusing the faculty of laziness, perhaps you should actually assemble a semester's worth of technical curriculum and teach it first. It's harder than it sounds. It is far better to recycle and refine a good curriculum and focus on student learning than to constantly be chasing the bleeding edge whatsit.
-
I am the Student Staff Consultative comity representative and have been asked by my Cohorts to raise this with the university.
We are wanting the class to teach ARM processors over this ancient tech.
No, you don't want to learn ARM for a DSP class. ARM is not a DSP.
Therefore I have a few questions i'm hoping someone on here can help with.
I need to demonstrate to the program manager / Dean that,
1) The hardware isn't used in industry / isn't in demand enough to warrant it's use in education.
2) The skills gained from learning on said hardware are not easily applied to learning current hardware.
3) The cost benefit of changing hardware is positive.
4) Changing the hardware will be of significant benefit to the students and the reputation of the university.
5) The fundamentals can be equally taught using modern ARM processors.
As for 5), no, non-DSP chips defeat the purpose of teaching hardware DSP.
Something like the TI 6000 might fit the bill though:
https://www.ti.com/processors/dsp/c6000-dsp-arm/overview.html (https://www.ti.com/processors/dsp/c6000-dsp-arm/overview.html)
Can anyone offer any advise on how I can demonstrate the above 5 criteria?
If you cant could you just answer the following few questions, it may be helpful to show the answers to the Dean and Program manager.
A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)
You need to go to them with a solution, not just a complaint.
Who will write the new course material for the new hardware? This alone could dictate everything. If some DSP manufacturer has DSP kit that targets courses with pre-prepared class material and project example, then there is your solution.
-
And before you go accusing the faculty of laziness, perhaps you should actually assemble a semester's worth of technical curriculum and teach it first. It's harder than it sounds. It is far better to recycle and refine a good curriculum and focus on student learning than to constantly be chasing the bleeding edge whatsit.
There should be a compulsory class called "dabbling with new shit" where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza.
-
A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?
I think learning should be done on hardware that is simple enough that its operating principles can be understood.
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
I do not select candidates on their technical skills, I select on their thinking and problem solving skills and on the depth of their insight and understanding (as best as can be learned from interview). In particular, I am less concerned with what someone has been taught, and more concerned with what they have learned.
C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?
This is not my field, but I do not expect professional engineers to have a hard time learning how to use new tools.
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
Someone who knows how to use assembly might stand out. How many people would have had the interest and curiosity to do that?
E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)
Again, not my field, but the answer to this question will depend entirely on the purpose. A commercial product in industry will have an entirely different answer to a teaching project in a university.
-
I see that ARM are pushing the DSP education market:
https://developer.arm.com/academia/arm-university-program/for-educators/digital-signal-processing
-
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
Someone who knows how to use assembly might stand out. How many people would have had the interest and curiosity to do that?
Yes I would assume any student has learned C/C++ as given.
Assembly stands out.
-
This could be potent:
Altera FPGA+ARM DSP educational stuff:
https://www.altera.com/support/training/university/overview.html (https://www.altera.com/support/training/university/overview.html)
-
They began development on the i860, which was a bad decision that harmed the project schedule and accomplished nothing. And Windows NT was written in C/C++, not i860 assembly.
And yet, Windows NT (including Win2K/XP/7/10/etc) is the world's most successful operating system. My point is not about what language the OS is written in, but that being flexible with your platforms does you a world of good. They could have restricted themselves to i860, x86, Alpha and MIPS, but they didn't. Now it's even available on ARM-based Windows devices. The point here is that even though a uni may teach you an old museum architecture, the skills and algorithms can be transferred to different environments if the fundamentals are taught right.
You have to consider how far behind the curve the 56000 architecture is, though. There is nothing portable about 56K assembly code, which means there are no analogies to be drawn with Windows NT.
The assembly code itself is not portable across the board, but the techniques used to craft that code are. Besides, it will do a student well to understand how historic architectures like the 56K worked, and how modern computers aren't actually all that much different in terms of their basic architecture (memory, CPU, I/O). When you go down to the basics, most of the technological advancements to this area have been with increasing the resources (CPU clock/bus speed, more memory and non-volatile storage, reduced I/O latency, caches, etc).
Frankly, a modern DSP course shouldn't be using a dedicated processor at all. It should be taught with native code, interfaced to the real world using something like one of the Digilent ADC/DAC boards. The curriculum should also emphasize FPGA work.
I think it's fine for it to be used as a supplementary teaching aid, but yes FPGAs are quite the norm these days, and it's going to be like that for the forseeable future.
There should be a compulsory class called "dabbling with new shit" where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza.
There were non-compulsory non-official variations of exactly this back when I was at uni, all thanks to security not giving a shit about students sleeping in certain buildings overnight. >:D
-
So let me throw some random thoughts out here which may or may not help:
An ARM is not a DSP. Some newer ones have DSP-friendly instructions or DSP coprocessors, but a DSP is generally a different beast than a general purpose processor. Let me quote a section from the DSP56800 datasheet:
Each on-chip execution unit, memory, and peripheral operates independently and in
parallel with the other units through a sophisticated bus system. The data ALU, AGU, and program
controller operate in parallel so that the following can be executed in a single instruction:
— An instruction pre-fetch
— A 16-bit x 16-bit multiplication
— A 36-bit addition
— Two data moves
— Two address-pointer updates using one of two types of arithmetic (linear or modulo)
— Sending and receiving full-duplex data by the serial ports
— Timers continuing to count in parallel
To paraphrase: That chip can, in a single instruction cycle, fetch an instruction, do a multiplication, an addition, move data to and from memory, determine the next address to grab data from, AND stream that data in and out of the serial ports. All at the same time.
By comparison, an ARM can often only do one of the above. Plus often each of those takes multiple cycles. I'm ignoring multicore here... since that is an entirely different beast which just complicates processing.
I can understand the desire to move to a more modern platform. But if this is really a DSP class in the context of learning about digital signal processors then you need to select one of the multiple DSP's out there, not a general purpose processor like ARM. If I was designing a DSP Class from scratch, I'd probably use a dsPIC33 - they're modern, dirt cheap, and slow enough that you have to learn how to work in a constrained environment. They're also widely used in places like motor control and power supplies where they are doing very quick analog processing at very low cost. Interesting dev boards are also available for not a lot of money (around the same cost as a typical textbook).
In relation to the age of the processor: don't forget that the ARM architecture is actually over 30 years old at this point.
In relation to programming in Assembly vs C: There is only one area which I know people still use assembly.... you guessed it, Digital signal processing. The reason? DSP work is often cycle-dependent. Even there, assembly is rarely needed. I'm skeptical that there is a valid reason for assembly here. But note that I said C, not C++. If you're working at the hardware level, generally you're going to use a C compiler, not a c++ compiler. Many of the things people like about C++ are incredibly inefficient, and on a DSP you care about every cycle.
BUT, the real advantage of Assembly vs C is that when writing in assembly, you learn quickly how much the underlying architecture matters. In a DSP, structuring things so that the processor can actually do all of the operations in parallel is important. You don't learn this without knowing assembly. I don't think that the goal would be to have you proficient in assembly language, but instead to be proficient with a typical DSP architecture.
One final thought: The question I have is what is the end goal of this course? If it's to familiarize you with DSP hardware architecture then hardware matters, and the teacher will want to pick a good, illustrative processor which is easy to understand. This might not be the fastest, newest processor. If it's an algorithms class, then the hardware matters less and there shouldn't be any assembly involved.
-
I think it's fine for it to be used as a supplementary teaching aid, but yes FPGAs are quite the norm these days, and it's going to be like that for the forseeable future.
I think that also addresses the points made about assembly language. Someone who is reasonably proficient in VHDL or Verilog has nothing to fear from any assembly language on Earth. The reverse isn't true (speaking from experience).
-
And before you go accusing the faculty of laziness, perhaps you should actually assemble a semester's worth of technical curriculum and teach it first. It's harder than it sounds. It is far better to recycle and refine a good curriculum and focus on student learning than to constantly be chasing the bleeding edge whatsit.
There should be a compulsory class called "dabbling with new shit" where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza.
Oh, yes!
Don't forget "fixing broken shit so it doesn't break again 254."
And, "un-hosing the last engineer's undocumented spaghetti Fortran (or insert arcane language here) 309."
-
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
Irrelevant. Modern HR machine hires by matching resumes. Resume doesn't say what processors were used by your teachers in your classes. And I don't think anyone would ask you that on the interview.
But resumes might say what you have experience with. And yes, I've been asked on my interview, what processors did I use previously.
-
Motorola DSP56800 is quite different from DSP56000 / DSP56300 series. DSP56800 is 16-bit device where DSP56K is 24-bit device. I haven't used DSP56800, but programming DSP56300 in assembly was very nice and smooth experience compared to TI's 16-bit processors.
http://www.nxp.com/docs/en/reference-manual/DSP56800FM.pdf (http://www.nxp.com/docs/en/reference-manual/DSP56800FM.pdf)
http://www.nxp.com/docs/en/reference-manual/DSP56300FM.pdf (http://www.nxp.com/docs/en/reference-manual/DSP56300FM.pdf)
Modern DSP architectures are typically heavily parallel and programming then manually by human in assembly is very hard in order to take full advantage the parallel execution units. That's why modern DSP processors are typically programmed in C/C++ as the compiler can optimize the code generation to take full advantage of the parallel execution units.
I would not consider ARM as a DSP although it does have some DSP instructions. For general a DSP course studying the general algorithms even ARM should be quite suitable, though.
-
It is an electronics study which probably explain the registers and all the inners of the DSP, so I need to look at the entire class material before I judge, but how can you explain the DSP instruction set without having the students directly use this instruction set?
Therefore I think some classes of assembly just to let the student get a feel of what is happening on a lower layer is productive but not for the entire class.
They should go to a c compiler after a few classes and move on.
Then another argument when I am debugging with a normal microcontroller I often look at the assembly the compiler generated, it will not be the first time that I see that some things are missing (optimizer just killed it) because of something I forgot (compilers are very good these days so I first look between the chair and the keyboard :) )
For a DSP I think this is even more trivial that you should have a feeling of the assembly.
-
Surprised they were not at least using the Sharc.
AD had some cool dev modules and tools when that came out and I've come across several designs using them (in audio anyway).
-
The education should teach you about fundamental principles that will last a lifetime not about specific tools which will be outdated in a few years. Isaac Asimov wrote a story about that 60 years ago, it stuck in my mind, and is still as relevant today. It is worth speed-reading http://www.abelard.org/asimov.php (http://www.abelard.org/asimov.php)
When learning, you need simple tools that allow you to see the fundamental principles; it is all too easy to become bogged down in boring and irrelevant details. See stackexchange for examples of "which button do I press", or "how do I set the timer to cause an interrupt" type questions.
Depressingly little has changed in 35 years, except things are smaller/cheaper/faster, nanopower is becoming practical, and ADCs/DACs are significantly improved. Coming back to doing embedded processing after 20 years, all the tools (MCU, C, in-circuit debuggers) were familiar. There is little sign that things will change radically in the next decade. Bonus points: understand what needs to change, and why, and the characteristics necessary in new approaches.
If you want to impress an employer, do a project on your own. That will demonstrate interest in the subject, drive, initiative, goal-setting, implementation and finishing, and that you have learned what you would do better next time.
-
The education should teach you about fundamental principles that will last a lifetime not about specific tools which will be outdated in a few years.
I agree 100% , but fundamental principles can be boring and out of touch with applications.
The problem with current generation students is that they would like a practical application of what they are learning and have a shorter attention span (yeah I know I am generalizing but google generation X, Y, Z and see I am not the only one).
So to get a students attention what is cooler than giving them the development board for home, be it a beaglebone, rasp pi , nucleo or whatever and learn them in class how to create some practical applications with them. They are more enthousiastic than a dinosaur board from 1990 that can't be bought and/or programmed these days.
However DSP boards are a bigger price and the applications are not very DIY friendly or you should be an audio freak.
So what probably happens on universities/colleges with older teachers is that they stick with what they know and have and do not invest themselves in new technologies and keeping up with developments.
That happened even when I was at college, we had to copy the book out of which he teached because there was a 3rd edition reprint out and 5 out of the 12 chapters dissappeared from the book and were replaced but the teacher refused to adapt the lessons and exams |O
-
There's another reason why "we" sometimes teach with old methods/devices: modern stuff is too perfect. When you're teaching opamps, per example, you can set up an excercise that gives bad results due to offset limations. With an ancient device, it will kick you in the face, quickly and without exception. Better devices will have vastly improved specs and will be less educational.
-
I actually find a few obscure assemblers or odd DSP chips to at least make a CV interesting, C on small cores should be a given...
However my number one interview question is "What have you built?", I actually tend to care about this far more then the details of some chip you may or may not know, I mean you will spend you whole career learning new chips, new languages and new ways of doing things, that is a given in engineering and is largely what makes it so cool.
I want to see the lessons that only come with building things, steam train, computer, rocket or treehouse I don't much care what you have built, but show me a passion for designing and making things and tell me what you would do differently if making that thing again (If there was a team involved, even better).
Maths, at least to the point of recognising the methods (I assume you are actually going to use matlab in reality), electromagnetism, DSP in a sort of Z transform and numerical stability kind of way, computer architecture, communications, some analogue some semiconductor physics, all that stuff is important, but without the desire to make things it is a route into financial services, not engineering.
Regards, Dan.
-
A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?
Yes. The specific type of hardware is irrelevant. Even digital hardware is irrelevant, for than matter.
The first DSP filter I created commercially was made from capacitors and switches, and had a Q of 4000 using 10% capacitors.
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
Yes.
I would hire someone that understands DSP. If they know that then they are in a decent position to choose whether to implement a solution in digital hardware, analogue hardware, mainframes, MCUs, DSP processors. Someone that only understands one technology is someone that will use a hammer to insert screws, because they have been taught how to use hammers.
C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?
In my case, after returning after 20 years, about 30 minutes. Depressinly little had changed. It took longer to decide on which tools to use and to install them.
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
Depends on the job. Nobody fresh from university will understand C++ (although they probably think they do). Even the language designers didn't understand what they were creating when they implemented templates - until someone rubbed their faces in it! https://en.wikibooks.org/wiki/C%2B%2B_Programming/Templates/Template_Meta-Programming#History_of_TMP
And then, of course, there's always the issue of which C++; later versions begin to overcome some of the infelicities in earlier versions - but you may not be allowed to use later versions!
E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)
An average processor, using average tools, and average programmers (because they are easily replaceable by cheaper average programmers).
-
If the DSP56800 family is older than some of your classmates you must be among some pretty young students. If I remember rightly it only reached the market in about 1999 or 2000. Oddly, perhaps, this makes it one of the younger processor cores on the market. The 56800 is NOT the 56000, or the 56100, or the 56300, which are all very different machines. It is a 16 bit core designed to execute DSP code well, without sucking too badly for bits of general purpose code mixed in with your DSP code. It is wrapped in a peripheral set that makes it really good for control oriented processing, like motor control, or digital power supplies. Its kinda clunky for most general purpose DSP applications, as none of the parts in the family have the kind of peripheral set or DMA controllers you would associated with general purpose DSP work.
Is your course supposed to teach you signal processing, or the nature of signal processing hardware architectures? If you are on a comms oriented course the 56800 sounds like an odd choice for teaching you either. If you are learning signal processing, the best place is on your PC. If you are learning about architectures for DSP in comms, something with a more appropriate peripheral mix would seem a better choice. The 56800 core is fine, but you really want to a device with rich DMA features, to see how most DSP applications are structured for good performance. They should probably also include some material about where FPGA/ASIC or processor based solution are more appropriate.
If you are learning about hardware architectures for signal processing you should be doing some assembly language work. Not huge amounts, but you should be doing enough to gain an understanding of just WHY things are structured the way they are, and how fragile performance on some of the key kernels of signal processing algorithms can be if the instruction set isn't quite right. DSP architectures can have instructions with extremely specific uses, limited only one application level purpose, because that thing turns out to be so important for performance on many occasions. You should get some basic understanding of these things. Remember you are at a respectable university, not a trade school running short courses. You should expect to gain in depth knowledge of the fields you study.
-
..... where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza.
that's my kitchen :)
-
I am the Student Staff Consultative comity representative and have been asked by my Cohorts to raise this with the university.
We are wanting the class to teach ARM processors over this ancient tech.
No, you don't want to learn ARM for a DSP class. ARM is not a DSP.
The distinction between typical DSP CPUs and general purpose CPUs has faded away over a decade ago. Most ARM cores have DSP instructions. Besides you can use any CPU for signal processing. There is nothing special about it because in the end it comes down to doing things with incoming data. Nowadays it is much more relevant to learn how to write robust algorithms in C/C++ instead of assembler. Branch prediction and caching make writing fast assembly language much more difficult while OTOH C/C++ compilers know all about the core's branch prediction strategy. The influence of caching can be perfectly handled in C/C++ by writing loops in a different way. Nowadays it is way more important to create code which portable so new products can be build on the foundation of existing products (code). You can buy performance but you can't buy time!
The DSP the OP refers to has been obsolete for quite a while now. It reminds me of a true story from about 2 decades ago. I was attending a technical discussion with a firm to see if we could use their DSP algorithms. x86 processor where starting to get way more powerfull than a handfull of DSPs on a board so we wanted to use a x86 for signal processing. It turned out all their DSP algorithms where coded in Motorola assembly for that specific DSP and therefore they couldn't port the code. They'd have to start writing from scratch. Ofcourse that didn't suit our needs so we ended up writing our own algorithms in C/C++.
Back in the old days I've also written DSP software in assembly but the Harvard architecture just sucked. Using things like lookup tables required to copy the table into RAM first IF there was enough space to begin with.
-
Something which has kind of irked myself and my fellow students is our perceived absurdity of our Digital signal processing micro apps class.
The instructor is having us program a Motorolla DSP56800 processor using assembly language. |O
When i was in college we had to learn repair TV's made out of tubes despite tubes being obsolete in TV's
for 25 years we didnt even get TV's made out of transistors. WHY? Becuse our mentor in repair TV class
was 64 years old and was about retiring next year so he didnt give a damn about us or the future!
So i can actually repair TV's made outof tubes! (fanfare) not that i ever had any use of that knowledge
in comercial life but in hobby life to build tube compressors with triods and pentods it did a tiny bit.
Strangely enough in 2017 tubes are more popular then ever! :horse:
https://www.youtube.com/watch?v=Xe1a1wHxTyo (https://www.youtube.com/watch?v=Xe1a1wHxTyo)
-
I am the Student Staff Consultative comity representative and have been asked by my Cohorts to raise this with the university.
We are wanting the class to teach ARM processors over this ancient tech.
No, you don't want to learn ARM for a DSP class. ARM is not a DSP.
The distinction between typical DSP CPUs and general purpose CPUs has faded away over a decade ago. Most ARM cores have DSP instructions.
I disagree. Although the differences between these have been reduced over the years, Digital Signal Processors offer much more in terms of special addressing and hardware loops - I clarify further here (https://www.eevblog.com/forum/microcontrollers/lowcost-dsp-for-beginner/msg232614/#msg232614).
Nowadays it is much more relevant to learn how to write robust algorithms in C/C++ instead of assembler.
Agree 100%. I used DSP56000 on my DSP labs in 1999 and it was somewhat outdated already - given the compiler was very weak, we did everything in assembly to benefit from the architecture intricacies. Nowadays the modern compilers relegate the usage of assembly to very niche applications - and certainly you would be hard pressed to justify presenting it throughout an entire semester.
Can anyone offer any advise on how I can demonstrate the above 5 criteria?
If you cant could you just answer the following few questions, it may be helpful to show the answers to the Dean and Program manager.
A) Do you think it is reasonable to be teaching DSP processors using this old technology or would you personally prefer to be taught on more modern hardware?
B) Would you hire a graduate engineer who was taught to use 20 year old processors over someone who was taught to to program current technology?
C) How long do you think it would take the average person to re-learn to use modern technology after learning this older tech?
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
E) If you are designing an average project which uses a processor, which processor would you choose? (Keeping costs to the average)
You need to go to them with a solution, not just a complaint.
Who will write the new course material for the new hardware? This alone could dictate everything. If some DSP manufacturer has DSP kit that targets courses with pre-prepared class material and project example, then there is your solution.
Agree 100%. The proposal must include a path for integration into the course. The choice of processor for a Digital Signal Processing labs class is something tricky, but this course was probably prepared twenty years ago and nobody took over to update it. Several much more modern architectures with dirt cheap DSP development boards such as the F28379D Launchpad (http://www.ti.com/tool/LAUNCHXL-F28379D), heaps of example codes (http://www.ti.com/tool/c2000ware) and even entire training sessions (http://processors.wiki.ti.com/index.php/C2000_Multi-Day_Workshop) have a much more practical use and will certainly give the students an edge when they leave for the marketplace.
Another that has an entire teaching class (http://processors.wiki.ti.com/index.php/C5000_Training_Archives#C5000_Teaching_ROM) is the somewhat older C5000 family.
-
To quote Professor Kingsfield in The Paper Chase: "You teach yourselves the law, but I train your minds. You come in here with a skull full of mush; you leave thinking like a lawyer."
-
To quote Professor Kingsfield in The Paper Chase: "You teach yourselves the law, but I train your minds. You come in here with a skull full of mush; you leave thinking like a lawyer."
But it would be nice if the students learn that using the laws used in the country they study in today and not the laws used in the Roman empire 2000 years ago.
-
A lot of good advice here.
One thing I learned was not to piss off the profs. They have big egos. I once complained about obsolete material and the prof said to take it up with the Dept Dean. I asked who that was and he said he was :-DD. I knew I was in deep doo doo. It turned out to be a hard course with him always calling on me. The next semester the course was changed.
I think someone said to go to the dept with a solution along with your complaint. Dave gave a couple of good sources for a school (I am waiting for EEVBlog Univ). My two cents are to go to the dept with that material and volunteer (along with some other students) to develop a course using this material. Say you and the others are willing to be TAs for the new course. Make it easy for the profs and school. I think this would look good on your resume. Who knows, maybe you will become a prof.
Keep in mind it is hard to train old dogs (your prof and me) new tricks.
Sometimes what someone writes brings back memories. Someone said they learned Fortran on an IBM 370 using punch cards. I also did. What I remember is I forgot "end" at the end of the code. When I started the program the guy running the 370 left the room. I watch the print out go through about 2 feet of paper before he came back and yelled at me. I used up all their paper and he closed the lab. I had no clue what was going on :-DD
-
To quote Professor Kingsfield in The Paper Chase: "You teach yourselves the law, but I train your minds. You come in here with a skull full of mush; you leave thinking like a lawyer."
But it would be nice if the students learn that using the laws used in the country they study in today and not the laws used in the Roman empire 2000 years ago.
Here's the thing... Much of recent laws find their origin in Roman times. And a lot of others have been put forward to patch up deficiencies of those laws. So if you understand the olden, simple laws of yesteryear you'll understand much of the new ones and you may see why others, seemingly overly complex and without purpose came to be... ;)
-
The instructor is having us program a Motorolla DSP56800 processor using assembly language.
Why are you so surprised and shocked?
DSP56000 is still used for Radar in avionics space and defense, and it comes with an excellent book targeting Motorola DSP56002, which has an interesting architecture as well as ISA!
In computer science it's also common to see courses based on 68HC11, as well as 68000, which are 38 years old at least!
You have to consider the complexity of modern staff, and you have to consider what really matters! Being focused on the iron? Or ... in getting the mind?
-
Vernichtung, I think you have the wrong expectations here.
First, as others have said, ARM is not a DSP. There are "DSP extensions", but it's still not a DSP.
Selecting the DSP56800 is not a bad choice for educational purposes. It has a general-purpose DSP architecture with all the elements for understanding what a DSP does: fast number crunching on real-time signals.
Sure, you can find newer devices, but they tend to add complexity not desirable for a basic course, like DMA etc.
Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.
Last, there is no real "industry-standard" for DSPs. Actually, most of the DSPs you won't even see, as they are often proprietary architectures deeply embedded in an SoC or loaded into an FPGA.
As an example, take the communication chips from Broadcom: they are shock-loaded with DSPs that do a fabulous job of filtering, demodulating, correlating, domain transforming etc., but you won't ever see them.
If you can put "Worked with and assembly-programmed DSPs used for ... " on your CV, you're in good shape.
"Worked with ARM" is a commodity today.
-
Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.
That is another misconception. Who ever said signal processing needs to be fast and/or time critical? Like only signal processing can be time critical?
-
Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.
That is another misconception. Who ever said signal processing needs to be fast and/or time critical? Like only signal processing can be time critical?
Are you trolling? I never said that. But a reason for using a DSP is real-time signal processing. Otherwise, just GOTO any micro and a BASIC interpreter.
-
It is an electronics study which probably explain the registers and all the inners of the DSP, so I need to look at the entire class material before I judge, but how can you explain the DSP instruction set without having the students directly use this instruction set?
The "DSP instruction set" is pretty simple. In fact, there are only two instructions, MUL and ADD.
The rest -- all the rest -- is architecture and implementation. Which are precisely the areas where it doesn't pay to fall 20 years behind.
-
Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.
That is another misconception. Who ever said signal processing needs to be fast and/or time critical? Like only signal processing can be time critical?
Are you trolling? I never said that. But a reason for using a DSP is real-time signal processing. Otherwise, just GOTO any micro and a BASIC interpreter.
I just want to point out there is nothing magical or complex to signal processing. A lot of people seem to think digital signal processing ALWAYS needs special processors, FPGAs, assembly code, lots of complexity, etc. Nowadays you only need a DSP if you need to process lots of data very fast with a limited power budget. In opther words: nowadays DSPs only serve a niche market because PCs, microcontrollers and SoCs have lots of processing power.
-
Your head-banging on working with assembly code is also beside the point. Almost all the signal-processing code parts are done in assembly on DSPs, otherwise no time-critical analysis/prediction is possible. Housekeeping tasks like init, I/O etc. are mostly done in C.
That is another misconception. Who ever said signal processing needs to be fast and/or time critical? Like only signal processing can be time critical?
Are you trolling? I never said that. But a reason for using a DSP is real-time signal processing. Otherwise, just GOTO any micro and a BASIC interpreter.
I just want to point out there is nothing magical or complex to signal processing. A lot of people seem to think digital signal processing ALWAYS needs special processors, FPGAs, assembly code, lots of complexity, etc. Nowadays you only need a DSP if you need to process lots of data very fast with a limited power budget. In opther words: nowadays DSPs only serve a niche market because PCs, microcontrollers and SoCs have lots of processing power.
Yes, I heard that argument 25 years ago as well. In those days it was about "soft modems" that didn't need any hardware other than AD/DA converters to run a 14400 line, by just using the "incredible processing power" of a 486.
The basis of that argument was and is "just throw some more processing power at it". Extremely primitive.
As I wrote, most DSPs are hidden nowadays, but crucial for their applications. And I stand by my opinion that the DSP56800 is a good choice for education.
-
DSP is applied discrete mathematics. You don't need a chip stamped "DSP" on top to do it. All algorithms used in DSP eventually funnel down to computation of an inner-product space. I.E. multiply and add.
I could teach a course on DSP using an 8051, or an abacus. Just because there is a new fancy processor that automates an algorithm doesn't invalidate the core knowledge base required.
Processing atmospheric infrasonic signals with wavenumbers << 1 can easily be done on an ARM... Or and 8051. The hard problem is understand the math your are trying to implement, not that particular platform.
There are *lots* of applications where you only a small Cortex-M do do some very interesting signal processing at very low power envelopes. There always be the "high end" (Radar, image processing, etc) but the 6-sigma can be done with general purpose chips nowadays.
Not everything needs a SHARC or a Virtex-7. Once you get to the super high end, you will need a solid background in implementing algorithms which can be done on any processor platform.
From my point of view, I would hire someone with ASM experience over something who is only trained in modern tools.
Many times faculty do not update the tools as it is a ton of work and are lazy....
That all being said, there is nothing stopping from buying a modern kit and getting yourself going on some other tools. Or you could offer to update the lab exercises!
-
Yes, I heard that argument 25 years ago as well. In those days it was about "soft modems" that didn't need any hardware other than AD/DA converters to run a 14400 line, by just using the "incredible processing power" of a 486.
The basis of that argument was and is "just throw some more processing power at it". Extremely primitive.
But very cost effective when done right and in the end that is what counts. One of my former employers killed and borged the entire competition by not using traditional DSPs but using the PC's CPU for doing the signal processing.
-
Again, you quote selectively from my post without regarding my other arguments, which I find an offensive, "cherry-picking" way of discussing, otherwise only known from desperate politicians up to an election.
I'm out, I don't like your style.
-
Again, you quote selectively from my post without regarding my other arguments, which I find an offensive, "cherry-picking" way of discussing, otherwise only known from desperate politicians up to an election.
I'm out, I don't like your style.
There is not much use in quoting entire posts because people can scroll up and read them. So in order to keep things short and to the point it is good practise to cut things which aren't relevant to the remark. Yeah sure there are niche applications but we already agreed on that so why leave that part in?
-
The basis of that argument was and is "just throw some more processing power at it". Extremely primitive.
The thing is, processing power scales, while dedicated hardware doesn't. If you leave school without understanding that... well, I won't say your education was wasted, but I will say that it's just beginning.
I was watching some old videos of talks by Seymour Cray the other day. Unfortunately there aren't many surviving ones, and the ones that have been posted on YouTube are fuzzy VHS transfers with bad sound quality. But the lessons he learned the hard way are timeless. Cray's designs were industry-leading in the 1970s, and were still going strong into the 1980s. But by the 1990s, Moore's Law caught up to him. He was forced into one reckless gamble after another. He bet the company on processors made with discrete GaAs logic, alien-looking three-dimensional modules made with exotic chips for which his company was the only customer on the planet. They had to be immersed in Fluorinert for cooling, with power consumption measured in the hundreds of watts per cubic inch. We all know how that worked out for him.
This is basically what has happened to hardware DSP. If you're studying 56000s in school today, you might as well be learning how 1970s-style vector processors worked. Or studying how to build flip-flops out of 12AU7s. Yes, the principles endure, but the hardware is just getting in your way.
-
Or studying how to build flip-flops out of 12AU7s.
:-DD I remember them
-
If you're studying 56000s in school today, you might as well be learning how 1970s-style vector processors worked. Or studying how to build flip-flops out of 12AU7s. Yes, the principles endure, but the hardware is just getting in your way.
People still teach embedded classes in universities using 8051s, and those things are even older than the DSP56000.
-
If you're studying 56000s in school today, you might as well be learning how 1970s-style vector processors worked. Or studying how to build flip-flops out of 12AU7s. Yes, the principles endure, but the hardware is just getting in your way.
People still teach embedded classes in universities using 8051s, and those things are even older than the DSP56000.
That still doesn't make it a good idea. The defacto standard is ARM nowadays! If I need to choose between hiring someone who already knows ARM and somebody who only knows about obsolete hardware then the choice will be easy.
-
If I need to choose between hiring someone who already knows ARM and somebody who only knows about obsolete hardware then the choice will be easy.
I -- and every company I have worked for[1] -- have always looked for people that know the fundamental principles and are competent when it comes to applying them in practical situations.
Why? Because given that it is easy for them to learn today's latest tool. And tomorrows. And to shift onto significantly different technology when it become available. And to assess which class of technology is most appropriate for the next problem they are presented with. And, most importantly, knows what a tool can never be expected to deliver and why.
In contrast, anybody that only knows one tool, even if it is the one I expect to use on the next project, is of little interest. They are the people that hit screws with hammers, because that's what they have done in the past. They are also the people that believe salesmens' patter, and build in fundamental defects that are only discovered very late in the day including after delivery.
[1] except one. That company was more than happy for people to catch and swallow NullPointerExceptions. Why not, after all that stopped the unit tests failing! When asked if they enjoyed polishing the product, one person replied that there was only so much that you could polish a turd!
-
People still teach embedded classes in universities using 8051s, and those things are even older than the DSP56000.
That still doesn't make it a good idea. The defacto standard is ARM nowadays! If I need to choose between hiring someone who already knows ARM and somebody who only knows about obsolete hardware then the choice will be easy.
Basic principles are more important that knowledge of a specific part. Someone well-rounded in the basics can easily pick up a new MCU (like an ARM) with very little trouble. I'd rather hire someone like this than someone who knows ARM and nothing else.
-
The defacto standard is ARM nowadays! If I need to choose between hiring someone who already knows ARM and somebody who only knows about obsolete hardware then the choice will be easy.
This explains why ARM is so popular. But popularity is a fickle thing. Today it is popular, but year from now it isn't. What if 3 (or 10) years from now something else becomes popular. Say, FPGAs will be cheap and everyone decide to switch to FPGA and ARM will be well forgotten. What are you going to do with your workforce who know nothing but ARM. Send them to college to learn FPGA? Fire them? Hire newer, more progressive guys?
-
The defacto standard is ARM nowadays! If I need to choose between hiring someone who already knows ARM and somebody who only knows about obsolete hardware then the choice will be easy.
This explains why ARM is so popular. But popularity is a fickle thing. Today it is popular, but year from now it isn't. What if 3 (or 10) years from now something else becomes popular. Say, FPGAs will be cheap and everyone decide to switch to FPGA and ARM will be well forgotten. What are you going to do with your workforce who know nothing but ARM. Send them to college to learn FPGA? Fire them? Hire newer, more progressive guys?
Both ARM and 8051 are standard microprocessor architectures, programmable in C/C++ and targeted by free toolchains based on gcc. They are more alike than different. If you learn C programming on 8051, you can transfer those skills to ARM in a weekend.
This will not be the case if you just spent half the semester dicking around with an antique proprietary toolchain for an obsolete DSP family.
-
Or studying how to build flip-flops out of 12AU7s.
:-DD I remember them
The more usual device used was the 12AT7.
12AU7s were more often used in audio work, though I have used both interchangeably.
More on topic, EEs used to be able to apply fundamentals to come up with very effective answers to problems.
Us grimy old Techs were more likely to "bodge" something up by digging through the National Semiconductor Data book.
That type of EE sadly seems to be extinct.
"Technical Education" as represented by the present "TAFE" in Oz has been dumbed down to have very little theoretical education.
It is more "do this & that to achieve this end", which is, allegedly, what Employers want.
As this has become the new reality, students don't realise they are being short changed, & any attempt to teach real Electronics would be meant by shrieks of "it isn't relevant!
It is sad to see the same attitude raising its head in Universities.
-
Those who are asking for relevant experience with a specific processor for employment purposes better hope that their proposed employer uses that chip set. Or maybe they should not set so much store in specific experience.
When I graduated from university it happened to be one of the lulls in engineering employment. I had very carefully prepared my curriculum to be useful in three widely different patches of electrical engineering - power engineering, RF and semiconductor design/fab. None of those fields happened to be hiring. The place I got on worked with infrared. In response to questions about how I could contribute to their problems I responded "It's all Maxwell's equations" and showed how they applied to some of the things they were doing. They apparently liked me because they hired me and kept me on through subsequent layoffs.
I think you will find similar things in terms of processor architectures. If the firm is hiring for a job that is going to last for less than a year they may select specific hardware experience. If you hope to work in more than a few months you will need to convince them that you can solve all of their problems, not just one problem du jour.
-
Both ARM and 8051 are standard microprocessor architectures, programmable in C/C++ and targeted by free toolchains based on gcc. They are more alike than different. If you learn C programming on 8051, you can transfer those skills to ARM in a weekend.
And so are many others. For someone who had programmed before, it probably would take few hours to grasp the basics of the C syntax, and probably few weeks to a month to study the standard and memorize the majority of the rules. Then you should be able to program equally well (or bad) for any processor. If you look from this viewpoint, you won't see any difference between processors, so you grab whatever lies closer, which most likely will be ARM.
I don't think the OP's course is about programming in C, perhaps not even about programming. May be it merely explains what is DSP and how it is different from RISC processors. Perhaps, if the students spend some time programming DSP in assembler and then do the same with ARM (or other RISC processor), they will see some differences and perhaps start thinking about them. Next time they will not grab what lies closer, but what fits the task better.
-
Something which has kind of irked myself and my fellow students is our perceived absurdity of our Digital signal processing micro apps class.
The instructor is having us program a Motorolla DSP56800 processor using assembly language.
Is that the whole class, or are you just starting the class and this is what you are learning first?
There are *many* hardware architectures that are very old, that still were so fundamental to the evolution of the industry that knowing about them is A Good Thing. I'm not sure that there ARE any significant architectures that are "new" - most things are ARM or x86 these days, but both of those are older than the DSP56800...
D) If you were hiring staff, would you rather them know how to use C++ or assembly to a high proficiency?
First, let me say that I've never been a DSP person; I haven't used DSP hardware, and I haven't programmed DSP algorithms. But I HAVE been a hiring manager. If you have "DSP" on your resume, I expect that you'll have some knowledge about how programming a DSP chip in assembly language is DIFFERENT than programming a DSP algorithm in C on ARM. (in fact, I'd make that an interview question...) Does C even support typical DSP features like MAC? (I did buy a TI DSP LaunchPad once, and read through the relevant processor manual, which spend LOTS OF TIME on how to manage the instruction/memory pipeline, for example.) Anything else would be similar to "I have microcontroller experience: we used Arduino Zeros with micro-Python" - a sort of "ok. But... reaction."
I once complained about obsolete material and the prof said to take it up with the Dept Dean. I asked who that was and he said he was. I knew I was in deep doo doo. It turned out to be a hard course with him always calling on me. The next semester the course was changed.
That sounds absolutely wonderful, actually! I always learn more from two knowledgeable experts (whether or not I'm one of them( arguing over some fine point, compared to just trying to soak in one point of view...
There should be a compulsory class called "dabbling with new shit" where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza.
Oh yes! One of the things I've noticed on-line is that forums or mailing lists with a large hobbyist contingent tend to be MUCH more interesting that vendor forums composed entirely of "professionals." I think this is because even "professional" dabbling is more similar to hobbyist activity than "work." The times in your career where you'll actually be able to spend a couple of months "comparing" different chips to see which ones you like better are going to be rare, compared to the number of times "I've been dabbling with X and I think it will do the job" might be influential. This is why cheap hobbyist-friendly evaluation modules are SO important, compared with $1000 "professional" boards.
-
People still teach embedded classes in universities using 8051s, and those things are even older than the DSP56000.
That still doesn't make it a good idea. The defacto standard is ARM nowadays! If I need to choose between hiring someone who already knows ARM and somebody who only knows about obsolete hardware then the choice will be easy.
Basic principles are more important that knowledge of a specific part. Someone well-rounded in the basics can easily pick up a new MCU (like an ARM) with very little trouble. I'd rather hire someone like this than someone who knows ARM and nothing else.
Why does everyone think you can't learn the basic principles on ARM? major :palm: !
ARM isn't going away anytime soon and if I hire someone who already knows this architecture then I don't need to pay for that person learning it (which will take more than just a few hours)!
Besides that if someone learned to work with ARM (instead of some obsolete architecture) at the university it also shows the university keeps track on current technologies and the students probably learn a thing or two about other modern methods.
-
Let me see if I can stick myself in the middle of the "DSP on ARM" sub-discussion here.
First of all, an ARM is NOT a Digital Signal Processor. Some ARM cores have Digital Signal Processing-friendly instructions, but they are not what I would call a digital signal processor.
Years ago, if you were doing signal processing of any meaningful sort, you really wanted a Digital Signal Processor. General purpose processors didn't really have the steam. Heck, I remember when you couldn't even reliably decode a MP3 on a PC. Any time you wanted to do signal processing work you really needed a processor which was optimized for that.
Time has gone on, and the applications that required a DSP 30 years ago can be done in a general purpose processor today in real time. And many of the processor cores have added DSP instructions to make it easier. If you're processing audio, generally you're going to be able to do that on a fast general purpose processor. That doesn't mean that a general purpose processor with DSP instructions is a Digital signal processor, it just means that the applications where a real digital signal processor is needed have evolved. And many of these applications have moved from a processor to a FPGA.
In a university class on "DSP" I think there are two main things which should/could be covered (I said some of this in a previous reply):
1) Digital signal processing algorithms, (filters, transforms, etc). This doesn't need a digital signal processor - instead can be taught on pretty much any processor. And for many applications, a general purpose processor would be the ideal end-product processor.
2) Digital signal processor architectures and how they are useful and how they differ from a general purpose processors. *IF* you want hands-on work in relation to this topic, then you need to find a processor which is simple enough to comprehend that you could actually be able to utilize it in the limited time given during a course.
There are still lots of applications out there where a real DSP is the ideal choice. There are some $1-2 real DSP cores which can do incredible things at very low power (motor control (aka BLDC), power supplies). There are also some very high end DSP's (and FPGA's) which can do signal processing that we only dreamed about just a few years ago. And yes, there are the general purpose cores which can handle far more applications than they did in the past.
I just think that making an argument that "you don't need a DSP to do signal processing" is just as bad as making the argument that "you need a DSP to do signal processing". The key is to understand the underlying algorithms of signal processing, and then understanding the tradeoffs between a real DSP core and a general purpose one. Sometimes the correct answer for a given product is a cheap general purpose core, sometimes the answer is a real DSP core, and sometimes the answer is a FPGA. Or a mixture of the above.
-
1) Digital signal processing algorithms, (filters, transforms, etc). This doesn't need a digital signal processor - instead can be taught on pretty much any processor. And for many applications, a general purpose processor would be the ideal end-product processor.
Algorithms and general principles are best taught using a high level mathematical environment, and by far the best choice is Matlab. It is vey widely used in industry, and a CV lacking Matlab experience would definitely raise an eyebrow when recruiting for a DSP position.
Remember also, when recruiting, that any candidate with exactly the right combination of experience and knowledge of the specific processor/tools & hardware is either working for you already, or in a better-paid post with your main competitor.
-
... if you just spent half the semester dicking around with an antique proprietary toolchain for an obsolete DSP family.
That's an important point. In this context, the toolchain which allows people to concentrate on the DSP (rather than on the toolchain) is the better choice - and the choice of processor should follow from that.
Now I don't know that specific toolchain, but in my experience newer toolchains have many bells and whistles that obscure what is happening underneath. The worst ones, and there are many, make it easy to do common tasks in a predefined way, but are bloody awkward when you need to do something outside the way they think you ought to do things.
In this context it may be preferable to have a command-line driven toolchain, since then all internal operations are visible (always good), and a teacher can examine/guide/mark the student's work without having to create a project in an IDE.
-
Does C even support typical DSP features like MAC
That's invisible at the language level and hhat's up to the compiler; some will, some won't.
Saturating vs non-saturating arithmetic is different, since the intent has to expressed in the source code.
-
Just quickly Looking at current DSPs and ARMs and hybrids (lot of modern DSPs have an DSP core and an ARM core) performances I do see some differences esp in floating point processing.
C6678 from TI can do 160GFlops and 320GMACs 1, even a Raspberri pi3 with 4 cores can not handle that (1-2GFlops)2.
If I look at inners of the last three generations of hometheater audio processors with now 14 channel audio and 3D sound (Atmos/DTS-X etc) they all have TI or AD DSPchipsets.
So I am still not convinced that anything a modern DSP can do an ARM can compete?
1http://www.ti.com/processors/dsp/c6000-dsp/c66x/overview.html (http://www.ti.com/processors/dsp/c6000-dsp/c66x/overview.html)
2http://browser.geekbench.com/geekbench2/2591431 (http://browser.geekbench.com/geekbench2/2591431)
-
I studied programming (IBM 370 assembly, FORTRAN, COBOL) using punched cards (years 1985 to 1990). Ended having a successful career working for several multinational computer hardware and software companies. The tools you use to learn is not important.
:bullshit: If you were a hiring manager, you'd be singing a very different tune. Those graduates will be at a serious disadvantage relative to their peers who will be familiar with more modern DSP platforms.
As (until quite recently) the guy sitting next to the hiring manager asking the technical questions, I couldn't disagree more.
These are graduates, not battle hardened engineers. I do not expect them to hit the ground running. I do not expect that their tool chain or processor specific experience will be relevant to me anyway.
What I do expect is a good understanding of the principles. I want them to know how the hardware does what it does. I want them to know how to approach problem solving.
But most importantly, I want them to have an aptitude and a thirst for engineering. A graduate engineer has a box of tools, but lacks the experience to apply them in a work environment. When they join the team they have to be taught. The more eager they are to learn, the better.
Technologies come and go. I couldn't give a flying poop what processor was learnt at Uni, it will be outmoded in seven years anyway. What's important is the principles.
I studied at a college that specialised in marine electronics ( I live in a city that has a large port.) Most of the kit that we practised on as students was donated to the college when ships were refitted. That means that, in the late 1980's we were working on valve based radios, radars, marine location systems etc.
Our digital logic was taught on the 1975 designed 6502. We used 7400 series TTL and were taught to prototype with wirewrap. Logic analysers were powered by Z80s and oscilloscopes were analogue.
The implementation of the technology is utterly irrelevant, as long as you understand the fundamentals you're good.
-
Just quickly Looking at current DSPs and ARMs and hybrids (lot of modern DSPs have an DSP core and an ARM core) performances I do see some differences esp in floating point processing.
C6678 from TI can do 160GFlops and 320GMACs 1, even a Raspberri pi3 with 4 cores can not handle that (1-2GFlops)2.
If I look at inners of the last three generations of hometheater audio processors with now 14 channel audio and 3D sound (Atmos/DTS-X etc) they all have TI or AD DSPchipsets.
So I am still not convinced that anything a modern DSP can do an ARM can compete?
1http://www.ti.com/processors/dsp/c6000-dsp/c66x/overview.html (http://www.ti.com/processors/dsp/c6000-dsp/c66x/overview.html)
2http://browser.geekbench.com/geekbench2/2591431 (http://browser.geekbench.com/geekbench2/2591431)
How many can a Motorola 56K do? That's more relevant to the OP's original question.
The implementation of the technology is utterly irrelevant, as long as you understand the fundamentals you're good.
How familiar are you with DSP technology, personally? (Not challenging or arguing, just curious.) The impression I've gotten from the thread is that the people saying "It doesn't matter" have no idea how old the 56000 architecture is, and how development tools, practices, and processes have changed since 1986 when that particular chip was introduced. That impression may be incorrect, so it seems worthwhile to ask.
-
I need to demonstrate to the program manager / Dean that,
1) The hardware isn't used in industry / isn't in demand enough to warrant it's use in education.
2) The skills gained from learning on said hardware are not easily applied to learning current hardware.
3) The cost benefit of changing hardware is positive.
4) Changing the hardware will be of significant benefit to the students and the reputation of the university.
5) The fundamentals can be equally taught using modern ARM processors.
You'll sure give them a good laugh at least but you'll also prove to them that you are missing the whole point of what they are teaching you. Many university degrees are not meant to give you a hands on experience that is 100% applicable in the real world - they are meant to teach you how things really work and give you the tools for learning what you need to be successful in your career.
Just because you are not using the latest and greatest hardware doesn't mean what you are learning is useless. Think more in terms of concepts and methods rather than specific lines of code or CPU.
-
You'll sure give them a good laugh at least but you'll also prove to them that you are missing the whole point of what they are teaching you. Many university degrees are not meant to give you a hands on experience that is 100% applicable in the real world - they are meant to teach you how things really work and give you the tools for learning what you need to be successful in your career.
Just because you are not using the latest and greatest hardware doesn't mean what you are learning is useless. Think more in terms of concepts and methods rather than specific lines of code or CPU.
Same question I asked vealmike above, if you don't mind. Let's take an informal poll. :)
-
Does C even support typical DSP features like MAC
If the compiler is targeted for a processor with DSP features, you can make the compiler to produce code using the DSP-features, like MAC. Typically you have to write the code in a certain way/pattern (or use compiler's built-in extensions and library functions) so that the compiler can detect the specific patterns in order to be able to generate optimized code for certain common DSP-operations, like MAC. The compiler vendor will provide detailed information and examples how to do it properly. Always check the compiler output!
ARM M-series overview and FIR-filtering:
http://www.keil.com/pack/doc/CMSIS/DSP/html/index.html (http://www.keil.com/pack/doc/CMSIS/DSP/html/index.html)
http://www.keil.com/pack/doc/CMSIS/DSP/html/group__FIR.html (http://www.keil.com/pack/doc/CMSIS/DSP/html/group__FIR.html)
ADI ADSP-2116x, ADSP-2126x, ADSP-2136x and ADSP-2137x processors (PDF pages 257 ..., 268 ...):
http://www.analog.com/media/en/dsp-documentation/legacy-software-manuals/50_21k_cc_man.rev1.1.pdf (http://www.analog.com/media/en/dsp-documentation/legacy-software-manuals/50_21k_cc_man.rev1.1.pdf)
TI C2000 series processors:
http://processors.wiki.ti.com/index.php/C2000_Performance_Tips_and_Tricks (http://processors.wiki.ti.com/index.php/C2000_Performance_Tips_and_Tricks)
TI C6000, section "Using Intrinsics to Access Assembly Language Statements":
http://www.ti.com/lit/ug/spru187u/spru187u.pdf (http://www.ti.com/lit/ug/spru187u/spru187u.pdf)
-
How familiar are you with DSP technology, personally?
I'm not a DSP guy at all, but to ask the question I think you may be missing my point. I don't care about the implementation architecture and I doubt the university does either.
Its never going to happen these days, but a graduate trained in valves would be just as useful as an analogue guy as a graduate trained in op-amps. A graduate trained on the 6800 is just as useful as a grad trained on Arm.
When they get into the work environment, lack of experience and lack of exposure to rigorous process is what limits a graduates usefulness. I'd expect them to learn a new architecture far faster than they'll gain general experience. Provided of course that they have solid fundamentals.
Exact experience implementation of the fundamentals is irrelevant when hiring a grad.
-
Exact experience implementation of the fundamentals is irrelevant when hiring a grad.
Not true! These days companies expect graduats to have both knowledge of principles and knowledge on current technology. Companies don't want graduates who need a lot of training on basic stuff. http://thegradstudentway.com/blog/?p=810 (http://thegradstudentway.com/blog/?p=810)
-
Exact experience implementation of the fundamentals is irrelevant when hiring a grad.
Not true! These days companies expect graduats to have both knowledge of principles and knowledge on current technology. Companies don't want graduates who need a lot of training on basic stuff. http://thegradstudentway.com/blog/?p=810 (http://thegradstudentway.com/blog/?p=810)
Our mileage, experience and expectations clearly differ. The likelihood of finding a grad with experience on the exact tool chain we're using is zero, so we have to retrain anyway. And then we'll retrain again when we do the next project.
It is far more important for a grad to have the correct attitude and enthusiasm than experience of the right toolchain.
-
Ofcourse you can't expect a graduate to know about an obscure processor architecture but I'd expect a graduate to know about the ARM architecture just like I expect the person to know about Matlab, C/C++ and UML.
-
Exact experience implementation of the fundamentals is irrelevant when hiring a grad.
Not true! These days companies expect graduats to have both knowledge of principles and knowledge on current technology. Companies don't want graduates who need a lot of training on basic stuff. http://thegradstudentway.com/blog/?p=810 (http://thegradstudentway.com/blog/?p=810)
Firstly, the author of that blog seems to be in the biotech industry - that is a vastly different field than EE. You can't really compare the two tbh - many biotech and pharama companies look for PhDs to do even the most basic work for them.
The other factor is that companies prefer to hire people that have some sort of interest in what they are doing and if you have that, you will look into things on your own and learn about modern tech with the help of the principles you were taught in class.
-
Soon learning DSP on ARM will be obsolete too... so I think the discussion goes back to the learning the fundamentals.
https://dspconcepts.com/st (https://dspconcepts.com/st)
-
@OP,
Uni can't train students for all sorts of platforms used out there.
That doesn't work. Only the concept can be reapplied.
The concept of bandwidth, sampling, stability, impulse response ... etc.
I wouldn't be bothered about it too much unless it's too time-consuming and pointless (Like doing GUI with assembly language).
Of course, it's helpful if the tool chain/platform is well-known and widely used in industry.
I''d put a weigh of the importance of tool/platform to be 25%.
I didn't get to touch any DSP processor during my time, only Matlab. Doing FFT was easy. :D
I find that you can train yourself what platform to use pretty quickly.
The hard part that needs some sort of "teaching" is the concept.
Also in the interviews, my employers didn't care what tool i used, it's always problem analysis and solving.
Just my thoughts
-
Well companies always ask for experience in their specific architecture. You can often figure out what CPU's a company is using by that style of vacancies.
There will always be niche choices for particular products. Few months ago I talked to a company that were using DSP Blackfins for data acquisition. No filtering or processing on the device (that was done a PC conveniently).. just grabbing data from an A/D at a few 100kHz and putting that over USB, ethernet or onto FLASH. One of their reasons was that SPI bus pins were not multiplexed with other functions, which could compromise the I/O allocation.
From my outside perspective I couldn't see why it won't run on a fast ARM chip in a big package (they were using BGA chips anyway), but they chose not to.
You may also need to support legacy products once a while. You think you're all set with these fancy cortex m4 chips that have tons of ram, half a dozen hardware breakpoints, data breakpoints, etc. All the tools in the world to debug them.
Then one day you jump back in time to the ARM7TDMI core (e.g. to solve a customer ticket) and curse everytime that you're using all of the 2 hardware breakpoints available, have got no data breakpoints, that you can't find a 1K buffer in that 16K of RAM for a serial trace module, and the quirks of an older architecture (like slow interrupts or lack of DMA).
I don't think age is much of an indication of relevance for a platform in an educational environment. If you look at academic then alot of times the MIPS core is being thought in computer architecture, design and engineering because of it's licensing model. Nevertheless it's a working 32-bit CPU core that is used in the industry, although a lot more seldom than ARM.
If you want to work with more cutting edge stuff, especially in microcontrollers or FPGA world, then pick up a development board for 20-100$ and get coding. I'm pretty sure that for a college student even a 25$ Nucleo board can provide tons of (software) projects to show of your proficiency in embedded programming.
-
Well companies always ask for experience in their specific architecture. You can often figure out what CPU's a company is using by that style of vacancies.
Yes, but...
The companies that do that tend to be run by people that haven't got a technical clue, and/or are only interested in hiring people for the next project. Such companies won't be interested in the employees' personal development - at the end of the project the employees will be made redundant, and maybe their jobs done by someone cheaper. At that point how has the employees' CV improved? Probably not much, since now they don't have two projects experience, they have one projects experience - repeated twice. Do you really want to work like that, because in 3 years time your experience probably won't be worth much!
The better companies with more interesting jobs don't work like that.
In other cases, while companies ask for experience of specific architectures, in reality they aren't too concerned. So long as you have any tenuous reason to be able to put architecture X.3.56 in your CV, it will pass their HR-bozo filter and you can get an interview with the engineers and display your value to them. If the engineers think that experience of X.3.56 is necessary, then you probably don't want to work there.
So, you should learn DSP on whatever architecture is used on the course, and have a small home-project using a $5 ARM board. That will be sufficient to pass the ridiculous bozo filter!
-
Well companies always ask for experience in their specific architecture. You can often figure out what CPU's a company is using by that style of vacancies.
Yes, but...
The companies that do that tend to be run by people that haven't got a technical clue, and/or are only interested in hiring people for the next project. Such companies won't be interested in the employees' personal development - at the end of the project the employees will be made redundant, and maybe their jobs done by someone cheaper. At that point how has the employees' CV improved? Probably not much, since now they don't have two projects experience, they have one projects experience - repeated twice. Do you really want to work like that, because in 3 years time your experience probably won't be worth much!
The better companies with more interesting jobs don't work like that.
In other cases, while companies ask for experience of specific architectures, in reality they aren't too concerned. So long as you have any tenuous reason to be able to put architecture X.3.56 in your CV, it will pass their HR-bozo filter and you can get an interview with the engineers and display your value to them. If the engineers think that experience of X.3.56 is necessary, then you probably don't want to work there.
So, you should learn DSP on whatever architecture is used on the course, and have a small home-project using a $5 ARM board. That will be sufficient to pass the ridiculous bozo filter!
This. All of it.
Do the course work with what the perfectly fine processor they've prepared the lessons for. If you want, get yourself an ARM-based Arduino-clone at home -- or better, an FPGA with an embedded ARM (e.g. Zynq). The cost is minimal, and the experience will be more than enough to pass interview questions let alone bozo HR filters.
-
Why does everyone think you can't learn the basic principles on ARM? major :palm: !
ARM isn't going away anytime soon and if I hire someone who already knows this architecture then I don't need to pay for that person learning it (which will take more than just a few hours)!
Not everyone uses ARM (believe it or not), and the learning curve for a competent engineer to learn ARM isn't that great. I came from a MC68K/MIPS background and learned the ARM architecture in about a week.
I'd have no issues with hiring someone with MIPS or ARC 600 experience, say, and no ARM experience to work on an ARM project. Sure, someone with ARM experience, all other things being equal, would be a better match, but the world is bigger than just the ARM fiefdom.
-
https://www.youtube.com/watch?v=XAN-9brv8Jk (https://www.youtube.com/watch?v=XAN-9brv8Jk)
-
Having been a hiring manager for a couple of silicon valley startups, I can say that hiring new grads for engineering positions is very different than hiring for a more senior role. First, the way that you find candidates is different. Most senior candidates come through recruiting firms (or services) and the sheer volume of resumes is a burden. Sorting through the posers is hard work and after a while, you cut candidates from the process pretty quickly.
For fresh grad candidates, those resumes arrive either over the transom or via a recommendation/referral and there aren't quite as many. Management (mine anyway) is always interested in new grads because they're "cheaper" than seasoned pros. Not sure I agree with that generally, but there are some grads who will turn into rockstars and it's worth the effort to try to find them.
Personally, what I look for in a new grad is someone who's accomplished something beyond just coursework. It might be personal engineering projects on the side, or some kind of significant experience that's entirely apart from going to school. A candidate who emphasizes coursework alone is one who (maybe) doesn't have enough drive to push through difficult challenges. Plus, when I was in school, none of the Profs could program their way out of a paper bag--we had to learn that on our own.
It's great that you took a DSP class, but I want to know if you can adapt that thought process to the messy problems we face in product development where sometimes we don't even know if the approach we're taking is going to work.
-
You need to go to them with a solution, not just a complaint.
Who will write the new course material for the new hardware? This alone could dictate everything. If some DSP manufacturer has DSP kit that targets courses with pre-prepared class material and project example, then there is your solution.
That's a superb tip in general. If you have a problem with how things are or go, don't just report a problem. You'll be considered a nuisance for it, for you create problem where there were none perceived. However, if you also provide a reasonable solution, it is much harder for others to say no without looking bad, and part of the work is also already done. If you play your cards right, the other will have a chance to look good while improving things for you, and that kind of motivation helps. Everybody wins.
-
Not true! These days companies expect graduats to have both knowledge of principles and knowledge on current technology. Companies don't want graduates who need a lot of training on basic stuff. http://thegradstudentway.com/blog/?p=810 (http://thegradstudentway.com/blog/?p=810)
Companies often expect the most ridiculous things. A recent example I came across was a company asking for 8 years of experience with something that was only available for 5. Go figure. They can ask for 40 years of experience in graduates all they want.
-
Companies that expect ridiculous things are not companies you want to work for. An interview is a two-way process. You are interviewing them and they are interviewing you. Never hesitate to turn down a job if the situation is bad.
-
Not true! These days companies expect graduats to have both knowledge of principles and knowledge on current technology. Companies don't want graduates who need a lot of training on basic stuff. http://thegradstudentway.com/blog/?p=810 (http://thegradstudentway.com/blog/?p=810)
Companies often expect the most ridiculous things. A recent example I came across was a company asking for 8 years of experience with something that was only available for 5. Go figure. They can ask for 40 years of experience in graduates all they want.
Those are the insane job descriptions probably put together by headhunters or HR people. That still doesn't mean it is a good idea to learn about obsolete technology. Just look at realistic EE job descriptions and you'll see that most list knowledge about modern technology like ARM, Wifi, bluetooth, IP networks, etc at least as a plus.
-
Companies that expect ridiculous things are not companies you want to work for. An interview is a two-way process. You are interviewing them and they are interviewing you. Never hesitate to turn down a job if the situation is bad.
Very true. Just make sure you don't turn down companies because the HR monkeys did something stupid.
Those are the insane job descriptions probably put together by headhunters or HR people. That still doesn't mean it is a good idea to learn about obsolete technology. Just look at realistic EE job descriptions and you'll see that most list knowledge about modern technology like ARM, Wifi, bluetooth, IP networks, etc at least as a plus.
It's not about obsolete technology, it's about learning the principles. Someone who knows ARM, but doesn't see the bigger picture is not going to be very popular. I have to assume that the people that put the curriculum together chose this processor at least in part because it's relatively simple, which means there isn't much stuff going on that only confuses and distracts students.
Not being able to buy the materials yourself isn't very convenient, that's true.
-
It's not about obsolete technology, it's about learning the principles. Someone who knows ARM, but doesn't see the bigger picture is not going to be very popular. I have to assume that the people that put the curriculum together chose this processor at least in part because it's relatively simple, which means there isn't much stuff going on that only confuses and distracts students.
Same question as above, if you don't mind. You're in the (rather large) club defending the school's choice to teach DSP with a platform that's several years older than the students themselves. What's your (recent) industry background in this area?
-
Companies often expect the most ridiculous things. A recent example I came across was a company asking for 8 years of experience with something that was only available for 5. Go figure. They can ask for 40 years of experience in graduates all they want.
That's not even recent but at least a 15- 20 year old practice. I recall the search for ""Superman"" started late 90'es or so.
It came to be when recruit personnel was rebranded to Human Resources, ie blingyfication.
Suddenly HR become pomp and circumstance often populated by non tech people.
-
It's not about obsolete technology, it's about learning the principles. Someone who knows ARM, but doesn't see the bigger picture is not going to be very popular. I have to assume that the people that put the curriculum together chose this processor at least in part because it's relatively simple, which means there isn't much stuff going on that only confuses and distracts students.
Same question as above, if you don't mind. You're in the (rather large) club defending the school's choice to teach DSP with a platform that's several years older than the students themselves. What's your (recent) industry background in this area?
It sounds like if you are presented with two hypothetical candidates:
- has used an A9 ARM
- knows when to choose an IIR or FIR and how to determine the precision required in the intermediate calculations
then you would choose the former.
I wouldn't; none of the companies I've worked for would have either.
-
It sounds like if you are presented with two hypothetical candidates:
- has used an A9 ARM
- knows when to choose an IIR or FIR and how to determine the precision required in the intermediate calculations
then you would choose the former.
I wouldn't; none of the companies I've worked for would have either.
First, I don't believe anyone has argued in favor of not teaching students about filters and bit growth. This goes beyond failing to answer the question the OP asked, and into the category of making stuff up at random to bolster a weak argument.
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum? Do I want them to climb that learning curve on my payroll?
-
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum? Do I want them to climb that learning curve on my payroll?
I suggest you have no choice. Pretty much anyone can learn the basics of IEEE 754 float representations in short order. On the other hand, it probably takes years of practical experience to learn all the pitfalls of floating point arithmetic and how to avoid them.
On the theme of previous comments, isn't it better that students have formed a general understanding of how to represent floating point numbers on a binary machine and how to do computations with them, and perhaps when it might be better not to use floating point?
-
The instructor is having us program a Motorolla DSP56800 processor using assembly language
A look at NXP and Digikey shows that the DSP56f8xx and MC56F8xx (based on the same architecture) are alive and apparently well, with relatively modern variants aimed at the current crop of "embedded DSP" applications (motor control, SMPS management, etc.)
So aside from all the other arguments, it might not be as bad a choice as you think, depending on which chips you're actually targeting.
-
It sounds like if you are presented with two hypothetical candidates:
- has used an A9 ARM
- knows when to choose an IIR or FIR and how to determine the precision required in the intermediate calculations
then you would choose the former.
I wouldn't; none of the companies I've worked for would have either.
First, I don't believe anyone has argued in favor of not teaching students about filters and bit growth. This goes beyond failing to answer the question the OP asked, and into the category of making stuff up at random to bolster a weak argument.
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum? Do I want them to climb that learning curve on my payroll?
They way I see it, the choice would be:
- Has used a C6000, SHARC, whatever and has seen an IIR/FIR filter C implementation in one of the vendor's toolchains; may know all its intrinsics and quirks or use a vendor library; may not know other vendors' toolchain intrinsics, quirks and libraries; may know little to nothing on how to make such filter in assembly and its architecture pitfalls of signal extension, addressing modes, etc.
- Has used a 56k, a C30, whatever and knows how to make an IIR/FIR filter in assembly taking into account its register allocation, signal extension and addressing modes; may know little to nothing on how to implement such filter in C;
- Has used a general purpose processor (ARM, x86) in the role of Digital Signal Processing and has seen an IIR/FIR filter C implementation in one of the vendor's toolchains; may or may not know anything about intrinsics; may leave university believing DSPs are a thing of the past and have no place in today's world... :popcorn:
-
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum? Do I want them to climb that learning curve on my payroll?
Hopefully he will learn floats on some other course.
Most of the DSP operations (FFT, FIR, IIR etc.) do not need floats. Meddling with about any DSP (no matter how old) even for a short time will reveal this. And this is one of the things which is worth learning about DSPs.
-
Wow I never expected such a question to raise such robust debate among the community.
However I feel the need to clarify a few things.
Firstly coming here is step one in finding a solution to this "problem". We are students our perception is that this hardware isn't the best device to be teaching DSP on.
That said we are basing that on our very limited experience in the industry. What better way to understand the "problem" then by asking directly the experienced professionals in the industry?
In asking you guys I have somewhat came to realize that the "problem" isn't so much of a "problem" but rather a matter of expectations. Evident by the division among the replies.
As students we are wanting to get an education which will get us employed, we want to understand the fundamentals whilst also having relevant skills which prepare us for our chosen career in the industry. We expect to stand out in interviews as having the relevant skills and the experience which are required by the companies looking for staff. If your company mainly uses ARM processors (which in our opinion most do) you will naturally gravitate toward an applicant with experience in ARM over this 20+ year old processor.
Whilst many of you guys seem to agree this this ideology many also don't.
It is all well and good to say you need to simply understand the principles and I somewhat agree. However expecting your employer to fit the bill while you learn to use modern hardware seems to be somewhat counter productive. Whilst an employer couldn't logically expect a graduate "to hit the ground running" they should reasonably expect them to hit the ground jogging or at least power walking....
Secondly the course is the final semester of an Advanced Diploma, we are using this hardware along with a hardware circuit we "designed" (filter pro did all the work for us) to filter an input signal into the DSP do a Fourier Transform using the DSP then send it to an external DAC, and back through another filter. Photo of my hardware below. We have one class using matlab to teach the theory. This is the only hardware exposure to DSP until the bachelor / Associate degree next semester. However fo some students this will be the ONLY exposure to DSP hardware before trying to enter the industry.
With that all said I / we understand nothing is going to change for us, there wouldn't be time or resource to change the curriculum. However it can be changed in the near future for future student studying this course. The only question is SHOULD it be changed...
I am thoroughly thankful for everyone's replies, whilst it has somewhat made the issue even more unclear it is great to hear from people in the industry and their opinions on the topic.
(https://preview.ibb.co/hikLrk/File_000_3.jpg) (https://ibb.co/mTFycQ)
-
I will re-quote vealmike from above, because what he said resonated exactly with my experience.
To stand out as an interview candidate requires a demonstration of an enthusiasm, interest and aptitude for engineering. It is the eagerness to learn, structured, rigorous thinking, analytical and problem solving skills that make you good at your job.
If you have those skills and you are interviewing at a company that doesn't seem to value them, you should consider whether you really would want to work there. It is the possession of those attributes in an environment where they are valued and encouraged that can really make work rewarding.
As (until quite recently) the guy sitting next to the hiring manager asking the technical questions, I couldn't disagree more.
These are graduates, not battle hardened engineers. I do not expect them to hit the ground running. I do not expect that their tool chain or processor specific experience will be relevant to me anyway.
What I do expect is a good understanding of the principles. I want them to know how the hardware does what it does. I want them to know how to approach problem solving.
But most importantly, I want them to have an aptitude and a thirst for engineering. A graduate engineer has a box of tools, but lacks the experience to apply them in a work environment. When they join the team they have to be taught. The more eager they are to learn, the better.
Technologies come and go. I couldn't give a flying poop what processor was learnt at Uni, it will be outmoded in seven years anyway. What's important is the principles.
It is far more important for a grad to have the correct attitude and enthusiasm than experience of the right toolchain.
-
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum? Do I want them to climb that learning curve on my payroll?
Just in case it ever helps, have them read these two papers on their coffee breaks:
What Every Programmer Should Know About Floating-Point Arithmetic: http://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf (http://www.itu.dk/~sestoft/bachelor/IEEE754_article.pdf)
What Every Computer Scientist Should Know About Floating-Point Arithmetic:
http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf (http://pages.cs.wisc.edu/~david/courses/cs552/S12/handouts/goldberg-floating-point.pdf)
-
I interviewed a guy around six years ago. A Masters graduate in microelectronics from one of the UKs most reliable universities (with a first in electronics at bachelors level). The job was some design, mainly debug of new designs.
He was OK, had worked on relevant hardware. Was clearly not that interested in electronics outside of the fact that it paid his bills.
Then I asked about buck converters. They are as common as muck in the micro world, a decent knowledge of power distribution is a must have. So I asked him to draw a buck converter, he couldn't. So I drew one on the whiteboard and asked him to explain it's operation, he couldn't.
In the end we'd boiled down to a capacitor driven by a constant current source, the guy was asked to show how the capacitor voltage varied over time. No scale on the graph, no tricks. He still couldn't do it.
I gave plenty of encouragement, explaining where he didn't know and praising where he did. I'd been doing my best to make the guy comfortable, asking easy questions. It could have just been brain freeze, but this is SO fundamental that it was inexcusable.
My point, well the guy failed the interview on two counts. Firstly because electronics was just a job to him. Actually at the level he was being brought in to do, I was OK with that. I don't think he was going to be a driven enthusiastic self learner, but if he was a competent 9 to 5er then that's fine. I'd have preferred someone whose job was their passion, but they can be hard to find.
What he really failed for was having built his knowledge on sand. Whilst he did have relevant experience on our architecture, he didn't have the underpinning fundamentals at his fingertips.
If, on the off chance the interview candidate reads this, he will no doubt recognise the scenario. I don't exactly obfusticate my name much! To to that candidate: I'm sorry. I gave you every opportunity I could and I tried to let you shine. Perhaps I misjudged you, but I had to do so on your interview performance.
I'll let y'all ponder the moral of the story.
-
...whilst it has somewhat made the issue even more unclear...
It didn't. The fact that there's 4 pages of discussion means that at least the assumption that "Old crap. Bad Teacher" is much too binary (pun intended) a conclusion.
-
As students we are wanting to get an education which will get us employed, we want to understand the fundamentals whilst also having relevant skills which prepare us for our chosen career in the industry.
Specific technology has a half life of a few years at most before it is outdated. What you use on one project will be out of date on the project after next, or probably irrelevant if you change employer.
Corollary: the most important skills you need are to know how to learn new technology, and how to choose which new technology to ignore (because it is merely a variant of something you already know) -- and what hasn't changed no matter which specific piece of technology you happen to be using at the moment.
However expecting your employer to fit the bill while you learn to use modern hardware seems to be somewhat counter productive. Whilst an employer couldn't logically expect a graduate "to hit the ground running" they should reasonably expect them to hit the ground jogging or at least power walking....
You are describing what a company wants from an experienced contractor or a technician, not what they expect from a new graduate employee nor an engineer.
Learn the fundamentals on any processor. Demonstrate your interest and initiative to potential employers by transferring that knowledge to an implementation on a £5 ARM board you have bought and used on your own time. That will get you an interview and you can discuss the relative merits during the interview.
-
The instructor is having us program a Motorolla DSP56800 processor using assembly language
A look at NXP and Digikey shows that the DSP56f8xx and MC56F8xx (based on the same architecture) are alive and apparently well, with relatively modern variants aimed at the current crop of "embedded DSP" applications (motor control, SMPS management, etc.)
So aside from all the other arguments, it might not be as bad a choice as you think, depending on which chips you're actually targeting.
While this is true, it doesn't make for the kind of uninformed meaningless rants so much loved in this forum. Best ignore reality, eh?
-
Specific technology has a half life of a few years at most before it is outdated. What you use on one project will be out of date on the project after next, or probably irrelevant if you change employer.
More specifically, a good deal of what seems like hot topics in the first year of a 4 year degree course will be old hat in your first year of employment. Stick to strategic knowledge until near the end of your course, and try to pick up some relevant tactical knowledge near the end. That way, you'll have a reasonable balance between the two, and the tactical knowledge you get will be fresher and more relevant.
One of the big shifts I see in graduates now versus 40 years ago, when I graduated, is a huge increase in the tactical knowledge most people leave college with, and a commensurate drop in strategic knowledge. Its easy to see why. Debt based education makes people so focussed on that first job, and starting to cope with that debt, that it blinds them to the need to get a solid basis for a long career from their studies. Debt based education is going to prove very destructive to economies in the longer term.
-
I will add that while I thought university was kind of intense, it was nothing like real world employment. I learned more in the first six months on the job than I had at school. And continued to learn at a significant rate for the rest of my career.
New technologies, new components, new toolchains, new manufacturing processes, new applications, all of the peripheral things to engineering (marketing, finance, warranty, HR, legal .....). And in many cases, having to do the archaeology to do something with an obsolete architecture.
-
With that all said I / we understand nothing is going to change for us, there wouldn't be time or resource to change the curriculum. However it can be changed in the near future for future student studying this course. The only question is SHOULD it be changed...
Test this. Do the same project, but with what you perceive is the modern technology. Then compare the two and analyze differences. If you can do it, then they tought you well. If you cannot, you will have to fill in the blanks by yourself.
If the idea of doing the new project doesn't sound appealing, think about other things. You're about to start a career where you will do this stuff 8 hours a day (or may be 10, even 12 if the company pushes harder than you can resist). Given that you spend 8 hours every day sleeping, the time you spend at work is the vast majority of your life. If doing a small project doesn't sound exciting then do you really want to spend all your life doing this?
-
It was easy for me. When I did BSC EE, we learned 8051.
Down to the opcode. We were given hex code, state of the registers, and a printed reference manual, what does this program do? Real hardcore stuff. And digital logic meant connecting AND gates together, and doing Karnaugh maps.
And afterwards, as a MSC EE, when you already choose specialization, you got the recent stuff. I had Embedded Systems, so I studied the latest ARM they could get their hands on. And FPGAs.
Bear in mind, that we did not have the completely useless "Industrial engineer" BSC ( not even jack of all trades).
If you only learn the best and newest stuff, you never became a good engineer. Why? Because the reference manual for a Cortex M3 is 1000 pages. You will never read it. For the 8051 it was some 60-100 pages. We went through everything. We learned how to understand this stuff. Not just the good pieces, the boring pieces also.
We made segmentation faults by hand, and optimized code for BCD computation. It was a lot of fun. But not for the ARM. Nobody does that. We wrote code in C, and we only looked the ASM code just to compare it with something.
If you only learn how to do X on Y, then you are a code monkey, not an engineer.
-
If you are being taught DSP principles then the hardware you do your labs on really doesn't matter that much. You can implement an FFT on a dedicated DSP chip or a PC or an old Commodore 64, as long as you understand the algorithm and the underlying DFT that's what matters. As to your future employers training you, well any IT employer that doesn't keep it's engineers trained and up to date will quickly fall behind and get swept away by those that do.
-
Just attend the class and use the given processor. Buy a cheap $25 ARM STM32F4-based discovery kit and implement the algorithms and exercises in C using fixed point and floating point. You will learn quite a lot and you will learn the ARM as a byproduct.
-
If you only learn the best and newest stuff, you never became a good engineer. Why? Because the reference manual for a Cortex M3 is 1000 pages. You will never read it. If you only learn how to do X on Y, then you are a code monkey, not an engineer.
H7 ref manual is 3180 pages half of it is sentence building faults, incomplete function descriptions, wrong function description, French/Italian thinking to English translation gobbedoboodido which for a coding monkey, engineer as well as a unistudent easily fit under the label of "dabbling with new evil shit" where you just throw everyone in a room with a bunch of the latest dev boards and a weeks worth of pizza and accompanying truck load of black fizzy drink delivered in aluminium cans wondering why just "they" have been punished by dealing with this evil new shit made by other E-engineers at ST who all once upona time was unistudents too!
As students we are wanting to get an education which will get us employed, we want to understand the fundamentals whilst also having relevant skills which prepare us for our chosen career in the industry. We expect to stand out in interviews as having the relevant skills and the experience which are required by the companies looking for staff.
At the end of the day its not about getting employed and having a career its about execute whatever your managment tell you to as an employee. If they ask(not even ask, just hint) you to implement DSP in such a way that regulations and laws can be circumvented YOU BETTER DO SO else "your fired" (Trumpism). No education or work merits in the world can stand a battle against the ego of a narcissistic management.
https://www.nytimes.com/2017/08/25/business/volkswagen-engineer-prison-diesel-cheating.html (https://www.nytimes.com/2017/08/25/business/volkswagen-engineer-prison-diesel-cheating.html)
https://www.nytimes.com/2017/05/17/business/volkswagen-muller-diesel-emissions.html (https://www.nytimes.com/2017/05/17/business/volkswagen-muller-diesel-emissions.html)
-
If you only learn how to do X on Y, then you are a code monkey, not an engineer.
Blunt, but there's a lot of validity in that.
There's nothing wrong with being a "code-monkey"; they are very useful within their limits. What is irritating is when code-monkeys refuse to accept their limitations and refuse to accept that engineers have different valuable skills. Ditto engineers w.r.t code-monkeys' skills.
The OP might care to think about what they want in their career. If they don't yet know (which is probable), then it is wise to avoid closing doors that don't need to be closed.
Do the class, get good marks, do a home-project which replicates the work on an ARM, work out the relative advantages/disadvantages and why they are that way. Companies and interviewers will appreciate that.
-
First, I don't believe anyone has argued in favor of not teaching students about filters and bit growth. This goes beyond failing to answer the question the OP asked, and into the category of making stuff up at random to bolster a weak argument.
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum? Do I want them to climb that learning curve on my payroll?
I don't think even many DSP major graduate students understand limitations and funny effects of IEEE754. This is a typical capability that can only be learned the hard way, in an actual project, after getting bitten.
Nowadays DSP major in universities are more focusing on communication algorithms and CS-CE-ST (math&stat) collaboration research (deep learning on image processing, etc.), no one is interested in diving deep down to the root of the underlying computation implementation.
It's amazing to see how narrow the view is for some students. I'm from a power electronics background, and I'm amazed by seeing so many power electronics graduate students that can talk control and modelling all day long but don't know how to drive a MOSFET properly.
I've also seen quite a few people enrolling PMIC course don't know how to design a flip flop nor how to Google that. I've seen people working with Virtuoso for multiple courses while not knowing any Linux commands other than those required to start Virtuoso.
The list goes on, and my point is university, even graduate education, doesn't give you much knowledge. What you get is vision and fundamental thing, then it's all up to you to fill in the blank.
So , i don't strange. My exdirector of the Engeneering School told us on a lecture ,that the Lear Corporation Engineer Staff had hit a great quarrel to him, due to a scholarship holder didn't know calculate and neither resize a thermal sink for a Power Electronics gear.
-
First, I don't believe anyone has argued in favor of not teaching students about filters and bit growth. This goes beyond failing to answer the question the OP asked, and into the category of making stuff up at random to bolster a weak argument.
Seocnd, what good does it do if the candidate has never encountered IEEE 754 floats before, as might be the case with a 56K-based curriculum? Do I want them to climb that learning curve on my payroll?
I don't think even many DSP major graduate students understand limitations and funny effects of IEEE754. This is a typical capability that can only be learned the hard way, in an actual project, after getting bitten.
Nowadays DSP major in universities are more focusing on communication algorithms and CS-CE-ST (math&stat) collaboration research (deep learning on image processing, etc.), no one is interested in diving deep down to the root of the underlying computation implementation.
It's amazing to see how narrow the view is for some students. I'm from a power electronics background, and I'm amazed by seeing so many power electronics graduate students that can talk control and modelling all day long but don't know how to drive a MOSFET properly.
I've also seen quite a few people enrolling PMIC course don't know how to design a flip flop nor how to Google that. I've seen people working with Virtuoso for multiple courses while not knowing any Linux commands other than those required to start Virtuoso.
The list goes on, and my point is university, even graduate education, doesn't give you much knowledge. What you get is vision and fundamental thing, then it's all up to you to fill in the blank.
So , i don't strange. My exdirector of the Engeneering School told us on a lecture ,that the Lear Corporation Engineer Staff had hit a great quarrel to him, due to a scholarship holder didn't know calculate and neither resize a thermal sink for a Power Electronics gear.
Well, depending on cost-sensitivity how close to the limit you are operating the components, that could be a very involved problem requiring skill in unfamiliar topics such as thermal FEM.
If that wasn't the case then an appropriate response would have been "I haven't done that before, but this is how I'll set about learning the topic...".
-
Then I asked about buck converters. They are as common as muck in the micro world, a decent knowledge of power distribution is a must have. So I asked him to draw a buck converter, he couldn't. So I drew one on the whiteboard and asked him to explain it's operation, he couldn't.
In the end we'd boiled down to a capacitor driven by a constant current source, the guy was asked to show how the capacitor voltage varied over time. No scale on the graph, no tricks. He still couldn't do it.
I gave plenty of encouragement, explaining where he didn't know and praising where he did. I'd been doing my best to make the guy comfortable, asking easy questions. It could have just been brain freeze, but this is SO fundamental that it was inexcusable.
Believe it or not, I once interviewed a Ph.D. candidate in power electronics for an industrial R&D job who also could not explain how a buck converter worked. I am not making this up.
By the same token, I was once interviewed for a power electronics position. I was asked a question about thermal management in a certain real-world scenario where the temperatures were dominated by the heat capacity of the system, but the interviewer did not like my answer. I heard later through alternate channels that the interviewer did believe that such a thing could exist, so he gave me a thumbs-down. I was glad I did not get the job.
John
-
Believe it or not, I once interviewed a Ph.D. candidate in power electronics for an industrial R&D job who also could not explain how a buck converter worked. I am not making this up.
I find that very believable. I once interviewed a candidate who was finishing up his fourth year in an electrical engineering program at a well-respected university who did not know what a diode was.
-
To quote Professor Kingsfield in The Paper Chase: "You teach yourselves the law, but I train your minds. You come in here with a skull full of mush; you leave thinking like a lawyer."
But it would be nice if the students learn that using the laws used in the country they study in today and not the laws used in the Roman empire 2000 years ago.
You would be surprised but Roman law is actually taught in pretty much any law school today because its principles are in many cases the foundation of how modern law systems work. And many concepts that were introduced in it are still as valid as they were 2000 years ago.
I have also faced this when teaching at the university. University is not there to teach you the tools but to show you the general principles. The role of the teacher is not to show you which buttons in the IDE to press or how to work a specific chip/technology (which will likely be obsolete by the time you graduate anyway) but to help the student understand the common principles behind it.
In fact, many universities expressly teach programming with obscure languages (Scheme, Logo, Occam, Trilogy ...) that the student likely will never see again - it is done so that they can focus on teaching the concepts without the distraction of the technology and also to level the playing field in the class. There are few things more distracting than a smart-ass thinking they know what you are trying to teach already and are disturbing the entire class.
If you want to learn to use a new whizbang tool X, take an elective course (if it is offered) or pay for a vendor training afterwards. Or simply get the materials and start learning yourself. You will need to do that later in your career anyway, university is there only to get the student started.
From the point of view of the hiring manager there would be exactly zero difference whether the fresh grad used a gizmo X during the studies already or learned it themselves after school - in both cases they have zero real-world experience with it and would likely need to be trained first anyway. It is more important whether or not they have the foundations in place. Of course, that assumes an HR more competent than a trained monkey that only compares keywords on the CV.
-
I once interviewed a candidate who was finishing up his fourth year in an electrical engineering program at a well-respected university who did not know what a diode was.
How so? In function, in composition (e.g. doped Silicon), on a schematic (arrow bar symbol), or what a random component labeled D2 on a PCB was?
-
I once interviewed a candidate who was finishing up his fourth year in an electrical engineering program at a well-respected university who did not know what a diode was.
How so? In function, in composition (e.g. doped Silicon), on a schematic (arrow bar symbol), or what a random component labeled D2 on a PCB was?
I had an engineering master student in an exam that had no idea about how to multiply matrices - he claimed he never needed it! And bachelor students (2nd-3rd year) that have never seen fractions and had no idea how to calculate with them ... Also a large and reputable uni.
-
I once interviewed a candidate who was finishing up his fourth year in an electrical engineering program at a well-respected university who did not know what a diode was.
How so? In function, in composition (e.g. doped Silicon), on a schematic (arrow bar symbol), or what a random component labeled D2 on a PCB was?
In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.
-
In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.
What the hell is going on at those institutions?
-
In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.
What the hell is going on at those institutions?
Nothing. They're turning out some of the best Z80 programmers of all time. Of all time!
-
To quote Professor Kingsfield in The Paper Chase: "You teach yourselves the law, but I train your minds. You come in here with a skull full of mush; you leave thinking like a lawyer."
But it would be nice if the students learn that using the laws used in the country they study in today and not the laws used in the Roman empire 2000 years ago.
You would be surprised but Roman law is actually taught in pretty much any law school today because its principles are in many cases the foundation of how modern law systems work. And many concepts that were introduced in it are still as valid as they were 2000 years ago.
OK, bad example but nowadays we don't crucify people and slavery has been banned for a while as well.
I have also faced this when teaching at the university. University is not there to teach you the tools but to show you the general principles. The role of the teacher is not to show you which buttons in the IDE to press or how to work a specific chip/technology (which will likely be obsolete by the time you graduate anyway) but to help the student understand the common principles behind it.
IMHO it is still better to use industry standards to teach principles than using obscure languages and hardware. There is a general concensus that there is a disconnect by what students learn in school and what they meet at their first job. There is also a difference between the various levels. A BSc graduate will be expected to work hands-on on hardware where an MSc graduate is likely to land a job which is at a more theoretical level.
-
Most reputable Computer Science programs start in Scheme, a language that is never used (and will never be used) in the real world. In fact, a computer science program that starts off in a "practical" language (Python, Java) is generally viewed with suspicion.
This is because new languages and technology incorporate layers and layers of abstraction which make it impossible to truly understand what is going on. Unless you understand computers at their most basic level you will eventually be surprised, and your depth of knowledge will be unable to predict or explain the behaviors you observe.
I will say from experience that it is very easy to move "up" the chain of abstraction. An experienced assembly, C++, and lisp programmer can learn any programming language in days, whereas someone who has only used Java/Python will not be able to move down the stack without intensive study. This is because new technologies build on old ones, and wrap the underlying structure in more convenient abstractions. If you know operations A, B and C, then you can recognize new feature D as A+B. But if you just use D for everything, you won't understand the subtle edge cases of A+B or even know that C is possible.
There are several reasons why it is not useful to study new technology and languages. Firstly, they change very quickly so intensively focusing on one toolchain is pointless. Secondly, and more importantly, learning a new toolchain is very easy (and more or less mundane) if you have a strong understanding of the basics.
On the other hand there is definitely a disconnect between school and work. Picking up new technologies is a very valuable skill in itself, so I think Dave's idea of having one class where you just screw around with current technology is a great idea.
-
I will say from experience that it is very easy to move "up" the chain of abstraction. An experienced assembly, C++, and lisp programmer can learn any programming language in days
This is because new technologies build on old ones, and wrap the underlying structure in more convenient abstractions.
Not in the modern world. Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting. The difference is like creating an opamp from discrete transistors versus using an opamp which comes as a chip in a package.
-
In function and in its symbol. We give candidates a simple electronics quiz. On part of the quiz they have to identify the schematic symbols of various components. He left the diode symbol blank. When I questioned him about it he said he didn't know what it was. I told him it was a diode and asked him to describe the function of a diode. He couldn't. I know this sounds ridiculous and preposterous, but it actually happened. He was within a month or two from graduating from UC Davis with a BSEE degree.
What the hell is going on at those institutions?
Nothing. They're turning out some of the best Z80 programmers of all time. Of all time!
You sir win the internets! =D :-DD
-
Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
-
Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
The documentation will, at best, indicate how to invoke the libraries, but they certainly won't tell you the limits of what you are asking the library to accomplish - and often won't indicate the "infelicities" in the implementation.
When, for example, did you see an RPC library that mentioned the Byzantine General's problem, or a distributed cache library that mentioned the Split Brain problem, or a distributed transaction library that mentioned that Two-phase Commits can silently fail? Or, at a lower level, a flip-flop datasheet that defines its metastability time constants?
-
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
There are many many libraries where you have no need to understand what's going on under the hood, and most of those don't even come with documentation that indicates what might be happening under the hood. Graphics and other user interface toolkits come to mind. There are many other libraries where its vital to understand what is happening under the hood, and it is extensively documented. The major of DSP libraries are in this category.
-
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
There are many many libraries where you have no need to understand what's going on under the hood, and most of those don't even come with documentation that indicates what might be happening under the hood. Graphics and other user interface toolkits come to mind. There are many other libraries where its vital to understand what is happening under the hood, and it is extensively documented. The major of DSP libraries are in this category.
And there are many many many libraries that don't fit into either of those categories. I noted an infinitesimal proportion of them in the examples you snipped.
Sorry, but that's the economics of the real world.
-
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
Of course. However, the standard practice is to skip understanding and just use the library. This is one of the major mechanisms of bloat proliferation.
-
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Somehow, I think the user does need to know how the libraries work, and in great detail. I seem to recall a Mars Lander crashing because of a mixup between units (Imperial vs Metric). It's been a long time but I also remember discussions at an aerospace company about the accuracy of their numerical analysis library. Something to do with not wanting the airplane to fall out of the sky. There were a bunch of math majors working on improving accuracy.
All algorithms trade off one thing for another. If there were a perfect algorithm, the floating point library would still mess it up. We all know that series expansions often require infinite terms and, since we don't have the time, we cut it short. The question is, how much accuracy are we willing to give up.
-
I will say from experience that it is very easy to move "up" the chain of abstraction. An experienced assembly, C++, and lisp programmer can learn any programming language in days
This is because new technologies build on old ones, and wrap the underlying structure in more convenient abstractions.
Not in the modern world. Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting. The difference is like creating an opamp from discrete transistors versus using an opamp which comes as a chip in a package.
Your example proves 691175002 s point. Those never having dealt with transistors (known what is inside the box) make many mistakes in the application of op-amps. Those who do really do appreciate not having to go through the details of design and layout to make the op-amp - they buy the package and use it - appropriately. And to push the analogy even further - a course or lab on OP AMP design based on a 741 op amp is totally appropriate - even though it was not just designed, but obsolete before most of the students were born. And even though they are unlikely to actually use a 741 professionally. The flaws that exist in all OP AMPs are readily apparent in the 741, and the students will be made aware of them, and their impact on system performance. And then should be able to use a modern part and properly predict its performance in the application du jour.
-
Most reputable Computer Science programs start in Scheme...
I find that difficult to believe... Got any references?
https://cacm.acm.org/blogs/blog-cacm/176450-python-is-now-the-most-popular-introductory-teaching-language-at-top-u-s-universities/fulltext
Scheme is 40+ years old and relatively LISP-based, isn't it? LISP did achieve some commercial success...
It somewhat reminds me of my own Alma Mater, where they taught PL/1 (actually PL/C) to the CS majors, and then all the subsequent classes pretty much abandoned it for fortran, because PL/C didn't INTERFACE to anything, and only ran on one of the campus machines. (I think; I was an EE major, so I pretty much cherry-picked CS classes.)
I will say from experience that it is very easy to move "up" the chain of abstraction. An experienced assembly, C++, and lisp programmer can learn any programming language in days
Yeah, I can write Assembly and C-like programs in half-a-dozen more modern languages. I don't consider that a particularly valuable skill. :-( OTOH, many new graduates can't "code" at all, by industry standards.
On the third hand, "Computer Science" is DIFFERENT than "coding." If you take, say, the online class from Princeton in "Data Structures and Algorithms", they use Java and it's beautifully abstract. The language subset needed is pretty minimal, the libraries needed are minimal, and you can really focus on the algorithms themselves, even if you're not really much of a Java programmer. (I highly recommend the class, BTW...) And you can take other classes, and read papers, and find any number of instances where you look at it and say: "Hah! *THIS* is Computer Science!" And while coding may be easier to "move up" the abstraction layers, the Science is easier to move down...
But most jobs and real-world problems are more in the realm of engineering or worse...
-
Most reputable Computer Science programs start in Scheme...
I find that difficult to believe... Got any references?
"6.037 Structure and Interpretation of Computer Programs" at MIT still uses Scheme as its language.
-
Wow I never expected such a question to raise such robust debate among the community.
However I feel the need to clarify a few things.
Firstly coming here is step one in finding a solution to this "problem". We are students our perception is that this hardware isn't the best device to be teaching DSP on.
That is just BS tbh. You are in class to learn things. At this stage, you will have to accept that others know better than you and trust their judgement.
I had the similar objections when I was taking classes at the university about 20 years ago. Some of those classes are now the ones I value the most because the principles are still valid while some of the classes that used modern stuff (at the time) are 100% irrelevant.
That said we are basing that on our very limited experience in the industry. What better way to understand the "problem" then by asking directly the experienced professionals in the industry?
In asking you guys I have somewhat came to realize that the "problem" isn't so much of a "problem" but rather a matter of expectations. Evident by the division among the replies.
I've found that nothing beats actual *work*-experience. What you are working on in the class room will always be pretty far from what you encounter in real life anyhow. No matter what you are taught in school, you will have a rough time to break into the work force as you are competing with more experienced people. Your way around that is to work hard and make sure you show potential employers that you can apply your knowledge to new situations and that you are willing to do more than what is the bare minimum. (I.e. what I'm saying is, do extra curricular stuff.!)
As students we are wanting to get an education which will get us employed, we want to understand the fundamentals whilst also having relevant skills which prepare us for our chosen career in the industry. We expect to stand out in interviews as having the relevant skills and the experience which are required by the companies looking for staff. If your company mainly uses ARM processors (which in our opinion most do) you will naturally gravitate toward an applicant with experience in ARM over this 20+ year old processor.
Whilst many of you guys seem to agree this this ideology many also don't.
Your education doesn't get you employed - you do! Don't expect a university degree to imply that you will be hired. You are making all the wrong assumptions here. Anyone who hires someone who just graduated will not expect a whole lot of experience, because that just isn't possible. Sure they advertise that they would like 10+ years of experience from a 20yo and all kinds of unrealistic requirements. But that just tells you that the ad is written by a complete idiot or that it is a fantasy. Don't judge based on that - apply and see where it takes you.
It is all well and good to say you need to simply understand the principles and I somewhat agree. However expecting your employer to fit the bill while you learn to use modern hardware seems to be somewhat counter productive. Whilst an employer couldn't logically expect a graduate "to hit the ground running" they should reasonably expect them to hit the ground jogging or at least power walking....
If you have a degree and you just graduated, any decent employer should know what to expect imho.
Secondly the course is the final semester of an Advanced Diploma, we are using this hardware along with a hardware circuit we "designed" (filter pro did all the work for us) to filter an input signal into the DSP do a Fourier Transform using the DSP then send it to an external DAC, and back through another filter. Photo of my hardware below. We have one class using matlab to teach the theory. This is the only hardware exposure to DSP until the bachelor / Associate degree next semester. However fo some students this will be the ONLY exposure to DSP hardware before trying to enter the industry.
Depending on your degree - it's still not bad. I worked on a MScE in Computer Science and we had a grand total of two courses where we touched hardware to build something. Situation was pretty much the same for the EE students. If you know the theory, doing the practical stuff isn't all that difficult.
With that all said I / we understand nothing is going to change for us, there wouldn't be time or resource to change the curriculum. However it can be changed in the near future for future student studying this course. The only question is SHOULD it be changed...
You still have not presented any good reasons for why it should change.
Universities like using old platforms for several reasons (and not only in EE). One of them being that it allows students to focus on the important bits of the class, rather than cool new features in the platform. All the toolchains for old platforms are normally more mature and it is easier to debug (especially when we are talking about hardware).
My advice - focus your energy on something that will make it worth your time, like a personal project that you can talk about when you go to your first job interview. That will probably impress the potential employer much more than any class you've taken.
-
Is there a FPGA soft-core available for that DSP family? If the labs could be transitioned onto an affordable FPGA board without the head of Faculty having to lean on all his Professors and associates to write a whole new course, there's a bigger chance of getting something done. If it can also emulate all (or most) of the other legacy processors on the syllabus, so they can reduce the number of hardware platforms they have to support, and get rid of ancient 'in-house' custom ones, so much the better.
I remember struggling with a vile 'in-house' Z80 based system that sat between a VT100 terminal and the serial cable back to the departmental mainframe, which hosted a crappy C cross-compiler and a cross-assembler that didn't even use standard Zilog syntax. It had two controls - a Load/Run switch and a Reset button (which usually crashed your session), and two LEDs, Power and Halt. The only way the word 'stable' could be applied to it was if prefixed with 'Augean', as it had so much buffering and glue logic between the CPU and the external bus connector in an attempt to protect the reasonably affordable CPU from student dumb-f**kery that you *COULDN'T* actually guarantee to meet the timing specs for any external memory access. The general student consensus was the Z80 boxes needed to be kicked off the roof of the department then given a Viking funeral on the lake. The brighter members of the class worked around the problem - e.g. It was easier to get the required lab work done at home on my ZX Spectrum (I had the Hisoft C compiler and Hisoft Devpack Assembler + debugger), and stream the listing output to my main computer (back then, not a PC), run it through a script that massaged it to match the horrible cross-assembler, dump it to a IBM PC formatted disk, and upload it, the sources and the HEX file (in case I had to attempt to demonstrate it in the lab) to the mainframe from one of the departmental PCs that had a terminal emulator, all so I could print it to the line printer to get it on the music ruled fanfold paper they expected the lab work to be submitted on. Oddly enough it was difficult to convince final year students to take on a project that included a Z80 . . . .
Later, I had a friend who was a transfer student so didn't have prior history with the Z80 boxes. He got suckered into taking on a Z80 based project the head of Faculty had been pushing for a few years. I actually saved his project by lending him my Speccy, which by then I had upgraded with Microdrives so I no longer had to compile or assemble from cassette tape and a Multiface cartridge to provide a NMI button and a resident debugger. Even with that lot already hanging off the unbuffered Z80 bus + his hardware which had a direct bus interface to a HD44780 LCD display + a job lot of ADCs, DACs, timers etc. to implement a frequency response measurement system from DC to 1MHz, once it was all double-sided foam taped to a baseboard to avoid the infamous 'ZX RAM pack wobble' crashes, it was more stable than the departmental hardware by a couple of orders of magnitude and it was faster to develop on. There was much egg on face from technical services when he successfully demonstrated it live to the head of department running on my Speccy, made a small change to the U.I. on the spot to answer criticism, and made the proposal that the next version be based on a Speccy with a custom ROM and a keyboard overlay! :-DD
-
Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
That way you won't get very far because you'd need to learn&know way too much for a single person to handle (unless your software doesn't go beyond 'hello world' console applications). If you write decent size applications I'm quite sure there is depedance on a library for which you don't know what it does exactly.
-
*MOST* hardware manufacturer supplied libraries are like gilded turds. There's a shiny but very thin wrapper round the reeking mess inside. The newer the hardware the higher the probability that the turd is soft centred and will explode in your face. If you cant get access to the library source then *AVOID* being a bleeding edge developer on that platform! |O Standard language libraries are a much better bet as at least they have been pounded on hard by hundreds of thousands or even millions of users and if only 0.1% have bothered to file bug reports, most of the danger areas will be fairly well mapped and the more egregious bugs will have been patched.
-
Nowadays if you want to get a product on the market you need to build on other people's libraries. You can't go messing around and re-invent the wheel. This is also why you can't learn a different language in a few days. Sure the syntax can be understood but nowadays languages come with extensive libraries/frameworks which do the heavy lifting.
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
That way you won't get very far because you'd need to learn&know way too much for a single person to handle (unless your software doesn't go beyond 'hello world' console applications). If you write decent size applications I'm quite sure there is depedance on a library for which you don't know what it does exactly.
Some of my software has gone far beyond that. The key is that you don't need to know "exactly", but you do need to know where the fundamental pain points are likely to be.
It is horrifying how frequently simple questions about fundamentals reveal skeletons lurking in the closet. Often the underlying reason is the library implementer didn't realise there were fundamentals that they needed to account for, and just coded up the "happy daze" scenarios about how it is supposed to work. Those of us that have been around the block as professional engineers know it is equally important to understand how things can fail, and to deal with those use-cases.
-
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
There are many many libraries where you have no need to understand what's going on under the hood, and most of those don't even come with documentation that indicates what might be happening under the hood. Graphics and other user interface toolkits come to mind. There are many other libraries where its vital to understand what is happening under the hood, and it is extensively documented. The major of DSP libraries are in this category.
And there are many many many libraries that don't fit into either of those categories. I noted an infinitesimal proportion of them in the examples you snipped.
Sorry, but that's the economics of the real world.
I thought the stuff I snipped was examples of bad libraries with inadequate documentation. There sure are plenty of those.
-
*MOST* hardware manufacturer supplied libraries are like gilded turds. There's a shiny but very thin wrapper round the reeking mess inside.
I'm not writing about crappy microcontroller libraries to wiggle GPIO pins but libraries which come with an OS or a programming framework.
-
*MOST* hardware manufacturer supplied libraries are like gilded turds. There's a shiny but very thin wrapper round the reeking mess inside. The newer the hardware the higher the probability that the turd is soft centred and will explode in your face. If you cant get access to the library source then *AVOID* being a bleeding edge developer on that platform! |O Standard language libraries are a much better bet as at least they have been pounded on hard by hundreds of thousands or even millions of users and if only 0.1% have bothered to file bug reports, most of the danger areas will be fairly well mapped and the more egregious bugs will have been patched.
There is a major psychological problem in the semiconductor industry, where most people in control are silicon people and most non-silicon people are looked down on. This is not a good environment for either systems design or software development. This tends to show in the lack of attention to detail in the systems design of silicon, and even more so in the quality of the accompanying software.
-
Even though libraries are widely used, but they're rarely understood. The whole point of using the libraries is that there's no need to understand the underlying algorithms. Libraries are used as black boxes. Even a cave man can do it.
Nonsense. You need to understand the underlying algorithms in order to know what they can and cannot do.
There are many many libraries where you have no need to understand what's going on under the hood, and most of those don't even come with documentation that indicates what might be happening under the hood. Graphics and other user interface toolkits come to mind. There are many other libraries where its vital to understand what is happening under the hood, and it is extensively documented. The major of DSP libraries are in this category.
And there are many many many libraries that don't fit into either of those categories. I noted an infinitesimal proportion of them in the examples you snipped.
Sorry, but that's the economics of the real world.
I thought the stuff I snipped was examples of bad libraries with inadequate documentation. There sure are plenty of those.
Precisely; the majority.
Hence the reason you have to understand what's going on under the hood, unlike "NorthGuy" contention.
-
Hence the reason you have to understand what's going on under the hood, unlike "NorthGuy" contention.
You're very good at misinterpreting NorthGuy's contentions. I didn't say that people should use libraries without understanding internals. I said that people do use libraries without understanding internals. Most of them do. BTW, you do it too. Remember, "... XMOS IDE guarantees hard timing ... ", you don't know how but it is enough for you to know that it guarantees it.
Personally, I don't use very many libraries. Most of my encounters with libraries proceed like this:
1. That's a cool library, it does exactly what I need. I will use it. It'll save lots of time for me.
2. Let's look at the interface. These are such and such functions. Very good.
3. I understand well what functions x() and y() do, but z() looks confusing. Let's see what it does.
4. Ok. I see what z() does now. Turns out that what it does is really simple.
5. Now that I understand what the library does I can see that it does lots of things which I don't need. The creators tried to cover a multitude of use cases, but in my particular case most of the functionality is not needed.
6. It would be nice to change the way how the z() function works. This would let me greatly simplify the rest of my code.
7. Rather than messing with the library, why don't I re-write z() in my own way.
8. Looks like there it was a very useful library, but now it appears I'd be better off writing the code by myself. It'll make it more compact and much more suitable for my use.
If I stopped at (2) or (3), it would appear to me that using the library is necessary and unavoidable and I must use it. But if I anticipate that I will go all the way through to the (8 ) anyway, I can just start from there right away - "Here's a nice library, do I have to use it or may be I can get by without it".
-
*MOST* hardware manufacturer supplied libraries are like gilded turds. There's a shiny but very thin wrapper round the reeking mess inside. The newer the hardware the higher the probability that the turd is soft centred and will explode in your face. If you cant get access to the library source then *AVOID* being a bleeding edge developer on that platform! |O Standard language libraries are a much better bet as at least they have been pounded on hard by hundreds of thousands or even millions of users and if only 0.1% have bothered to file bug reports, most of the danger areas will be fairly well mapped and the more egregious bugs will have been patched.
There is a major psychological problem in the semiconductor industry, where most people in control are silicon people and most non-silicon people are looked down on. This is not a good environment for either systems design or software development. This tends to show in the lack of attention to detail in the systems design of silicon, and even more so in the quality of the accompanying software.
TBH, the people in control are finance people and most SW and HW projects are bound by financial decisions with the resources they have.
I have experienced the scenario where "SW people" had free reign over embedded libraries. Several of these were absolutely unreadable and impractical for the embedded world: SW packages with many levels deep of directories that turned a simple blinky LED project a maze of source files and directories; code reuse taken to the max with zillions of #define directives for each platform of interest; use of brand-spanking-new build environments with promised high efficiency but with obscure principles and a steep learning curve; code ridden with shenanigans that were designed by folks trying to show off as the smarter kid on the block, and so on.
I also experienced the opposite scenario: out-of-box examples that couldn't be built properly; lack of a minimum hardware abstraction with code ridden with architecture intrinsics or inlined assembly code; poorly commented code with a lack of proper documentation, complete disregard for code modularization, with header and source files overreaching their scope, and so on.
-
Hence the reason you have to understand what's going on under the hood, unlike "NorthGuy" contention.
You're very good at misinterpreting NorthGuy's contentions. I didn't say that people should use libraries without understanding internals. I said that people do use libraries without understanding internals.
Actually you did write something asymptotically close to that!
You wrote "The whole point of using the libraries is that there's no need to understand the underlying algorithms." in https://www.eevblog.com/forum/microcontrollers/engineering-students-being-taught-dsp-on-20-year-old-processors-rmit/msg1292262/#msg1292262 (https://www.eevblog.com/forum/microcontrollers/engineering-students-being-taught-dsp-on-20-year-old-processors-rmit/msg1292262/#msg1292262)
Most of them do. BTW, you do it too. Remember, "... XMOS IDE guarantees hard timing ... ", you don't know how but it is enough for you to know that it guarantees it.
You are fantasising. I have looked hard at the that, have seen how it works and - while it isn't perfect -, I haven't found a significant avoidable fault in it.
-
Actually you did write something asymptotically close to that!
You wrote "The whole point of using the libraries is that there's no need to understand the underlying algorithms." in https://www.eevblog.com/forum/microcontrollers/engineering-students-being-taught-dsp-on-20-year-old-processors-rmit/msg1292262/#msg1292262 (https://www.eevblog.com/forum/microcontrollers/engineering-students-being-taught-dsp-on-20-year-old-processors-rmit/msg1292262/#msg1292262)
You haven't scrapped enough context. You could've done much better: "there's no need to understand ... algorithms."
-
Actually you did write something asymptotically close to that!
You wrote "The whole point of using the libraries is that there's no need to understand the underlying algorithms." in https://www.eevblog.com/forum/microcontrollers/engineering-students-being-taught-dsp-on-20-year-old-processors-rmit/msg1292262/#msg1292262 (https://www.eevblog.com/forum/microcontrollers/engineering-students-being-taught-dsp-on-20-year-old-processors-rmit/msg1292262/#msg1292262)
You haven't scrapped enough context. You could've done much better: "there's no need to understand ... algorithms."
We notice you have chosen to avoid addressing the point, and have introduced a strawman argument. Sorry, I'm not going to bite, other than to note that it doesn't make you look good.
If anybody is actually interested, they can easily follow the pointer I gave to see the context - and see that I didn't snip anything significant.
BTW, your quoting is "off".
-
We notice you have chosen to avoid addressing the point,
What point? I described how things are done. You misinterpreted this as my argument that the things should be done this way. Is there any point in this?
If there's any more to this that I don't see, please let me know.
BTW, your quoting is "off".
Guilty. Wouldn't it be nice if the forum could warn you about mismatched quotes as the compiler does?
-
Candidate 1 and 2 have similar BSCS programs. They both did most of their classes using Java, Python, and Javascript. They took classes in basic programming, generalized computer architecture, data structures and algorithms, compiler design, mathematical theory of computation, digital logic, UI/Graphics, networking, web page design, and etc in addition to the usual crop of science, math, and "Social Science and Humanities" classes.
EXCEPT - their "embedded systems" class were significantly different.
One class used Arduinos and existing Arduino libraries, and focused mostly on the sort of devices you can connect to a microcontroller. For a final project, the student built an alarm clock that used an I2C RTC, read images from an SD card that were displayed to an SPI TFT display, automatically corrected for ambient brightness, and played chip tunes on a PWM output, plus ran some NeoPixels just for show.
The 2nd class learned to program AVR in assembly language, mostly using the AS simulator on their laptops. Most of the class was spent learning the assembly language and AS. The final project was a "voltmeter" that read the ADC and displayed the results on a multiplexed 7-segment display, but everything was written from scratch, in assembly language.
Which one do you hire?
(It's a trick question: you hire the one that's been reading enough on their own time to have an opinion on whether TI Tiva ARMs are better or worse than SiLabs Gecko ARMs... :-) )
-
Of course. However, the standard practice is to skip understanding and just use the library. This is one of the major mechanisms of bloat proliferation.
It's simple economics. If chips are cheap and people are expensive, it pays to slap in a more powerful chip and call it done, rather than optimizing it to the hilt. I think Jack Ganssle mentioned some companies using much more expensive chips, so they can run a complex OS and hire much less expensive developers.
It's not necessarily a bad thing. Developing black boxes that can be used elsewhere in a modular fashion can greatly increase final efficiency, even though the system as a whole is not perfectly optimised. The trick is to develop a black box that won't trip up whoever uses it.
-
It's simple economics. If chips are cheap and people are expensive, it pays to slap in a more powerful chip and call it done, rather than optimizing it to the hilt. I think Jack Ganssle mentioned some companies using much more expensive chips, so they can run a complex OS and hire much less expensive developers.
It's not necessarily a bad thing. Developing black boxes that can be used elsewhere in a modular fashion can greatly increase final efficiency, even though the system as a whole is not perfectly optimised. The trick is to develop a black box that won't trip up whoever uses it.
Of course, the development should be driven by economics. But bloated software isn't necessarily faster or cheaper to develop.
Using black box component may be beneficial (faster, cheaper), but it also may be detrimental (big delays, unforeseen extra costs). The cost of the black box, the cost of using it, and the risk it poses should be measured, weighted, and then the design decision should be made whether the black box should be used or not.
If you don't really know what might be inside the black box then the cost of developing an alternative looks very high for you. When internals are unknown, everything looks magic. In this case, you don't really have any choice other than using the black box.
On the other hand, if you know and understand what's inside, you can evaluate the cost and time of developing an alternative solution in house. Then you can compare your estimates and decide for or against the black box.
-
Of course, the development should be driven by economics. But bloated software isn't necessarily faster or cheaper to develop.
Using black box component may be beneficial (faster, cheaper), but it also may be detrimental (big delays, unforeseen extra costs). The cost of the black box, the cost of using it, and the risk it poses should be measured, weighted, and then the design decision should be made whether the black box should be used or not.
If you don't really know what might be inside the black box then the cost of developing an alternative looks very high for you. When internals are unknown, everything looks magic. In this case, you don't really have any choice other than using the black box.
On the other hand, if you know and understand what's inside, you can evaluate the cost and time of developing an alternative solution in house. Then you can compare your estimates and decide for or against the black box.
In programming, creating robust black boxes is the basis of success for a lot of things. Both the Unix philosophy and object oriented programming are successful because of it. It shouldn't work much differently when using hardware or software made by another. Increasing knowledge of the black boxes you use might help you improve the project, but in any sizeable team, black boxes are explicitly used to prevent everyone from having to know and understand everything. You modularize the project and have every part of the team focus on its own area.
You also should be mindful not to fall victim to NIH, or the Not Invented Here syndrome. You wouldn't be the first company, or even the millionth, to think that in-house development is a shortcut, only to embark on a hugely expensive and painful journey towards an inferior product. Cost estimations in this area often are wildly inaccurate.
-
Just attend the class and use the given processor. Buy a cheap $25 ARM STM32F4-based discovery kit and implement the algorithms and exercises in C using fixed point and floating point. You will learn quite a lot and you will learn the ARM as a byproduct.
this is the best, most concise answer the OP could get. hope he realizes why (if he doesn't reread the topic).
this is also what the professor should have told him, word for word. if the professor wanted to use an updated architecture for an updated course he would already have. we had some who did, some who didn't. why doesn't he? probably because it doesn't matter.
regarding obsolescence: in almost every industrial production environment there is at least one very expensive machine that still uses dos/3.1 and it needs to be mantained. Many important softwares for PA are still using dos/3.1/95 unless they were updated to work on a more modern OS in the last year.
wasn't nasa looking for a guy a couple of years ago that knew assembly for a very specific processor used in satellites systems?
-
Talking to a recent student yesterday that just got hired, he could not spent an extra year on his study for fun as most of us could in our times, his MSc program on the technical university was so full he was glad to pass it in nominal time. The HR department asked about his extra curricular activities they were most impressed with the fact that he took an italian class in Rome on one of his holidays. They did not ask about his engineering hobbies and hired him for his degree and potential. The rest he will have to learn on the job since the machines they are building are so complicated (waversteppers) that they expect anybody they hire even professionals with 10+ years of experience to be learning the first year anyway.
Just saying that there are many jobs out there where it does not matter what you did, if you are intelligent and eager to learn and a good team player you will have the job.
-
You also should be mindful not to fall victim to NIH, or the Not Invented Here syndrome. You wouldn't be the first company, or even the millionth, to think that in-house development is a shortcut, only to embark on a hugely expensive and painful journey towards an inferior product. Cost estimations in this area often are wildly inaccurate.
The converse is also true :(
"Buying in" opens the Pandora's box of buying a crap product, a poorly documented product, or one that has hidden/undocumented internal gotchas that mean it won't play well with the other things in your product. There is no, and can be no, simple solution to the buy-vs-build dichotomy.
All you can do is apply humility, diligence, and previous experience to choosing a development path. The motto "trust, but verify" is a good guiding principle, but it can be so expensive that it is cheaper to simply build.
-
IMHO it is still better to use industry standards to teach principles than using obscure languages and hardware. There is a general concensus that there is a disconnect by what students learn in school and what they meet at their first job. There is also a difference between the various levels. A BSc graduate will be expected to work hands-on on hardware where an MSc graduate is likely to land a job which is at a more theoretical level.
Yes and no. I agree with you theoretically, however practically that is just not possible in many cases. There are both pedagogical reasons for it (teaching concepts not tools) and purely practical ones.
E.g. I am software engineer by trade who taught a lot of programming and computers graphics courses. If I had to teach programming using "industry standards", what should I pick? Should I focus on javascript because web programming is *the thing* today? Which one? The classic one? The ES6? Which frameworks? React? Vue? Angular? Whatever-the-fad-of-the-day-is? Which versions? (they tend to become obsolete 2 months after release ...). This is an extreme example, but it isn't that far off in other fields neither. And then someone will cry why am I teaching Javascript and not Typescript, why I am using node.js instead of Rails (or vice versa), etc.
Something changing that fast is not something you can build a curriculum on, especially when curricula are being updated and approved in 5-10 year cycles. The teacher is not free to teach whatever they want, they have a curriculum to follow, with more or less implementation freedom, depending on course/department/university.
Also, in order to teach a certain technology you need to have the people who actually know it - the university profs are rarely following the latest tech for teaching because teaching is almost never rewarded. Their tenures and funding hang completely on their research output (papers, patents, etc.), teaching gets little to no credit. You can be the best teacher in the world but if you don't produce research then you get fired/your funding gets cut. Given such conditions, teaching is often see as only the necessary evil the profs don't really get paid for and don't get resources for. So only minimum time and money is spent on it. So nobody is going to train themselves for e.g. a new CPU architecture only for the sake of teaching it.
Apart from teachers, you then have all the supporting materials for the new tech (books, software, lab equipment, etc.). That all costs non-trivial amounts of money and e.g. a school can will not be all crazy about replacing e.g. Z80 based lab course with an ARM based one - it is not only about replacing the devboards but all the course material has to be rewritten, lab staff retrained, new hardware bought, new software acquired etc. This is a huge and expensive job, even if you use vendor provided course material (common in the US, much less common in Europe, requiring obscenely overpriced textbooks & tools is just not the thing many teachers want to do).
It is the main reason why universities are still teaching with 20+ year technologies. They work, all the course materials are there, tested and proven, they allow the students to learn the concepts (also, will you really learn more about how a CPU works using the newest whizbang ARM CPU that you cannot even probe without special tools or an old Z80 in a DIP socket where you can literally stick LEDs on a bus?) and the money can be spent on other, more useful/urgent things.
I am going to repeat myself, but university is not there to teach tools and technologies. That's the job of a professional training or a vocational school. Uni is there to teach you the concepts, any tools you learn in the courses are only a bonus. The students are expected to learn the tools they need (editors, IDEs, compilers, stuff like Matlab, ...) themselves.
And no matter what you do, no university will never be able to teach the latest and greatest tools for the reasons outlined above. This is a common misconception many students have too - "Why do I have to do X using Y and not Z that everyone in the industry uses?!" Well, because there are reasons for it that you may not see or understand (e.g. the pedagogical ones). Or simply because the Uni doesn't have resources for it - it is not just about acquiring the tool, the most significant costs are the overhead around.
So bear this in mind before bashing someone's course only because they are using old technology to teach it.
-
oh for some strange sense of irony, in the meanwhile something happened and I now have to get hands on the second evaluation board made by Motorola during 90s.
Why? Because it uses a DSP56002 and a coupld of customers do need for consulting a professional.
Obviously I am not the pro-guy of the scene, but I am who has to help the pro-one (the One?) in writing his documentation since it's huge!
my boss: "hey, oh? It's a dirty job, but somebody's gotta do it ... It's your turn!"
me: "FSKSHT, why always my turn, eh?!?!?!?" :rant:
answer: "because I am the one with a badge on his jacket which allows to have two secretaries, a personal coffee machine inside his office, to give orders to people, and .... to make employed without a desk!"
Ah, ok, now it makes sense, LOL :-DD
-
The trick is to develop a black box that won't trip up whoever uses it.
Nor expose the retarded architecture of the internet and frequently bring it down to its knees ... they failed.
-
this is the best, most concise answer the OP could get. hope he realizes why (if he doesn't reread the topic)
We are reading and incidentally we had already purchased an ARM processor to see if we can actually replicate the same task on modern hardware.
:-+
-
this is the best, most concise answer the OP could get. hope he realizes why (if he doesn't reread the topic)
We are reading and incidentally we had already purchased an ARM processor to see if we can actually replicate the same task on modern hardware.
:-+
If you want to do something that will be applauded by both your teacher and prospective employers, build an emulator for the DSP and then perform the tasks in your emulator.
Back in my university days, I took an AI class. The lab part of the class was designed around a LISP library and it took me and my lab partner about 20 minutes before we both wanted to puke from writing parenthesis. So, what do you do? Well we simply refocused our efforts and wrote a transpiler. Not only was it a great deal of fun, but it also turned out to be a really clever idea as we could focus much more on clever algorithms and less on data structures in our actual code.
Now, how is this different from what the OP is suggesting? Well, for one, we didn't try to replace the platform (the LISP library in our case) and we also had to understand how it worked just as much as our fellow students. What we did was extend the solution to go beyond what was expected, not replace the basis for it. It wasn't really until the lab assistant started asking how we managed to break the high score for one of the labs by about 4x that our little side project became known.
-
I have been also criticized for teaching using an 'old' processor by some students and faculty. In this case an 8051 derivative, albeit a recent fancy one. So, not long ago I had a slight change of tactics: I teach using the 8051, students complete the course assignments using something else. The options I provide: STM32, LPC824, ATmega328, PIC32, and MSP430 (new this year) or anything else they find/buy! I require them to bread board their own system. Most of the programming is done in C but some assembly may be also present. The purpose of this is to teach them principles as well as to force them to RTFM (in an educational environment the F stands for 'fantastic').
-
I have been also criticized for teaching using an 'old' processor by some students and faculty. In this case an 8051 derivative, albeit a recent fancy one. So, not long ago I had a slight change of tactics: I teach using the 8051, students complete the course assignments using something else. The options I provide: STM32, LPC824, ATmega328, PIC32, and MSP430 (new this year) or anything else they find/buy! I require them to bread board their own system. Most of the programming is done in C but some assembly may be also present. The purpose of this is to teach them principles as well as to force them to RTFM (in an educational environment the F stands for 'fantastic').
Like the famous four f's of evolution: fighting, fleeing, feeding and mating.
They're young adults, they should know how things work by now :D
-
Well, if you think this is strange - think again. At Zagreb University, Croatia if you are a student at Faculty of Electrical Engineering and Computing you can choose this course:
http://www.fer.unizg.hr/en/course/tbt1# (http://www.fer.unizg.hr/en/course/tbt1#) :palm:
I am ashamed to have a degree from that University, although it was 35 years ago when such stupidites were non-existent...
- addendum:
Oh, there's second degree too:
http://www.fer.unizg.hr/en/course/tbt2# (http://www.fer.unizg.hr/en/course/tbt1#) :palm:
-
Well, if you think this is strange - think again. At Zagreb University, Croatia if you are a student at Faculty of Electrical Engineering and Computing you can choose this course:
According to my experience you can choose between a lot of things. I picked my own courses in my final year (BSc). Amongst the choices I recall seeing 'playing the piano'. That was tempting but I ended up choosing source encoding (compression algorithms).
-
You are probably right - but we have a different system here. If you are studying EE&C, the courses you can choose from are ALL strictly related
to this field - you can't, for example, take courses in liberal arts, music or Greek philosophy. THE ONLY course that has nothing to do with EE
is that one. And I do not consider this to be normal in a secular (at least on paper) state.
-
this is the best, most concise answer the OP could get. hope he realizes why (if he doesn't reread the topic)
We are reading and incidentally we had already purchased an ARM processor to see if we can actually replicate the same task on modern hardware.
:-+
i don't see why you shouldn't be able to :-+ then at your future workplace you will have to use even another architecture, guaranteed ;)
-
I have been also criticized for teaching using an 'old' processor by some students and faculty. In this case an 8051 derivative, albeit a recent fancy one. So, not long ago I had a slight change of tactics: I teach using the 8051, students complete the course assignments using something else. The options I provide: STM32, LPC824, ATmega328, PIC32, and MSP430 (new this year) or anything else they find/buy! I require them to bread board their own system. Most of the programming is done in C but some assembly may be also present. The purpose of this is to teach them principles as well as to force them to RTFM (in an educational environment the F stands for 'fantastic').
That's not a bad approach how to get them to actually understand the topic - by forcing them to transfer the skills. OTOH, I am not sure I would do this on a completely beginner's course, it could be a tad overwhelming - the point being learning the subject, not battling unknown tooling/platform. However, if your students have the level already where they can handle this, great! :-+
The uni I have taught at used semester projects where the students had to apply the knowledge gained from the courses. Most would pick the tools they knew from the courses for the projects too but they are free to use whatever they want in most cases. So I had students do all sorts of weird and wonderful things, including some rather spectacular disasters - but hey, that's also part of the learning :)
-
That's not a bad approach how to get them to actually understand the topic - by forcing them to transfer the skills. OTOH, I am not sure I would do this on a completely beginner's course, it could be a tad overwhelming - the point being learning the subject, not battling unknown tooling/platform. However, if your students have the level already where they can handle this, great! :-+
The students have some experience programming in assembly. Usually ARM, 68k, or something else depending on who taught the prerequisite course. They also had a course in C programming. I wouldn't do that in a completely beginner's course either! They seem to handle it fine. I should mention that I provide them with a getting starting guide for each of the processors. That includes links to the documentation, IDE, compiler, flash loader, and basic examples (blinky, hello world, ADC, timer, interrupts, etc).
-
I have been also criticized for teaching using an 'old' processor by some students and faculty. In this case an 8051 derivative, albeit a recent fancy one. So, not long ago I had a slight change of tactics: I teach using the 8051, students complete the course assignments using something else. The options I provide: STM32, LPC824, ATmega328, PIC32, and MSP430 (new this year) or anything else they find/buy! I require them to bread board their own system. Most of the programming is done in C but some assembly may be also present. The purpose of this is to teach them principles as well as to force them to RTFM (in an educational environment the F stands for 'fantastic').
That's forward looking teaching, and you could also do the opposite let students do the thing
on a blingy HAL crippled 32bitter in C then do the same solution on a bare bone 8051 in assembler.
That will induce some healthy perspective into their thinking! :)
-
You are probably right - but we have a different system here. If you are studying EE&C, the courses you can choose from are ALL strictly related
to this field - you can't, for example, take courses in liberal arts, music or Greek philosophy. THE ONLY course that has nothing to do with EE
is that one. And I do not consider this to be normal in a secular (at least on paper) state.
I am sorry for you who are trapped in this educational system, and for your employers who are stuck with the result. Over the years I ran into many engineers like this. It was often physically painful to read their reports and documentation. And often their decisions missed whole areas of real world impact. The most wonderful widget in the world is useless if its function and limitations can't be communicated to the user, if the wonder and potential profit of the device cannot be communicated to the management and funding sources. In some cases a communicator will be hired to fill out the skills of such an employee, but that really means that the work of the engineer has to be so good that it justifies two salaries. Not many are that good.
At many universities you can take (and indeed are required to take) courses which result in a more rounded education. Something for those not already committed to a particular university to consider.
-
already purchased an ARM processor to see if we can actually replicate the same task on modern hardware.
That's an excellent idea. Good Luck!
I notice that there have been very few suggestions for more modern "true DSP" chips. That's "interesting", too.
My alma mater required EE candidates to take 7 semesters of "Social Science and Humanities" classes (to ensure a proper "rounded education", you know), in addition to a certain number of elective science/engineering classes, plus some "free electives", plus the required track (a total of 5 classes/semester.) It was tough (at the time) to pick up all the CS classes I wanted to take, because they tended not to qualify under the "requirements." (IIRC, "Computer architecture" was OK, but "Compilers" had to come from the "free electives.") I took Russian History, a general psychology class, "History and Sociology of Science 110: Science in Literature" (heh: Science Fiction!), a sociology class in visual perception (fascinating!), and a second psychology class focused on vision (likewise fascinating. I got to mention the then-new Xerox Optical Mouse in my final paper!), plus the credits from HS AP English.
-
I am sorry for you who are trapped in this educational system, and for your employers who are stuck with the result. Over the years I ran into many engineers like this. It was often physically painful to read their reports and documentation. And often their decisions missed whole areas of real world impact. The most wonderful widget in the world is useless if its function and limitations can't be communicated to the user, if the wonder and potential profit of the device cannot be communicated to the management and funding sources. In some cases a communicator will be hired to fill out the skills of such an employee, but that really means that the work of the engineer has to be so good that it justifies two salaries. Not many are that good.
At many universities you can take (and indeed are required to take) courses which result in a more rounded education. Something for those not already committed to a particular university to consider.
I agree with your sentiments here. In the conversation Dave had with Jack Ganssle they touch upon the trouble with the modern day curriculum. The field has become so wide that, to include all the essential parts, you cannot go too much in depth without neglecting something else. The curriculum has also been stretched from 4 to 5 years to accommodate this.
Even though it certainly does pay to make engineers more well rounded in non-engineering tasks, you have to be careful not to hurt core knowledge in the process. It also underlined the formal education only being an introduction, with the real world experience after that being integral part of your education and knowledge.
-
I need to demonstrate to the program manager...
The taught class should be about principles and problem-solving approach. The processor should have a reasonably simple architecture not to detract from the class objectives. Obviously you want to reach higher and further, so you could pitch for an environment where you can practice these concepts on 'current' technology. This could be peer-led tutorials, some 'DSP club' with a budget etc. Have a think how you could give your proposal some 'political momentum' to maximise your chances of adoption and don't forget to address supervision/liabilities.
More generally speaking, note that many moons back ARM got interested in me because I used a low-end 8-bit PIC where one would expect a much higher-end MCU.
-
I have been also criticized for teaching using an 'old' processor by some students and faculty. In this case an 8051 derivative, albeit a recent fancy one. So, not long ago I had a slight change of tactics: I teach using the 8051, students complete the course assignments using something else. The options I provide: STM32, LPC824, ATmega328, PIC32, and MSP430 (new this year) or anything else they find/buy! I require them to bread board their own system. Most of the programming is done in C but some assembly may be also present. The purpose of this is to teach them principles as well as to force them to RTFM (in an educational environment the F stands for 'fantastic').
I like this approach. It is very likely students will discuss amongst themselves the pros and cons of the platforms they choose to use for their assignment so instead of getting in touch with one architecture they get a feel for several.
-
Even though it certainly does pay to make engineers more well rounded in non-engineering tasks, you have to be careful not to hurt core knowledge in the process.
The education is (should be anyway) designed to set you up for life, which might be 50 years give or take. During this time, many things will change, and the more you go on, the more important the general education (or a lack of it) becomes. Philosophy is a good thing. It gives you a vision which guides you through. Details ... you can figure by yourself.
-
The education is (should be anyway) designed to set you up for life, which might be 50 years give or take. During this time, many things will change, and the more you go on, the more important the general education (or a lack of it) becomes. Philosophy is a good thing. It gives you a vision which guides you through. Details ... you can figure by yourself.
I don't think there exists, of ever has existed, an education that sets you up for life. If done properly, it can act as a catalyst and also give you a basic survival kit of skills. Education is just the beginning.
I would also argue the contrary of it becoming more and more important. After a few years, people will not care much about your formal training. What you did and learnt recently is much more important and a curious and inquisitive mind is by far the most important element.
-
Education is just the beginning.
Exactly. It is important to begin well.
I would also argue the contrary of it becoming more and more important. After a few years, people will not care much about your formal training. What you did and learnt recently is much more important and a curious and inquisitive mind is by far the most important element.
Education is not formal training. It plays very important role in determining whether you get the "curious and inquisitive mind" which you value so high. The development of a human brain is such that in the age from about 18 to 25 the function is predominantly driven by emotions while rational thinking is suppressed and gets developed. What you do at this age determines the nature of your mind.
It is the same as speach. If you didn't learn to speak by the age of 10, chances of you speaking are slim to none. Rational thinking follows the same pattern. If you don't develop it by the age of 25, you don't have any chances. But if you do, you can use it to learn whatever you like rather quickly. Here's where the education comes in - it develops your brain and teaches you to think.
-
Education is not formal training. It plays very important role in determining whether you get the "curious and inquisitive mind" which you value so high. The development of a human brain is such that in the age from about 18 to 25 the function is predominantly driven by emotions while rational thinking is suppressed and gets developed. What you do at this age determines the nature of your mind.
It is the same as speach. If you didn't learn to speak by the age of 10, chances of you speaking are slim to none. Rational thinking follows the same pattern. If you don't develop it by the age of 25, you don't have any chances. But if you do, you can use it to learn whatever you like rather quickly. Here's where the education comes in - it develops your brain and teaches you to think.
I don't see how this all detracts from my previous statement that it shouldn't hurt the core knowledge in the process.
-
This doesn't really apply to microprocessors but often by the time many technologies get to start being taught in academia they are already old news and the field has by then moved on to newer things.
Technology skills are the most rapidly moving of targets imaginable. People also have to keep using them or they will very rapidly forget much of what they know.
-
I don't see how this all detracts from my previous statement that it shouldn't hurt the core knowledge in the process.
The nature of the knowledge is irrelevant. Life is long and changing. Doesn't matter if you have a degree in mathematics or in EE. Your knowledge may be drastically different, but if you had good education then you can learn new things quickly, and consequently you can take on any job. People switch careers quite often and with great success.
-
The nature of the knowledge is irrelevant. Life is long and changing. Doesn't matter if you have a degree in mathematics or in EE. Your knowledge may be drastically different, but if you had good education then you can learn new things quickly, and consequently you can take on any job. People switch careers quite often and with great success.
Again, I don't see how this detracts from my previous statements. The core knowledge should be safeguarded, for it enables exactly what you describe here.
-
Again, I don't see how this detracts from my previous statements. The core knowledge should be safeguarded, for it enables exactly what you describe here.
Very well then. Looks like we agree on that. Perhaps I misunderstood what you encompass by "core knowledge".
-
As jobs get scarcer, it starts looking like a game of musical chairs and geopolitical concerns start getting in the way of common sense..
This kind of thinking puts services, 80% of all jobs, on the bargaining table.
In order to put all those jobs into play, they anticipate lots of churning..
This has been encouraged by various political entities.. and hidden by others.
Jobs in services are now internationally "tradable commodities".
-
I don't see how this all detracts from my previous statement that it shouldn't hurt the core knowledge in the process.
The nature of the knowledge is irrelevant. Life is long and changing. Doesn't matter if you have a degree in mathematics or in EE. Your knowledge may be drastically different, but if you had good education then you can learn new things quickly, and consequently you can take on any job.
To me this translates to: if you are smart you can learn new things quickly.
Generic things like physics, math and language are skills you can use for your entire career. However more specific skills like programming languages, hardware platforms will change drastically so while necessary to land a first job these will change.
-
I agree that some things are old. There are communities for newer processors where you can find a ton of information to understand your hardware better. There are options like in circuit debugging, JTag etc which can save you a lot of time. But assembly is not old, every line of code in any language in any processor ends up in assembly. Knowing it doesn't mean that you will use it but you can learn and understand any other language better.
I believe that it's the best way to feel your hardware. You have all the knowledge to build on it. You can be better if you work on it.
Then hardware comes in, if you have to set 1000 registers to do something then you won't learn. Old mcu means simplicity and most of the case same principles so you know how they did it in the past and you can understand perfectly the newer implementations, the benefits etc.
Then its up to you to learn the latest MCU. If you could learn ARM in a semester without knowing shit about it before then you can learn the same things in half that time with all that you know from old mcu. And I am talking about 100% knowledge, sure 50% ARM is better than 50% an old MCU because you lost the ability to build on it. You can't expect a uni to make you a master on anything, they just give you the tools.
-
As a final, more focused recommendation for those who feel training on a specific processor is necessary to land a job.
Study the companies where you intend to apply for employment. Find out what processor those companies use. If the all use the same one, lucky you. If not, more work in your near future. Because the next step is to google, buy development boards, buy books and anything else you can to learn about those systems. Practice on them. Start small with "hello world" and "blinking light" applications. Then do something useful. Repeat for each processor on your list.
After this you should be as prepared as possible for those companies that want new graduates with specific processor experience.
This technique of studying what a company you are interested in working for does works wonders whether the company does microprocessor development or builds waste treatment macerators.