The Godfather talking
This is god damn my place! Capisci?
Sonsivri
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
November 26, 2024, 02:37:59 02:37


Login with username, password and session length


Pages: [1]
Print
Author Topic: Speed difference of used Programming Language  (Read 5965 times)
0 Members and 1 Guest are viewing this topic.
0815achim
Junior Member
**
Offline Offline

Posts: 50

Thank You
-Given: 224
-Receive: 25


« on: January 28, 2008, 01:50:53 13:50 »

Hi!
Is there an difference in the speed of the programms, depending on the Language there are written with?
What i mean is...
On a PC, a application that was written in Basic is much slower than an application that was written in pure Assembler.
Is this the same on Pic Languages?

Thanks...
0815achim
Logged
robban
Senior Member
****
Offline Offline

Posts: 265

Thank You
-Given: 34
-Receive: 38


Warrior


WWW
« Reply #1 on: January 28, 2008, 03:11:31 15:11 »

Yeah, sure it is...
All high-level languages(BASIC C/C++ Pascal or whatever) are built with assemblers and use standars libraries, so if You want to build fast, hardware specific and efficient code, You must use assembly. For the PIC and other MCU:s, they are only 8-bits so it's not that hard to learn. Microchip has started out with 32-bit processors, but why switch from Intel?
Logged

Code Warrior
0815achim
Junior Member
**
Offline Offline

Posts: 50

Thank You
-Given: 224
-Receive: 25


« Reply #2 on: January 28, 2008, 04:48:53 16:48 »

Thank you very much vor your quick answer.

That's exactly what i want to know.

I would try to learn how to program the pic in assembler.
Simply for better understanding what happens inside the PIC.

Greetings...
0815achim
Logged
klivi1
Guest
« Reply #3 on: January 29, 2008, 08:59:20 08:59 »

Using assembler is a little bit painful... I think it is worse to know the basics (assembler) but you defenetly need some high level languages if you want to optimize the development time. E.G. using arithmathic in assembler even floating point number would be a nightmare.

Anyway I also have a question: what are the speed differences between  mikroC/mikroPascal/mikroBasic/HITECH-C etc. ? It would be useful to know.

Thanks
Logged
robban
Senior Member
****
Offline Offline

Posts: 265

Thank You
-Given: 34
-Receive: 38


Warrior


WWW
« Reply #4 on: January 29, 2008, 11:40:47 11:40 »

I would'nt worry so much about speed here and speed there. If You master assembler, You not only get a good understanding of the MCU but also a better understanding of high-level languages.

Here's a link containing MPASMsuite complete with a bunch of code snippets and helpfiles

http://rapidshare.com/files/87515079/MPASMAssembler.rar.html

Enjoy!
Logged

Code Warrior
twonuts
Active Member
***
Offline Offline

Posts: 117

Thank You
-Given: 55
-Receive: 42


« Reply #5 on: January 31, 2008, 10:42:48 22:42 »

High level pic languages use compilers to convert the high level language to assembler. Different compilers will not all produce identical assembler. ie some will create larger assembler files than others. This means there will be differences in the execution times of the different pieces of code created by the different compilers. So the answer to your question is yes.

Unless you are prepared to spend a more than a fair amount of time learning to program in assembler, I would go for one of the high level languages. These, especially basic, make it very easy to develop, and read, your program. A simple mistake (bug)  in your assembler program can be a nightmare to find.   
Logged
sohel
Senior Member
****
Offline Offline

Posts: 442

Thank You
-Given: 167
-Receive: 149



« Reply #6 on: March 10, 2008, 01:21:37 01:21 »

i think asm is not painfull. all compiler goes to asm. u can create macro or lib . like 35 instruction and 1000 in basic.  sorry if iam wrong.
Logged
hemlig
Translator
Active Member
***
Offline Offline

Posts: 168

Thank You
-Given: 26
-Receive: 50



« Reply #7 on: March 10, 2008, 03:23:12 03:23 »

It is also possible to use an hex editor to make the .hex directly but that would be painful
at least for larger applications Smiley

You could look at a high level language as if every high level command is a template of
appropriate asm instructions (collected from macro and lib) and merged together by the compiler
to the final hex ready to send to the MCU.
Logged

If it work don't fix it!
mhayball
Guest
« Reply #8 on: March 12, 2008, 11:35:57 23:35 »

Also depends on exactly what you want to do.  I have run small programs and programmed in ASM and using Picbasic Pro for comparision, and found very little difference.  If you are wanting precision timing then you are far better off using ASM as you can use the micros instruction cycle time whereas Picbasic can be inaccurate.  If you just want to flash an LED or integrate to an eeprom then I have written many routines without having to resort to ASM, it is faster turnaround time and less errors.  If you are familiar with ASM then go for it, but if you know Basic then you can do 95% of what you need with little or no compromise.

Logged
gedonet
Newbie
*
Offline Offline

Posts: 7

Thank You
-Given: 20
-Receive: 3


