-
I thought the stuff I snipped was examples of bad libraries with inadequate documentation. There sure are plenty of those.
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.
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.
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".
-
TBH, the people in control are finance people and most SW and HW projects are bound by financial decisions with the resources they have.*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!
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.
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.
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/#msg1292262QuoteMost 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
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/#msg1292262Quote
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.
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.
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.
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?!?!?!?"
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
-
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
-
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#
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#
-
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 