Hello.
I have recently purchased a pickit 2 and a few 16f pics. I began learning from a website, some instructions in asm. Now I have read a little more I think I get that the general idea of c is that a lot less lines are needed for c and instructions will be converted into asm by a chosen software like mplab. Please correct me if I am wrong.

I want to use a pic to generate two variable pmw to be controlled by tact switches. I believe that this would be a relatively simple matter for an experienced person and so I wonder... should I carry on with asm just to use for this project or should I scrap the idea and just go with c? please could those with experience please post opinions? Thank you for reading, any input is much appreciated.

 

It is mainly a question of personal preference, try both, with PIC's with limited memory it is possible to run out of space earlier with C.
BTW, if not already aware, the Pickit 2 has the logic analyzer and signal generator when using the stand-alone Pickit-2 v2.61 program.
The logic analyzer is useful when trouble shooting or displaying a PWM output.
I would also recommend graduating to the 18f, especially if going with assembler, it makes for easier and a few more powerful programing instructions.
There is a Nigel Goodwin Tutorial for assembler with 16f.
Max.

 

MPLAB is the IDE, the development environment.

The compiler (e.g. XC8, Hi-Tech C, PIC BASIC Pro, etc.) Is responsible for taking the higher level language, C and BASIC, and converting it to the lower level assembly that is then converted to the machine code that the PIC understands.

I think it is important to understand how the PIC operates before moving on to C, that way, you can understand the differences and drawbacks of each method.

If you need two individual, hard-timed PWM signals and the PIC you've chosen doesn't have two hardware CCP modules, then I'd recommend ASM, as your PWM will probably be generated in software. However, if your timing isn't too critical, or is much slower than the processor's execution speed, then C would probably be easier.

 

You are almost correct in what you say, C gets compiled to machine code not ASM - which could be thought of as human readable machine code. Machine code is the raw bytes that the processor reads from memory and executes. However that is just a bit of hair splitting really.

The other thing you need to consider is that the free versions of the C compilers have many of the optimistions disabled to encourage you to spend some money. What this means is that the compiled C program could be quite a bit larger than the equivalent ASM version (depending a bit on how good you are at coding in each language). So on a PIC with a small program memory ASM could be a better choice than C.

 

You are wrong.

The number of lines comparison is not appropriate here.

 

You are wrong.

The number of lines comparison is not appropriate here.

I'd disagree. The amount of work required to accomplish a task is always important. In this case, the number of lines written correlates with the amount of work required to realize a solution.

In general, C requires less lines - read developer effort and time - than an equivalent ASM program.

Considering the OP has stated this, it seems clear the OP values the time and effort put forth.

 

I'd disagree. The amount of work required to accomplish a task is always important. In this case, the number of lines written correlates with the amount of work required to realize a solution.

In general, C requires less lines - read developer effort and time - than an equivalent ASM program.

Considering the OP has stated this, it seems clear the OP values the time and effort put forth.

To quote Bruce Eckel: "C is an abstraction of assembly."

 

To quote Bruce Eckel: "C is an abstraction of assembly."

I'm missing how that implies the point is moot..

 

To quote Bruce Eckel: "C is an abstraction of assembly."

Which usually means less complexity (software abstractions usually hide details) to get the same result.

http://en.wikipedia.org/wiki/Abstraction_(computer_science)

 

... the number of lines written correlates with the amount of work required to realize a solution ...

I am writing a big program, and, believe it or not, I got into a habit of measuring my progress by a number of lines I wrote. That's a lot of fun!

Of course, there's a correlation between the number of lines and amount of work. It is much more work to write 100,000 lines than to write 10, but other than that the correlation is very weak. When I write easy parts and use lots of copying and pasting, the number of lines grows like crazy. When I go through a tough stuff, with lots of hard and dreadful work, the number of lines doesn't increase so much, sometimes even decreases

 

Ok guys, thank you for your replies so far, and some interesting info and viewpoints. I did not already know that pickit 2 comes with a logic analyser function coooool! Lets say that I have 16f628A a 16f627 and a 16f88 that I chose simply because I have found tutorials based around them. I have not yet looked at the data sheets so I am not sure of what can be done in hardware but in any case I would like to generate the 2 x pwm in software, so the end result is a great combo of my two goals. 1, to have my pwm to add to my project, and 2, to have gained a little knowledge and experience along the way. So if I am to choose a language to do this, (also considering that I am using free softwares if indeed that will make a deal of difference) I need to chose the right path to find the best possible balance of:

Knowledge gained.

Reward for time invested, depending on how good of a book or tutorial I can find.

And ease of use, and ending up with a working code.

Is it possible to tell how large or small a set of instructions in asm or c for this application would be... relatively speaking?
Thank you guys for all of your help. Please bare with me as I try to make sense of all this information in order to make the best choice as so far I have seen only that it seems to really be about preference. I am trying to get an idea of peoples reason for preferring one or the other so I may have a head start in choosing what I may prefer based on to what aspects of an individuals preference sounds good to me. Once again, thanks guys

 

The PICs that you have bought only have 1 CCP module, so it'll be easy to generate a single PWM - as easy as setting PWM parameters.

If you need two separate PWMs, it would be better for you to buy a PIC which has 2 or more CCP modules.

If you want to stay with one of your PICs, you will have to bang PWM manually, which is not hard to do unless the PWM frequency is too high.

 

