Beggining with PIC's

[cne]

Hello,

I am fairly new to PIC's and I was wondering, if I were to learn a programming language, which would be the best to start with. I have some experience in the actual programming of the chips themselves, and building the hardware, and I have a PICkit 2 programmer to do the programming of HEX files to the chip.

Thank you in advance,

Cameron

 

[Nigel Goodwin]

Assembler is really the best, because it's completely free, and it ensures you have to understand the hardware.

 

[Mickster]

Assembler is really the best, because it's completely free, and it ensures you have to understand the hardware.

Cameron,
Don't forget to have a look at Nigel's excellent PIC tutorial page....

 

[colin55]

Higher level languages are really good when you are producing complex designs but if you want to know how a micro can be programmed to its fullest, and see what it is doing, you have to use ASSEMBLY CODE. This is only suitable up to 2k of program. That's up to 20 quarto pages of program.

 

[3v0]

Learning assembler has advantages and gives you a firm foundation regarding THAT processor. But chips with a decent amount of memory are getting cheaper every day and assembly level programing is by far the in minority.

If you do not know any programming language and know little or nothing about microprocessors....

then learning to program assembler for a micro controller can be a lot to take in at once. Especially on a low or mid level PIC.

If that is the case I would suggest learning a higher level language like C on a PC first.

I just wanted you to understand that not everyone is on the same page regarding this issue.

EDIT: I need to clarify this. I love assembler programming but the PIC is a ugly chip at that level. Not enough register and bank switching is enough to keep me away.

We have a few people that do some wonderful stuff in PIC assembler. My hat is off to them.

As an instructor I would rather have people work in a good high level language and learn general programming technique. It will serve them well on any processor or language.

 

[Mosaic]

Going with assembler is important, becuz even using C or PicBasic there WILL be times that a tight assembler routine can deliver the timing u need. Especially so for interrupt handling and communications. If u r into to hardware at all, assembler also gives u good control over your peripherals. Lastly, If u r doing any commercial products, then the cost factor of the time spent doing tight assmbly is amortised over the product distribution count. It is more profitable to use smaller PICs with less RAM in that case.

 

[3v0]

Going with assembler is important, becuz even using C or PicBasic there WILL be times that a tight assembler routine can deliver the timing u need. Especially so for interrupt handling and communications. If u r into to hardware at all, assembler also gives u good control over your peripherals. Lastly, If u r doing any commercial products, then the cost factor of the time spent doing tight assmbly is amortised over the product distribution count. It is more profitable to use smaller PICs with less RAM in that case.

We are talking about learning and not mass production.

Depending of the number of units produced it is often more profitable to use a more expensive processor and code in a high level language.

There is an old saying that a manager should fire a programmer that insists on programming in assembler to keep his (the mangers) job.

 

[Mosaic]

We don't know his reason for learning PICS, he may very well have a commercial purpose. And I disagree that high level languages which require large PIC RAM sizes are more economical when a smaller PIC using assembly is viable. The higher the unit cost, the more it matters when selling hundreds or thousands of units. High level languages are good when RAM and resources are plentiful or for hobby work. Higher languages also insulate the user from the PIC architecture, which can limit true learning about PICs.

 

[Hayato]

Well, this is my little opinion.

The most important thing is to learn programming logic. To achieve that, the easiest way is to use a middle/high level programming language, like C, for example (as 3v0 suggested). And I'm going to say one more thing, start with C for PC, to program with a PC, because within a PC you have everything you need to test and debug your first programs and you just don't have to worry about setting registers, memory manangement, etc.

After you get a good programming mojo, after you see how the "machine" thinks, then you move to the uC and the Assembly.

 

[3v0]

You views had merit about 20 years ago.

We don't know his reason for learning PICS, he may very well have a commercial purpose.

If he has a commerical purpose with the sort of volume the justifies ASM code he should hire a pro!

And I disagree that high level languages which require large PIC RAM sizes are more economical when a smaller PIC using assembly is viable. The higher the unit cost, the more it matters when selling hundreds or thousands of units.

