-
I agree, it's good to know assembly language, but it's not worth using it to write entire programs in any more.
Even on modern ARM chips, the startup code is usually written in assembly code. Just look for startup.S or crt0.S (sometimes lower case .s if the file doesn't need pre-processing) in the project.
https://github.com/MyEmbeddedWork/ARM7TDMI-LPC2148/blob/master/1.Docs/Codes/BUZZER/Startup.s
Sooner or later, you need to know this stuff.
-
The LPC2148 isn't a modern ARM microcontroller. The Cortex-Mx ARM controllers don't need any assembly to start or execute interrupts. You can use pure C to program these.
Personally I'm not sure whether knowing assembly is required nowadays. Mainstream compilers like GCC for mainstream platforms like ARM do generate correct code. If something does go wrong due to different optimisation levels, the problem is in the code and not the compiler. Knowing assembly has been handy for me but the times I use that knowledge become more rare.
Maybe it depends on what kind of projects a software engineer is working on. For low level stuff (hardware drivers) it can be handy but for higher level not so much. You can try to learn a million things but the trick is to learn only what is needed so you can spend more time on what really is important. All in all I'd concentrate on C and C++ for embedded development. A bit of Python for experimenting and maybe some embedded scripting could be handy. -
Mainstream compilers like GCC for mainstream platforms like ARM do generate correct code. If something does go wrong due to different optimisation levels, the problem is in the code and not the compiler.
That's the traditional "victim blaming" attitude. Now it can be true that the core issue is PEBKAC, but IMNSHO there are so many instances of it with C (and especially C++) that the tools are part of the problem.
Why else was it necessary for Hans Boehm to point out to competent C programmers that you couldn't write threading libraries in C? Now that particular "surprising" deficiency may have been rectified in later versions of C. The excessive complexity and "feature interactions" which concealed that deficiency from professional programmers has only got worse.QuoteYou can try to learn a million things but the trick is to learn only what is needed so you can spend more time on what really is important.
That's a very important point, and applying it has saved me countless hours of angst - notably avoiding C++ like the plague it is
I wonder whether Rust will diminish the appeal/necessity of C for embedded systems? That will become apparent over the next decade or so. -
While you can definitely write firmware for many projects without ever touching a line of assembly code, that is still a very valuable skill to have. It *will* come in handy at some point, whether it is for understanding or modifying some startup code when needed, or for debugging a tricky issue, especially if it's actually a compiler bug. And yes, you will occasionally run into one.
-
I wonder whether Rust will diminish the appeal/necessity of C for embedded systems? That will become apparent over the next decade or so.
Uh yeah. I am now almost convinced that Rust is a lost cause. We'll see.
-
Do you have any contacts with the tutors at your college? Can you ask a subject librarian for the school/college you will be studying with about any set texts that are recommended? Basically networking. This is what freshers week is for.
If I was to recommend a certain language, then it would waste your time. Most students in my experience just want to learn the essentials so that they can progress through the courses set for them.
Using a problem-solving approach is probably best. Kind of like building up a toolbox of different languages as you go along. For instance, I've just started using the PI PICO, so I've been dabbling in MicroPython, so I'm picking up some python along the way. And I've also got to refresh my memory on PIC assembly language to get an LCD interface working. We teach C programming where I work. You will find out that the same basic structures are the same in ALL the programming languages. It also depends on if you want to major in software or hardware. Sorry if I've not answered your question. -
Quote
While you can definitely write firmware for many projects without ever touching a line of assembly code, that is still a very valuable skill to have.
Yes, I agree, but I don't think you need specific assembler knowledge if you generally program in a high-level language. The odd times you need to sink to that level you can look up the specifics for that CPU, but in principle they are much the same. -
I learned cobol and fortran on an IBM mainframe that required punch cards and every time you hit a key on the keyboard you thought it might eat some of your fingers.
My opinion is that learning the programming concepts and terms is much more important than learning a specific language at the point you describe. Yes, learn something you think you will use even for fun.... and avoid pascal like it has covid.
But seriously, Information Systems & Technology has a long-term cancer that is stiffing advancement. That cancer has spread into education and business in general. The problem is that no matter what you learn to use or do or create today, someone will decide for you that that there is a better & different way that will eventually obsolete what you have learned. They will claim it is to make everything better, but the fact is it will make them richer.
There are entire industries that reap huge profits for every major change. New books to be written, new classes to be taught, new required courses for students, new hardware to design, build, sell, and on and on. This goes hand in hand with the disposable society we are creating where nothing is repaired. Just toss it in the trash.
Making things with ASICS means you can force people to buy new things. Could Intel design sockets that don't need to be redesigned every two years? Sure, but then they would not sell as many motherboards. They learned this decades ago; there are profits in 'upgrades'.
Instead of concentrating engineering on improving a time tested go instead for creating new higher cost equipment.
ok, I am old and bitter
I am not saying it is all bad, really. I am saying that if profit was not such a driver of the tech, the tech would be improved. Imagin if NASA or ESA was only doing what was the most profitable thing. Would there be an international space station? More likely so many communications satellites they would block out the sun. Would CERN even exist?
as an old person, all I can say is good luck.
-
My opinion is that learning the programming concepts and terms is much more important that learning a specific language at the point you describe. Yes learn something you think you will use even for fun.... and avoid pascal like it has covid.
But seriously, Information Systems & Technology has a long-term cancer that is stiffing advancement. That cancer has spread into education and business in general. The problem is that no matter what you learn to use or do or create today, someone will decide for you that that there is a better & different way that will eventually obsolete what you have learned. They will claim it is to make everything better, but the fact is it will make them richer.
That problem also has advantages - sometimes but not as often as salesmen claim.
There's an associated problem that doesn't have any advantages. HR and hands-off managers need to recruit staff for their project using technology X, so the adverts and screening process is based around buzzwords related to X. That's understandable. What isn't acceptable is that they filter out people with experience close to X that could easily be transferred to their project. That leads to clueless newbies making old mistakes all over again.
Basically in hardware, software and systems, knowledge of the fundamentals will last a lifetime. But knowledge of specific technologies has a half-life of 3-5 years. Choose which specific technologies you learn with care.