[SOLVED] C vs Assembly in Pic programming

[kgavionics]

Hi guys
i'm planning to learn C to program pic micro controllers and its a big dilemma for me.
i like assembly because i can manipulate registers and that allows me to understand the hardware side of the chip.As student in electronics , i like the low level side of the digital electronics,so with C will i have the same possibility to understand how the micro controller works? the only down side of assembly for me it takes too much time to write a simple program.
can someone who used to use assembly and now had switched to C, tell me if it's worth to pass to high level language and what's the advantage to use C over assembly.

thank you in advance

 

[kam1787]

Where in Canada are you? My hometown is Victoria.

C
-----------------------------------------------
much much faster to write AND debug
easier to use functions
easier to use libraries
easier to re-use code
more portable
more widely used
basis for C++ and JAVA


Assembler
======================
runs faster


BTW did you know you CAN call assembler routines from in C? If the C code runs too slow, you can code in Assembler and then call from C.

 

[bigdogguru]

There are still occasions where the use of Assembly Language are necessary.

Code derived from Assembly is deterministic, while code from C is not.

As such Assembly Language is often used to implement predictable accurate delays and tasks whose sequence of operations must not change regardless of the make/model/version of the compiler.

Assembly Language routines are also used to implement Interrupt Service Routines, whose speed, minimal latency and size is of the utmost importance.

It is often not a question of selecting one or the other, but having the knowledge to effectively combine them for the reliability and performance.

BigDog

 

[kam1787]

As such Assembly Language is often used to implement predictable accurate delays and tasks whose sequence of operations must not change regardless of the make/model/version of the compiler.

A 'good' compiler should largely negate those concerns.

 

[bigdogguru]

A 'good' compiler should largely negate those concerns.

Unfortunately, whether compiler is "good" or "bad" is irrelevant.

Unless a section of code is specified in assembly, there is no guarantee as to the actual makeup of the resulting machine code.

For example, delay routines provided by compilers which offer any degree of accuracy are typically written in assembly language.

Attempting, to compose such delay routines using standard C language structures, like for or while loops are plagued with issues.

Changes in system clock frequency, compiler versions, optimization levels can all adversely affect the accuracy of a delay routine written in C language, while leaving a delay routine written in assembly unchanged.

In many cases, optimization can simply optimize such for or while loop based delay routines out of existence.


BigDog

 

[kgavionics]

Where in Canada are you? My hometown is Victoria.

.

i'm from Montreal kam1787, happy to know that you're canadian.
Thank you all for helping make this decision.i'm gonna use both of them from now on.

 

[kam1787]

Attempting, to compose such delay routines using standard C language structures, like for or while loops are plagued with issues.

Nobody in my peer group would consider implementing a delay [in C] using a basic loop [using for or while] largely because of variation in processing speed.

- - - Updated - - -

In many cases, optimization can simply optimize such for or while loop based delay routines out of existence.
BigDog

I never heard of code being removed by optimization! It can be moved, however.

 

[Darkcobra]

I'd say it's definitely worth it to code mainly in C, just as a practical matter. However, with the PIC I found it almost unavoidable to use a few small snippets of assembler.

For example, let's say you want to modify a single bit in a particular hardware register, while leaving the others unchanged, from your main code. An interrupt also sporadically modifies a different bit, in the same register. The processor modifies the bit by reading the register, changing the bit, then writing the updated value to the register; it cannot modify a single bit directly. So a concurrency issue exists, in which one complete operation must not be interrupted before the other is complete; otherwise the wrong result will occur. There are two ways to solve this:

1) Turn off the interrupt (or all interrupts) in the main code until the modification is complete. This takes a few extra cycles and delays the interrupt. More importantly, it relies on your ability to correctly identify all situations in which concurrency issues exist. Should you miss one, the resulting errors can be sporadic, and very hard to diagnose.

2) Perform the read/modify/write operation using a single assembler instruction, which is atomic and cannot be interrupted.

Such atomic bit modification instructions do exist on the PIC, specifically to address this kind of situation. And with the C compiler's optimization maxed out, it uses them; at least in most situations.

