From Assembly to C

Discussion in 'Embedded Systems and Microcontrollers' started by Eric007, Aug 27, 2015.

  1. Eric007

    Thread Starter Senior Member

    Aug 5, 2011
    1,041
    33
    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
     
  2. djsfantasi

    AAC Fanatic!

    Apr 11, 2010
    2,794
    829
    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.
     
    Eric007 likes this.
  3. Eric007

    Thread Starter Senior Member

    Aug 5, 2011
    1,041
    33
    Thank you for your reply!

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

    Eric007
     
  4. atferrari

    AAC Fanatic!

    Jan 6, 2004
    2,645
    759
    15 minutes or 6 hours but...did it work? :p
     
  5. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,163
    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.
     
    Last edited: Aug 27, 2015
    Eric007 likes this.
  6. Eric007

    Thread Starter Senior Member

    Aug 5, 2011
    1,041
    33
    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.
     
  7. Eric007

    Thread Starter Senior Member

    Aug 5, 2011
    1,041
    33
    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 ...
     
  8. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,163
    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.
     
  9. Eric007

    Thread Starter Senior Member

    Aug 5, 2011
    1,041
    33
    @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!
     
  10. Art

    Distinguished Member

    Sep 10, 2007
    785
    61
    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.
     
  11. djsfantasi

    AAC Fanatic!

    Apr 11, 2010
    2,794
    829
    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;
     
  12. Art

    Distinguished Member

    Sep 10, 2007
    785
    61
    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
    Code (C):
    1.  
    2. //
    3. void shift_left() { // bitwise rotate array left once
    4. for (index=0 ; index<50 ; ++index) {
    5. disarray[index] = (disarray[index+1] >> 7) | (disarray[index] << 1);
    6. } // index
    7. disarray[50] = 0 | (disarray[50] << 1);
    8. }
    9. //
    10.  
     
    Last edited by a moderator: Aug 30, 2015
  13. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,163
    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.
     
  14. joeyd999

    AAC Fanatic!

    Jun 6, 2011
    2,674
    2,717
    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.

    ;)
     
  15. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    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?
     
    Eric007 likes this.
  16. Eric007

    Thread Starter Senior Member

    Aug 5, 2011
    1,041
    33
    Sound very interesting!:) Can't wait to experiment that. Probably in a few days as I am busy C# coding.

    Thanks a lot!
     
  17. joeyd999

    AAC Fanatic!

    Jun 6, 2011
    2,674
    2,717
    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):

    Code (ASM):
    1.  
    2.     pushfl    x    ;put x on stack    
    3.     call    pushcp    ;  and a copy
    4.  
    5.     poly    fmnum    ;compute numerator polynomial -- value on stack
    6.     call    swapxy    ;swap numerator and x
    7.     poly    fmden    ;compute denominator polynomial -- value on stack
    8.     call    divf    ;divide -- result on stack
    9.  
    10.     popfl    y    ;get result from stack
    11.  
     
    Eric007 likes this.
  18. Eric007

    Thread Starter Senior Member

    Aug 5, 2011
    1,041
    33
    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
     
  19. nsaspook

    AAC Fanatic!

    Aug 27, 2009
    2,907
    2,163
    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.
     
    Eric007 likes this.
  20. takao21203

    Distinguished Member

    Apr 28, 2012
    3,577
    463
    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?
     
    nsaspook likes this.
Loading...