Hi All,

Most people that know me here know that I prefer assembly (PIC) to C and I never used C when it comes to embedded systems.

I might be forced (90% chances) to code in C, so where do I start?
I am going to try to re-write my very first project in C this weekend just to get familiar a bit.

BTW, I will *always* code in PIC assembly for personal projects.

Any guidance?

Thanks in advance

Eric007

 

Have you ever programmed in a higher language? That will help.

Regardless, to me it was learning the structure and syntax. Study a Hello World C program for the basic structure.

It took me a while to learn the differences between (), [], & {}

A missing ; still haunts me.

I keep a quick reference nearby for control structures, data types, operators and common statements and functions.

I am still new to C, but have written 1,000 line programs. My first C program took me about fifteen minutes.

 

Have you ever programmed in a higher language? That will help.

Regardless, to me it was learning the structure and syntax. Study a Hello World C program for the basic structure.

It took me a while to learn the differences between (), [], & {}

A missing ; still haunts me.

I keep a quick reference nearby for control structures, data types, operators and common statements and functions.

I am still new to C, but have written 1,000 line programs. My first C program took me about fifteen minutes.

Thank you for your reply!

Yes, I can write programs (software PC-based) in C, C++, VB.Net, and C# (my favorite).

Eric007

 

Have you ever programmed in a higher language? That will help.

Regardless, to me it was learning the structure and syntax. Study a Hello World C program for the basic structure.

It took me a while to learn the differences between (), [], & {}

A missing ; still haunts me.

I keep a quick reference nearby for control structures, data types, operators and common statements and functions.

I am still new to C, but have written 1,000 line programs. My first C program took me about fifteen minutes.

15 minutes or 6 hours but...did it work?

 

If you already know C then it's easy. Install the needed programming system for the controller you will use. Get a good low-level C programming book (like Programming Microcontrollers in C by Ted Van Sickle, Motorola based but still good for the C instruction) and really study the low-level memory, pointer, logical, bitwise and control structures to how they physically map into processor memory and address space. Make speed and optimization a low priority at first and concentrate on how data moves from signal input to variables to functions/subroutines then to signal output in a systematic way so you don't write spaghetti C code, let the complier write the spaghetti ASM code. Don't be terse with names or comments or get cute with tricky control structures to save a microsecond unless needed.

 

...I keep a quick reference nearby for control structures, data types, operators and common statements and functions...

Btw, I also have written a quick reference (syntax) in notepad for each of the language mentioned above that I refer to when I forget the syntax and / or structure of something. I find it very useful and helps me to write programs quickly. I usually spend more time on the 'algorithm' and 'design' than the coding.

 

If you already know C then it's easy. Install the needed programming system for the controller you will use. Get a good low-level C programming book (like Programming Microcontrollers in C by Ted Van Sickle, Motorola based but still good for the C instruction) and really study the low-level memory, pointer, logical, bitwise and control structures to how they physically map into processor memory and address space. Make speed and optimization a low priority at first and concentrate on how data moves from signal input to variables to functions/subroutines then to signal output in a systematic way so you don't write spaghetti C code, let the complier write the spaghetti ASM code. Don't be terse with names or comments or get cute with tricky control structures to save a microsecond unless needed.

Thank you so much for this useful post. I already have MPLAB installed in my PCs. How about the compiler or... not even sure if I already installed one ...

 

For C I would install mplabX IDE and the needed compiler(s) for the chip type you wish to program on. If it's a 16 or 32 bit device the translating of academic C to embedded C programming styles will be much easier as they are GCC based. xc8 (and just about any 8bit compiler) is in it's own world as C was not designed for the 8 bit world. We can tweak the compiler to let the programmer think it's real C like is done in xc8 or you can say these are the facts of life at 8bit like with C18 and dodge the gotcha's manually.

 

@nsaspook Just downloaded "Programming Microcontrollers in C by Ted Van Sickle". Looks like a nice book. I will have to skip the first two chapters as I already know the C language.
I have some reading to do this weekend

Thanks!

 

What are you using Microchip C30?
The more proficient you are with assembler, the more of a headache you’re in for.
Try any bitwise operation in C. You’re in for writing a paragraph for what was a few lines.

For assembler to C, you are probably best thinking the assembler into BASIC, and writing the C in BASIC.

 

But bitwise operations need not require a paragraph. In one line, get me the third bit, from the right, of bitSource:

Bit3=(bitSource & 0x04) >> 2;

 

True, but that will still not be anything like what Eric is used to,
and will get ridiculous doing something like bitwise rotate a byte array and carry to the new bit.
It won’t be very RISC looking for sure.
example off the net

//
void shift_left() { // bitwise rotate array left once
for (index=0 ; index<50 ; ++index) {
disarray[index] = (disarray[index+1] >> 7) | (disarray[index] << 1);
} // index
disarray[50] = 0 | (disarray[50] << 1);
}
//

 

True, but that will still not be anything like what Eric is used to,
and will get ridiculous doing something like bitwise rotate a byte array and carry to the new bit.
It won’t be very RISC looking for sure.
example off the net