« Reply #9 on: March 13, 2008, 05:00:48 05:00 »

Hi
I think you must know very well your picbasic compiler options to have a fast program in the pic, but it will not be so fast than with pure assembler.
The assembler have only 35 instructions to learn, its not very difficult.
Gilles
Logged
iguana
Guest
« Reply #10 on: March 13, 2008, 10:09:32 10:09 »

As far as speed and compactness goes its (fastest first)

1 Proton
2 Swordfish
3 Pbpro
4 MikroEBasic

I doubt there are many people who can match the asm coding of Proton or SF let alone some of the C compilers  (real not Mikro offerings) .

But saying that nobody cares as I have seen that most people write the biggest load of crap with no regard to what is happening underneath. It makes no difference how good the compiler is, most people will just think if it compiles its good enough.

Like I said before have a set of bench mark tests. But really you will find some advocates of certain compilers will not partake in a trial as there compiler will be shown up to be the dog it really is or they just cannot do the job.




Logged
ArySoft
Inactive

Offline Offline

Posts: 5

Thank You
-Given: 4
-Receive: 1


« Reply #11 on: March 13, 2008, 04:37:38 16:37 »

1 Picbasicpro
A.L
Logged
mhayball
Guest
« Reply #12 on: March 18, 2008, 11:20:04 23:20 »

I completely agree with Gilles.  The fastest is assembler which is why purists will use this for optimum efficiency and speed.  Of course, it is the programmer themself that dictate how fast a program will run.  You are right - I have spent a lot of time with Picbasic, around 8 years using it, and code very efficiently with it, but there are some applications that ASM has to be used.  I only use Picbasic because I am familiar with the language and can develop a program within minutes whereas my knowledge is limited with ASM and find myself introducing programming errors.  As I said earlier, if you want to program using maximum speed, and you can actually get the benefits from this through correct program structure then ASM is the way to go.  Unfortunately a lot of people like myself find ASM syntax can get confusing when trying to debug so I stick with Picbasic for most apps, even if they need some speed.  You can get programs to run faster in Picbasic by writing the code for a 4MHz xtal and just run the pic at 20MHz, although timings have to be recalculated to suit.  Yes, this is cheating but it has worked wonders for me  Smiley
Logged
ez
Guest
« Reply #13 on: March 20, 2008, 04:54:15 04:54 »

That is an interesting tip I never thought of.  Can you elaborate a but more on the timings aspect?  Are you talking about adjusting PWM values for the speed difference?

Thanks,
Ethan

I completely agree with Gilles.  The fastest is assembler which is why purists will use this for optimum efficiency and speed.  Of course, it is the programmer themself that dictate how fast a program will run.  You are right - I have spent a lot of time with Picbasic, around 8 years using it, and code very efficiently with it, but there are some applications that ASM has to be used.  I only use Picbasic because I am familiar with the language and can develop a program within minutes whereas my knowledge is limited with ASM and find myself introducing programming errors.  As I said earlier, if you want to program using maximum speed, and you can actually get the benefits from this through correct program structure then ASM is the way to go.  Unfortunately a lot of people like myself find ASM syntax can get confusing when trying to debug so I stick with Picbasic for most apps, even if they need some speed.  You can get programs to run faster in Picbasic by writing the code for a 4MHz xtal and just run the pic at 20MHz, although timings have to be recalculated to suit.  Yes, this is cheating but it has worked wonders for me  Smiley
Logged
twonuts
Active Member
***
Offline Offline

Posts: 117

Thank You
-Given: 55
-Receive: 42


« Reply #14 on: March 22, 2008, 12:11:33 12:11 »

Instead of writing code for 4MHz and then running at 20MHz, why not just simply write the code for 20MHz and run at 20MHz? It is fairly obvious, using simple mathematics  that code will run 5* faster if you use a crystal frequency which is 5* higher. (20/4 = 5 * faster program instruction execution).
Using the method described, using the 'overclocking' crystal frequency,  means the code for RS232, PWM, and all functions which are time critical will need to have modified code for the faster crystal frequency to run properly. More bother than it is worth with the potential for error exponentially increased.

High level languages are intended to make program writing easier, and also easier to read and debug. A good compiler will have optimised code creation, meaning that the compiler will produce consistently reproducable minimal code which is, or should be , reliable and bug free.

I agree that there are still some times where the use of assembler is still necessary, where the high level language or compiler does not provide the exact functionality the program writer requires. That said, some languages, such as Proton, allow the use of in line assembler in the program. This means you get the best of both worlds. High level language AND/OR assembler as desired.
Logged
ez
Guest
« Reply #15 on: March 22, 2008, 06:29:01 18:29 »

Ah yes that make sense as well!  I'll have to experiment a bit with this...

Instead of writing code for 4MHz and then running at 20MHz, why not just simply write the code for 20MHz and run at 20MHz? It is fairly obvious, using simple mathematics  that code will run 5* faster if you use a crystal frequency which is 5* higher. (20/4 = 5 * faster program instruction execution).
Using the method described, using the 'overclocking' crystal frequency,  means the code for RS232, PWM, and all functions which are time critical will need to have modified code for the faster crystal frequency to run properly. More bother than it is worth with the potential for error exponentially increased.

