The one subject that rears its ugly head from time to time and is always a catalyst for a heated debate is “which programming language to use for PICs”, and I am talking about only PICs here, though this is probably the same for many of the embedded type CPUs available.
Assembler is the best to use as it allows the developer to get as close to the PIC hardware as possible, gives the most flexibility and offers the best performance, and this is true… to a point.
It’s also the most complicated as many simple tasks require a lot of assembler instructions, so there’s more you have to type, so more you can get wrong. On the flip side, you have the opportunity to fine tune the program and validate the need for every instruction within your program. Another problem is that every CPU manufacturer has their own assembler and instruction set and it can be a real pain moving from one CPU manufacturer to another. Often, the same manufacturers often use different assemblers and instruction sets for different CPUs that they make.
For the best performance and the tightest control, in the hands of a highly skilled programmer you can’t beat assembler, but you have to know exactly what your doing and you stand an equal chance of creating slow, bloated and buggy code.
“C” – is a higher level language than Assembler which means that it shields the programmer from some of the nitty gritty issues that Assembler has. It’s easy to read but like any programming language, if you don’t know what you’re doing, you can make a complete pigs ear of things.
The advocates of “C” will brandish around phrases and words like “ANIS compatible”, and portable. Unfortunately, in the PIC world, one also has to brandish around the word “rubbish” as well. “C” as a programming language has only a few instructions associated with it. Most of the really cool features like talking to the A2D ports or the I2C hardware within the PIC are actually performed by 3rd party libraries; there is NO native support within the "C" language for this. Usually supplied with the language installation, some of these libraries are written in Assembler, some written in “C” but they aren’t standard across all “C” implementations. This means that “C” from Microchip is different from the “C” version from FED so you can’t just cut and paste source code and watch it re-compile without a page full of warnings or errors.
Now my favourite, BASIC.
I can hear the groans and moans about how BASIC is slow and bloated. RUBBISH !!!!
BASIC comes in two main flavours; compiled or interpreted. Interpreted BASIC’s are usually slower than compiled languages and that’s a fact, but you get a bit more flexibility. For example, you don’t always need a PC (or a PIC programmer) to program a PIC that’s running interpreted BASIC; a dumb terminal will often suffice. (Yes, you can get boot-loaders, but they still usually need a PC unless you use a PICKIT with it's on-the-go programming feature and these don't allow you to develop new code; just flash the device with a pre-built HEX file).
Also, interpreted programs are often simpler to debug as you can stop them mid way through execution and look at variable contents. However, speed and code size are usually more important than ease of development once you've passed the pure beginner stage.
Compiled BASICs are no slower than “C” programs and I’ve timed them to prove it !!
All the “C” compilers that I’ve found work in the same way. They parse your “C” source code, spit out a file containing PIC assembler, and then pass that assembler to the standard Microchip assembler to generate the .HEX file for the PIC. And why not? There's no point creating your own assembler as the Microchip one is maintained by the supplier, is free, and rather good at what it does.
The BASIC compilers tend to work in exactly the same way.
The ONLY thing that makes one compiler better than another is the tightness of the assembler code it produces and the quality of the associated libraries and code optimiser and this rule is programming language independant. I compared Proton+ BASIC with Microchip “C” and found no difference in the speed of execution for some simple tasks. Some differences were noted when using some library routines and there were swings and roundabouts with both.
Yes, it’s possible to write slow and bloated code in BASIC, but that’s also true in “C” or any programming language.
Some of the cool features like bit manipulation that are common in "C" but not often found in PC type BASICs are fully supported in PIC BASICs.
The bottom line is find a programming language you like, learn it well, and you should be able to write fast and efficient code.
The "thing" about BASIC; nobody expects it to be portable or "standard".
Assembler is the best to use as it allows the developer to get as close to the PIC hardware as possible, gives the most flexibility and offers the best performance, and this is true… to a point.
It’s also the most complicated as many simple tasks require a lot of assembler instructions, so there’s more you have to type, so more you can get wrong. On the flip side, you have the opportunity to fine tune the program and validate the need for every instruction within your program. Another problem is that every CPU manufacturer has their own assembler and instruction set and it can be a real pain moving from one CPU manufacturer to another. Often, the same manufacturers often use different assemblers and instruction sets for different CPUs that they make.
For the best performance and the tightest control, in the hands of a highly skilled programmer you can’t beat assembler, but you have to know exactly what your doing and you stand an equal chance of creating slow, bloated and buggy code.
“C” – is a higher level language than Assembler which means that it shields the programmer from some of the nitty gritty issues that Assembler has. It’s easy to read but like any programming language, if you don’t know what you’re doing, you can make a complete pigs ear of things.
The advocates of “C” will brandish around phrases and words like “ANIS compatible”, and portable. Unfortunately, in the PIC world, one also has to brandish around the word “rubbish” as well. “C” as a programming language has only a few instructions associated with it. Most of the really cool features like talking to the A2D ports or the I2C hardware within the PIC are actually performed by 3rd party libraries; there is NO native support within the "C" language for this. Usually supplied with the language installation, some of these libraries are written in Assembler, some written in “C” but they aren’t standard across all “C” implementations. This means that “C” from Microchip is different from the “C” version from FED so you can’t just cut and paste source code and watch it re-compile without a page full of warnings or errors.
Now my favourite, BASIC.
I can hear the groans and moans about how BASIC is slow and bloated. RUBBISH !!!!
BASIC comes in two main flavours; compiled or interpreted. Interpreted BASIC’s are usually slower than compiled languages and that’s a fact, but you get a bit more flexibility. For example, you don’t always need a PC (or a PIC programmer) to program a PIC that’s running interpreted BASIC; a dumb terminal will often suffice. (Yes, you can get boot-loaders, but they still usually need a PC unless you use a PICKIT with it's on-the-go programming feature and these don't allow you to develop new code; just flash the device with a pre-built HEX file).
Also, interpreted programs are often simpler to debug as you can stop them mid way through execution and look at variable contents. However, speed and code size are usually more important than ease of development once you've passed the pure beginner stage.
Compiled BASICs are no slower than “C” programs and I’ve timed them to prove it !!
All the “C” compilers that I’ve found work in the same way. They parse your “C” source code, spit out a file containing PIC assembler, and then pass that assembler to the standard Microchip assembler to generate the .HEX file for the PIC. And why not? There's no point creating your own assembler as the Microchip one is maintained by the supplier, is free, and rather good at what it does.
The BASIC compilers tend to work in exactly the same way.
The ONLY thing that makes one compiler better than another is the tightness of the assembler code it produces and the quality of the associated libraries and code optimiser and this rule is programming language independant. I compared Proton+ BASIC with Microchip “C” and found no difference in the speed of execution for some simple tasks. Some differences were noted when using some library routines and there were swings and roundabouts with both.
Yes, it’s possible to write slow and bloated code in BASIC, but that’s also true in “C” or any programming language.
Some of the cool features like bit manipulation that are common in "C" but not often found in PC type BASICs are fully supported in PIC BASICs.
The bottom line is find a programming language you like, learn it well, and you should be able to write fast and efficient code.
The "thing" about BASIC; nobody expects it to be portable or "standard".
RSS Feed