These PICs dont have large memories, they are dated.

I recommend for instance 16F1824, and 16F1709.
Much larger memory.

I used assembler for years, but in the end I regretted it, way too much effort.
In C language simply the number of lines is much smaller, and you can modularize easier, no manual banking, and you can make major changes quickly without to risk your program no longer works.

Maybe play a little with assembler, then change over to C.

The missing optimizations dont really make a difference, simply, buy a PIC with more memory and faster speed.

Change to 18F and PIC32 as soon as possible.

Well I actually still use 16F PICs for small test circuits. But dont try to squeeze too much out of a 16F PIC.

18F have more MHz.
There is also 24F, just harder to configure, but with MPLABX, it is also not really difficult. Most things work on default setting.

PIC32 even have more MHz, 80 MHz in a small TQFP44 or TQFP64, and that's still easily possible to solder yourself.

Or try the new 16F1454, it has USB, and therefore, a large FLASH memory, could be used without USB too. It's a 14pin IC.

Assembler is good upto 4 KByte FLASH, but for larger programs you run into trouble, at best, you end up with 30 individual source files. After a year or two, you'd find it hard to understand again your own code.

 

Don't get discouraged, there are still many that program in assembler, and the progression to 18f is good advice, I just implemented a PWM DC motor reverser using the ECCP modules in a 18F23K22, these have quite a few multiplexed pins for lower pin count optimization.
Max.

 

Thanks for your replies guys. I am reading, Programming 8 bit pic microcontrollers in c, that I found as a free download pdf. I have read that 16f pics have an instruction set of 35, how do the instructions differ for say, an 18f? And what are the differences between programming an 14 bit or an 8 bit pic? Thanks for your replies

 

The 18f instruction set is around 72 instructions, no page boundaries and much easier table reference instructions, any length,any where etc, bit toggle, set file, prioritized interrupts, and a few other more powerful instructions.
Max.

 

These PICs dont have large memories, they are dated.

I recommend for instance 16F1824, and 16F1709.
Much larger memory.

I used assembler for years, but in the end I regretted it, way too much effort.
In C language simply the number of lines is much smaller, and you can modularize easier, no manual banking, and you can make major changes quickly without to risk your program no longer works.

Maybe play a little with assembler, then change over to C.

The missing optimizations dont really make a difference, simply, buy a PIC with more memory and faster speed.

Change to 18F and PIC32 as soon as possible.

Well I actually still use 16F PICs for small test circuits. But dont try to squeeze too much out of a 16F PIC.

18F have more MHz.
There is also 24F, just harder to configure, but with MPLABX, it is also not really difficult. Most things work on default setting.

PIC32 even have more MHz, 80 MHz in a small TQFP44 or TQFP64, and that's still easily possible to solder yourself.

Or try the new 16F1454, it has USB, and therefore, a large FLASH memory, could be used without USB too. It's a 14pin IC.

Assembler is good upto 4 KByte FLASH, but for larger programs you run into trouble, at best, you end up with 30 individual source files. After a year or two, you'd find it hard to understand again your own code.

As already explained here http://forum.allaboutcircuits.com/showpost.php?p=742637&postcount=18 disagree that Assembler is more complicated than C in any way, and I am working on much larger projects than 4 KB without 30 individual source files.

 

As already explained here http://forum.allaboutcircuits.com/showpost.php?p=742637&postcount=18 disagree that Assembler is more complicated than C in any way, and I am working on much larger projects than 4 KB without 30 individual source files.

I wrote a 300K assembler source some day for 8086 and until some years ago, I also liked assembler.

Problem is, every assy whiz is cooking his own brew, and you'd find it very hard to read into some unorthodox spelling. some bits are shuffled 3 pages before, and how does it interact?

As it is not a structured language at all, even smaller assy programs written by amateurs and semi professionals will be very messy.

Even if you put a lot of structure into it, even emulate C features such as stack frame and function calls, you'll find yourself hunting bugs too much.

Source length is 5x to 10x, and also you can pack C, more than one statement into a line.

there is no real benefit, the C compiler produces the assy code you tell it to produce, with suitable statements supported natively.

C is an automated means to produce assembler, and give it structure.

2

Why relearn all the Mnemonics and banking for each chip series?
With C, you have a standard, and it will compile on 8bit, 16bit and 32 bit chips.

Use a special instruction, your code will never have a chance to be portable.

 

I don't wish to get into yet another C vs. asm debate.

With that said, here is my beef wrt embedded C:

1. The code you write is dependent upon a particular compiler (and, possibly, a particular version of that compiler). Assembly builds today, tomorrow, and ten years from now.

2. Each vendor has its own set of libraries, function names, and calling conventions. Live by the vendor, die by the vendor.

3. Generally speaking, vendor libraries, especially those for hardware interfaces, suck. Most that I've seen are blocking routines that don't exit till the hardware has completed its job.

4. You have to trust the vendor!

5. Why does embedded C insist on procedural math (in spite of the fact that that is a C standard)? Stack based math -- think RPN vs. infix notation -- is far simpler for a small processor to implement, and executes faster.

 

With C, you have a standard, and it will compile on 8bit, 16bit and 32 bit chips.

If you look at this forum (and other ones dealing with MCUs) you will find hundreds of people who got a working program from somehere and they cannot make it work on the same controller it was written for, yet alone on another architecture.