I guess you have never heard about "time to market" or maintainability. If you are only selling a few hundred or thousand units then the time savings provided by the higher level language is very economical. How much programming time can you buy for a few thousand dollars ?

High level languages are good when RAM and resources are plentiful or for hobby work. Higher languages also insulate the user from the PIC architecture, which can limit true learning about PICs.

You have it backwards. It is a good thing to be isolated from the idiotic bank switching and limited register count. Focus on the program and not the chip! As regards to setting up peripherals, understanding the data sheet is far more important then the language used to set the values.

 

[Mosaic]

3v0

As a commercial producer of electronics , I do know about time to market as well as the economics of scale. I have been doing this since 1990 (=20yrs experience) so I believe I have the credentials to have some knowledge of this. I joined this forum to learn about PICs FOR a commercial PURPOSE eventually. I am learning assembly 1st, as the electronics I am involved in requires small size & low power, ergo compact PICS & assembly is the way to go.

Therefore all your arguments are not applicable to my requirements as a PIC beginner, so they may not be applicable to other beginners either. I am wearing the shoes so I know the fit. When u start commercial production for export you might have a chance of understanding. Further I have been published for having produced commercial assembly language utilities for the 6510 C-64 processor back in its day. I know what assembly can accomplish. It might take more effort as a learning curve, but C or Basic cannot compete with assembly for compactness & Speed of code or multitasking via interrupt handling.

Why should I need a 40MHz 18F MCU when a 4MHZ 16F will do? Because C is more convenient? Get over being afraid of bankswitching. You speak like a driver afraid to look under the hood.


I am not interested in hiring a PRO, I intend to be the PRO in PIC assembly.

EDIT: I have nothing more to say on this as this is degenerating and not really helping the original poster.

 

[3v0]

This in its own post in that I would not want to let it get lost in the previous text.

I have programmed in assemblers ranging from simple resource poor micro controllers to the wildly complex and resource rich IBM370's.

I do not care to program exclusively in asm on any machine, especially the ones at the extremes. If I had to pick one it would be the PDP11. There were only a handful of instructions each with a source and destination that could be a register, a memory location pointed to by the register, any one of 7 modes. Once you memorized the instruction codes and addressing modes it was possible to read the code from octal (Like hex but 3 bit groups instead of 4) or even from a paper tape.

Instead of using LOAD and STORE or LOAD_SOME_REG instructions the PDP11 used a MOVE instruction. You could move reg to reg, mem to reg, reg to mem, even load the program counter.

 

[3v0]

Mosaic,

It would be nice had said up front where you were coming from. Your initial post sounded like you were starting from ground zero.

I have retired from programming in industry. Much of that micro controllers. I stand by what I said.

Of course this is application dependent. But the need to write assembler is much smaller then people make it out to be.

In quantity the cost differential between a PIC that is just enough for ASM and one that can do the job in C is not that much. If you time is worth anything to you, how can you afford to program in ASM unless you are coding very simplistic applications.

 

[nsaspook]

Mosaic,

It would be nice had said up front where you were coming from. Your initial post sounded like you were starting from ground zero.

I have retired from programming in industry. Much of that micro controllers. I stand by what I said.

Of course this is application dependent. But the need to write assembler is much smaller then people make it out to be.

In quantity the cost differential between a PIC that is just enough for ASM and one that can do the job in C is not that much. If you time is worth anything to you, how can you afford to program in ASM unless you are coding very simplistic applications.

I hear you. The problem in any large controller project becomes not the bit-wise interface to modules but the data structures that contain the state of process and actions in response to the data generated from those interfaces. It's usually at this point where the thing becomes a buggy mess because sometimes little forethought was put into efficient data structures before.(guilty) A this point C gives you 10X the power to reorganize code/data to a model that can be tested to work properly and can be understood by someone other than the guy who wrote it.

 

[Pommie]