But when running your code in debug mode, you must turn off optimization, otherwise many debugging functions don't work. Or you may simply choose to use a lower optimization setting. And then the compiler produces three separate instructions for read, modify, and write, instead of the atomic instructions. Not good!

I solved this by identifying all common, basic operations that may require atomicity, like single-bit or masked multi-bit modification; and which may not produce atomic code based on the compiler settings. Then I created macros with inline assembly for these operations. I use them exclusively as a matter of habit, whether it is technically needed in any particular situation or not.

A few more assembler macros are used to expose particularly useful opcodes like FF1L, which no C code will compile directly to. Or rare instances when absolute maximum speed is needed. Kam1787's delay loop is also a good example, as optimization settings can indeed optimize the loop out of existence (unless you do something where it thinks some actual result from it will be used, for instance by updating a global variable); or at least significantly alter the timing.

 

[kam1787]

I used calls to Assembler code with the understanding that such causes higher overhead in processing. The C books I read did state that such calls do cause 'extra' processing - which makes sense.

 

[Darkcobra]

I used calls to Assembler code with the understanding that such causes higher overhead in processing.

It depends. For simple inline assembly on the PIC24's and C30 compiler I'm currently using, you can let the compiler choose the exact registers used by the assembly opcode. Which lets it use whatever is optimal. In this case there's typically no overhead at all, not even a single wasted cycle; it integrates seamlessly with the rest of the compiled code.

I have much less experience with assembly function calls, but from what I can see it depends on solely on proper coding, plus clues to the compiler what registers are used and how. There is no explicit reason on this platform why overhead should be higher than that of a C function call. Maybe on another platform that's true, if the compiler should use a less intelligent approach of always pushing/popping all registers around assembly function calls.

In any case, checking the disassembled code will reveal exactly what's happening, and requires much less assembler familiarity to read, than to code in from scratch. I do it whenever I question what the compiler is really doing, and it can also yield clues how to structure your C code in a way that optimizes best. Doing this you may even discover a compiler bug someday, we put a lot of trust in them to be perfect, which doesn't always hold true.

 

[kam1787]

Doing this you may even discover a compiler bug someday, we put a lot of trust in them to be perfect, which doesn't always hold true.

I using a compiler which had been refined over a 15 year period, and found a bug...............

- - - Updated - - -

It depends. For simple inline assembly on the PIC24's and C30 compiler ...........

My work environment, in this situation, was the Windows/DOS platform using primarily the MS C compiler. It would be appear that different environments have different behaviours in this context.

We also worked in UNIX environment but there was a systems programmer responsible for the library functions [which contained limited Assembler routines] - as it wasn't my domain, I didn't inquire on the nitty gritty.

 

[123jack]

I can't see a single instance to use assembler. If your C compiler is doing something you don't like then you can always use assembler
or even as suggested above - put some inline assembler in - to modify the code but I'd rather just get a better C compiler in the first place.
FYI it is not possible to modiify a single "bit" on a PIC either in C or assembler as described above. You will always be dealing with bytes.
It is an 8 bit + processor family.
Seriously there should be no need to ever use assembler these days.
Understanding it - however - is IMHO important.

 

[kam1787]

FYI it is not possible to modiify a single "bit" on a PIC either in C or assembler as described above. You will always be dealing with bytes.
It is an 8 bit + processor family.

That is odd, because I did just that often when doing data communication software. There are even commands and technqiues for doing that.

 

[kgavionics]

hi guys
what about the pic16 family, from the books i read, they said that are not optimized for C languge, but for pic18 are of course optimized to run high level languge.
i'm gonna continue using assembler for pic16f and C for Pic18 family.
another question which is the best C compiler for pic micro controller guys?

thanks

 

[bigdogguru]

another question which is the best C compiler for pic micro controller guys?

The above question is certainly off topic from the original inquiry of this thread.

As such I'm going to close thread as it has run its course.

Besides, the forum offers enough previous, "What is the best compiler?" threads to offer you a wide array of opinions and reasons for their choice.

BigDog