//
void shift_left() { // bitwise rotate array left once
for (index=0 ; index<50 ; ++index) {
disarray[index] = (disarray[index+1] >> 7) | (disarray[index] << 1);
} // index
disarray[50] = 0 | (disarray[50] << 1);
}
//

A smart compiler (like GCC) would mangle this into a unreadable jumble of ASM code anyway you write it in C, so write it in C so it's easy to understand and let the machine do its work. If it's so time critical that it needs hand-written ASM code then do it that way. That's the mindset of a high-level language programmer.

 

Hi, Eric.

The best way to write efficient MCU code in C is to wrap your .asm in an asm directive in a .c file -- then, compile.

 

Extremly complicated constructs in assembler boil down to a few lines C.
So you can write many lines extremly complicated C constructs.

Its not even possible in Assembler properly.
You dont get a good depth of expression especially when using RISC.
You cant reuse source codes (for instance FAT filesystem, Arduino, USB stack).
You are tied to a particular IC.
Nobody will learn the assembler syntax of your IC so you cant talk about your code.

Pretty good reasons for me to think Assemler = Museum

Still have my older Assembler codes starting from 2008, dropboxed all recently
before the next hard drive dies.

Not to speak you will be tempted to use every last bit of the too small FLASH instead of switching to a larger IC.

You can do all Assembler things in C but you get rid of the particular IC syntax.
Yet its not very good to program the VGA raster lines directly or do software USB stack.
Anyway, where is really a need for this? Does it exist?

 

Hi, Eric.

The best way to write efficient MCU code in C is to wrap your .asm in an asm directive in a .c file -- then, compile.

Sound very interesting! Can't wait to experiment that. Probably in a few days as I am busy C# coding.

Thanks a lot!

 

Extremly complicated constructs in assembler boil down to a few lines C.

Yup. And extremely complicated constructs in C boil down to a few lines in .asm. Here's an example I've shown before that computes y=g(x)/h(x) where x and y are floats, and g and h are polynomials of arbitrary order with floating point coefficients (for 18F PIC):

    pushfl    x    ;put x on stack     
    call    pushcp    ;  and a copy 

    poly    fmnum    ;compute numerator polynomial -- value on stack
    call    swapxy    ;swap numerator and x
    poly    fmden    ;compute denominator polynomial -- value on stack
    call    divf    ;divide -- result on stack

    popfl    y    ;get result from stack

 

I think @takao21203 you are right about this " You are tied to a particular IC". Personally, I do not see the need to use another MCU. I like PIC and will probably stick with that UNLESS required to use another MCU such as AVR or ARM or ...
The only good thing about C, IMO I think, is that you can reuse the same code with minor changes with other MCUs. But I love assembler.

To me, coding in assembler is like driving a manual drive car where you have full control of the engine while C is like driving an automatic (boring to me) drive car... LOL

Eric007

 

I think @takao21203 you are right about this " You are tied to a particular IC". Personally, I do not see the need to use another MCU. I like PIC and will probably stick with that UNLESS required to use another MCU such as AVR or ARM or ...
The only good thing about C, IMO I think, is that you can reuse the same code with minor changes with other MCUs. But I love assembler.

To me, coding in assembler is like driving a manual drive car where you have full control of the engine while C is like driving an automatic (boring to me) drive car... LOL

Eric007

The important thing about C is the data abstraction. It's inferior to ASM at the bit fiddling level and equal in conditional constructs but the ease at which data can be manipulated, encapsulated and structured is the art of programming that while possible at the ASM level with great care becomes almost an automatic process with C or true high level language. Data flow and structures is what makes C not boring once you get past the boilerplate of I/O.

 

The important thing about C is the data abstraction. It's inferior to ASM at the bit fiddling level and equal in conditional constructs but the ease at which data can be manipulated, encapsulated and structured is the art of programming that while possible at the ASM level with great care becomes almost an automatic process with C or true high level language. Data flow and structures is what makes C not boring once you get past the boilerplate of I/O.

PICs arent really great with bits either. You cant set/reset a bit by index.
I think since the 80386 x86 can do it actually.
Its of course a pain and quite slow to load the bitnumbers via pointers, then manipulate the data with masks.
But if you want to use random IO assignment, you need the tables anyway.

I found C and assembler are very equivalent, with some tradeoff since compilers arent all too smart.
Windows98SE was a Windows edition which still contained some assembler, after that, fundamental changes were made.

Optimizing code at the assembler level isnt happening anymore at Microsoft for quite a long while.
Is it needed? There are so many powerful MCUs recently, small single board computers, which you name it, can run Linux.
No assembler wizardry here either.

I did use assembler. It took weeks for a large source boiling down to 1K or 2K, then memory was full.
Always these mysterious bugs and riddles about memory banking.
Really a serious stopgap to productivity.

So. When we have all these fantastic C compilers, fast 32 bit MCUs, what do we do with this technology?
Well you name it. Design a highly efficient 8080 emulator, use a bad table with function pointers,
and then, dont you guess, write 8080 assembler programs and emulate this old CPU cycle for cycle,
then research the Z80 and think about the improvments it brought.

I havent put much effort into the emulator since, well, Im a little scared to deal with this 8080 assembler, again?

To use the opcode as such as index into a table with function pointers isnt too bad for C, or is it?