Well looks like C is the chosen one after all , ASM for optimization .

Not really. If you want to be an expert professional on embedded systems design, learn ASM first.

 

Not really. If you want to be an expert professional on embedded systems design, learn ASM first.

Thats what i had in mind , i will use it mainly and sometimes use c in paralell , i will then see witch choice is more suitable .

 

That is not what I meant.

You can program in C 100% of the time for all I care.

If you want to understand why you are doing what you are doing in C, you begin with the fundamentals by learning ASM first.

As an analogy, one does not learn to use a calculator without first learning arithmetic.

 

That is not what I meant.

You can program in C 100% of the time for all I care.

If you want to understand why you are doing what you are doing in C, you begin with the fundamentals by learning ASM first.

As an analogy, one does not learn to use a calculator without first learning arithmetic.

I appreciate your solid input , and you are right , i have wrote some c programs and am still not fully understanding the script functions , even if the program runs fine.

I would like also to thank all the other members for the opinions .

 

Not to mention time to market. It does not make sense to have person coding weeks in asembler then coding in C will bring a solution in one week.

That depends on whether or not the asm optimisation can do the job in less
memory and CPU time on a cheaper micro for a large volume of units or not.

 

...
Am asking this because i would like to know witch road to follow in this specific field .

If you asked 10 years ago I would have said YES! Learn asm for sure, it's very important.

But these days (and considering you are asking about skills for the FUTURE) I would say start learning microcontrollers in C, get good at that, and don't look back.

 

As an analogy, one does not learn to use a calculator without first learning arithmetic.

Well.... that's the way it should be, anyway. If only it were still that way. Far too many schools today require calculators in first grade and only teach students which buttons to press to evaluate an expression.

Sorry for the aside.

 

I've been out of the embedded game for quite some time, so my comments might be obsolete. Take them with the appropriate sized grain of salt.

To be really good at using an embedded processor you have to have a strong appreciation for how that processor works at the lowest level. This is because most embedded processors are rather resource-starved (if the one you are using for a project isn't, then you are probably using a processor that is too capable and could get by with a cheaper one). That will let you match your program logic to the strengths and weaknesses of the processor. Probably the best way to gain that knowledge is by programming in ASM. Now, as with all things, there are various degrees. If you spend some time getting really familiar with the workings of a simple MCU you will gain a level of familiarity that will largely translate to other MCU families that are at least reasonably comparable.

Armed with a decent familiarity with how the things work -- in particular what types of logic are fast/small and what types of logic are slow/large -- you are in a good position to write high-level code (i.e., in C most likely) that will compile well.

In a production environment the approach you take will depend on what is important for that project. If development time is not too critical but performance (speed, size, cost, etc.) is, then you will tend toward ASM. If development time is important and less than optimal performance is tolerable, then you will tend toward C.

As optimizing compilers for embedded MCUs get better and better, you will be able to use C for more projects even if they have tighter performance requirements. But using a high level language will probably always have performance penalties that can be avoided with ASM programming. But as long as accepting those penalties still results in code that is "good enough", it is better to accept the penalties in favor of the quicker development time and improved maintainability of the code base.

My guess is that, as with other areas of technology, the majority of embedded programmers in the future will have little to no "under the hood" experience or knowledge of the MCUs they are using and will rely on decent compilers and more capable hardware to be able to produce solutions that are "good enough". Since the tools they will be using will allow them to get those solutions relatively quickly, they will be the ones in demand for most of the embedded jobs. However, there will always be problems for which this approach is not "good enough" and that is where the ever-smaller pool of programmers that DO have strong "under the hood" experience and knowledge will operate. They will probably be able to command premium salaries, but finding jobs that require those skills will become harder and harder.

 

Thanks max for the book suggestion , i sent you an email BTW .

As for witch microcontroller i ll be using its not just PICs but also other brands like Intel or Samsung,winbond,tochiba , witch don't use C language i guess ??

Uh, no. C is implemented on pretty much any microcontroller or microprocessor that you can find. Assembly language is not one language, but rather a different language for each family of processors. If you are going to program all of the above processors, learn C and learn it well.

Bob, who's day job is working on a C/C_++ compiler for Intel processors.

 

http://electronicdesign.com/blog/50-years-basic-programming

Max.

 

http://electronicdesign.com/blog/50-years-basic-programming

Max.

Whats really interesting for me in programming , is the leap from punched cards based instructions controlled by mechanical machinery , and the evolution to something that looks so easy to perform with a bunch of functions .