Having wrote code for the smallest pic (10f200) in assembler and the larger ones in both assembler and C, I think that assembler is required in very few applications. For most applications C will produce code that is hard to beat for size and speed. One thing I will state is that people should take the time to learn the hardware rather that rely on libraries or potted routines. The language is irrelevant, what is the difference between,

    PORTB=0b10000000;	//compiles to 9 instructions
    TRISB=0b01111111;   	//in BoostC
    SPBRG=103;
    BAUDCTL.BRG16=1;

and
	movlw	0b10000000        ;is 15 instructions
	banksel	PORTB             ;in MPASM
	movwf	PORTB
	movlw	0b01111111
	banksel	TRISB
	movwf	TRISB
	movlw	d'103'
	banksel	SPBRG
	movwf	SPBRG
	banksel	BAUDCTL
	bsf	BAUDCTL,BRG16

Answer, none, except one is easier to read. Either way, you still need to know the hardware.

BTW, C produces smaller (and therefore faster) code in the above example. Forty percent smaller, go figure.

Edit, added,

It might take more effort as a learning curve, but C or Basic cannot compete with assembly for compactness & Speed of code or multitasking via interrupt handling.

This is simply not true as shown by the example above and C would match asm in interrupt handling as well.

Mike.

 

[Nigel Goodwin]

If you want the best performance, then it's assembler - there's no two ways about it.

Because games on the Amiga were written in assembler (and the hardware was better of course) games running on an 8MHz odd Amiga with 512Kb of RAM out performed PC's running in the 100Mhz range with multi-Mb of RAM.

Writing commercially in a high level language is for cheapness, nothing else - hence the modern set-top boxes that run really slowly, because many run on Java.

 

[Pommie]

If you want the best performance, then it's assembler - there's no two ways about it.

This is simply not true as I demonstrated earlier.

Because games on the Amiga were written in assembler (and the hardware was better of course) games running on an 8MHz odd Amiga with 512Kb of RAM out performed PC's running in the 100Mhz range with multi-Mb of RAM.

You're not comparing apples with apples here. The Amiga had the first accelerated graphics chips and that is why it was ahead of it's time. The blitter chip did all the work and so using C made a lot of sense. Writing to hardware registers is as fast in any language. (Note, the Windoze function for moving pixels around is called BitBlit).

Writing commercially in a high level language is for cheapness, nothing else - hence the modern set-top boxes that run really slowly, because many run on Java.

Sorry, bad example. Had they used C (and someone who could program) then they would fly. They chose a OO language and so it crawls. I'll not go into the OO argument here.

End of the day, any reasonable sized project cannot be economically written in assembler.

Mike.

 

[Gayan Soyza]

There is an old saying that a manager should fire a programmer that insists on programming in assembler to keep his (the mangers) job.

A very well saying.If I resign from the job then the whole project list goes down.

 

[ericgibbs]

hi,
For PIC's I prefer to use assembler, over the years the debugged modules I have written, form the basis of the program.
As the subroutines are written in a modular way and the EQU and INC are standardised its usually a simple matter of using some 'glue' programming to bring the modules into a working program.
After all isn't that what 'C' really is, subroutines and libraries, [probably written in assembler] by some other programmer.??

I am NOT knocking 'C', but from my early comparisons of 'C' versus Assembler in speed and program memory storage, I found that I could write tighter and faster code using assembler.

Having said that, for PC programming which has the speed and memory to spare for running Visual Basic, I use VB5 for its ease for creating working programs.

I think 'mosiac' has a point, why use a Porsche when a Ford will get the job done.

With regarding to teaching programming, 3v0 has IMHO the correct approach, teach the little beggers logic and code flow.

I agree with most of what of Mike says except this line.

End of the day, any reasonable sized project cannot be economically written in assembler.

It boils down to, what works best for the individual..

 

[Nigel Goodwin]

A very well saying.If I resign from the job then the whole project list goes down.

As you 'should' be leaving behind your well commented and documented source code, it should be relatively easy to replace you with any competent programmer.