Hello,
I'm a micro-newbie. I have few questions please!
Is it preferable to write C instead of Assembly for such a newbie or pure Assembly/C?
Is it Ok to mix C and Assembly in 1 source code?

Thank you!

 

Hello,
I'm a micro-newbie. I have few questions please!
Is it preferable to write C instead of Assembly for such a newbie or pure Assembly/C?
Is it Ok to mix C and Assembly in 1 source code?

Thank you!

Yes, it is okay to mix C and assembly, just be sure to know what you are doing...

As far as language choice, it depends. For timing critical requirements, I use assembly, but for the most part, and so others understand what you are doing, C is the preferred choice.

 

It is ok to write exclusively in C.

Just make sure that at some point in your career you learn what is asm.

Because asm comes before C, for this reason I recommend learning asm first.

 

There is absolutely no compelling reason to ever learn assembly, no less learn it before any other programming language.

C is obtuse enough all by itself, though it so useful that can be overlooked.

Several C compilers allow you to define assembly instructions "inline," or within a C file, but for anything complex I would consider keeping the assembly by itself and letting the linker merge things. (A linker is a program that stitches several code files together to make one final executable file.)

 

Thank you for your all comments. Have a nice day!

 

C is obtuse enough all by itself, though it so useful that can be overlooked.

C on purpose is designed to give 95% the freedom of assembler once you properly understand pointer arithmetic. It however isolates such arithmetic from the hardware implementation (that is, various addressing modes).

You still have to be aware the banking, RAM, ROM, etc., but the compiler will generate the sequences automatically.

If you copy using a pointer and an index plus postincrement, to a structure with an index as well, you need quite a number of assembler instructions, not to speak of register reloading, and what is worse, register backup.

Tell me a language that implements complex addressing and is not obtuse.

In C you can spell many times deeper expression within a single line- to a degree which would be impossible to maintain in assembler. That is why you normally would forget about assembler.

If you use assembler, you need to use special addressing modes, for instance linear address space, this makes things a bit easier, but is NOT present on some MCU models.

In C on the other hand, you prefer to even minimize the number of lines further to keep the total size of the source manageable. And you'd pay a tradeoff that the resulting assembler source will be less efficient than assembler. Potentially. But, you can change and edit C so quickly, that you are often able to redesign the addressing the algorithm is using. In assembler, once it works, you are happy, and never touch it anymore (speak, very hard to change or maintain).

 

Hello,
I'm a micro-newbie. I have few questions please!
Is it preferable to write C instead of Assembly for such a newbie or pure Assembly/C?
Is it Ok to mix C and Assembly in 1 source code?

Thank you!

It makes no difference. The C compiler will emit assembler in the end anyway. Each time you use assembler, you tie that source to a specific MCU (except trivial stuff that you could code in C easily).

As long as your program is small, and you do not plan to reuse the code, or to extend, change and maintain it, it does not matter much.

Typically, there will be 2 or 3 smaller sections containing assembler. For instance if you want to implement a software USART, you would prefer assembler to control the timing.

But once you have a small network of let say 10 or so functions containing assembler, let say for I2C, and want to reuse it for a different PIC, you will encounter problems.

So, people normally live with a speed tradeoff, or they use hardware USART.

For a newbie, mix C and assembler like you wish, use whatever is easier for a particular section of the program. Later, change to C whatever you can.

The absolute variables allocation and the reloctable allocation as well (for assembler) are both a pain. This is one very big advantage of C. You only declare the variables inside the function, they will be allocated automatically.

 

If you copy using a pointer and an index plus postincrement, to a structure with an index as well, you need quite a number of assembler instructions, not to speak of register reloading, and what is worse, register backup.

While you may have needed that once as a work around for some well known errors in one version of one compiler, generally (and even with the C8 compiler under version 1.10) you no longer need such dramatic work-arounds and can write statements such as:

char Source[] = "Hello World";
char Dest[12];
...
while (*Dest++ = *Source++);

to copy a buffer from one RAM location to another.