High level languages are intended to make program writing easier, and also easier to read and debug. A good compiler will have optimised code creation, meaning that the compiler will produce consistently reproducable minimal code which is, or should be , reliable and bug free.

I agree that there are still some times where the use of assembler is still necessary, where the high level language or compiler does not provide the exact functionality the program writer requires. That said, some languages, such as Proton, allow the use of in line assembler in the program. This means you get the best of both worlds. High level language AND/OR assembler as desired.
Logged
gedonet
Newbie
*
Offline Offline

Posts: 7

Thank You
-Given: 20
-Receive: 3


« Reply #16 on: March 23, 2008, 05:04:40 05:04 »

That is an interesting tip I never thought of.  Can you elaborate a but more on the timings aspect?  Are you talking about adjusting PWM values for the speed difference?

Thanks,
Ethan

Hi
You can olso use some pic like 16F88 with internal oscillator, the speed can change during the program run from 31.25 kHz to 8 MHz with 8 steps, with IRCF<2:0>bits of OSCCON register . Some speed change need a delay for changing speed so the bit IOFS of OSCCON register indicate the oscillator stability.
Excuse me for my language, i'm not english
Gilles
Logged
ez
Guest
« Reply #17 on: March 23, 2008, 05:23:38 05:23 »

That's ok thanks!  I think I understand.  This allows for more adjustability from both the hardware and code sides of it...

Hi
You can olso use some pic like 16F88 with internal oscillator, the speed can change during the program run from 31.25 kHz to 8 MHz with 8 steps, with IRCF<2:0>bits of OSCCON register . Some speed change need a delay for changing speed so the bit IOFS of OSCCON register indicate the oscillator stability.
Excuse me for my language, i'm not english
Gilles
Logged
mhayball
Guest
« Reply #18 on: March 24, 2008, 11:38:03 23:38 »

Picbasic command structure assumes you are using a 4MHz oscillator.  If you use a different frequency then you have to define the oscillator value in your program, however if you don't define it then some commands will run a lot faster than expected.  I use this to generate higher frequencies from the pic than you normally could.  Example, if you use commands like 'sound' then if you don't define the osc the sound output will be much higher than if you had defined the osc.  Great fun to play around with.
Logged
JohnnyT
Inactive

Offline Offline

Posts: 5

Thank You
-Given: 10
-Receive: 0


« Reply #19 on: March 25, 2008, 01:18:45 01:18 »

Picbasic command structure assumes you are using a 4MHz oscillator.  If you use a different frequency then you have to define the oscillator value in your program, however if you don't define it then some commands will run a lot faster than expected.  I use this to generate higher frequencies from the pic than you normally could.  Example, if you use commands like 'sound' then if you don't define the osc the sound output will be much higher than if you had defined the osc.  Great fun to play around with.

When you define then PIC running frequency for your compiler it is only used to produce automaticaly correct time delays, baud rates, critical timings for various internal algorithms.
What you are doing is simply meaningless because you do not really gain anything but only losing all these automatic calculaions.

For example... I define 4Mhz clock, and program a loop to toggle a led and I put a 1 sec delay between each toggle. Then I run the real PIC in 20Mhz and like a miracle the led toggles each fifh of a second !!!!  We really showed that compiler who is the boss!!! Why don't you put 200ms delay in the first place and define 20Mhz clock?

It only makes sense when a particular command does not accept as high a value as you would like. But maybe there is a reason for it...

I do not want to offend anyone... I just believe that logic has a flaw...
Logged
ez
Guest
« Reply #20 on: March 25, 2008, 03:02:24 03:02 »

Hmmm...that makes sense.  More to think about for sure...

When you define then PIC running frequency for your compiler it is only used to produce automaticaly correct time delays, baud rates, critical timings for various internal algorithms.
What you are doing is simply meaningless because you do not really gain anything but only losing all these automatic calculaions.

For example... I define 4Mhz clock, and program a loop to toggle a led and I put a 1 sec delay between each toggle. Then I run the real PIC in 20Mhz and like a miracle the led toggles each fifh of a second !!!!  We really showed that compiler who is the boss!!! Why don't you put 200ms delay in the first place and define 20Mhz clock?

It only makes sense when a particular command does not accept as high a value as you would like. But maybe there is a reason for it...

I do not want to offend anyone... I just believe that logic has a flaw...
Logged
Pages: [1]
Print
Jump to:  


DISCLAIMER
WE DONT HOST ANY ILLEGAL FILES ON THE SERVER
USE CONTACT US TO REPORT ILLEGAL FILES
ADMINISTRATORS CANNOT BE HELD RESPONSIBLE FOR USERS POSTS AND LINKS

... Copyright © 2003-2999 Sonsivri.to ...
Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines LLC | HarzeM Dilber MC