And it is precisely statements such as "while (*Dest++ = *Source++);" which will copy the entire contents of one zero terminated string from one buffer to another, including the zero termination that lead me to call C "obtuse"to a newbie. There is a lot of work going on in a seemingly small statement.

 

There is absolutely no compelling reason to ever learn assembly, no less learn it before any other programming language.

How about a timing requirement? no reason..... ever!? Well, you've officially deemed a RISC processor pointless...

 

How about a timing requirement? no reason..... ever!? Well, you've officially deemed a RISC processor pointless...

If I have a timing requirement (and I frequently do) I use a hardware timer, and an interrupt handler, all in C.

 

If I have a timing requirement (and I frequently do) I use a hardware timer, and an interrupt handler, all in C.

And you lose the advantage of knowing exactly how long each instruction takes. What if you have 20 instruction cycles to process an interrupt in your ISR? Do you simply hope your compiler will give it to you?

 

Counting up instruction execution times isn't so much done professionally these days I think.

Solutions for that could for instance to buffer the waveform in RAM, and then clock it out. Or to use a small CPLD.

I looked at the assembler source for USB stack, and I would not want to program things like that. I would not even want to run such a code.

 

Counting up instruction execution times isn't so much done professionally these days I think.

Solutions for that could for instance to buffer the waveform in RAM, and then clock it out. Or to use a small CPLD.

I looked at the assembler source for USB stack, and I would not want to program things like that. I would not even want to run such a code.

As we discussed in a previous thread , yes, a FPGA would probably used in a professional setting, however, even if you are using an ARM processor and your ISR has to be as fast as possible, you will be expected to optimize your code in assembly.

 

As we discussed in a previous thread , yes, a FPGA would probably used in a professional setting, however, even if you are using an ARM processor and your ISR has to be as fast as possible, you will be expected to optimize your code in assembly.

I agree to that actually, yes for the ISR, sometimes assembler is used.

 

I agree to that actually, yes for the ISR, sometimes assembler is used.

Didn't think it would happen!

 

Didn't think it would happen!

If you squeese a device for the max. possible in terms of optimizing instructions to use the least of clock cycles, ask yourself if you are really on the right track.

 

If you squeese a device for the max. possible in terms of optimizing instructions to use the least of clock cycles, ask yourself if you are really on the right track.

Well, that didn't last long

If your system is already in place and you are issuing a new firmware upgrade that has to support a new feature, this very well may become an issue...

It really depends at which stage in development you discover the timing requirements...

 

Well, that didn't last long

If your system is already in place and you are issuing a new firmware upgrade that has to support a new feature, this very well may become an issue...

It really depends at which stage in development you discover the timing requirements...

I mean I'd rather discourage people from establishing larger assembly language constructs. http://www.dcee.net/Files/Programm/Sound/

 

I mean I'd rather discourage people from establishing larger assembly language constructs. http://www.dcee.net/Files/Programm/Sound/

I agree wholeheartedly, don't use assembly unless you really are going to benefit from it.

Use C when it doesn't matter if your switch statement is 10 clock cycles vs 15 clock cycles...

Use assembly if you're masochistic and don't want help from anyone else...

 

I agree wholeheartedly, don't use assembly unless you really are going to benefit from it.

Use C when it doesn't matter if your switch statement is 10 clock cycles vs 15 clock cycles...

Use assembly if you're masochistic and don't want help from anyone else...

Most of the programs I write don't really need optimization. Also C code can be optimized. I mean download some of the zip's from that site, and examine it.

Would you like to go down that road?

Normally professional software is not so much optimized these days.
Either a more powerful chip is used, or parallel computing.

It is OK to give it a try and see if the C code can be spelled differently. It is OK to use some small assembler constructs. But doing programming work using these instruction cycle timing charts, to me these days seem to be over.

Either CPLD, more powerful chip, or parallel computing are the solutions.

Even if it is possible (on Atmel controllers) to do USB in software. I have looked at such a source code.